Modern yazılım geliştirmede iyi kod imkansız mı? [kapalı]

Görünüşe göre geliştirici araçları daha sağlam ve sağlam hale geldi, iyi kod yazmak zor bir iş haline geldi. Bu araçlar daha güçlü olsa bile, kod kalitesi daha iyi olamaz. İki önemli faktörle karşılaşıyorum, daha az zaman var ve projeler daha karmaşık. Bugün kullandığımız araçlar daha güçlü olduğu için daha karmaşık kod yazmak daha kolaydır, ancak planlamak için zamana sahip olmak ve geriye bakmadan kod kalitesini düşürür, hataları ve bakımı artırır. Daha önce karmaşık kod yazmadık. Daha karmaşık bir kod yazıyoruz.

Sorum şu: Daha güçlü bir dil ve araçlara sahip olduğumuzu düşünürsek.

• İyi kod yazmak neden daha zordur?
• Faktörler, zaman ve karmaşıklık buna katkıda bulunur mu?
• Metodolojiler doğru uygulanmıyor mu?

Düşündüğüm proje türü, büyük karmaşıklığa ve iş mantığına sahip kurumsal uygulama. “İyi kod” un tanımı bireyseldir, lütfen “iyi kod” un yorumuna takılmayın.

İçeri DeMarco ve Lister da belirttiği gibi PEOPLEWARE bazı 20ish yıl önce başarısız yazılım projelerinin büyük çoğunluğu nedeniyle teknik zorluklar, ancak sosyolojik sorunlara değil başarısız . Son on yılda, araçlarımız ne kadar gelişmiş olursa olsun bu durum değişmedi.

Yanlış yönetim, gerçekçi olmayan beklentiler, iş için doğru insanları alamama ve / veya işlerini yapmalarına izin vermeme, sonuç olarak onları muhafaza edememe; SW geliştirme çalışmaları için uygun olmayan işyerleri ve aletler; işlenmemiş kişisel çatışmalar; siyaset ; bunlar, bir projeyi en başından beri mahvedebilecek tipik sorunlardan sadece birkaçıdır.

İyi kod yazmak neden daha zordur?

İyi kod yazmanın on yıl önce olduğundan çok daha zor olduğuna ikna olmadım. Aslında, makine kodu veya montajla karşılaştırıldığında, şu anda ana akımda sahip olduğumuz her şeyin kullanımı çok daha kolay. Sadece daha fazlasını üretmemiz gerekebilir.

Sadece söz konusu faktörler, zaman ve karmaşıklık yüzünden mi?

Evet, araçlarımızın gücü arttıkça ulaşılabilir karmaşıklık kesinlikle arttı (ve artmaya devam ediyor). Başka bir deyişle, sınırları zorlamaya devam ediyoruz. Bana öyle geliyor ki, o günün en büyük zorluklarını çözmek için 30 yıl önce olduğu gibi bugünün en büyük zorluklarını çözmek de aynı derecede zor.

OTOH, alan çok büyüdüğünden, 30 yıl öncesine göre artık çok daha "küçük" veya "bilinen" sorunlar var. Bu problemler artık teknik olarak zor olmalı (olmamalı), fakat ... burada en üst seviyeye giriyor :-(

Ayrıca o zamandan beri programcıların sayısı çok arttı. Ve en azından kişisel algılarım, ortalama tecrübe ve bilgi seviyesinin azalmasıdır, çünkü bu alana sürekli olarak gelen gençler, onları eğitebilecek yaşlılardan çok daha fazladır.

Metodolojiler doğru bir şekilde uygulanmıyor mu?

IMHO kesinlikle hayır. DeMarco ve Lister'ın big-M Metodolojileri hakkında sert sözleri var. Hiçbir Metodolojinin bir projenin başarılı olamayacağını söylüyorlar - sadece ekipteki insanlar başarabilir. OTOH, övdükleri küçük-m metodolojileri şu anda yaygın olarak yayılan "çevik" olarak bildiğimiz şeye oldukça yakın (iyi bir nedenden dolayı IMHO). Sadece 10 yıl önce yaygın olarak bilinmeyen birim testi ve yeniden düzenleme gibi iyi uygulamalardan bahsetmiyorum ve günümüzde birçok mezun bile bunu biliyor.

Gerçekçi olmayan son tarihler altında kodlama ve teknik borçlarla ilgili konular Weinberg '71 ve Brooks '72'den beri bilinmektedir. Bundan önce literatürün çevrimiçi olarak yayınlanması zorlaşıyor, ancak eminim aynı şeyi söyleyen eski CDC, IBM ve NASA raporları var.

Bence hepimizin "İyi Kod" için kendi fikirleri ve eşikleri var. Bununla birlikte, hepsinin katkıda bulunduğu bir takım sorunlar vardır:

• "Çalıştırın sonra geliştirin" yanlış uygulanması, ölü kod ve her biri kod tabanında yalnızca bir kez kullanılan aynı yöntemin 10 farklı varyantını bıraktığımız anlamına gelir. Bu ţeyler asla temizlenmiyor gibi görünüyor.
• Zaman ve bütçe eksikliği. Müşteri 3 ay içinde 100 yeni özellik istiyor, bazıları önemsiz değil ve doğrudan göremedikleri şeylere para harcamak istemiyor.
• Bakım eksikliği. Kabul edelim, bazı geliştiriciler kodun diğerlerinden daha fazla nasıl göründüğünü ve davrandığını önemsiyorlar. Örnek için ilk madde işaretine bakın.
• "İyi kod" un nasıl oluşturulacağını gerçekten bilmiyoruz. İyi kod kavramım sürekli gelişiyor. On yıl önce iyi olduğunu düşündüğüm artık o kadar iyi değil.
• "İyi kod" bir değer yargısıdır. "Çalışır" dışında ve bilinen bir hata yoktur, iyi kod için başka herhangi bir kriter aslında bir fikir meselesidir.

Sonunda, "iyi" veya "en iyi" peşinde koşmaktan daha iyi bir yol izlemenin en iyisi olduğunu düşünüyorum . En iyi kodu orada görürsek, bu şekilde tanıyabilir miyiz?

İyi kod yazmak neden daha zordur?

Çünkü yazılım, soyutlama katmanlarının üstüne giderek daha fazla inşa ediliyor. Geliştirmeyi daha kolay ve daha hızlı hale getirdiğini iddia eden her yeni teknoloji, bir geliştiricinin anlaması gereken bir karmaşıklık düzeyi daha ekliyor. Şimdi, bu soyutlamanın üretkenliğe büyük faydası olabilir, ancak neyi saklamaya çalıştıklarını anlamıyorsanız, yazılımı hatalara ve düşük kaliteye daha duyarlı hale getirir.

Modern yazılım geliştirmede iyi kod imkansız mı?

Gerçekten de mümkün değil. Ama daha önce duyduğunuz sebeplerden herhangi biri için değil.

Projelerin büyük çoğunluğunun kapsamı bir insan beyninin kapasitesinin çok ötesindedir. Bu yüzden insanlar soyutlama fikrini ortaya attılar , bu da detayları saklamaya devam ediyor ve dalların yoğunluğu (ele alınacak bilgi miktarı) kabul edilebilir bir orana düşene kadar soyutlama ağacına tırmanıyor.

Bunu yaptık, karmaşıklık sorununu çözdük, ama bu daha önce yaşadığımız daha büyük sorunu çözmedi.

Bizim için hala çok karmaşık.

Yüksek kaliteli bir çözüm oluşturmak için, her şeyi aynı anda görebilmeli ve anlayabilmeliyiz , yani tüm modüller büyük ve tüm küçük uygulama detaylarında. Aynı anda tutarsızlıkları görmek için, tüm kod parçalarını olası tüm senaryolar bağlamında görün ve tüm kod tabanını aynı anda optimize edin.

Bunu asla yapamayacağız.

Ve eğer yapamazsak asla kalite kodu üretmeyiz.

Yöneticiler modüllerin dağılmasını görecek, ancak modül başına dahili sorunları ve sınırlamaları bilmeyeceklerdir.

Modül programcıları yerel sınırlamaları bilirler, ancak daha büyük bir resim bağlamında optimize edemezler.

Yöneticiler ve programcılar arasında (ve hatta programcılar arasında) anlayışı iletmenin bir yolu yoktur. Ve olsa bile, insan beyninin kapasitesi bunu başaramadı.

Denemeye devam etmek dışında yapabileceğimiz çok az şey var (boşuna bir egzersiz). Kodu az ya da çok çalışır halde tutalım ve hayatın tadını çıkaralım.

Sorunuzun önermesini inkar ediyorum. İyi kod yazmak her zamankinden daha kolay ve bu nedenle daha önce uğraştığımız sorunları çok daha fazla ele alıyoruz.

Herhangi bir satıcı seçmek istemiyorum, ancak Windows 1.0 ile Windows 7 karşılaştırın. İkincisi binlerce kat daha fazla kod içeriyor, ancak çökmeler arasındaki ortalama süre yüz kat arttı. Windows 3.1'den beri bir Excel belgesini bir Word belgesine gömebilmemiz gerekiyordu, ancak bu günlerde az çok çalışıyor.

"Bugünlerde ördek yazmanız ve VM ile çocuklarınız" duygusallığına düşmek istemiyorsanız, 80'lerde iyi kod yazmanın ne kadar zor olduğu hakkında hiçbir fikriniz olmadığını öneririm: TINY, SMALL ve HUGE bellek modelleri, kaplamalar , kiracı olmayan işletim sistemi çağrıları (titreme). Tüm bunlara iyi kurtuluş.

Modern uygulamalar şunlardır çevreleri daha zengin ve çok yönlü daha çünkü onlar, 20-30 yıl öncesine göre daha karmaşık.

Bir DOS programının, kullanıcıdan sonraki tuşa basmayı bekleyen sıkı bir döngüde oturması ve karşılık gelen kodu çağırması ve bir sonraki tuşa basmayı beklemeye geri dönmesi tipikti.

Fareyi TÜMÜ'nde hiçbir şey için kullanamayacağınız herhangi bir modern uygulamada ciddi bir açıklama sorunu var. Kullanıcının yazdığı, kullanıcıya en yeni girişleri gösteren uygulamada RSS beslemeleri güncellenirken, kullanıcının yazması, fareyle tıklaması ve yazmaya devam etmesi mümkün olduğu için, herhangi bir sırada olabilir.

Tüm bu çoklu görevler, düşünmeniz gereken tek şey kullanıcının anahtarlarından çok daha karmaşık. Bu gerçekten iyi kod yazmayı zorlaştırır.

Umarım araştırmacılar, çoklu görev programlarını geliştiriciler açısından nasıl daha kullanışlı hale getirebileceğimizi anladığında, bu kolaylaşabilir, ancak şimdilik bunu iyi yapmaya çalışan herkesle sıkışıp kaldık, ancak nasıl yapılacağını bilmiyoruz o.

Bana öyle geliyor ki, yazılım mevcut işlemci hızını, belleği, diski ve programcı süresini dolduracak şekilde genişledi. Yazılım bunun çok daha fazlasını başardığı için iddia edilebilir. Eminim çok daha fazlasını başarır, ama şişmeyi haklı çıkarmak için yeterli değildir.

Sanırım hatırlamaya değer eski bir bilim yasası var:

Doğa bir boşluktan nefret eder.

Francois Rabelas (Fransız keşiş ve hiciv 1494-1553)

Aslında, iyi kod yazmanın daha kolay hale geldiğini düşünüyorum, yani son on yılda beklendiği gibi çalışan ve sürdürülebilen programlar. Mevcut araçlar şimdi daha iyi, kütüphaneler daha olgun ve kapsamlı, donanım çok daha hızlı hale geldi, bu yüzden optimizasyon numaralarını kullanmak zorunda değiliz.

Öyleyse neden yapmıyoruz?

IMO'nun ana nedeni, sürekli olarak şeyleri kötüye kullanmanın yollarını ve mazeretlerini aramamızdır. Bir Windows yürütülebilir dosyası oluşturmak gibi eski moda, kolay, muhtemelen sıkıcı bir şekilde gitmek yerine, mümkün olanın sınırlarını zorluyoruz ve örneğin bir web uygulaması olarak PhotoShop gibi bir şeyi yeniden yaratmanın yollarını arıyoruz. Neden? Çünkü yapabiliriz. Ya da en azından öyle düşünüyoruz.

En son ne zaman ANYONE ne zaman bir istismar yazmadı ya da meclisle dolaştırıldı (çekirdek bilgisayar korsanlarını ve ASIC adamlarını saymıyor)? C çekirdek kütüphanelerinde kaç hata bulundu? Neredeyse hiçbiri ve birkaç. Söylediğim tek şey insanların mükemmel kod alabilmeleri. Daha iyi araçlar ve diller, onu daha az 'gerekli' ve daha 'isteğe bağlı' yapar. Hepimizin gerçekten korkunç bir kod yazmamız gerektiğini düşünmüyorum, ama karmaşık mantıksal yapıları düşündüğümde ... hiç kimse montajda karma dizilerle bir şeyler yazmayı hayal etmezdi. Karmaşık bir yapı kullanmak yerine mantığı işlemek için “daha ​​iyi” bir yol olmalıydı. Kod güzel olsa bile, bazen yaklaşım o kadar zarif değildir. Sanırım bahsettiğiniz problemi çözüyor. İyi kod her zaman organize değildir,

Bence bunun nedeni, daha iyi araçlar ve daha hızlı yanıt veren bilgisayarlar, birkaç yıl (veya birkaç on yıl) öncesine göre çok daha fazla nihai ürün karmaşıklığı perunit süresi elde etmeyi umduğumuz anlamına geliyor. Bu yüzden uygulamaların karmaşıklığı artmaya devam ediyor ve makul bir verimlilik düzeyinin ne olduğuna dair varsayımlarımız büyümeye devam ediyor.

Çalıştığım yerde, geliştiriciler her zaman acele ediyorlar (çünkü müşterilerin istedikleri her zaman daha fazla şey var, o zaman için zaman var). Bu yüzden çok sayıda kod bloğu, minimum düzenleme ile ve onları gerçekten anlamak için çaba sarf etmeden kopyalanır. Ve elbette hatalar yapılır. Bir geliştiricinin optimizasyonu geçerli kılan varsayımların onu nereye koyduğu doğru olmadığını fark etmeden optimize ettiğim bazı kodları kopyaladığı bir hatayı düzelttim.

Bütün bunlar hem içsel (kendi beklentilerimiz) hem de organizasyonlarımızdan beklentilerle ilgilidir. Mümkün olduğunca kısa sürede mümkün olduğunca çok yapmaya çalışıyoruz. Ve hatalar kaçınılmaz olarak sonuçlanır.

Ayrıca bilgisayar duyarlılığı hızlı bir hızlı düzenleme, daha sonra bir derleme ve test çalıştırmasını teşvik eder. Eski eski günlerde (35 yıl önce olduğu gibi), geri dönüş o kadar yavaştı ki, kodu yazdıracağım (daha sonra kaynak kartlardı) ve destemi göndermeden önce kodun manuel bir adımını atıyorum. Şimdi, derleme ve yürütme işlemlerini düzenliyoruz. Bu nedenle, yöntemsel kod geçişi yoluyla fark edeceğimiz birçok hata, şimdi derleyiciye ve / veya bunun yerine yakalamak için birim test paketine güveniyoruz.

İnsanlar iyi kod üretmede nasıl kötüleşti?

Eğer alırsan .NET ve C # gibi bir dil, örneğin, ben kodlama iddia ediyorum (ve bunu tek platform / dil olmadığını fark) de bağlı Visual Studio içinde birçok şeyin otomasyona çok, çok daha kolay hale geldi ortamı.

Eğer bir şey varsa, şimdi kodlama ve geliştirme sürecinde bize rehberlik edebilecek çok sofistike IDE'lere sahip olmamız, "iyi kod" u elde etmeyi kolaylaştırıyor.

Programcılar artık parantez ve parantez ve yeni satırlar yazmak ve yöntem çağrılarını ve sınıf adlarını hatırlamak için çok fazla zaman harcamak yerine aslında iyi bir yapı üretmeye odaklanabilirler.

Benim görüşüm.

Evet, bir endüstri olarak iyi yöntembilim olarak bilinen şeyleri uygulamıyoruz. Kaynak: Steve McConnell'in Construx Yazılım Yazılımı Geliştirmesinin Düşük Asılı Meyvesi .

kod kalitesi daha iyi değil

lütfen “iyi kod” un yorumuna saplanmayın

Harika mantıklı totoloji.

Kod daha iyi olamaz çünkü insanlar "iyi" tanımını değiştirmeye devam eder.

Eğer "iyi kodu" tartışabiliyorsanız, kıyaslayamazsınız ve bunun "bir meydan okuma" olup olmadığına gerçekten karar veremezsiniz.