Daha etkileyici programlama dillerinin gelişimi ile yazılım tasarım spesifikasyonlarına duyulan ihtiyaç önemli ölçüde azaldı mı?

Birkaç yıl önce kendim de dahil olmak üzere birçok BT insanı için ideal yazılım geliştirme süreci, bir kod satırı yazılmadan önce çok sayıda UML diyagramı içeren ayrıntılı tasarım belgelerinin oluşturulmasını içerecektir. (Bu şelale modelinin bir tanımına benziyor, ancak iterasyonların daha küçük olması dışında çevik ile aynı.)

Son iki ya da üç yıl boyunca fikrimi tamamen değiştirdim. Yine de ilişkili test vakalarıyla ilgili ayrıntılı bir gereksinim belirtiminin kesinlikle gerekli olduğunu düşünüyorum. Büyük projeler için, kodlamaya başlamadan önce genel mimarinin bir taslağını da isterim. Ancak geri kalan her şey mümkün olduğunca kod içinde yapılmalıdır. İdeal durumda, kodun kendisi dışında hiçbir yazılım tasarımı açıklaması olmamalıdır.

Bu sonuca nasıl geldim? İşte bazı argümanlar:

geri bildirim

Belge yazma veya diyagram oluşturma araçları çok az geri bildirim sağlar. Evet, UML diyagramlarında bazı tutarlılık kontrolleri yapan modelleme araçları vardır, ancak bunlar sınırlıdır ve çok fazla ek yük ile birlikte gelir.

Geri bildirim olmadan hataları tanımak ve düzeltmek zordur.

Kod yazar yazmaz çok sayıda geri bildirim alırsınız, örneğin:

• Derleyiciden hatalar ve uyarılar
• Statik kod analizi sonuçları
• Birim testleri

Hatalar hızlı bir şekilde tanınabilir ve düzeltilebilir.

Tutarlılık

Kodun belgelerinizle tutarlı olduğundan emin olmak için tekrar tekrar kontrol etmeniz gerekir. Sık değişiklikler varsa, kod ve belgeleri senkronize tutmak zordur.

üstlenmeden

Metin açıklamalarını veya diyagramlarını yeniden düzenleme genellikle zor ve hataya açıkken, kodu yeniden düzenlemek için güçlü araçlar ve teknikler vardır.

Bu çalışmanın yapılabilmesi için bir ön koşul vardır: Kodun okunması ve anlaşılması yeterince kolay olmalıdır. Bu muhtemelen Assembler, Basic veya Fortran ile gerçekleştirilemez, ancak modern diller (ve kütüphaneler) çok daha etkileyici.

Dolayısıyla, argümanlarım geçerliyse, daha az veya daha fazla hafif yazılım tasarım spesifikasyonu ve dokümantasyonu yönünde bir eğilim olmalıdır. Bu eğilim için ampirik kanıt var mı?

Dillerin gittikçe daha anlamlı olduğu fikrini sorgularım. Bugünün ASP.NET kodu c # ile, Visual Basic'te ASP kodu yazarken yaptığımla aynı düzeyde yazıyorum. Hala c ++ kullanıyoruz. Javascript özellikler ekledi, ancak genel olarak dil değişmedi. SQL ile aynı.

Bu diğer değişikliklerin daha önemli olduğunu düşünüyorum:

1. Otomatik birim testlerinin benimsenmesi. Bazı testler söyleyebilirim olan şartname. Dolayısıyla, teknik özellik yazma ihtiyacını ortadan kaldırmadık; onları Word belgelerinden ziyade kodla yazıyoruz.

2. Dağıtım yöntemindeki değişiklikler. Geçmişte bir hata yapmak çok pahalıydı çünkü yazılımınızın güncellenmiş bir kopyasını göndermeniz gerekiyordu. Bu yüzden dikkatli olmalısın. Web tabanlı uygulamalarla, derhal kullanım için düzeltmeler dağıtabilirsiniz ve sorunlara tahmin etmek yerine tepki vermeyi göze alarak kodu ilerledikçe yeniden yapılandırabilirsiniz.

3. Tasarım kalıplarının benimsenmesi. Herkes kalıpları bildiğinde, hiçbir şey tasarlamanız gerekmez; "bir depo fabrikası ekle" diyebilirsiniz ve ekibiniz UML'yi görmeye gerek kalmadan bunu yapmalıdır.

4. SOA'nın veri sözleşmeleri. Bugünlerde hemen hemen her şey SOA. Tek ihtiyacınız olan bir WSDL. Veri aktarım formatlarının tanımlandığı ve belgelendiği günler geride kaldı. Daha RESTful ve mikro hizmetlere yönelik mevcut hareket bu eğilimi sürdürüyor.

5. Yazılımlar daha küçüktür. Kısmen SOA mimarilerinin bir sonucu olarak, ekipler birbirine bağlı daha küçük programlar yazıyorlar. Her bir bileşen daha az karmaşıktır ve daha az ön tasarım gerektirir; ayrıca, bileşenler arasındaki arayüz tanımları tarafından zorlanan yangın kesintileri nedeniyle mimarinin bir bölümünü genel çözümü kırmadan değiştirmek daha kolaydır.

6. Yerleşik kütüphanelerin çok, çok daha fazla kullanımı. .NET CLR rafta bir ton işlevsellik sunar, bu nedenle oturum verilerini önbelleğe almak için bir plan tasarlamaya gerek yoktur. JQuery UI veya Bootstrap gibi üçüncü taraf kütüphaneleri, belirli bir şekilde çalışmak için kod yazma standartlarını belirler. Bunları belgelemenize gerek yok; ekipler sadece bunları kullanabilmelidir.

7. Endüstri olgunluğu. SWE'ler yıllarca ve yıllarını belirli bir hedefe ulaşmak için harcadığınız "Battlestar Galactica" projesi diye bir şey olmadığını öğrendi; o yıllar geçtikten sonra hedef değişmiş olacak. Bugün, pazara sunma zamanının her şeyi tasarımda tam istediğimiz şekilde elde etmekten çok daha önemli olduğunu biliyoruz.

8. Daha iyi ve daha tutarlı eğitimli mühendisler. Bu günlerde (umarım) en iyi uygulamaları anlayan ve ne yapacaklarını söyleyen bir tasarım belgesi olmadan uygulayacak mühendisleri işe alabilirsiniz.

9. TFS gibi üretkenlik araçları, bir kullanım örneğine başvuran ve belirsiz teknik kararlar için birkaç mermi noktası sağlayan basit bir görev yazmanıza olanak tanır. Bundan daha fazlasına ihtiyacınız yok. Geliştiriciler araç aracılığıyla her şeyi gözden geçirebilir, tahmin edebilir, kod incelemeleri alabilir, check-in yapabilir vb. Bu, her şeyi birbirine bağladığı için harici belgelerle çalışmaktan çok daha etkilidir.

Bazı şeyler için hala tasarım belgelerine ihtiyacınız var ... örneğin, uygulamanız farklı ekipler tarafından geliştirilen farklı bileşenlere ayrılırsa, en azından hangi bileşenin hangi gereksinimlerden sorumlu olduğunu söylemeniz gerekir. Ancak, çoğunlukla, günümüzün geliştirme yöntemleri, size kötü bir karar veren bir geliştiriciden kaynaklanabilecek herhangi bir riski yönetme ve içerme araçları sunarken çok daha fazla özgürlüğe izin verir.

Hayır için tartışırım .

Basit bir nedenle

Birkaç yıl önce kendim de dahil olmak üzere birçok BT insanı için ideal yazılım geliştirme süreci, bir kod satırı yazılmadan önce çok sayıda UML diyagramı içeren ayrıntılı tasarım belgelerinin oluşturulmasını içerecektir.

Aşırı Programlama 1990'lardan beri var olduğu için asla "ideal" olarak değerlendirilmemiştir . Ve dediğin gibi:

İdeal durumda, kodun kendisi dışında hiçbir yazılım tasarımı açıklaması olmamalıdır.

Çağlar önce tartışıldı. Örneğin, 1992'den bu efsanevi makale: Yazılım Tasarımı Nedir .

Yukarıda, karmaşık dillere veya IDE'lere ihtiyaç duymadan, son derece evrimsel mimariye ve yinelemeli yaklaşıma sahip "aşırı" bir sürece sahip olabileceğiniz gösterilmiştir.

Bunun yerine, bu "görünüşlü" tasarımın ön planından çok sayıda şema ile değiştiğini ve vaka belgelerini daha evrimsel ve yinelemeli yaklaşıma dönüştürdüğünü söyleyebilirim. dinamik çevre ve kim için daha "çevik" bir ortamda kabul ve çalışmak çok daha kolay.

Buna oldukça katılıyorum ama bence ima ettiğinden çok daha erken başladı. Ayrıca, dışavurumculuktan başka büyük bir faktör olduğunu düşünüyorum. Babam programlamaya ilk başladığında, delikli kartlar yaratmalı ve bilgisayarda zaman ayarlamalıydı. Programınızı çalıştırmak için günde bir şansınız olabilir. Bina kodunu boşa harcamak, başarısız olmasına izin vermek ve sonra düzeltmek için çok zaman yoktu. Belki 2 ya da 3 atışınız var ve eğer çalışmazsa başınız beladaydı.

Bunun riski, programınızı planlamak için çok fazla zaman harcamanın çok önemli olduğu anlamına geliyordu. İnsanlar kodlarını kurşun kalemle yazıp delikli kartlara aktaracaklardı. Teknoloji ilerledikçe, doğrudan terminale kod yazabilirsiniz, ancak hala paylaşılan kaynakları kullanıyordunuz ve CPU pahalıydı. Test ilk metodolojisi o dünyada tamamen savunulamaz olurdu. Eğer önceden plan yapmadıysanız, akranlarınız dirgenlerle masanızda olacaktı.

Bilgi işlem kaynakları inanılmaz bir hızla daha ucuz ve daha iyi hale geldi. Tüm bu uygulamaların geliştirildiği kısıtlamaların çoğu tamamen ortadan kaldırılmıştır. Euphoric'in belirttiği gibi, bundan uzaklaşmak gerçekten 90'larda başladı. Büyük ön tasarımın çoğunun devamı saf atalet olmuştur.

Bu nedenle, evet, programlama dillerinin geliştirilmiş ifadesinin bunu ifade etmesi, kendi belgelerinde ifade kodunun kullanılmasının daha kolay olmasından kaynaklanmaktadır. Kodun ne dediğini söyleyen bir belge üretmenin maliyeti çok yüksektir ve değeri (bir düzeyde kaçınılmaz olarak yanlıştır.) Aynı zamanda duvara bok atmanın ve hangi sopaların göz ardı edilebilir olduğunu görmenin maliyeti.

İlk etapta tasarım belgelerine sahip olmayı amaçladığınızı düşünüyorum!

Tasarım belgeleri (gereksinimler, kullanım senaryoları, maketler vb.) Sistemi yüksek düzeyde tanımlamamıza, anlamamıza ve tartışmamıza olanak tanır. Bu tür belgelerin dışında kalan ayrıntıların miktarı onları kullanışlı kılar.

Kaynak kodun kendisi bu amaca hizmet ettiğinden, sistem sisteminin tam davranışını tüm detaylarıyla açıklayan belgelere gerek yoktur .

Yazılım geliştirme, üst düzey insan tarafından okunabilir özelliklerin, bir makine tarafından çalıştırılabilen düşük düzeydeki belirsiz özelliklere dönüştürülmesi süreci olarak düşünülebilir. Ancak bu işlem için bazı girdilere ihtiyacınız var .

İdeal durumda, kodun kendisi dışında hiçbir yazılım tasarımı açıklaması olmamalıdır.

Bu, ima ettiğinden daha uzakta. Bağımlı tipler (anladığım kadarıyla, teorik olarak oldukça umut vaat eden) gibi şeyler bile birkaç yıl sonra.

Resmi doğrulama oldukça zordur ve bu nedenle resmi doğrulamanın yaygın olarak kullanıldığı tek yer kriptografi kütüphaneleridir.

Birim testleri

Mülkiyet testi ana akımdan etkilenmediyse, bunun uzun süre pratik olacağını düşünmüyorum.

Ayrıca, iyi testler yazmak (her refactor ile düzenlenmesi gerekmeyecek, ancak yine de yeterli hataları yakalayacaktır) oldukça zordur.

Kodun belgelerinizle tutarlı olduğundan emin olmak için tekrar tekrar kontrol etmeniz gerekir. Sık değişiklikler varsa, kod ve belgeleri senkronize tutmak zordur.

Şu anda bir dokümantasyon test aracı kullanmak muhtemelen daha kolaydır.

Bu çalışmanın yapılabilmesi için bir ön koşul vardır: Kodun okunması ve anlaşılması yeterince kolay olmalıdır.

Ne yazık ki, sadece son derece etkileyici değil, aynı zamanda son derece okunabilir diller tasarlamak zordur. Go gibi diller okunabilirliğe öncelik verir ve üst düzey düşünceleri engeller.

Son olarak, tecrübelerime göre, daha iyi diller ve araçlar daha az hata içeren yazılıma değil, daha büyük projelere yol açıyor. pandoc1970 yılında yazmanın gerçekten mantıklı bir yolu yok.