Programlama tesadüf eseri olarak nasıl aşılır? [kapalı]

Pragmatik Programcı adlı kitapta , yazarlar programlamayı tesadüf kavramı ile belirtirler. Ne olduğunu, neden ortaya çıktığını, karşılaşabileceğiniz tehlikelerin neler olduğunu ve bir savaşta bir mayın tarlasıyla karşılaştığını açıklar.

Hiç eski siyah beyaz savaş filmlerini izledin mi? Yorgun asker, fırçayla dikkatlice ilerler. İleride bir açıklık var: Herhangi bir kara mayını var mı, yoksa geçmesi güvenli mi? Bunun bir mayın tarlası olduğuna dair herhangi bir belirti yok - hiçbir işaret, dikenli tel veya krater yok. Asker süngeriyle önündeki yeri dürter ve bir patlama beklerken kazanır. Bir tane yok. Böylece bir süre boyunca saha boyunca titizlikle ilerler, ilerledikçe ve dürter. Sonunda, alanın güvenli olduğuna ikna etti, sadece parçalara ayrılmak için düzeltir ve gururla ilerler.

Askerin mayın için ilk sondaları hiçbir şey göstermedi, ancak bu sadece şanslıydı. O feci sonuçlarla yanlış bir sonuca götürüldü.

Geliştiriciler olarak mayın tarlalarında da çalışıyoruz. Her gün bizi yakalamayı bekleyen yüzlerce tuzak var. Askerin hikayesini hatırlayarak, yanlış sonuçlar çıkarmaya karşı dikkatli olmalıyız. Programlamanın tesadüf eseri - şansa ve tesadüfi başarılara dayanarak - kasıtlı olarak programlama lehine ...

Ancak, "bunun üstesinden nasıl gelineceği" konusunu tarif ettikleri yöntemden gerçekten memnun değilim. Evet, kodu yazmadan önce ileriyi düşünmek zorundasın, ama bunu nasıl uygulayacaksın? Düşünebildiğim tek şey, hem “şu anda ne yapıyorum” hem de “diğer kod parçalarının nasıl çalıştığı” hakkında bilgi sahibi olmanız gereken mevcut Açık kaynak projelerine özellikler ekleyerek. kendi projelerinizi yazarken.

DÜZENLE:

yayınlarınızdan bir özet:

• Bir sonraki hareketini tahmin etme, doğru olduğunu ispatla
• Birim testi ve refaktör gerektiğinde, gerektiğinde
• Özellik ekleme – derleme – sık sık test
• Kodu bir noob'a açıklayamazsanız, büyük olasılıkla tesadüfen programlıyorsunuzdur.

Btw, cevap kabul etmek zor, gerçekten zor. Tüm cevaplar gerçekten harika :)

İleriyi düşünmek zorunda değilsiniz, sadece ne yapıldığı konusunda çok net olmalısınız ve şu anda ne yaptığınız konusunda çok açık olmalısınız.

Alt programlar, yaptıklarını söylemeli, söylediklerini yapmalı ve gizli bağımlılıklara sahip olmamalıdır. O zaman birileri onları arayarak ne yapacakları hakkında daha kolay bir sebep olabilir.

Küresel devletten kaçının. (Değişkenler, tekiller, vb.) Kafanızda, ne işlerin yapıldığını anlamak için ne kadar zorunluluk varsa, ne olması gerektiğini anlamak ve son durumları bulmak zorlaşır.

Birim testleri yaz. Birim testleri, bulmayı umduğunuz ideal davranış yerine, henüz yazdığınız kodun gerçek davranışını yakalamak için mükemmeldir.

Düzenleme / derleme / test döngüsünü kısalt. Büyük miktarda kod ekleyip zayıf bir şekilde test ettiğinizde, ihtimaller düşündüğünüzden farklı davranacak. O zaman rastgele bir değişiklikle onu "düzeltirsin" ve şu an için doğru cevabı aldın, ama gerçekte nasıl olduğu hakkında hiçbir fikrin yok. Şimdi tesadüf esasına göre programlama yapıyorsunuz. Ancak 5 satır ekleyip test ettiğinizde, doğru cevap alma ihtimaliniz, çünkü işe yaradığını düşündüğünüz gibi çalışıyor. Deneyimden, her biri ayrı ayrı test edilen 10 satırlık 5 satırın, aynı anda test edilen 50 satır kod satırından çok farklı bir canavar olduğunu söyleyebilirim.

Refactor acımasızca. Çoğu zaman, kodumu biraz daha kolaylaştıracak ancak yapmak istemediğim bir sürü çalışmayı gerçekleştirecek bir refraktör gördüm. Bu refaktörleri kasıtlı olarak öncelikli olarak ele almaya başladıktan sonra, genellikle bir ay içinde kendi kendine ödediğini öğrendim. Ancak, dikkat edin, odaklandığım yansıtıcılar günden güne daha kolay hale getirenlerden ve daha iyi veya daha genel olan bazı keyfi estetiğe sahip olanlar değil. Bu refaktörler ile çok daha temkinli olmayı öğrendim.

Bunların hiçbiri önceden planlama gerektirmez. Ancak hepsi mevcut kodunuzu anlamayı kolaylaştırır ve bu nedenle bir sonraki küçük öbeğinizi bilinçli bir şekilde uygulamayı kolaylaştırır.

Tahmin etmemek için neredeyse kaynıyor . Çoğunlukla yeni programcılar bunu yapar, ancak gazileri de yaptığını gördüm, çünkü araştırma zamanının tasarruf edeceğini düşünüyorlar. Bir şey işe yaramadığı için, a +1veya a ekler -1, truea falseveya a'nın tersini değiştirir, bazı ifadeleri yeniden sıralar, gecikmeler ekler veya değiştirir, iş parçacığı önceliklerini ve diğer küçük dönüşümleri değiştirir, temelde rastgele permütasyonları çalışana kadar test eder.

Bu çoğunlukla mevcut kodun değiştirilmesi için de geçerlidir, fakat aynı zamanda yeni kodda da bir faktördür, çünkü hiç kimse gerçekten sıfırdan başlamaz. Her zaman standart kütüphaneler, işletim sistemleri veya en azından işlemci mimarileri üzerine inşa ediyorsunuz.

Başka bir deyişle, düzeltmenizin neden işe yaradığını bulana kadar işiniz bitmedi . Oraya gitmek için attığın yol çok önemli değil. Rasgele permütasyonlar bile, zaman zaman kendinize sormak için zaman ayırdığınız sürece, teşhis edilmesi zor bir hatayı daraltmak için faydalı olabilir, "Tamam, yanlış düzeltildi, ama neden?"

Bir programda şimdiye kadar karşılaştığım en korkutucu yorum:

Buna dokunma. İşe yarıyor. Nasıl veya neden olduğunu bilmiyoruz, ama işe yarıyor. ¹

ve sadece kodun parçasının rastlantısal olarak programlamanın sonucu olduğunu kabul etmesi korkutucu .

Tesadüfen programlama yapmaktan kaçınmak için , kodun ne yaptığını ve neden çalıştığını tam olarak (bir iş arkadaşınıza, kendinize veya lastik bir ördeğe ) açıklayabilmelisiniz . Programlamaya yönelik mermiler, kasıtlı olarak programlamada, kodu açıklayabilmenin amacına doğru ilerlemeye yardımcı olur.

¹ Bağlam için, bu yorum ilkel bir işletim sisteminde bağlam anahtarlarını işleyen kodda göründü. Kod karşılaştığımda birkaç yıldan beri üretim yapıyordu.

Yeni programcılar için bunun üstesinden gelmenin en önemli kısmı ne yaptıklarını gerçekten anlamaktır.

Birçok alanda, bir şeyi nasıl yapacağınızı bilmediğinizde, sadece deneme yanılma yoluna gidersiniz. Bir şeyler dene; eğer işe yararsa, harika, eğer değilse, başka bir şey deneyin.

Programlamada, özellikle tanımsız davranış kavramına sahip bir dil kullanıldığında (C veya C ++ gibi), bu yaklaşım işe yaramıyor, çünkü başarı artık boolean bir karar değil. Bazı girdiler için işe yarayan, bazen işe yarayan, bazen "işe yarayan" bazı şeylere sahip olabilirsiniz.

Ara sıra yeni programcılara özel ders verdim ve işe yarayıp yaramadığını görmek için rastgele şeyler yazmaya çalışma eğilimindeyim. Bir satır yazarlar ve sonra bana döner ve "Bu şekilde çalışır mı?" Diye sorarlar. açık olsa da, olabilecek olup olmadıklarına dair hiçbir ipucu yoktu.

Paket servis, yeni bir programcı olarak gerçekten kodunuzun ne yaptığını açıklayabilmeniz gerektiğidir. Sadece yazmayı değil, kodu okumayı öğrenmelisin.

(Tabii ki tecrübeli programcılar için de geçerlidir, ancak buradaki deneyimim çoğunlukla yeni başlayanlar için).

"Yarış çizgisinde" kodlamak, test etmek ve düzeltmek çok kolaydır. X & Y verilen, Z üreten bazı işlevlere sahipsiniz. Fakat ya X bozuksa ve Y kullanılamıyorsa? Ya Z ile çıkamıyorsanız? Neyin yanlış gidebileceğini sürekli olarak aklınızdan çıkarmayın ve test döngüsü için not alın.

Rutinlerinizi kısa ve açıklayıcı tutun - en iyi kod, çok az (varsa) yorum gerektirir.

Anlamlı yöntem, sınıf ve değişken isimleri okunabilirliğe yardımcı olmak için uzun bir yol kat etmektedir.

Bir kod kokusu ile karşılaşırsanız STOP. Bu kokunun kaybolması pek olası değil ve şimdi küçük bir çaba sizi sonradan büyük miktarda kederden kurtarabilir.

Geliştirme sürecinize test dahil edin. Size, sahte bir güvenlik hissi verebilecek bir dizi testten körü körüne güvenmek yerine, neyi başarmayı hedeflediğinizi açıklamaya zorladığından TDD yerine BDD kullanımını savunuyorum .

Ekstra harika özellikler ekleme dürtüsüne karşı koy (kendi evcil hayvan projen değilsen). Herhangi bir ilave kod tasarlanmalı, yazılmalı, test edilmeli ve korunmalıdır. Müşteri / işletme tarafından istenmiyorsa - bunun kaynaklarınız üzerinde büyük bir boşa harcanması riskiyle karşı karşıyasınız.