Önceden bir şeyler planlamaya çalıştım, ancak bir kod yazmaya başlayana kadar her şeyi gerçekten öngöremiyorum.
Mükemmel planlamanın size mükemmel bir yazılım tasarımı / mimarisi vereceğini düşünmek cazip gelse de, bunun kategorik olarak yanlış olduğu ortaya çıkıyor. Bununla ilgili iki büyük sorun var. Birincisi, "kağıt üzerinde" ve "kod" nadiren eşleşiyor ve bunun nedeni, aslında bunu yapmak yerine nasıl yapılması gerektiğini söylemek kolay olmasıdır . İkincisi, gereksinimlerdeki öngörülemeyen değişiklikler, başlangıçta neden olamadığı geliştirme sürecinde geç görünür hale gelir.
Çevik hareketi duydun mu? “Bir planı takip etmenin” aksine (“şeylerin yanı sıra” yerine) “değişime tepki vermeyi” değerlediğimiz bir düşünce tarzı. İşte manifesto (hızlı bir okuma). Ayrıca Big Design Up Front (BDUF) ve tuzakların ne olduğunu da okuyabilirsiniz.
Ne yazık ki, "Çevik" in kurumsal versiyonu bir grup sahtedir (sertifikalı scrum ustaları, "Agile" adına ağır işlem, scrum zorlama,% 100 kod kapsamını zorlama, vb.) Çevik'in bir süreç ve gümüş bir mermi olduğunu düşünün. Çevik manifestoyu okuyun, Bob Amca ve Martin Fowler gibi bu hareketi başlatan insanları dinleyin ve "şirket Çevik" in saçma versiyonuna emmeyin.
Özellikle, sadece bilimsel kod üzerinde TDD (Test Odaklı Geliştirme) yapmakla kurtulmak için elinizden geleni yapabilirsiniz ve yazılım projenizin oldukça iyi sonuçlanma olasılığı yüksektir. Bunun nedeni, başarılı bilimsel kodun çoğunlukla ikincil (ve bazen de rekabet eden) bir endişe olarak performans gösterdiği ultra kullanışlı arayüzlere sahip olması ve böylece daha "açgözlü" bir tasarımdan kurtulabilmenizdir. TDD, yazılımınızı ultra kullanışlı olmaya zorlar , çünkü aslında uygulamadan önce işlerin nasıl çağrılmasını istediğinizi (ideal olarak) yazarsınız . Aynı zamanda , basit, "giriş" / "çıkış" tarzında hızlıca çağrılabilecek küçük arayüzlere sahip küçük fonksiyonları zorlar ve sizi refaktör için iyi bir pozisyona getirir Gereksinimlerin değişmesi durumunda.
Bunun numpybaşarılı bir bilimsel bilgisayar yazılımı olduğuna katılıyorum . Arayüzleri küçük, süper kullanışlı ve her şey birlikte güzelce oynuyor. Referans kılavuzunun TDD'yi açıkça tavsiye ettiğini unutmayın numpy: https://docs.scipy.org/doc/numpy-1.15.1/reference/testing.html . Geçmişte TDD'yi SAR (Synthetic A Temperature Radar) görüntüleme yazılımı için kullandım: Ayrıca bunun belirli bir etki alanı için son derece iyi çalıştığını da söyleyebilirim.
Uyarı: TDD'nin tasarım kısmı, temel bir yeniden düzenleme işleminin (yazılımınızın aynı anda eşzamanlı olmanız gerektiğine karar vermek gibi) dağıtılmış bir sistemde olduğu gibi zor olacağı sistemlerde daha az işe yarar. Örneğin, milyonlarca eşzamanlı kullanıcınızın bulunduğu Facebook gibi bir şey tasarlamak zorundaysanız, TDD'yi (tasarımınızı sürdürebilmek için) yapmak bir hata olur ( ön tasarıma sahip olduktan sonra da kullanmaya devam etmek ve sadece ilk geliştirmeyi test etmek) "). Kod içine geçmeden önce uygulamanızın kaynaklarını ve yapısını düşünmeniz önemlidir . TDD sizi asla yüksek oranda kullanılabilir, dağıtılmış bir sisteme yönlendirmez.
Programımı sıfırdan tamamen yeniden inşa edersem, daha iyi yaparsam nasıl hissedebilirim?
Yukarıda verilenler göz önüne alındığında, mükemmel bir tasarımın elde edilmesinin gerçekten mümkün olmadığı açıkça görülmelidir, bu nedenle mükemmel bir tasarım peşinde koşmak aptal bir oyundur. Gerçekten sadece yakınlaşabilirsin. Eğer bile düşünmek sıfırdan yeniden tasarlamayı, muhtemelen orada hala kendilerini göstermedim gizli gereksinimleri. Ayrıca, yeniden yazma, en azından orijinal kodu geliştirmenin sürdüğü süreyi alır . Neredeyse kesinlikle daha kısa olmayacak, çünkü yeni tasarımın kendi başına öngörülemeyen sorunlarına sahip olması muhtemel , ayrıca eski sistemin tüm özelliklerini yeniden uygulamanız gerekiyor.
Dikkate alınması gereken bir başka şey, tasarımınızın yalnızca ihtiyaçlar değiştiğinde gerçekten önemli olduğudur .Hiçbir şeyin değişmemesi durumunda tasarımın ne kadar kötü olduğu önemli değildir (mevcut kullanım durumları için tamamen işlevsel olduğu varsayılmaktadır). 22.000 satır anahtarı deyimi olan bir temel çizgisi üzerinde çalıştım (işlev daha uzun sürdü). Berbat tasarım mıydı? Evet, berbattı. Düzeltdik mi? Hayır. Olduğu gibi iyi çalıştı ve sistemin bu kısmı hiçbir zaman gerçekten çökmelere veya hatalara neden olmadı. Projede bulunduğum iki yılda sadece bir kez dokunuldu ve bir başkası, siz onu tahmin ettiniz, anahtara başka bir dava ekledi. Ancak çok nadiren dokunulan bir şeyi düzeltmek için zaman ayırmaya değmez, öyle değil. Kusurlu tasarım olduğu gibi olsun ve kırılmadıysa (veya sürekli kırılmıyorsa) düzeltmeyin. Böylece belki olabilir iyi yapmak ... ama tekrar yazmaya değer mi? Ne kazanacaksın?
HTH.