Çevik metodoloji: hızlı ve kirli mi yoksa ilk plan mı?

Çevik soru: Çevik şeylerin kalkmasına ve “hızlı ve kirli yolun” yürütülmesine inanıyor mu? Yoksa bu bir metodoloji sorusu değil, daha çok vaka bazında değerlendirdiğiniz bir soru mu?

Teknik olarak sistemin temelini "yeniden" yapıyorum, yapının çoğunu zaten inşa ettikten sonra ... anıtsal bir iş değil ... çeviklik önce tüm akışı belirtmemi, analiz etmemi, tweak ve sonra inşa? Bir şekilde bu şekilde daha iyi hissediyorum ... dağınık bir sistem kurduktan sonra nasıl yapılması gerektiğini daha iyi görüyorum ... öte yandan o kadar organize değil ... sadece en iyi gelişmenin ne olduğunu merak ediyorum uygulama bu bağlamda.

Prototip ve takas kodu hakkında soru sormadığım için bu sorunun Çevik ve prototipten biraz farklı olduğuna inanıyorum ; Üretim sınıfı kodlar için çeviklikle ilgileniyorum.

Çevik metodoloji önce plan. Sadece her şeyi planlamak değil. Aslında gereksinimleri, tasarım, kod, test, dağıtma ve sunma. Bunları sadece bir iki haftadan daha kısa bir sürede (dağıtabileceğiniz veya verebileceğiniz) dağıtabileceğiniz ve hakkında geri bildirim alabileceğiniz en küçük küçük özellik üzerinde yaparsınız. Sonra tekrar başka bir özellik ekleyerek veya eski bir özelliği değiştirerek yaparsınız.

Anahtar, değişikliği kabul eden bir kod yazmaktır, böylece sonunda "tüm akış nasıl olmalıdır" ifadesini gördüğünüzde bunu yapmak için kodu değiştirebilirsiniz. Bu şekilde "akışın gitme şekli" (ya da her ne olursa olsun) yine değiştiğinde, bu travmatik değildir.

Hızlı ve kirli yazamazsınız. Hızlı ve kirli ridgid kodu verir. Küçük çalışarak hızlı olun. Esnek kalın bilgi sıçraması . İdeal olarak, herhangi bir özellik değişikliği kodda yalnızca bir yeri etkilemelidir.

Tonlarca zaman harcamaktan başka bir şey yapamazsınız. Planlayabilirsiniz, ancak planı değiştirebilmeniz gerekir. Planı değiştirmek için nedenleri hızla keşfetmeniz gerekiyor. Planlama sorunsuz ilerlerken, öğrenecek sürprizler olmadan, yani planlama çok uzun süredir devam eder. Planlama ve kodlama birbirine yakın olmalıdır. Eğer öğrenirseniz, plan ne kadar eski olursa, o kadar büyüktür.

Uzun vadede daha akıllı olmayı planlamalısınız. Esnek kod yazın. O zaman daha akıllı olmak pişmanlığa yol açmaz.

Çoğu insan için "hızlı ve kirli" veya "önden büyük tasarım" olduğunu sevmiyorum. Başka seçenekler olduğunu bile düşünmüyorlar.

Çevik, değişimin, gelişimin sonlarında bile önemsiz olduğu bir sistem inşa etmekle ilgilidir. Bu, yazılımı küçük, artımlı parçalar halinde oluşturarak ve sağlam otomatik testlerle bu parçaların davranışlarını kilitleyerek yapılır. Ve bu değişikliklerin değerini doğrulamak için üretime sık sık, otomatik dağıtım uygulamak.

Sağlam otomatik testler yaparak, daha uzun süreler boyunca artımlı yeniden düzenleme yaparak mimarinin en zorlu kısımlarını bile değiştirmek önemsiz hale gelir. Bu nedenle, mimarinizin projenin yarısında daha iyi yapılabileceğini fark etseniz bile, değişikliği nispeten hızlı bir şekilde yapmak gerçekçi bir şekilde mümkündür.

Bazı insanlar "bazı tasarımlar ön" çevik ile iyi olduğunu söylüyor. Ancak bu tasarımı daha sonra tekrarlamak istiyorsanız, geliştirme kültürünüzün değiştirilmesi kolay bir sistem ürettiğinden emin olmanız gerekir. Dolayısıyla "SDUF" sağlam test, agresif yeniden düzenleme ve sürekli konuşlandırma ihtiyacını geçersiz kılmaz.

Sisteme "değişim kolaylığı" oluşturarak, daha sonra değiştirilebileceği için projenizin ilk tasarımı hakkında fazla düşünmenize gerek yoktur. "Hızlı ve kirli" yaklaşım, çoğu insan buna "başak" der, ancak değerli bulduğunuz özellikleri stabilize ederseniz kullanılabilir. Ancak değişimi yavaşlattıklarından, kod tabanınızda saldırıya uğramış kod parçalarını çok uzun süre bırakmamalısınız.

Ne.

"Basit başlayın ve ilerlerken kendinizi geliştirin".

Hızlı ve kirli kırılgandır, ancak hızlıdır (proje yeterince küçük ve kısa ömürlü ise).

Öncelikle plan katı ancak kararlıdır (eğer proje finansal veya zamansal kısıtlamalarla karşılaşmadan tamamlanırsa).

Çevik, yukarıdaki 2'ye bir alternatiftir. Özelliklerin birer birer tamamlandığı, özellik özellikli olduğu ve programın bu tamamen işlevsel parçalarını tamamlarken edinilen bilginin, gelişme ilerledikçe planı etmek ve ayarlamak için kullanıldığı yinelemeli bir yaklaşıma dayanır. Bunu yapmak için önceden planlama yapılması gerekir - bireysel özelliklerin ne kadar çalışma gerektirdiğini tahmin edebilmek için en azından yeterli planlamaya ihtiyacınız vardır - ancak çeviklik değişim beklediğinden, aşırı planlama israfa yol açar.

Çevik'in temel özelliklerinden biri kısa iterasyonlar yapmak ve sonra yeniden değerlendirmektir. Yeni bölgeyi keşfetmek için ilerleyin, ondan öğrenin ve sonra bir plan yapın. Bu şekilde planınız daha iyi olacak. Ve başarısız olursanız (kurs fikrinizin işe yaramadığını bulun), "hızlı başarısız oldunuz", bu da iyidir.

Yani yaklaşımınız iyi. O zaman tehlike "Güzel, işe yarıyor, işim bitti. Sırada ne var?" Demek. İşiniz bitmedi, düzeltmek için çok sayıda kesim köşesi var ve yaklaşımınızın çalışan ve uygulanabilir bir sistem sağladığı anlaşıldıktan sonra bunu düzgün bir şekilde yapmak için zaman ayırmalısınız. Bu testler, belge, StyleCop yazmak, optimize etmek, meslektaşlarınıza yaptıklarınız ve nasıl yaptığınız hakkında bilgi vermek, onları incelemek, vb.

Yukarıdaki cevaplara eklemek için anahtar bir ilke YAGNI'dır . Ön tasarımınız ve planlamanız bir sonraki adımı etkinleştirirse, iyi. Fakat eğer ispatlayamayacağınız varsayımsal bir gelecek adımı gerektiriyorsa, YAGNI'yı varsayalım.

Hem yukarıdan aşağıya hem de aşağıdan yukarıya birçok tasarım, kodun önemli ölçüde yeniden kullanılacağını varsayar. Deneyim, kodun yeniden kullanılmasının o kadar da yaygın olmadığını söylüyor, çünkü aynı sorunu nadiren çözüyorsunuz. İleride bu problemin bir varyantını çözmek gerekirse, gelecekte tasarım o varyantı eklemek planı ayrı, ama yok değil hemen şimdi düşünün.

Başka bir deyişle, acil görev için plan yapın, ancak ileride başka bir şey için plan yapmayın.