Gelecekteki değişiklikler için tasarım veya eldeki sorunu çözmek [kapalı]

Kodu yazarken veya tasarım sırasında sorunu ilk etapta genelleştirmeye ya da bu çok özel sorunu çözmeye çalışıyorsunuz.

Bunu soruyorum çünkü problemi genelleştirmeye çalışmak, işleri zorlaştırmaya meyillidir (gerekmeyebilir) ve diğer taraftan, gereksinimde bir değişiklik olursa, belirli bir çözümü genişletmek çok zor olacaktır.

Sanırım çözüm, söylenenden daha kolay olan orta yolu bulmak. Bu tür bir problemi nasıl ele alıyorsunuz? Genelleştirmeye başlarsanız hangi noktada bu kadar genellemenin yeterli olduğunu biliyorsunuz?

Gelecek için tasarlamaya çalıştığınızda çok sık geleceğe yönelik ihtiyaçlara ilişkin öngörüleriniz yanlış çıkmaktadır. Gereksinimlerin nasıl değiştiğini gerçekten bildiğiniz zaman, ilk gününde sisteminizi fazladan tasarlamaktan daha iyidir. Aynı zamanda, kendinizi yaya olarak da vurmayın. Kesinlikle bir orta yol var ve bunun bilimden daha çok sanat olduğunu bilmek.

Tek bir kurala indirgemek için: az daha fazladır.

Çevik konusunda bilginiz var mı? Çevik'in büyük ilkelerinden biri YAGNI'dir . Bunun olaylara yaklaşmanın en iyi yolu olduğunu biliyorum.

"İhtiyacınız olmayacak" ... bir programcının gerekli görülene kadar işlevsellik eklememesi gerektiğini belirten aşırı programlama ilkesidir (XP). Ron Jeffries , "Her zaman ihtiyaç duyduğunuzda, sadece ihtiyaç duyduğunuzda hiçbir zaman öngörmediğiniz zaman, her şeyi uygulayın" yazıyor.

... YAGNI, XP uygulamasının ardındaki "muhtemelen işe yarayabilecek en basit şeyi yap" (DTSTTCPW) ilkesidir. Sürekli refactoring , sürekli otomatik ünite testi ve sürekli entegrasyon gibi diğer birçok uygulama ile birlikte kullanılması amaçlanmıştır . Sürekli refactoring olmadan kullanıldığında, dağınık kodlara ve çok büyük çalışmalara yol açabilir. Devamlı yeniden yapılanma, güvenlik önlemi (öngörülemeyen hataları tespit etmek için) ve daha geniş entegrasyon sorunlarını önlemek için sürekli entegrasyon olarak otomatik birim testlerine dayanır ...

YAGNI, destekleyici uygulamalarla birlikte bile evrensel olarak geçerli bir ilke olarak kabul edilmez. Bağımsız kullanmak yerine onu destekleyici uygulamalarla birleştirme ihtiyacı, orijinal XP tanımının bir parçasıdır ...

Bu muhtemelen yazılım geliştirmenin en zor kısımlarından biridir, çünkü "YAGNI" ve "PYIAC" ("Bir Köşe İçine Kendinizi Boyayın") arasındaki çizgiyi izlemeniz gerekir.

"İhtiyacın olmadıkça bir özellik yazma" demek oldukça kolay. Zor kısım, kodunuzu tasarlıyor, böylece daha sonra ihtiyacınız olduğunda kolayca özellik ekleyebiliyorsunuz.

Önemli olan, şu anda ihtiyacınız olandan daha fazla kod yazmadığınız genişletilebilir bir mimari tasarlayabilmektir. Bunu iyi yapabilme yeteneği gerçekten çok fazla deneyimden (ve acıdan) geliyor.

Tasarımın genel yönü hakkında düşünmek için biraz zaman harcıyorum - çok fazla değil, fakat temelde üst düzey bir genel bakış ortaya koyacak kadar. Daha sonra bireysel hikayeler için çözümler geliştirmek üzere TDD kullanarak hikaye tabanlı bir çevik metodoloji izliyorum. TDD üzerinden uygularken, üst düzey genel bakışımı aklımda tutuyorum ve (a) özel uygulamalarımı, üst düzey genel bakışı takip etmeye yönlendirmek veya (b) üst düzey anlayışımı / yönümü esas almak (yeniden geliştirmek) Test / uygulama sırasında öğrendiklerimi.

Önceden planlama yapmamak bir hata, ama çok fazla yapmak için muhtemelen daha büyük bir hata olduğunu düşünüyorum. Mümkün olduğu kadar büyük resimde bana rehberlik etmeme izin vermeyi ve ardından uygulamanın nasıl geliştirileceğini düşündüğümde tasarımın aklımda ortaya koyduğum çizgiler boyunca organik olarak büyümesini sağlamayı seviyorum. TDD'yi kullanarak, tasarımın kendisinin daha iyi tasarım ilkelerine (ayrıştırılmış, tek sorumluluk vb.) Zorlandığını ve bütünüyle önceden gebe kalmaya çalışıp geliştirmeye uyduğumdan daha fazla dövülebilir olduğunu buldum.

İyi bir tasarım gelecekteki değişiklikleri barındırır ve kesinlikle böyle bir şey olmaya değer. UNIX işletim sistemini ve "her şey bir dosya felsefesidir" deyin. Bu tasarım kararı, acil bir ihtiyaç için değil, gelecekteki ihtiyaçlar göz önünde bulundurularak alındı. Biri "çevik" bir tasarıma dayanan bir işletim sisteminin nasıl görüneceğini düşünmeye titrediyor.

Başa çıkmaya çalıştığınız şey yeniden kullanımla ilgilidir (yani şu anda uğraştığınız bir sorunun genelleştirilmesi, gelecekte çalışmayı (kod) yeniden kullanabilmeniz için). Daha önce de söyledim ve tekrar bağlanacağım .

Galiba başkalarının da etkisine bir şeyler söylediğini duydum:

Sorunu ilk defa çözüyorum. Çözümümü ilk defa tekrarladığımda not ederim. Tekrarladığımda, tekrar etkisizleştiriyorum.

"Şimdi + 1" için tasarım yapın. Bu, elinizdeki acil sorunu çözmek ve yeteri kadar işlevsellik oluşturmak anlamına gelir, böylece bir dahaki değişiklik isteyip istemediklerinde, bunu zaten yarı yolda (veya daha fazla) yaptınız ve bu seçeneklerden birini a) hemen çözebilirsiniz. daha sonra yeniden yapılanma veya b) tekrar "şimdi + 1" i yeniden çözme ("şimdi" yarısı bitti)

Bu projeye bağlı ve kısaca, deneyim size "+1" in ne olduğunu öğretecek.

YAGNI’nin felsefesi, İhtiyacınız olmayacak, (makaleden) ile özetlenebilir:

YAGNI yaklaşımını savunanlara göre, şu anda gerekli olmayan ancak gelecekte olabilecek kod yazma cazibesi aşağıdaki dezavantajlara sahiptir:

• Gerekli işlevselliğin eklenmesi, test edilmesi veya iyileştirilmesi için harcanan zaman alınır.
• Yeni özellikler hata ayıklanmalı, belgelendirilmeli ve desteklenmelidir.
• Herhangi bir yeni özellik gelecekte neler yapılabileceğine kısıtlamalar getirdiğinden, artık gereksiz bir özellik gerekli bir özelliğin daha sonra uygulanmasını engelleyebilir.
• Özelliğe ihtiyaç duyulana kadar ne yapması gerektiğini tam olarak tanımlamak ve test etmek zor. Yeni özellik doğru bir şekilde tanımlanmamış ve test edilmemişse, nihayetinde gerekli olsa bile doğru çalışmayabilir.
• Kod şişirilmesine yol açar; yazılım daha büyük ve daha karmaşık hale gelir.
• Spesifikasyonlar ve bir çeşit revizyon kontrolü olmadığı sürece, bu özelliği kullanabilecek programcılar tarafından bilinmeyebilir.
• Yeni özellik eklemek, başka yeni özellikler önerebilir. Bu yeni özellikler de uygulanırsa, bu sürtünme özelliğine karşı kartopu etkisine neden olabilir.

Eldeki sorun için tasarım yapma konusunda büyük bir inanan ve "bir gün buna ihtiyacımız olabilir" için hazırlamanız gereken tüm davaları tahmin etmeye çalışarak tasarımınızı dışlamamasına inanıyorum.

Temel olarak, belirli bir gereksinimler listesi göz önüne alındığında, buna karşı tasarım yapın, ancak bu yapmamanız gerektiği anlamına gelmez:

• Tasarımınızdaki yönleri, çözümünüzdeki bu yönleri kodlamak yerine, yapılandırılabilir hale getirin. Çalışma zamanında geçen parametreler veya başlangıçta okunan harici bir konfigürasyon aracılığıyla (veya HUP’tan sonra).
• kodunuzu sihirli sayılarla işaretleyin,
• Yeniden kullanabileceğiniz bir yazılı şey olup olmadığını görmek için bir göz atmaktan kaçının, belki de mevcut çözümü ve yeni şartlar için uygun olan bir yaklaşımı sağlamak için mevcut çözümü uyarladıktan sonra.

"Olası gelecekler" için tasarım yaparken asıl sorun, her zaman sadece tahmin etmenizdir. Muhtemelen eğitimli tahminler yapmak, ancak "itmek can sıkmaya başladığında" hala bir dizi tahminde bulunuyor.

Bunu yaparak, çözümünüzü bilinen gereksinim (ler) iniz tarafından tanımlandığı şekilde elde etmek yerine genel dava (lar) a sığdırmak için gerçekten sıkma olasılığınız da çok yüksektir.

Bu ne diyor? "Sahip olduğun tek şey bir çekiç olduğunda, her şey bir çiviye benzemeye başlar."

Keşke birisinin "Her ne kadar gelecekte görebileceğimiz bu genel durumlar için daha uyumlu bir çözüm" dediğini duyduğumda bir pound olsaydı.