Kargo-kült programlama tutumuyla nasıl başa çıkabilirim?

Bazı bilgisayar bilimi öğrencilerim, bir programlama dilini bir sihir dizisi olarak gören, bazı efektler elde etmek için atılması gereken (bir çözüm fikrini ifade etmek için esnek bir araç olarak görmekten ziyade) bir programlama dili olarak gören zorunlu bir giriş programlama kursuna sahibim. .

Sorunun özünü düşünmeden önceki, benzer görünüşlü ödevlerden kodu kopyalayıp yapıştırma eğilimindedirler.

Bu öğrencileri, yazdıkları her kod parçasının yapısını ve anlamını anlamaları ve anlamaları gerektiğinden emin olmaları için bazı alıştırmalar veya analojiler var mı?

Onlara, her biri bir önceki ek binaya eklenirken veya soruna büküm eklerken veya konuyu farklı bir bakış açısıyla inceleyen, bir önceki çözümün zayıflığını ortaya çıkaran, yeni ve farklı bir yaklaşım gerektiren bir dizi alıştırma sunabilirsiniz. . Bu, hazır bir kod parçasını kopyalayıp yapıştırmak yerine, her çözümle ilgili düşünmeye, analiz etmeye, değiştirmeye ve denemeye zorlar.

Başka bir olasılık - kesinlikle bir programlama görevi olmasa da - onlardan çeşitli şeyleri tahmin etmelerini istemek . Örneğin, Mississippi deltasında saniyede ne kadar su akıyor? Bu tür soruların kesin bir cevabı yoktur, çünkü özellikle birinin inandırıcı (değer) bir değere ulaşmak için belli varsayımlarda bulunması gerekir. Ve - bu "klasik" olanların birçoğunun cevapları gerçekten de googled olsa da - internette herhangi bir yerde (henüz) bulunmayan yenileri kolayca oluşturabilirsiniz.

Bu iki alıştırma türünün örnekleri, örneğin Jon Bentley tarafından Programlama İncileri'nde bulunabilir . Ayrıca Pragmatik Programcının bazı zorlukları var.

Üçüncü tür bir görev, içinde bulmaları ve düzeltmeleri gereken (bir veya daha fazla) böcek içeren bir kod parçası sunmaktır. Bu da tekrar onları analitik becerilerini ve programın gerçekte nasıl çalıştığına ilişkin sebeplerini kullanmaya zorlar.

Güncelleme

Billy ONeal tarafından yapılan bir yorumdan geri bildirim:

"Bir dizi alıştırma" ile ilgili sorun, daha önceki bir alıştırmada problemi olan öğrencilerin geri kalan alıştırmalar için tamamen vidalanmış olmalarıdır.

Haklısın, bunun daha zor olduğunu düşünüyorum. Her ne kadar benzer beceri seviyesine sahip öğrencileri doğru seviyeye / gruplandırmaya zorluyoruz? Ayrıca, öğrenciler problemleri ve çözümleri tartışmak ve tartışmak ve problemleri birlikte çözmek zorunda oldukları daha küçük gruplar halinde düzenleyebilirler. Biri bunu alamazsa, diğerleri yardım edebilir (bu kurulum ekip çalışması becerilerini de geliştirir). Ve eğer birisi tembel olmaya çalışırsa ve diğerlerinin tüm işi yapmasına izin verirse, kesinlikle öğretmen tarafından fark edilir (köşede dolaşması, öğrencileri denetlemesi ve danışmanlığı, köşesinde dizüstü bilgisayarında WoW oynamaması ;-)

Ayrıca, alıştırmalar farklı beceri seviyelerine sahip öğrencileri barındıracak şekilde ayarlayabilir. Yeni başlayanlar daha yavaş gidebilir, deneyimli olanlar daha hızlı.

Onların öğrencilerin dengeleme eylemi mücadele ediyorlar sizin konu hakkında bakım ihtiyacı ve bunların geçer not almak gerek . Birçok öğrenci bunu hisseder:

(Hatalı Olun || Deneme) == (Sınıf & & Atık Zamanının Arızası)

Bir öğrenci, zamanının veya notunun risk altında olduğunu hissettiğinde, ilginç bir konu için bile, öğrenmeyi bırakıp doğrudan "umursamıyorum, sadece öğretmene doğru cevabı ver" e atlıyorlar. Öğrencileriniz sorun hakkında mümkün olduğunca az düşünerek ve sadece kopyalayıp yapıştırarak keserek köşelerini kesmeye çalışıyorlar (ya da öyle düşünüyorlar) .

Bununla nasıl başa çıkılacağı konusundaki önerilerim:

1. Bob Ross yöntemini kullanın: Onlara yeniden kopyalama ve yapıştırma işlemine başlamanın hem mümkün hem de daha hızlı olduğunu kanıtlayın . Ders sırasında gözlerinin önünde yeni programlar yaratın - programlamanın resim yapmak gibi olabileceğini gerçekten gösterin.
2. Yaratıcılık gerektiren ödevler verin . Örneğin, her öğrencinin kurs boyunca kullanması için kendi veri yapılarını (bir Hayvanat Bahçesi, Hayvan Mağazası, Kasaba, Kolej vb. Oluşturmak için gerekli nesneler nelerdir) oluşturmalarını isteyin. Atama # 2, bu yapıları sınıflara veya nesnelere vb .
3. Mümkün olan en az sözdizimini kullanın. Sınıflar ve dil sözdizimi oluşturma gibi kazan plakaları, programlamanın tanıtılmasında o kadar yaygındır ki, çoğu programlamanın sadece küme parantezini nereye koyacağını bildiğini düşünmeleri konusunda öğrencileri yanıltmaktadır - kıvrımın ortasının ortasında olduğunu farketmezler. ayraçlar yaratıcılığın aktığı yerdir . Basit bir dil seçin ve bir şeyi kopyalayıp yapıştırmak isteyen öğrencilere örnek dosyalar (boş bir sınıf dosyası gibi) sağlayın. Kurs ilerledikçe yavaş yavaş sözdizimi ve derlenebilir ödevler hakkında daha katı olabilirsiniz.

Aklıma gelen bazı şeyler:

• Onlara gerçekte (siz) yazmış olduğunuz kodu açıklamak zorunda oldukları ödevleri verin. Önceki kodun anlaşılması veya daha spesifik olarak eksik olması, kargo kültü programlamasının hem en büyük nedeni hem de tehlikesidir. Programınızı sade İngilizcede (ya da hangi insan dilini kullanıyorsanız) açıklamak için, gerektiğinde satırları sırayla yorum yapmalarını isteyin.

• Yalnızca kodu açıkladıktan sonra, belirli bir değişiklik yapmak için kodu değiştirmelerini isteyin. Örneğin, onlara azalan türden bir sıralama işlevi verdiyseniz, sıralamadan artan sıralama yapmalarını isteyin. Ya da daha talepkar bir şey. Ancak verilen kodun anlaşılmasını gerektiren bir şey olduğundan emin olun .

• İsterseniz bazı paskalya yumurtaları koyabilirsiniz. Yararlı hiçbir şey yapmayan veya hatta problemle ilgili olan bir veya iki satır. Onlara bu tür çizgilerin var olduğuna dair bir ipucu verin ve bunları kaldıranlara ekstra puan verin.

• O zaman ve ancak o zaman onlara sıfırdan başlarına bir kod parçası yazma görevini verebilirsiniz. Bu noktada, kodun gerçekte ne olduğu konusunda daha iyi bir anlayışa sahip olmaları gerekir. Bunu kendileri yapmak için biraz daha kolay bulabilirler.

Temel fikir, programlamanın sadece kod yazmak değil, aynı zamanda onu okumak olduğu. Okuma kodu da öğretilmelidir.

Buna başka bir şekilde bak. Bu kargo kült fenomeni, Dreyfus beceri kazandırma modelinin acemi aşamasıdır . Bu şekilde öğreniyoruz. Programlamayı ilk öğrendiğimde, tek yaptığım, Compute! 'Un arkasındaki kod sayfalarına yazmaktı. dergisi. Tekrarlama anahtarıdır. Bebekler, ebeveynlerinin duydukları sesleri kopyalayarak konuşmayı öğrenirler. Öğrendiğimiz her şey taklit yoluyla. Sadece taklitten ustalığa nasıl geçileceği öğretilmeli.

Sahip olduğun sorun, öğrencilerinin hiçbir şeyi tekrarlamaması, internetten kopyalamaları. Bunun bir faydası var ama kazançlar az. Aslında kodu girme eylemi, beni bir anlayış yerine getiren şeydi. Yazdıklarımdaki kalıpları görmeye başladım ve yaptığım şeyi anladım.

Bir seçenek, laboratuarınızı bir kod dojo olarak yapılandırmaktır. Öğrencilerin aynı sorunla ilgili sırayla eşleşmelerini sağlayın. Çözülmesi yaklaşık 10-15 dakika sürecek bir problem seçin. Bu problemi birkaç laboratuvarda tekrarlayın ve sınıfın yeterliliği arttıkça soruna yeni bir dönüş getirin. Muhtemelen laboratuvara, öğrencilerin çözümü izlerken sizi izlemesini sağlayarak ve tekrar etmelerini sağlayarak başlayın. Her yinelemede çiftleri değiştirme.

Testleriniz için, her öğrencinin dersin geri kalanının önündeki sömestrdeki problemleri çözdüğü bir kata kodu var. Sadece doğruluk üzerine değil, biçim ve yaratıcılık üzerine odaklanın. Bunun nasıl programlanacağının daha iyi anlaşılmasını sağladığını ve ev ödevleri almanın daha iyi olacağını düşünüyorum.

Geçmişte giriş dersleri verdim ve geriye döndüğümü hatırlıyorum:

Bazı öğrenciler programlamanın farklı sebeplerden dolayı böyle olduğunu düşünürler. Bir zamanlar, kargo yaptığım şeyi yapan iyi bir çocuğu hatırlıyorum:

Bunun izole edilmiş bir sorun olmadığına inanmakla birlikte, aynı sınıftaki diğer öğrenciler de benzer davranış sergileyebilir ya da soruna yaklaşabilir ve dile getiremezler, her zaman sınıfa hitap ediyordum.

1. Determinizm gibi bazı şeyleri açıklamak için biraz zaman harcandı, bu onlar için aynı veri ve kodla aynı ortamda aynı sonuçlara sahip olacaklarını (“rastgele” yi ortadan kaldırarak),

2. Problem çözme, öğrencinin davranışlarına bağlı olduğundan ve başka hiçbir şey yapmadığından, dikkatin problemi çözmede ve doğru büyüyü bulamamasında,

3. Bunlar bir eğitim ortamındadır, bu nedenle problemler bir öğrenme deneyimi sunmak için hazırlanır, sonuç nasıl programlanacağını (veya Sistem Yöneticileri için olan sınıflar, programların nasıl çalıştığını, farklı olanları) öğrenmektir. bana bir çözüm ver. ("Dünya başka bir hesap makinesine ihtiyaç duymaz, bu bir alıştırmadır"), bu nedenle sorunları mevcut materyallerle çözülebilir (örnek: verilen notlar),

4. Bence Kod Tamamlandı: "Kopyalayıp yapıştırsanız bile kod sizindir". Biri yaptıysa, kargo tarzı olmamalıdır. Her satır bana (bireysel olarak) veya başka bir öğrenciye (aynı) veya sınıfa açıklanmalıydı.

Öğrencileriniz mı başlayacak de doğru 'soyutlama düzeyinde' tabii başında? Örneğin, bunları tek bir kod satırı yazmadan döngü ve koşul gibi ana programlama yapılarına tanıtan bir ev ödevi?

Programlamaya girdiğimde ilk görevimiz ' Rick the Robot ' olarak adlandırılmıştı . Bankalar, marketler, vb. Gibi ilginç noktaları olan bir şehrin hava haritası olan bir kağıdımız vardı ... 'Rick' adında bir adamımız vardı ve 'bir adım atmak', 'sola bakmak' gibi eylemler yaptık, 'doğru bak', 'yolun karşısına geç' ve 'tekrar' ve 'bir şey varsa, o zaman bir şeyler yap' gibi şeyleri kullanabiliriz. (Bu ödevi bulamadığım için bu% 100 değil.) Fikir, Rick'in yalnızca verilenleri kullanabileceği ve haritadaki farklı yerlere gitmek zorunda kalacağıydı.

Bu eğlenceli bir alıştırmaydı ve sizi temellerle tanıştıran bir şeydi (bazen yeni gelenlere yakalanması en zor olanı). Bu sorunun iyi bir cevabı yoktur (oyun) ve kopyalayıp yapıştırabileceğiniz bir çözüm yoktur. Bunun gibi bir şey, kodlarıyla korkutmadan yaratıcılıklarıyla biraz daha oynamanıza izin verebilir.

Son olarak, fikir ile başlamak olduğunu soyut ve doğru hareket beton . Yapıştırma özetini kopyalayamazlar. Bir problemi çözmek için bunu anlamak zorundalar.

Onlardan yapmalarını istediğin şey, şu anda sadece uygulamalarını gösteren Bloom'un Taksonomisinin bilişsel alanındaki analiz ve sentezi göstermek.

Ne yazık ki, bu bir tür "atı suya yönlendir" durumu. Analiz ve sentez, hala anlama ile uğraşırken bile yapmak çok zordur. Kavrama mevcut değilse, analiz ve sentez aktiviteleri öğrenme aktivitelerinden daha çok yabancı ot gibi davranacaktır.

Benim kişisel görüşüm, programlama derslerine girişte uygulamadan daha fazla bir şey beklemenin uygun olmadığı yönünde. Bu ilk kez öğrenciler bu kavramlara maruz kalıyor, bu yüzden çocuklara bir kompozisyon yazmalarını istemeden önce okumayı öğretmek gibi. Bu üst düzey beceriler sonraki sınıflarında takip edecek.

Onlara başlamak için bir kod vermeyi düşündünüz mü ? Boş bir ana işlev (hangi dili kullandığınızı bilmiyorum) gibi atama ne olursa olsun basit iskele ihtiyacı. Derleyen ve çalışan ve hiçbir şey yapmayan bir şey. Sonra kodlarını, en azından bir kısmının işe yaradığı bir dereceye kadar güvenle eklemeye başlayabilirler .

Bu aslında "gerçek dünyada" oldukça yaygındır; Birçok IDE ve diğer araçlar, hali hazırda mevcut olan tipik kütüphaneler / şablonlar / konfigürasyon dosyaları ile boş projeler oluşturur.

Herhangi bir kargo kült zihniyeti ( kargo kültleri dahil ), söz konusu teknolojiyi temelden anlamamış bir eksiklikten kaynaklanmaktadır.

Kargo-kült programlama, sorunlu bir alışkanlık olarak düşünülmemeli, bunun yerine programcının karşı karşıya olduğu karmaşanın bir belirtisi olarak düşünülmemelidir.

Daha da önemlisi, öğrencinin anlama konusundaki eksikliğinin, güven eksikliğinin basit bir şekilde ortaya çıktığı varsayımı temelde yanlış yönlendirilmiştir ve temelde yatan sorunu çözmez.

Bunun yerine, öğrencinin kopyala-yapıştır programlama stili, bu öğrencinin yapması beklenenlerin karmaşıklığı ile boğulmuş olduğunu söyleyen kırmızı bir bayrak olmalıdır.

İçgüdüsel olarak geçmişteki çalışmalarını mevcut projesini inşa etmek için daha önce çözülmüş problemleri yapı taşları olarak kullanarak bir çözüm üretmeye çalışan bir iskele olarak kullanıyor. Bunu hepimiz bir dereceye kadar yapıyoruz, ancak çoğumuz bunu geçmiş çalışmalardan edindiğimiz bilgileri yapı taşları olarak kullanarak yapıyoruz . Bu öğrenci bunun yerine çalışmayı kullanıyor, bu da çalıştığı blokları gerçekten anlamadığı anlamına geliyor. İşi anlayışı elverdiği ölçüde parçalara ayırdı ve büyük kod bloklarını atomik birimler olarak ele aldı, çünkü nasıl çalıştıklarını anlamıyor . Sadece ne yaptıklarını biliyor.

Change senin projelerin fikir!

Programlama dünyasında, nadiren ortaya çıkan her çözüm için yeni projeler yaratıyoruz. Çoğu zaman eskileri değiştiririz.

Bir proje hakkındaki fikrinizi, her dönem için bir çözümden, tüm dönem boyunca bir çözüme dönüştürün. Her atama önceki atama üzerine kuruludur .

Örnek

Proje: Bir asansör sistemi inşa etmek

• Atama 1: Geçerli katı yazdırın
• Ödev 2: Bir asansör sınıfı için veri yapıları oluşturun ve asansörü temel alarak zemini yazdırın
• Atama 3: Zemini bastırarak "asansörü hareket ettiren" kod oluşturun. Klavye girişini kabul et (> kat:)
• Atama 4: Birden fazla asansörü taşıyın

Nokta olmasıdır inşa yerine yeni görev için eski atamaları geri dönüşüm önceki görevde.

Minimum kazan kodunu gerektiren çok yüksek seviyeli bir dil kullanmayı düşünün.

Bana göre, çoğu zaman büyü çerçeveleri gibi görünen ve anlamayı engelleyen büyük çerçevelerdeki veya ayrıntılı dillerdeki kazan kodudur.

CS tanıtıcı programlama kursumda kişisel olarak ML öğretildi . Uzun yıllar boyunca Lisp , MIT'de programlamaya giriş olarak öğretildi. Her ikisi de mükemmel seçimlerdir. Sahip oldukları faydalardan bazıları

• Etkileşimli tercüman. Çok önemli, bu keşfe izin verir.
• Çok özlü. Hiç kazan plakası yok. Öğrencilerin, ifade etmeye çalıştıkları fikirlere konsantre olmalarını sağlar.
• Nispeten belirsiz ve yabancı (en azından Java, C veya öğrencilerin zaten deneyimleyebileceği diğer ana dillerle karşılaştırıldığında). Evet, bunu profesyonel olarak listeliyorum. Öğrenciler için oyun alanını düzleştirir, çünkü muhtemelen kimse daha önce deneyime sahip olmayacaktır. Üstelik, web üzerinden ödevlerini yapmak için sadece kopyala-yapıştır çözümlerini kullanabilmeleri daha az muhtemeldir.

80'li yıllarda acemi programcılarının sorunları hakkında biraz araştırma yaptım. Bugün acemi programcıları ile olan deneyimime dayanarak pek bir şey değişmedi. Acemiler, bilgisayarların gerçekte ne yaptıklarına dair faydalı bir zihinsel modele sahip değildir. Makinenin kendisi büyülü olduğu için sihirli büyülere başvuruyorlar.

Programlama doğal olarak basit işlerin doğal olmayan küçük adımlara bölünmesini gerektirir. Acemiler günlük yaşamda bu kadar ince ayrıntılarla uğraşmadıklarından, özellikle küçük makinelerin hangi küçük adımları kullanabileceği belli olmadığında, küçük adımların ne olduğunu anlamaları zor. Ancak, bunu çözmeyi başarsalar bile, gizemli makineyi uzaktan kumanda ile kontrol eden bir programlama dilinin (doğal bir dil olarak nitelendirilen doğal olmayan bir dil) stilize edilmiş bir sözdizimi ve sınırlı semantiği ile karşı karşıya kalıyorlar.

Soruna mantıklı bir çözüm ile makinenin işlevselliği arasındaki bağlantıyı kuramadıkları için dilin taleplerini yerine getirmeye odaklanırlar. İlk amaç, derleyen bir şey - bir şey - yazmaktır. İkincisi, bu programı ince ayar yapmaktır - aslında ne yaparsa yapsın - çökmesini önlemek. Daha sonra, zamanları, enerjileri ve ilgileri varsa, programın, sorunun gerektirdiğine benzeyen sonuçlar üretmesini sağlamaya çalışırlar. Yol boyunca, yanlışlıkla iyi yazılmış kodlar üretebilirler.

Her ihtimalde, programlamayı öğrenen acemiler başarılı bir şekilde başarılı oluyorlar çünkü bilgisayar için faydalı bir zihinsel model çıkardılar, çünkü bilerek verdikleri ve içselleştirdikleri için değil.

Onlara yazılı cevap gerektiren kod parçaları hakkında sorular sorabilir misiniz? "Bu kod ne yapıyor?" Gibi. “Programcı neden böyle çözdü?” “Daha iyi bir yolu var mı?” Vb.

Bu aslında problem hakkında düşünmelerini sağlayacaktır, bu kodlara dokunmadan yapabilecekleri bir şeydir.

• Problemin mümkün olan en kısa çözümlerini oluşturmak için onlara meydan okuyun.
• Daha özlü çözümleri bir teşvikle ödüllendirin.
• Tamamen refactoring kodunun etrafında dönen alıştırmalar oluşturun
• Öğrencilere ödevlerini takas etmelerini ve verim ve kod temizliği için ders vermelerini ve en az verimli olanları örnek olarak bir tepegöz projektörde kullanmalarını sağlayın.

JoelFans fikrine benzer şekilde, oluşturduğunuz sahte kodu (dil) kullanarak kağıda ilk ödevleri yapmalarını sağlayın. Yapıları uygun gördüğünüz şekilde ekleyebilirsiniz ve sihirli kutu için endişelenmezler.

'Kargo kültü' ile, gerekli olduğunu düşündüğü şeyleri yerleştirdiklerini söylüyorsunuz, ama aslında sorunu çözmek için kesinlikle hiçbir şey yapmıyor.

Bu durumda, öze dayalı bir dereceye her zaman bir faktör ekleyebilirsiniz - programınızda gereksiz veya gereksiz bir kod bırakmak, gelecekte kırılması ya da sadece bakımını zorlaştırması gibi sorunlara yol açmaktadır.

İngilizce dersinde bir yazma alıştırmasında da benzer şekilde yargılanırlardı - hiç kimse rastgele bir teğette giden veya istemeyen bir noktaya gelmeden başıboş dolaşan şeyler istemez.

Bir montaj dersine girdiğimde, öğretmen hız, boyut ya da bellek kullanımı için kod yazmamızı isterse her egzersiz için bize söylerdi ve istediğini optimize etmeye yaklaşmamış olsaydınız işaretlerdi. için.

...

Eğer önceki benzer ödevlerden kod kopyalayıp yapıştırıyorlarsa ve bu aslında yeni sorunu çözecek bir şey ... peki, bu sadece yeniden kullanım kodu ve tekrar kullanım için uygunluk konusunda kötü varsayımlar yapmadıkça , Bence yapmaları tamamen makul. (örneğin, bir dosyadan okuma, girdi için destek verme ... yeniden kullanılabilecek tüm modüler parçalar. Bunları yapmalarını istemiyorsanız, egzersizleri farklı hale getirmeniz gerekir.

Ne yazık ki, bu birçok insanın beyninin çalışma şeklidir. Öyleyse bu anlayışın içine girip, tedavi edemeyeceğiniz insanlar var. Programlama için gerekli zihinsel hassasiyet düzeyinde çalışamayan birçok insan var. Bazı insanlar bunun için tasarlanmamış. Öğrencilerden vazgeçmiyorum demiyorum - herkes onu seçmezse başarısız olduğunuzu varsaymayın.

Sınıfın bağlamı hakkında daha fazla şey bilmeden, bu problem öğrencilerine çok temel yapılara odaklandığını söylerim - eğer basit / eğer varsa, döngüler, vb. Her biri 10'dan fazla kod satırı. Eğer 'sihirli düşünce' ise, henüz belli değil. Neler olduğunu anlayana kadar birçok farklı basit rutin yapmalarını isteyin. Birisi kodu kağıda yazmaktan bahsetti - bu basit rutinleri yapmanın da harika bir yolu olacağını düşünüyorum.

Ayrıca akış çizelgelerini öğrenmelerini de düşünebilirsiniz. Bazı insanlar için, bir algoritmanın akışını ve sonra da koda nasıl bağlandığını görebilmek, kodu akışa bağlamak için onlara yardımcı olabilir.

İdeal olarak, ilk derste, onları tamamen soyut olan bir şeyle başlatın: onlara (bir grup olarak, lider olarak sizinle birlikte) bir listeden bakkal alışverişine nasıl gidileceğine ilişkin talimatları yazmalarını ve kademeli olarak üst düzey talimatları parçalamalarını sağlayın. aydınlanana kadar.

Onlara bu talimatların kelimenin tam anlamıyla bir şeyi nasıl yapacaklarını bilemeyen bir robot tarafından takip edileceğini söylemeye yardımcı olur. Yine de onlara rehberlik yapmaktan sorumlu olduğunuz, uygulamalı bir faaliyet olmalıdır.

Alistair Cockburn, Shu-Ha-Ri kavramı ve programlamaya nasıl uygulanacağı hakkında konuşuyor, http://alistair.cockburn.us/Shu+Ha+Ri . Öğrencilerinizin bu süreklilikte nerede olduklarını akılda tutmanın önemli olabileceğini düşünüyorum. İlk olarak, bazı hayal kırıklığınızı hafifletmeye yardımcı olacaktır. Kopyalama / taklit etme, bir şeyler öğrenmeye ilk başladığınızda çok doğal bir cevap ve kabul edilen bir moddur. İkincisi, nasıl ilerleyeceğinize dair bazı fikirler edinmenize yardımcı olabilir. Örneğin, birçok yoldan çözülebilen bir problem seçmeyi düşünebilirsiniz (döngüler - özyineleme, konsol vs. web / gui), sonra açık bir şekilde önce bir şekilde çözmelerini, sonra başka bir yolu - öğrenebileceklerini meşru kod kullanımı, bileşenlendirme, yeniden kullanılabilir kitaplıklar oluşturma, vb. hakkında

Kullandığım bir diğer başarılı yol, birbiri üzerine inşa edilmiş bir dizi projeye sahip olmak ve insanların geride kalmasını engellemek için görevlendirmeler yapıldıktan sonra her adımda varsayılan, çalışan bir sürümü kullanıma sunmaktır. Sürecin her aşaması yeni bir şey getirmeli. Size bunun bir tasarım sınıfında bir programlama sınıfından daha kolay olabileceğini, ancak yine de yapılabilir olması gerektiğini söyleyeceğim. Bununla ilgili güzel bir şey, her adımda kendilerine göre karşılaştırmaları için onlara açıkça iyi bir uygulama (umarım) uygulamanızdır. Bu karşılaştırmayı bir ödev olarak gösterin, yani çabalarına karşı kendi kodlarının bir mini kod incelemesini yapın. Bunu birkaç ekstra kredi seçeneğinden biri yapmak isteyebilirsiniz.

Genelde "yorumlar" konusunda büyük değilim, ancak kodun belgelerini not öğelerinden biri haline getirmek isteyebilirsiniz. Yaklaşımlarını, her bir bileşenin nasıl uyduğunu ve sorunu nasıl birlikte çözdüklerini açıklayan her proje için bir "Çalışma Teorisi" belgesi üretmelerini sağlayın. Normalde, kodun bunun çoğunu kendi başına yapmasını isterdim, ancak düşünme kapaklarını takıp kağıda koymaları onları zorlardı.

Son olarak, yaratıcı olmak ve öğrencilerinizin birbirlerinin kodlarını incelemelerini ve bir değerlendirme vermelerini isteyebilirsiniz. Sizin için çalışmaya akran baskısı uygulayın. Bunun, en yüksek puan alan kod (ve dokümanlar) için notun veya ekstra kredinin bir parçası olmasına izin verin.

Sadece hızlı bir öneri. Ne zaman çözülmesi veya hata ayıklanması gereken bir programlama sorunum varsa, koduma bakıp 'bilgisayar oynamayı' severim. . Yani, eğer bir kodu bir yerden kopyalarsam, kendi başına tamamlanmadıysa ve sadece referans vermem gerekiyorsa, tam olarak ne olduğunu anlamak için satır satır gitmeyi seviyorum. Esasen bilgisayar oynamak. VBA Debugger aslında bu görevi kolaylaştırıyor ancak öğrencilerinizin bunu kağıt üzerinde yapmasını sağlamak, onlara temelleri verebilir. Bu çizgi aslında ne yapar?

Üniversite düzeyinde tanıtım programcılığı öğrettim. Ekmek-tereyağı kursu oldu, tüm fakülteler yaptı ve bence gayet iyi yaptık. Ortak bir metni takip ettik ve ortak sınavlar yaptık, ancak her birimizin işe yarayan kendi sınıf yöntemimiz vardı. O zamandan bu yana uzun zaman geçti, ama bazen programlamada bazı çocuklara özel dersler veriyorum ve tüm resim aynı.

Yapmamın yolu mümkün olduğunca somut, en alttan başlamak. Öğrencilerin bildiği bir yapıdır. Zaten çok fazla kavramları var. Bunların üzerine başka kavramlar inşa ediyorum ve onların üretkenliği olan kavramları oluşturabiliyorum. Aynı zamanda yaparak öğrenmelerini sağlarım .

Intel 8008 yonga, biraz EPROM ve birkaç devre ile küçük bir bilgisayar inşa ettim. G / Ç yongası birkaç hoparlöre bağlandığında, küçük bir düet çalması için programlamıştım. Küçük programın nasıl çalıştığını, bir sayacı geri saymak için bir iç döngü ile açıklayacağım. Bu gecikme gibi davranır. Sonra çıktı biti değiştirir ve tekrar yapardı. Bunu bir süre yapar ve sonra başka bir gecikmeye geçer, başka bir adım verir, vb. Bellek yongasının biraz zamanlayıcısı vardı ve zamanlayıcı girişlerinden birinin altına bir kapasitör kablosu soktuysam , program yavaşça vejeteryanı çalıştırırdı . Sınıf konuşmacıların tıklandığını, tıklandığını, tıklandığını duyabiliyordu ... Sınıfın bilgisayarın her seferinde bir adım çok basit şeyler yaptığını anlamasını istedim.. Sonra kapasitörün bağlantısını keserdim ve “müzik” patlardı. (alkış)

Sonra, her biri 4 haneli bir ondalık basamağa sahip, 1000 bellek konumuna sahip, çok basit bir ondalık bilgisayar için bir simülatör kurdum. "Akümülatöre ekle", "eğer negatifse zıplar" gibi çok basit kodlara sahipti. Bu "makine dilinde" iki sayı eklemek veya bir numara listesi eklemek gibi küçük programlar yazmalarını isterdim. Sonra tek adımla çalışarak veya "hızlı" çalışmasını izlemek için Enter tuşunu basılı tutarak çalışabilirlerdi.

Bunun amacı, bilgisayarların yalnızca çok az sayıda farklı temel işlemleri yapabileceği ve bunları birer birer yapabilecekleri kavramını ortaya koymaktı. Bu, bilgisayarların karmaşık olduğu ve her şeyi aynı anda yaptıkları izlenimine karşı koymak ve aklınızı pazarlıkta okumaktır.

Oradan "basit" bir dilde (BASIC :) programlama yapmaya başladık, çok basit ama ilginç programlardan başlayarak, koşullarla çalışma, döngüler, diziler, dosyalar, birleştirme vb. Amaç, kendi seçtikleri bir projeye devam edebilmeleri için yeterli bir beceri seti koymaktı, çünkü programlamayı ilginç kılan tek şey - onu kullanabileceğiniz kullanımı. Projeler için bazı fikirler ortaya atardım ve sonra onu oradan alırlardı. Onlardan son dakikaya ertelemelerini ve sonra paniklemelerini engellemek için yazılı fikirler isteyeceğim ve ardından raporları ilerleteceğim. Projelerin en iyi kısmı olduğunu düşünüyorum çünkü kendi güçleriyle öğreniyorlardı.

Bu, hangi bilgisayarların ne yaptığını çok net bir şekilde anlamanın ilk temeli, daha sonra kavramları öğretmeyi çok daha kolay hale getirdi; aksi halde, diziler veya (daha sonraki bir kursta) işaretçiler gibi gerçek bir hız artışı olacaktır. “Soyutlama” kavramını bu harika şey olarak yüceltmeye meyilliyiz, ancak havada değil somut bir temel üzerine inşa edilmesi gerekiyor.

Bir kendini öğreten programcı Animasyonun kodun ne yaptığını bilmek açısından en zorlayıcı olduğuna inanıyorum . Bir program, soyut manipülasyonlar yapan algoritmalar ve matematiksel dönüşümler içerdiğinde, matematiğin herhangi bir noktada (bir dahi olmadıkça) ne yaptığını anlamanın tek yolu, kodun yürütülmesini anlamayı gerektirir.

Saf fikrim yanlışsa beni düzeltin. Yapmak istediğiniz not, öğrencilerinizin "tasarım desenleri" kullanmalarını engellemek, ancak CnP'lerin ne olduklarını anlamalarını sağlamak için bir yol bulmak mı? Sonra bir animasyonu işlemek için öğrencilerinize meydan okuyun. Çıktıyı bir animasyonda çimdiklemek için her adımda neler olduğunu anlamak gerekir. Belirtilen kaygınız için, iyi düşünülmüş bir animasyon projesinin bir öğrencinin "aldığında" açıkça ortaya çıkacağını - tahmin etmemiş olduğunuz bir dönüşümün farkına vardıklarında, beklediğiniz veya birbiriyle ilişkili bazı değişkenleri küçülttüğünü hayal ediyorum.

Çalıştığınız pedagojik sınır ve hedefleri bilmeden, animasyonun tam cevap olduğunu söyleyemem. Animasyon mesleği dışındaki bütün bir animasyon müfredatı, söz konusu olmadığı için tahmin etme tehlikesi taşımalı. Birkaç proje, hiç de kötü değil, sanatsal ve harika bir şeyle sonuçlanamaz.

Başka bir notta, lise seviyesindeki Kodlama Olimpiyatları - wot-wot - kolej öncesi programcıları için bir yarışma hakkında bir gazete makalesi (evet, bildiri!) Okudum. Mücadelelerinin tanımı, okuduğumu hatırlayabildiğim saf kodlamanın en açık ifadesiydi . Yarışmacılar birbirlerine ve iyi uygulama standartlarına göre değerlendirilir. Bu yarışmalarda için öğrencilerin hem çözüm planı olmalı ve elle kod sorunu zaman sınırları içinde bitirmek için gerektirir element "tasarım deseni". Bu nedenle, CnP programlamasıyla ilgili endişelerinizin çözümü , öğrencilerin aynı "kod parçaları" yazıp yazamayacağını test etmektir; CnP'n!

NY Times'da olduğuna eminim. Hızlı bir arama bulamadı. Benzer bir örnek, ACM'nin Uluslararası Collegiate Programlama Yarışmasıdır. Bu yarışma hızlı programlamayı vurgulamaktadır: "Takım yarışmasında yıldırım hızlı programlama kesinlikle ilginç bir beceridir, tam olarak pek çok iş arayan bir özgeçmişin üzerine koyamaz." Böylece gerçek dünyadaki sorunlardan soyutlamayı öneriyorum cevabı.

Ayrıca,

HP Kod Savaşları

Sınıfı, teknik olarak iyi olan ancak kopyalanacak mevcut kodları bulamayacak kadar karanlık olan bir programlama dili kullanarak öğretin.

Onlara zor yoldan da davranabilirsiniz.

Kopyala yapıştır işleminin kendilerine zarar vermesinin bir yolunu bulun. Kesin bir örneğim yok ama çözümü benzer görünümlü ikinci bir alıştırmaya yapıştırılırsa, kargo-kült öğrencilerine çok uzun ve acı veren bir "kararsız dengesizlik" ya da "sessiz veri bozulması" böceklerini getiren ilk bir alıştırma hazırlarsanız. Bu arada "kargo kültü olmayan" bir 2 milyon düşünme, en kötü öğrenciye bile bariz bir çözüm getirecekti (ilk egzersiz çözümünü görmemişti). Daha sonra, belki de dersi öğrenebilecekleri ve üçüncü alıştırmaya kodu yapıştırmadan önce iki kez düşünebilecekleri bir ihtimal vardır.

Bu davranışın, programların sihirli büyü olduğuna inandığı için şüpheliyim - daha büyük olasılıkla tembellik ve motivasyon eksikliği.

Bu yüzden bir öğretmen olarak işinizin öğrencilerinizi motive etmek olduğunu düşünüyorum - gerçekten motive olmuş hiçbir öğrenci bir çözümü kesemez ve yapıştıramaz (bu sadece buluşmaları için son tarihleri ​​ve alt satırları olan çalışan programcılar için ...)

Alt rutinleri öğret. Önceki ödevlerden aldıkları kodu almalarını ve bir alt rutine dönüştürmelerini sağlayın. Alt yordamın gerçekte ne yaptığını anlamalarına yardımcı olmaları için onlara işlev belgelerini öğretin.

Atamaları sınıfta önlerinde Internet erişimi olmayan bir şekilde yapmalarını sağlayın (okulun kestirmesini sağlayın, ders sırasında telefon kullanılmasına izin vermeyin). En azından bunu testler için yap. İnterneti temel programlama deneyleri için kullanmaları için hiçbir neden yoktur. Giriş egzersizleri için kitap yeterli bir kaynak olmalıdır. İleri düzeyde bir sınıfa girdikten ve nasıl düşüneceklerini öğrendikten sonra İnternet kullanımına izin verin.

Asla benzer şekilde ses veren ödevler vermeyin.

Ya da daha çılgınca, TDD'yi baştan öğren. Çözülen problemi formüle etmeye yardımcı olan birçok kod (yani testler) yazmak (kopyalamak, yazmak değil) için zorlar.

Sınıfımdaki insanlar için çok faydalı bulduğum bir şey, kendi seçebilecekleri bir konuda kendilerine küçük bir proje yazıyor.

Programlamaya başladığımda benim için de zordu ve sınıfta çok şey kopyaladım. Sonra evdeyken, oyun programcısı olmak istediğim için küçük oyunlar yapmaya başladım ve onları daha kolay hale getirdim. Çok zor olsalar da sınıfta gördüğümüz şeyler. Sadece beni ilgilendirdiği için.

Sınıfımdaki diğer birkaç kişi sınavlarında% 40-50'den% 90-100'e gitti, çünkü aynı şeyi yaptılar.

Giriş kursundayken, eğitmen herkesin İngilizce olarak bir algoritma yazmasını ve kod yazmaya başlamadan önce yazdırmasını ve açmasını istedi. Sonra Değişkenleri yarat, Kullanıcıdan Girdi Al, Hesaplamaları gerçekleştir, Çıktısı yazdır, vb. Gibi çok fazla yorum koymak zorunda kalırdık. Çok fazla düşündüğümde yeterince yorum yapmadığım için birkaç kez kenetlendim, bu yüzden eklemeye başladım. Daha. Bu beni ne yaptığımı düşünmeye zorladı ve çözümleri yazmaya ve İngilizce ile Java arasında ileri geri çevirmeye devam etti.