Bir zamanlar sevdiğiniz programlama uygulaması hakkında fikrinizi değiştirdiniz mi? [kapalı]

Programlarken hepimiz kullandığımız ve güvendiğimiz uygulamalar ve kalıplar geliştiririz. Ancak, zamanla anlayışımız, olgunluğumuz ve hatta teknoloji kullanımımız değiştikçe, bir zamanlar harika olduğunu düşündüğümüz bazı uygulamaların olmadığını (veya artık geçerli olmadığını) fark ederiz.

Bir zamanlar oldukça sık kullandığım, ancak son yıllarda değiştiğim bir uygulamaya örnek, Singleton nesne modelinin kullanımıdır .

Kendi deneyimlerim ve meslektaşlarımla yaptığım uzun tartışmalar sayesinde, tekillerin her zaman arzu edilmediğini anladım - test etmeyi daha zor hale getirebilirler (alay etme gibi teknikleri engelleyerek) ve bir sistemin parçaları arasında istenmeyen bağlantı oluşturabilirler. Bunun yerine, artık tekillerin doğasını ve varlığını sistemin umursamayan veya bilmesi gereken kısımlarından gizleyen nesne fabrikaları (tipik olarak bir IoC konteyneri ile) kullanıyorum. Bunun yerine, bu tür nesnelere erişim elde etmek için bir fabrikaya (veya hizmet bulucuya) güvenirler.

Kendini geliştirme ruhuyla topluma sorularım:

• Son zamanlarda hangi programlama kalıplarını veya uygulamaları yeniden gözden geçirdiniz ve şimdi kaçınmaya çalışıyorsunuz?
• Onları neyle değiştirmeye karar verdiniz?

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

Tek dönüş noktaları.

Bir zamanlar her yöntem için tek bir dönüş noktası tercih ettim, çünkü bununla rutinin gerektirdiği herhangi bir temizliğin gözden kaçmamasını sağlayabiliyordum.

O zamandan beri, çok daha küçük rutinlere geçtim - bu yüzden temizlemeyi gözden kaçırma olasılığı azaldı ve aslında temizleme ihtiyacı azaldı - ve erken dönüşlerin kodun görünen karmaşıklığını (iç içe geçme düzeyi) azalttığını gördüm . Tek bir dönüş noktasının yapaylıkları - "sonuç" değişkenlerini etrafta tutmak, bayrak değişkenlerini tutmak, henüz yapılmamış durumlar için koşul cümleleri - kodu gerçekte olduğundan çok daha karmaşık görünmesini sağlar, okumayı ve sürdürmeyi zorlaştırır. Erken çıkışlar ve daha küçük yöntemler, gitmenin yoludur.

• İlk denemede her şeyi mükemmel bir şekilde kodlamaya çalışmak.
• Kodlamadan önce mükemmel OO modeli oluşturmaya çalışmak.
• Her şeyi esneklik ve gelecekteki iyileştirmeler için tasarlamak.

Tek kelimeyle aşırı mühendislik .

Macar gösterimi (hem Formlar hem de Sistemler). Her şeyin önekini kullanırdım. strSomeString veya txtFoo. Şimdi someString ve textBoxFoo kullanıyorum. Yeni birinin gelip alması çok daha okunaklı ve daha kolaydır. Ek bir bonus olarak, onu tutarlı tutmak önemsizdir - kontrolü camelCase ve kullanışlı / açıklayıcı bir ad ekleyin. Forms Hungarian'ın her zaman tutarlı olmama dezavantajı vardır ve Systems Hungarian size pek bir kazanç sağlamaz. Tüm değişkenlerinizi bir araya getirmek, özellikle modern IDE'lerde o kadar kullanışlı değildir.

"Mükemmel" mimari

Ben ile geldi birkaç yıl önce mimarlık. Kendimi teknik olarak yapabildiğim kadar ittim, böylece% 100 gevşek bir şekilde bağlı katmanlar, kapsamlı delege kullanımı ve hafif nesneler vardı. Teknik bir cennetti.

Ve berbattı. Mimarinin teknik saflığı, geliştirici ekibimi sonuçlar üzerinde mükemmelliği hedefleyerek yavaşlattı ve neredeyse tam bir başarısızlık elde ettim.

Artık çok daha basit, teknik olarak mükemmel olmayan bir mimariye sahibiz ve teslimat oranımız fırladı.

Caffine kullanımı. Bir zamanlar beni uyanık tuttu ve kodun parmaklarımdan ateşli bir akışkanlıkla uçtuğu muhteşem bir programlama havasında tuttu. Şimdi hiçbir şey yapmıyor ve eğer sahip olmazsam başım ağrıyor.

Kodu yorumlamak. Eskiden kodun değerli olduğunu ve kendi hazırladığınız o güzel taşları silemeyeceğinizi düşünürdüm. Ekli bir TODO veya NOT olmadıkça karşılaştığım herhangi bir yorumlanmış kodu şimdi siliyorum çünkü onu içinde bırakmak çok tehlikeli. oradaydı: yakın zamanda yorum yaptılar mı? bu bir geliştirme ortamı değişikliği mi? neden bu ilgisiz bloğu yapıyor?

Cidden kodu yorumlamamayı ve bunun yerine silmeyi düşünün. İhtiyacınız olursa, hala kaynak kontrolünde. YAGNI gerçi.

# Bölge direktiflerinin aşırı kullanımı / kötüye kullanılması. Bu sadece küçük bir şey, ancak C # 'da daha önce sınıflarımı düzenlemek için her yerde # bölge yönergelerini kullanırdım. Örneğin, bir bölgedeki tüm sınıf özelliklerini birlikte gruplardım.

Şimdi eski koda bakıyorum ve çoğunlukla onlardan rahatsız oluyorum. Bunun çoğu zaman işleri daha net hale getirdiğini sanmıyorum ve bazen sizi yavaşlatıyorlar. Bu yüzden şimdi fikrimi değiştirdim ve iyi düzenlenmiş sınıfların çoğunlukla bölge yönergeleri olmadan daha temiz olduğunu hissediyorum .

Genel olarak şelale gelişimi ve özel olarak, bir şekilde kanonik olması beklenen eksiksiz ve kapsamlı işlevsel ve tasarım şartnamelerinin yazılması ve ardından bunların doğru ve kabul edilebilir bir şekilde uygulanmasının beklenmesi uygulaması. Onun Scrum ile değiştirildiğini gördüm ve ondan kurtulduğumu söylüyorum. Basit gerçek şu ki, müşteri ihtiyaçlarının ve arzularının değişen doğası, herhangi bir sabit spesifikasyonu etkili bir şekilde yararsız hale getiriyor; soruna gerçekten doğru bir şekilde yaklaşmanın tek yolu, yinelemeli bir yaklaşımdır. Elbette, Scrum sihirli bir değnek değildir; Birçok kez kötüye kullanıldığını ve kötüye kullanıldığını gördüm. Ama şelaleden daha iyi.

Asla çökmez.

Çok iyi bir fikir gibi görünüyor, değil mi? Kullanıcılar çökecek programları sevmezler, öyleyse çökmeyen programlar yazalım ve kullanıcılar programı beğenmeli, değil mi? Ben böyle başladım.

Bugünlerde, işe yaramazsa, çalışıyormuş gibi davranmaması gerektiğini düşünmeye daha meyilliyim. İyi bir hata mesajıyla mümkün olan en kısa sürede başarısız olun. Bunu yapmazsanız, programınız birkaç talimat sonra daha da sert çökecektir, ancak bazı tanımlanmamış boş işaretçi hatasıyla hata ayıklamanız bir saat sürecek.

En sevdiğim "çökme" kalıbı şudur:

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

Şimdi, kullanıcılarınızdan hata mesajını kopyalayıp yapıştırmalarını ve size göndermelerini istemek yerine, günlük girişini bulmaya çalışırken günlüklere dalmanız gerekecek. (Ve geçersiz bir kullanıcı kimliği girdiklerinden, günlük girişi olmayacak.)

Tasarım kalıplarını her tanıdığımda uygulamanın mantıklı olduğunu düşündüm .

Çalıştığım dil çok daha zarif veya daha kolay çözümlere izin verirken, aslında yabancı programlama dillerinden stilleri kopyaladığımı bilmiyordum.

Birden çok (çok) farklı dil kullanmak gözlerimi açtı ve bana ait olmayan sorunlara başkalarının çözümlerini yanlış uygulamak zorunda olmadığımı fark etmemi sağladı. Ruby gibi bir dilde uygulanan fabrika modelini gördüğümde şimdi titriyorum .

Saplantılı test. Eskiden önce test geliştirmenin kuduz bir savunucusuydum. Bazı projeler için bu çok mantıklı geliyor, ancak her bir işlevsellik parçası için birim testleri yazma doktrinine kölece bağlı kalmanın birçok proje için sadece olanaksız değil, aynı zamanda zararlı olduğunu da fark ettim.

Gerçekten, herhangi bir şeye kölece bağlı kalmak zararlı olabilir.

Bu küçük bir şey, ama: Küme parantezlerinin nereye gittiğini önemsemek (aynı satırda mı yoksa sonraki satırda mı?), Önerilen maksimum kod satır uzunlukları, değişkenler için adlandırma kuralları ve stilin diğer öğeleri. Herkesin bunu benden daha çok önemsediğini fark ettim, bu yüzden bugünlerde çalıştığım her kimse ile devam ediyorum.

Düzenleme: Bu varlığın istisnası, elbette, en çok önemseyen (veya bir grubun stilini belirleyecek konumda olan) olduğumda. Bu durumda ne istersem onu ​​yaparım!

(Bunun tutarlı bir stile sahip olmamakla aynı şey olmadığını unutmayın. Bir kod tabanında tutarlı bir stilin okunabilirlik için çok önemli olduğunu düşünüyorum.)

Belki de o zamandan beri fikrimi değiştirdiğim en önemli "programlama uygulaması", kodumun herkesten daha iyi olduğu fikridir. Bu, programcılar için yaygındır (özellikle yeni başlayanlar).

Fayda kitaplıkları. Bir gün onları başka bir yerde kullanabileceğim teorisi ile çeşitli yardımcı yöntemler ve sınıflar içeren bir derlemeyi taşıyordum.

Gerçekte, çok sayıda kötü organize edilmiş işlevsellik parçalarına sahip dev bir ad alanı yarattım.

Şimdi, onları yarattığım projede bırakıyorum. Muhtemelen ihtiyacım olmayacak ve eğer yaparsam, onları her zaman daha sonra yeniden kullanılabilir bir şeye yeniden düzenleyebilirim. Bazen onları ortak bir derlemeye olası çıkarma için // YAPILACAKLAR ile işaretleyeceğim.

Kodladığımdan fazlasını tasarlıyorum. Bir süre sonra analiz felci olur.

İş mantığını gerçekleştirmek için bir DataSet kullanımı. Bu, kodu veritabanına çok sıkı bir şekilde bağlar, ayrıca DataSet genellikle SQL'den oluşturulur ve bu da işleri daha da kırılgan hale getirir. SQL veya Veritabanı değişirse, DataSet'in dokunduğu her şeye damlama eğilimi gösterir.

Bir nesne yapıcısı içinde herhangi bir iş mantığını gerçekleştirmek. Kalıtım ve aşırı yüklenmiş kurucular yaratma yeteneği, bakımı zorlaştırma eğilimindedir.

Kısaltılmış değişken / yöntem / tablo / ... İsimler

Bunu her zaman yapıyordum, adların uzunluğu konusunda zorunlu sınırlamalar olmadan dillerde çalışırken bile (muhtemelen 255 veya benzeri bir şeydi). Yan etkilerden biri, (standart olmayan) kısaltmaları açıklayan kod boyunca dağılmış çok sayıda yorumdu. Ve tabii isimler herhangi bir nedenle değiştirildiyse ...

Şimdi, şeylere gerçekten oldukları gibi, iyi açıklayıcı isimlerle hitap etmeyi tercih ederim. yalnızca standart kısaltmalar dahil . Yararsız yorumlar eklemeye gerek yok ve kod çok daha okunaklı ve anlaşılır.

Kurumsal Kitaplık gibi mevcut Veri Erişimi bileşenlerini özel bir yardımcı yöntem katmanıyla sarma.

• Kimsenin hayatını kolaylaştırmaz
• İçinde hatalar olabilecek daha fazla kodu
• Birçok kişi EntLib veri erişim bileşenlerini nasıl kullanacağını bilir. Yerel ekip dışında hiç kimse şirket içi veri erişim çözümünün nasıl kullanılacağını bilmiyor

Nesne tabanlı programlamayı ilk olarak 1984'te Smalltalk hakkında okurken duydum, ancak 1992'de cfront C ++ derleyicisini kullanana kadar bir oo diline erişimim yoktu. Nihayet 1995'te Smalltalk'ı kullanmaya başladım. Oo'yu merakla bekledim. teknoloji ve yazılım geliştirmeyi kurtaracağı fikrini satın aldı.

Şimdi, oo'yu bazı avantajları olan bir teknik olarak görüyorum, ancak bu araç kutusunda sadece bir araç. İşimin çoğunu Python'da yapıyorum ve genellikle sınıf üyesi olmayan bağımsız işlevler yazıyorum ve genellikle geçmişte bir sınıf oluşturduğum yerlerde veri gruplarını tuple veya listelerde topluyorum. Veri yapısı karmaşık olduğunda veya verilerle ilişkili davranışa ihtiyacım olduğunda hala sınıflar oluşturuyorum, ancak buna direnme eğilimindeyim.

Aslında doğru anlarsam Java nesnelerini kullanabilmesine rağmen, zaman bulduğumda Clojure'da bazı işler yapmakla ilgileniyorum. Oo'nun öldüğünü söylemeye hazır değilim, ama şahsen eskiden hayran olduğum kişi değilim.

C # 'da kullanarak _notation özel üyeler için . Şimdi bunun çirkin olduğunu düşünüyorum.

Daha sonra this.notationözel üyeler için değiştirdim , ancak onu kullanırken tutarsız olduğumu fark ettim, bu yüzden onu da bıraktım.

Uygulamadan önce üniversitenin tavsiye ettiği tasarım yöntemini kullanmayı bıraktım. Kaotik ve karmaşık bir sistemde çalışmak beni tavrımı değiştirmeye zorladı.

Elbette hala kod araştırması yapıyorum, özellikle daha önce hiç dokunmadığım koda dokunmak üzereyken, ama normalde bir şeyi önce yapmak için mümkün olduğunca küçük uygulamalara odaklanmaya çalışıyorum. Bu birincil hedeftir. Ardından mantığı kademeli olarak iyileştirin ve tasarımın kendi kendine görünmesine izin verin. Programlama yinelemeli bir süreçtir ve çevik bir yaklaşımla ve birçok yeniden düzenleme ile çok iyi çalışır.

Kod, neye benzeyeceğini düşündüğünüz ilk şeye hiç bakmayacaktır. Her seferinde oluyor :)

Kontrat bazında tasarım konusunda çok iyiydim. Bu, tüm işlevlerimin başına çok sayıda hata denetimi koymak anlamına geliyordu. Endişelerin ayrılması açısından sözleşmeler hala önemlidir, ancak kodumun ne yapmaması gerektiğini uygulamaya çalışmak yerine, ne yaptığını doğrulamak için birim testleri kullanmaya çalışıyorum.

Daha özlü olduğu için birçok yöntemde / sınıfta statikleri kullanırdım. Testler yazmaya başladığımda bu pratik çok hızlı değişti.

Kontrol Edilen İstisnalar

Kağıt üzerinde harika bir fikir - sözleşmeyi açıkça tanımlar, hataya yer yoktur veya bazı istisna durumlarını kontrol etmeyi unutur. İlk duyduğumda satıldım.

Elbette pratikte çok karışık bir hal aldı. Bugün, mirası gizleyen Spring JDBC gibi kitaplıklara sahip olma noktasına kadar, istisnaları ana özelliklerinden biri olarak kontrol etti.

Değerli her şeyin yalnızca belirli bir dilde kodlandığı. Benim durumumda C'nin şimdiye kadarki en iyi dil olduğuna inandım ve başka bir dilde hiçbir şeyi kodlamak için hiçbir nedenim olmadı ... asla.

O zamandan beri birçok farklı dili ve sundukları faydaları / işlevleri takdir etmeye başladım. Küçük bir şeyi kodlamak istersem - hızlı bir şekilde - Python kullanırdım. Büyük bir proje üzerinde çalışmak istersem C ++ veya C # ile kod yazardım. Bir beyin tümörü geliştirmek istersem Perl'de kod yazardım .

Biraz yeniden düzenleme yapmam gerektiğinde, hemen başlamanın ve yeni tasarımı uygulamaya geçirmenin, bağlantıları işe yarayana kadar düzeltmenin daha hızlı ve daha temiz olduğunu düşündüm. Sonra, yeni tasarıma doğru yavaş ama güvenilir bir şekilde ilerlemek için bir dizi küçük yeniden düzenleme yapmanın daha iyi olduğunu fark ettim.

Belki de kodlama uygulamalarımda ve diğerlerinde değişen en büyük şey, uygulamalardaki davranışların ve işlevselliğin temeli olarak internetten indirilen dış sınıfların ve kitaplıkların kabul edilmesidir. Üniversiteye gittiğimde okulda, kendi kodumuzla işleri nasıl daha iyi hale getirebileceğimizi anlamaya ve sorunlarımızı çözmek için dile güvenmeye teşvik edildik. Kullanıcı arayüzünün ve hizmet / veri tüketiminin tüm yönlerindeki gelişmelerle, bu artık gerçekçi bir kavram değil.

Bir dilde asla değişmeyecek bazı şeyler vardır ve bu kodu daha basit bir işlemle ve yazmam gereken daha az satır kodla saran bir kitaplığa sahip olmak bir nimettir. Bir veritabanına bağlanmak her zaman aynı olacaktır. DOM içinde bir öğe seçmek değişmeyecektir. Sunucu tarafı komut dosyası aracılığıyla bir e-posta göndermek asla değişmez. Bu defalarca yazmak zorunda kalmak, uygulamadaki temel mantığımı geliştirmek için kullanabileceğim zamanı boşa harcıyor.

Tüm sınıf üyeleri başlatılıyor.

Her sınıf üyesini bir şeyle, genellikle NULL ile açıkça başlatırdım. Bunun farkına vardım:

• normalde her değişkenin okunmadan önce iki kez başlatıldığı anlamına gelir
• aptalca çünkü çoğu dilde değişkenleri otomatik olarak NULL olarak başlatır.
• aslında çoğu dilde hafif bir performans vuruşunu zorlar
• daha büyük projelerde kodu şişirebilir

Ben de sizin gibi, uygulamalarımın çeşitli bileşenleri arasındaki eşleşmeyi azaltmak için IoC modellerini benimsedim. Her bir bileşeni olabildiğince bağımsız tutabildiğim sürece, bakımı ve parça değiştirmeyi çok daha basit hale getiriyor. Ayrıca, veritabanı yönetimi işlerini basitleştirmek için NHibernate gibi daha fazla nesne ilişkisel çerçeveler kullanıyorum.

Özetle, yazılımı daha hızlı ve verimli bir şekilde oluşturmaya yardımcı olmak için "mini" çerçeveler kullanıyorum. Bu mini çerçeveler çok fazla zaman kazandırır ve doğru yapılırsa, bir uygulamanın bakımını son derece basit hale getirebilir. Kazanmak için Tak Çalıştır!