Kodum kokladığında ne yapmalıyım?

Ben acemi bir programcıyım ve sık sık kendi projelerim üzerinde çalışırken, kodumun tasarımının olabileceği en iyi şey olmadığını hissediyorum ve bu duygudan nefret ediyorum. Sonuçlara bakmak için zaman harcıyorum, ancak daha sonra soyut bir sınıf veya arayüz kullanmak için tasarım desenleri gibi birçok ayrıntıyla kolayca boğuluyorum. Bir kerede her şeyden biraz öğrenmem gerekiyor mu?

Birkaç öneri:

1. İşlevselliği farklı yapı taşlarına ayırarak karmaşıklığı yönetmek için kapsüllemeyi kullanın . Her blok çalışmasını kanıtlayın (birim testleri ile) ve iç ayrıntılarından endişe etmeden kullanabilirsiniz.

2. Yazılım kalıplarını öğrenir ve inceler . Yazılım kalıpları, bilinen, iyi bilinen bazı görevleri gerçekleştirmek için denenmiş ve kanıtlanmış yöntemler.

3. Veri yapılarını inceleyin ve anlayın . Her veri yapısı türü için uygun kullanımları ve performans özelliklerini öğrenin.

4. Programlama dilinizi, güçlü ve zayıf yanlarını ve özelliklerini en iyi nasıl kullanacağınızı iyi bilin.

Bir seferde bunların hepsini biliyorum gerekmez, ancak gerektiği zaman içinde hepsini inceliyoruz.

Benim tavsiyem: endişelenmeyi bırak.

Deneyim en iyi öğretmendir ve kod yazmazsanız deneyim elde edemezsiniz. Ayrıca, kötü tasarlanmış kod edilir yazılı olduğu büyük bir tasarım daha iyidir değil .

Daha fazla kod yazın. Projelerinizi tamamlayın. Kodun ideal olmadığı hissi muhtemelen doğrudur. Ve muhtemelen bu kodla ilgili sorunlarınız olacak. Eğer bu sorunları sahip olunca o kötü olduğunu tam olarak neden öğrenmek istiyorum. İlk elden deneyimlerden, "şeylere bakmaktan" çok daha fazla şey öğreneceksiniz.

Ayrıca, bu "kod kokusu" hissinin ortadan kalkacağını ummayın. İyileştikçe, bazı sorunları çözeceksiniz, ancak yeni, daha belirsiz / gelişmiş olanları fark etmeye başlayacaksınız.

Bu, programcıları başlatmakla ilgili yaygın bir sorundur. Her şeyin mükemmel olması gerektiğini düşünerek felç etmeyin. Bir projeyi asla bitirmemenin en kesin yolu bu. Bir geliştirici olarak öğrenilecek en önemli becerilerden biri, mükemmel ve yeterince iyi arasındaki farktır . Oluşturduğunuz her sistemin geliştirilebileceğini kabul edin. Projelerinizi bitirmeye odaklanın. Bitirdikten sonra geri dönüp onları geliştirebilirsiniz. Sonuçta sürüm 2.0'larımız var.

Bir kerede her şeyden biraz öğrenmem gerekiyor mu?

Umarım değildir. Öte yandan, tüm zaman boyunca öğreniyor ve geliştiriyor olmalısınız .

Kitap okuyun, ders alın, kalifiye olun, üzerinde çalışın ve kendinizi geliştirmelisiniz.

En iyi tavsiyem Robert Harvey'nin önerdiği liste gibi temellere odaklanmak. Yazılım geliştirme, özellikle iyi arayüz tasarımı konusunda, uzaktan bile iyi bir şekilde çalışılması yıllar alan karmaşık bir canavardır. Yazılım geliştirmenin birçok yönünü ilk önce yaşamadan takdir etmek gerçekten zordur. Yorum kodu gibi temel bir şey bile takdir edilebilir. İlk günden itibaren, iyi belgelenmiş kod yazmanız öğretilir. Gerçekten iyi yorumların değerini gerçekten takdir önce aylar önce yazdım anlamaya çalışıyorum bir $$ anlamaya çalışıyorum bir $$ kadar biraz değildi itiraf edeceğim. Aynı şey birçok programlama konsepti için de söylenebilir. Örneğin, veri kapsülleme, düşük bağlantılı modüller ve net temiz arabirimler.

Karşılaştığım en değerli kaynak iş arkadaşlarım. Kötü kod yazacaksın. Sadece kabul et. Sizi bir programcı olarak tanımlayan zaman içinde daha iyi kod yazdığınızdan emin olmak için yapmanız gereken budur. Örneğin, çalışmaya ilk başladığımda, şirketimde herhangi bir resmi kod ya da tasarım inceleme prosedürü yoktu. Çalışmamı daha üst düzey iş arkadaşlarımın eleştirisine tabi tutmayı ve dürüst olmak gerekirse, ilk yıl çalışmamın daha iyi bir parçası için bir aptal gibi hissettim.

Yazılım geliştirme sürekli bir öğrenme deneyimidir. Tonlarca soru sorun, kodunuzu gözden geçirin, daha üst düzey insanların verdiği önerilerin nedenini anlayın, daha üst düzey geliştiricilerin verdiği önerilerin geçerliliğini sormaktan korkmayın ve çoğu yanlış olmaktan korkmayın. Sonunda içgörü faktörü veya bunalmış soluk olma hissi. Kayıt için ... öğrenme eğrileri emmek.

• Birincisi: Yeniden düzenleme (hala kokacak, ancak biraz daha organize olacak)
• İkincisi: Yeniden düzenlenmiş parçaların mantığınızla eşleşmesi için bazı Tasarım Patter'i kullanıp kullanamayacağınıza bakın.
• Üçüncü olarak: işler daha iyi görünmeye başladığında, birinci ve ikinci adımı atmak için harcadığınız zamanı hatırlayın. Bu şekilde yeni bir özellik yazdığınızda, bunu yaparken başka bir süreç olarak düşünmeyeceksiniz.

Yeniden Düzenleme: Mevcut Kodun Tasarımını İyileştirme kitabına bir göz atın, Martin Fowler. Yapmanız gereken ilk şey , kodun okunabilirliğini artırmak ve kodun sürdürülebilirliğini artırmak için karmaşıklığı azaltmak amacıyla kodunuzu yeniden düzenlemektir.

Kodunuzu yeniden düzenlediğinizde, zaten Tasarım Desenleri , Kapsülleme kodu vb.

Bu konu hakkında şimdiye kadar okuduğum en iyi kitaplardan biri. Birçok yararlı tarif sağlar.

Pragmatik Programcı iyi bir kaynaktır . "Bozuk Pencereler" bölümü, kendinizi nerede gördüğünüzü açıklamaktadır. Kısa ve özlü yanıt sorunları düzeltmektir.

Tasarımınızı düzeltmeye başladığınızda, neyi sevmediğinizi anlamanıza yardımcı olur. "Her yere gidiyor" ya da "neden orada yaptım?" Gibi belirsiz cevaplar bulmak kolaydır. Ancak, kullandığınız ortak kalıpların olup olmadığını görmek için zaman ayırın.

• İyi tasarım, kod tabanı boyunca az sayıda kavramı yeniden kullanır (ideal bir kavramdır, ancak pratikte birkaç tane daha ihtiyacınız olabilir)
• İyi bir tasarım, sorunların nerede düzeltileceğini bulmayı kolaylaştıracaktır (KURU prensibi, SRP prensibi)
• İyi bir tasarımın iyi bir hata raporlaması olacaktır (yukarıdaki nokta ile ilgili, ancak genellikle göz ardı edilen bir özellik olduğu için ayrı bir öğe olarak adlandırılır)

Nereye gitmek istediğinizi anladıktan sonra, oraya ulaşmak için küçük, kolayca geri döndürülebilir adımlar atın (yani Yeniden Düzenleme budur). Kodunuzu her geliştirdiğinizde, kodun geri kalanı üzerindeki etkisini göz önünde bulundurun. İşleri daha iyi mi yoksa daha kötü mü yaptın? En azından kaosa düzen getirme yaklaşımım budur.

Programlama konusunda zaten deneyiminiz varsa, neden temiz kod içeren bazı açık kaynak projeleri üzerinde çalışmıyorsunuz ? Sen içine görünebilir BU ilgili bağlantıları içerir SO, söz.

Ayrıca, tasarım desenleri bir zorunluluktur - düşünün, desen sahibi olma fikri, tekerleği yeniden icat etmeden veya buggy kodu yazmadan bilinen sorunları çözmektir.

Son olarak, başınızı temizlemek için bir miktar fonksiyonel programlamaya ihtiyacınız var gibi görünüyor. Başlangıç ​​için Haskell veya Ocaml'a bakın.

Tehlikeli bir canavar değilseniz , kodunuzu inceleyebilecek bir arkadaş bulmalısınız , bunun tersi de geçerlidir. Ayrıca, yeniden ziyaret edilecek veya başkaları tarafından denetlenecek bir şeyler yaparsanız, daha iyi bir şekilde yapmak iyi bir baskıdır.

Ve unutmayın, programlama kodlamadan önce başlar , her zaman fikirlerinizi, planlarınızı tekrar ziyaret edin. Planınız kötüyse, bunu atmak eğlenceli bir eylemdir: kötü bir plana dayanarak bir grup kod (ve oluşturulma zamanı) atma hayal kırıklığını kurtardınız.

Benim tavsiyem her kokuyu ciddiye al ve düzeltmeye çalış. Konuyla ilgili birçok iyi kitap var (Temiz kod ve GOOS en iyi IMHO'dur). Ancak kitaplardan daha fazlası, diğer insanları ve çevrimiçi toplulukları (posta listesi, gruplar) duymak ve tartışmak için konferanslara gider. Yine de daha iyi yerel xxug (dotnetug, sürahi, xpug, vb) katılmaya çalışın veya bir tane buldum.

Diğer programcılarla tartışmak, gerçekten geliştirmeyi bildiğim tek yoldur (diğer özel programcılarla birlikte çalışmak için yeterince şanslı değilseniz).