Projenin ilk yinelemesine ne kadar ayrıntı konulur?

Yeni bir kişisel projeye (Python) yeni başladım ve programın "kaba taslağı" ne kadar yazmak istediğimi yazıyorum, yapmak istediğim şeyi yapmak için gereken minimum miktar. Henüz kapsamlı hata / istisna yönetimi veya estetik UI öğeleri koymuyorum (bu şeylerin nihayetinde gerekli olacağını bildiğim durumlarda bile) ve dokümantasyon gelecekteki ne yaptığımı görmeme yardımcı olmak için yeterli.

Bu kadar kaba bir başlangıç ​​yapmak proje tasarımı / yönetiminin belirlenmiş ilkelerine aykırı mıdır? Ben bir bilim insanıyım, programcı değilim, bu yüzden bu şeyleri hızlandırmak için uygun değilim. Yani asıl soru şu ki, birinin şu iki uç arasına düşmeyi amaçlaması gerektiği konusunda bir fikir birliği var mı:

1. Tüm istisna işlemleri ve sonuçta ihtiyacınız olacağını bildiğiniz şekilde, baştan itibaren kapsamlı, yüksek kaliteli kod yazın.

2. En başından itibaren asgari düzeyde çalışan kaba bir taslak yazın ve daha sonra tüm minutiaları doldurun.

İlgili soru: Bir projenin yapılması için tasarımın "düzgünlüğünü" feda etmek ne zaman doğru olur?

Bu tamamen projeye bağlı olduğu için tek bir cevap yoktur. Burada iki şeyi düşünmeliyiz. Nihai hedefiniz nedir? Oraya nasıl ulaşmayı düşünüyorsunuz?

Sonuç

Mars Orbiter kontrol yazılımı mı yazıyorsunuz? O zaman mümkün olan en sağlam kodu yazdığınızdan emin olsanız iyi olur, her istisnanın akıl sağlığı konusunda ele alındığını kontrol etseniz iyi olur.

Yalnızca sizin çalıştıracağınız bir program mı yazıyorsunuz ve arada sırada yalnızca manuel olarak çalışacak mısınız? O zaman istisnalarla uğraşmayın. Ağır mimari ile uğraşmayın. Sizin için çalıştığı noktaya kadar çalışmasını sağlayın.

Oraya nasıl ulaşmayı düşünüyorsunuz?

Neyin gerekli olduğunu anlamak için çok zaman harcadığınız ağır şelale gelişimi mi yapıyorsunuz ve sonra aylarca kalkacak, gelişecek misiniz? Eğer öyleyse, yukarıda belirtilen hedef kaliteyi oldukça erken vurmak istersiniz. Tüm hata kontrol altyapınızı başlangıçta planlayın.

Bir veya iki hafta boyunca bir şey koyduğunuz, daha sonra radikal revizyonlar isteyebilecek paydaşlara gösterilecek ve 1-2 wee sprint'i tekrar edebileceğinizi düşündüğünüz ağır çevik bir gelişme mi yapıyorsunuz? hedefi vuruncaya kadar? O zaman işe yarayan bir şey elde etmek daha iyi olabilir, ancak birlikte hızlı bir şekilde kırılgan olabilir ve ürün gereksinimleri katılaştıkça sadece kemer ve askılar ekleyebilirsin.

Şelale veya çevik karar (eğer ikili bir seçim değil, aslında bir sürekliliktir) üzerinde kontrolünüz varsa, bu kararı beklenen değişikliğe göre verin. Nihai sonucun nasıl görüneceğini tam olarak bildiğinizden eminseniz, şelale en iyi seçiminizdir. Sonunda neye ihtiyacınız olduğuna dair belirsiz bir fikriniz varsa, çevik en iyi seçimdir. (Agile, günümüzde daha doğal olduğu için değil, ikinci durum çok daha yaygın olduğu için daha popüler.)

Şimdi kendi cevabını bul

Çoğu için, cevap ortada bir yerde olacaktır. Projenizle ilgili her iki soruyu da yanıtlayın, bu da sizi temel yönde yönlendirmelidir.

Kendim için söyleyebilirim, eğer sık ​​sık uçsuz bucaksız tasarlanmış ve herhangi bir şeyi kontrol etmekte hata olmayan bir kerelik komut dosyaları yazarsam. Ayrıca hata işleme ve mimarinin büyük ilgi gördüğü üretim kodunu da ele alıyorum. Her şey ne yaptığınıza bağlıdır.

Son bir uyarı: Hızlı ve kirli yapılabilen tek seferlik komut dosyaları yapmaya karar verirseniz, emin olun. Ne yazık ki, ilginç bir şey yapan hızlı ve kirli komut dosyaları, diğerleri fark ettiğinde geniş kullanım alanına girer. Bu olduğunda, sertleşme için zaman verildiğinden emin olun.

Tüm yazılım tasarımı ve kodlama kavramları ve modelleri, bazı sorunlara yanıt olarak ortaya çıkar. Desen veya kavram bu soruna bir çözümdür. Zamanla, bazı modeller tercih edilen çözümler olarak "iyi bilinir" hale gelir, çünkü sorunu tutarlılık, aşinalık, performans, sürdürülebilirlik ve benzeri için belirli gereksinimleri karşılayacak şekilde çözerler.

Sonuç olarak, yazılım deseninin çözmesi gereken sorun özel yazılımınızda mevcut değilse, o zaman kalıba ihtiyacınız yoktur. Ayrıca, ne desen yazılım herhangi tartışmalar kudretinin de önerdiğiniz yazılımın ayrıntılı tartışmalar içermelidir ihtiyacını: bunu yapmak için ne gerekiyor? Hangi sorunu çözüyor? Kaç kullanıcı olacak? Kullanıcılar bir şekilde veri paylaşacak mı? Ve böylece.

İstisnaların çözmesi gereken sorun, kodun bir şey yapamayacağı bir şey olduğundadır. Örnek, depolama ortamında bulunmayan bir dosya adının belirtildiği bir Dosya / Aç işlemi olabilir. İstisnalar, kodu arayan kişiye "Devam etmemi engelleyen bir şey oldu ve bu konuda yapabileceğim bir şey yok, bu yüzden vazgeçiyorum." Kodunuzda bunun gibi koşulların mevcut olduğu herhangi bir yer yoksa, istisnalara ihtiyacınız yoktur. Veya, bir hata kodu döndürebilir ve istisnayı tamamen önleyebilirsiniz.

Deneyim kazandıkça, yazılım kalıpları ve kullanımlarının ne zaman uygun olduğu hakkında bilgi edineceksiniz. Ayrıca ne kadar ön tasarıma ihtiyacınız olduğunu da bileceksiniz; yine, bu tamamen yazdığınız uygulamaya bağlıdır. Küçük araçlar büyük, kurumsal uygulamalardan, diğer bir deyişle temelde farklı bir şekilde yazılır.

Çok çeşitli küçük ve orta ölçekli projeler için çalışan çok basit ve pratik bir yaklaşım var. Mars Kaşifleri için muhtemelen iyi çalışmayacak olsa da.

İlk olarak, sistemin ne yapmasını istediğinizi öğrenin ve her bir özelliği not edin. Bu, bir kullanıcı hikayesi panosu kadar sofistike olabilir veya önünüzdeki bir kağıda not edilen birkaç mermi noktası kadar basit olabilir. Ama ne yapmasını istediğinizi bilmeniz önemlidir .

Buna dayanarak sistemin genel yapısını çizer. Yine, bu genellikle farklı sınıfların / modüllerin hızlı bir çizimi ve birbirleriyle nasıl ilişkilendikleri, ancak tüm bir belge kadar karmaşık olabilir. Önemli olan , sistemi nasıl uygulayacağınız hakkında bir fikriniz olması . Ancak, muhtemelen üzerinde çalışırken rafine edilecek, bu yüzden karmaşık ve ayrıntılı olmaya çalışmayın.

Tüm bu özelliklerden, programın yapması gereken temel şeyleri - temel özellikleri - hesaplayın.

Sonra bunları tek tek uygulayın. Şimdi buradaki anahtar şey, bir özelliği uyguladıktan sonra bunun yapıldığından ve tamamen çalıştığından emin olmaktır - ideal olarak, çalışmaya devam etmesini sağlayan bir birim testi eşlik eder. Genellikle o kadar meşgul olacağım varsayımına girerim, özelliğe geri dönüp onu düzeltmek için asla zamanım olmayacak.

Temel özellikler uygulandıktan sonra, sistemi genellikle üretim ortamına olabildiğince yakın bir şekilde kullanmaya çalışırım. Bu size a) daha önce kaçırmış olabileceğiniz hataları ve b) sonraki özelliklerin önceliği hakkında iyi bir fikir edinir.

Ardından, kalan özellikleri gerektiği gibi uygulamaya devam edebilirsiniz.

Kod Kalitesi ve Özelliklerin Karşılaştırması

Yukarıdakileri göz önünde bulundurarak, bir son tarih yapmak zorunda kalırsam, kod kalitesi üzerinde özellikleri feda etme eğilimindeyim. Çünkü en azından benim çalışma alanımda, bir şeyi bitirdiğimde, yönetimimin yapıldığını varsayar. Ve bana bir sonraki görevi verebilirler. Kod aslında daha güzel hale getirmek için çok fazla zamanım yok.

Şimdi, istisna yönetimi ne olacak?

Bunu sopayı uygulamak istemiyorsanız, bunu listede başka bir özellik olarak listeleyebilirsiniz. Ve ona ulaştığınızda bunu uygulayabilirsiniz. Ancak büyük olasılıkla sizin durumunuzda, muhtemelen daha önemli olan başka şeyler de vardır.

Bununla birlikte, istisnalar için minimum bir gereklilik vardır: Çıktının ne kadar çirkin olursa olsun, bir şey ters giderse kullanıcıya bildirildiğinden emin olun. İstisnaları bir yerde yutmayın.