Kod yeniden düzenleme ve optimizasyon hem çevik hem de şelale süreç zaman çizelgesine nerede uymalıdır?

Proje yönetimi ekibi arasında, "işe yaradığını" belirten, bunun% 100 tamamlanmış olarak kabul edilmesi gerektiği anlamına geldiği görülmektedir. Çoğu programcı bunun her zaman böyle olmadığını bilir. Bir işlevsellik parçasını çalıştırmak için alternatif yaklaşımlar deniyorsam, bu mutlaka en iyi çözümü bulduğum anlamına gelmez veya diğer geliştiricilerle inceledikten sonra yeniden çalışma gerektirmez. Sık sık bir şeylerle bitiririm, geri adım atarım ve iş kurallarına uyulduktan sonra kendime daha iyi neler yapabileceğimi sorarım. Bu "Daha iyisini yapabilirim" zamanı aslında zaman çizelgesi içinde bir yere sığmalı mıdır? En iyi yaklaşımın kodu her zaman bulduğunuzdan (bir dereceye kadar) daha iyi bırakmanızdır, bu da lansman sonrası yeniden düzenleme anlamına gelebilir. Ancak,

Hem şelale hem de Çevik'te yeniden düzenleme ve optimize etme ihtiyacını yöneten bir kapsayıcı prensip vardır: YAGNI (Buna ihtiyacınız olmayacak). İkinci ilke birincinin sonucudur: "Erken optimizasyon tüm kötülüğün köküdür", genel atasözünün kodlama eşdeğeri "mükemmellik düşmanı mükemmelliktir".

Hadi prensipleri alıp uygulayalım. Belirli bir türdeki bir dosyayı alan, bilgilerini ayıklayan ve sonra bu bilgileri bir veritabanına koyan bir ETL algoritması oluşturma gereksiniminiz vardır. Bu haftaki amacınız (bizim amacımız için bir Agile veya SDLC mağazasında olmanızın önemi yoktur) bunu yapmaktır.

Sen akıllı bir adamsın ve sana büyük resme bir göz attı. Bunun, projenin bir ETL'ye ihtiyaç duyacağı tek dosya türü olmadığını biliyorsunuz. Bu nedenle, bu ETL algoritmasını, yalnızca küçük farkları olan başka bir dosya türü üzerinde de çalışmak üzere uygulamayı düşünürsünüz. Bunu yapmak YAGNI'yi ihlal edecektir. İşiniz o diğer dosya için algoritma geliştirmek değil; hafta sonunda ihtiyaç duyulan bir dosya için algoritma geliştirmektir. Bu hedefe ulaşmak ve kabul testlerini geçmek için, bu algoritmayı geliştirmeniz ve doğru çalışmasını sağlamanız gerekir. Diğer dosyayla çalışmasını sağlamak için ek koda "ihtiyacınız olmayacak". Şimdi dahil etmeniz için zaman kazanacağınızı düşünebilirsiniz ve haklı olabilirsiniz, ancak çok yanlış olabilirsiniz; diğer dosya için algoritmanın kodunuzun kullanılamadığı bir alanda kullanılması gerekebilir veya yeni dosya için gereksinimler sizin bilmediğiniz yollardan sizinkinden farklı olabilir (Agile'da, bunlar gereksinimler henüz mevcut olmayabilir). Bu arada, zaman kaybettiniz ve algoritmanızın karmaşıklığını gereksiz yere artırdınız.

Şimdi, gelecek hafta ve ilk algoritmadaki mükemmel çalışmanız için şüpheli bir ödül olarak, iki yeni dosya türü için algoritmalar oluşturma görevi verildi. Şimdi, algoritmanızın daha fazla dosyayla çalışmasını sağlamak için ek koda ihtiyacınız var. Varolan algoritmanızı, dosyaya özel ayrı adımlarla temel bir desen kullanacak bir şablon yöntemi deseni kullanarak genişletebilir veya mevcut algoritmanızdan ortak bir arabirim türeyebilir, arabirimi izleyen iki yenisini geliştirebilir ve bunları takabilirsiniz. hangi algoritmanın kullanılacağını seçebilen bir nesne.

Gelişirken, sistemin saniyede 10KB ham veri işleyebilmesi gerektiğini biliyorsunuz. Bir yük testi yapın ve ilk taslak algoritmanızın 8KB / s tutamaçlarını bulun. Bu AAT'leri geçmeyecek. Bir bakıyorsunuz ve algoritmanızda O (benim Tanrım) karmaşıklık döngüsü yapısının olduğunu görüyorsunuz; düzene sokar ve 12KB / s alırsınız. "Oldukça iyi" diye düşünüyorsunuz, "ama kodda bu kadar zayıf bir döngü olsaydı, başka ne tıraş olabilirim?". buzz "Erken optimizasyon" kuralını ihlal ettiniz. Kodunuz çalışır ve tüm gereksinimleri iletir. Gereksinimler 15KB / s gerektirecek şekilde güncellenene kadar "bitti". Bu olduğunda ve sonra, kodu geri çekin ve iyileştirilecek şeyler arayın.

İster Agile'de ister geleneksel SDLC'lerde olsun, bu basit süreci takip edin: "İlk geçişte, çalışmasını sağlayın. İkinci geçişte güzelleştirin. Üçüncü geçişte SOLID yapın." Bunun anlamı, bir kod satırı ilk oluşturduğunuzda, bu kodun işini doğru ve hatasız yapmasını sağlayın, ancak şu anda bildiğiniz her şey için olduğu gibi, bu koddaki tasarım kurallarına çok fazla dikkat etmeyin ' Bu alana bir daha asla dokunmayacağım. Bir dahaki sefere bu kod satırını ziyaret ettiğinizde, kendinizi yanlış buldunuz; artık sistemin tek seferlik bir parçası değil. Okunabilirlik, kodun kısa olması ve / veya KURU ilkeleri için yeniden düzenleyin (bir şeyi beş kez yapmak için bazı kodları kopyalayıp yapıştırmış olabilirsiniz; bunu bir döngüye ve / veya yöntem çağrısına dönüştürün). Bu kod satırında veya çevresinde üçüncü kez çalıştığınızda,

Çalışıyorsa ve test edilmişse, neden düzeltin?

Bu, bir mühendis / programcı olarak kendi kişisel mizacınıza aykırı olabilir, ancak eğer çalışıyorsa, onu geliştirmeye devam etmek için hangi iş değeri vardır? Zaman içinde bakımını kolaylaştırır mı? Eğer öyleyse, çevik metodoloji altında çalışarak, mevcut kodunuzu hassaslaştırmak ve yeniden düzenlemek için biriktirme listenizde yeni öğeler oluşturabilmeniz gerekir ve bunlar biriktirme listesindeki diğer öğelerle önceliklendirilir. Bu, çevik sürecin değerinin bir parçasıdır: takım neyin en önemli olduğuna ve neyin sonra yapılacağına birlikte karar verir.

Ekibimiz ayrıca "teknik borç" dediğimiz şeyi de izler, bu yüzden işe yarar bir şey bulursanız ancak daha iyi yapılabileceğini biliyorsanız, teknik borç olarak kaydedersiniz. Scrum kullanıyoruz ve bazen tüm çalışmaları bir sprintte erken bitirirsiniz (tahminlere oldukça yakınsanız kabaca yarısını biraz erken bitirmelisiniz), ancak tamamen yeni bir şey çekmek için yeterli zamanınız kalmaz kullanıcı hikayesi, bu yüzden geri dönmek ve teknik borcumuzu azaltmak için ekstra zaman harcıyoruz. Birikmiş işlerimizdeki kullanıcı hikayelerimiz gibi resmi olarak izlenmez ve zamanımız olduğunda hemen hemen üzerinde çalışabiliriz.

Görevi "tamamlandı" olarak adlandırdığınızda, az çok sizin tarafınızdan bir karar çağrısı da yapar; kodunuzun bulunduğu durumdan memnun değilseniz, görevi tamamlandı olarak işaretlemeyin.

Bu "Daha iyisini yapabilirim" zamanı aslında zaman çizelgesi içinde bir yere sığmalı mıdır?

Evet.

Bir sonraki sürümü kodlamaya başlamadan hemen önce .

"Sezgiye" dayalı yeniden düzenleme yapmayın.

Bir sonraki sprint'in gerçek hikayelerine dayanan refactor.

Yeniden düzenleme işleminden memnun kalana kadar kodu% 100 tamamlandı olarak işaretlemeyin. Kodu yeniden düzenlemenin maliyetini / faydasını sürekli olarak değerlendirmeniz yeterlidir, çünkü yeterince çalışıyorsanız kodu daha iyi hale getirmenin yollarını görürsünüz.

TDD'nin kırmızı yeşil refactor yöntemini kullanıyorum. Bu yüzden yeniden düzenleme benim gelişimimde yerleşiktir. Altta yatan modeli veya benzer bir şeyi değiştirmek gibi büyük refactorings için önce zaman geçirmek için yönetim satın almak istiyorum.

"lansman sonrası yeniden düzenleme", göz ardı ettiğiniz regresyon testinde ve KG süresinde gizli bir maliyete sahiptir, ayrıca raporlanan hatalar ve yeni / istenen özellikler ve değişiklikler üzerinde çalışmamanın fırsat maliyetini taşır. TANSTAAFL

Yapmaya değerse, özel bir istisna olarak değil, normal işleminizle önceliklendirilmek için bir görev yapmaya değer. Ne de olsa bir ekibin parçasısınız ve ortak hedefler üzerinde çalışıyorsunuz ve çalışma kodunuzu düzeltmek için programınızı keyfi olarak genişletiyorsunuz da onları etkiliyor.

Gerçek bir cevap için: yeniden düzenleme yapmak isteyeceğinizi biliyorsanız, o zamanı görevin bir parçası olarak planlayın. Scrum / agile yapıyorsanız zaman kutusuna bir temizlik görevi koyun. Şelale / spiral iseniz, modülleri kodlamak ve kabul etmek için refactor sürecinin bir parçası olun.

Bir işlevsellik parçasını çalıştırmak için alternatif yaklaşımlar deniyorsam, bu mutlaka en iyi çözümü bulduğum anlamına gelmez,

... bu durumda henüz% 100 işiniz bitmedi ...

veya diğer geliştiricilerle birlikte inceledikten sonra yeniden çalışma gerektirmez.

Kod gözden geçirmeleri ve sonraki yeniden işleme, geliştirme yaşam döngünüzün bir parçasıysa, yine tüm bunlar bitene kadar özellik yapılmaz.

Sık sık bir şeylerle bitiririm, geri adım atarım ve iş kurallarına uyulduktan sonra kendime daha iyi neler yapabileceğimi sorarım. Bu "Daha iyisini yapabilirim" zamanı aslında zaman çizelgesi içinde bir yere sığmalı mıdır?

Değişir. Yeniden düzenleme anlamına geliyorsa, orijinal geliştirme görevinin bir parçası olmalıdır. Potansiyel olarak daha iyi bir algoritma ile deneme yapmak istiyorsa, ayrı bir görev olabilir.

En iyi yaklaşımın kodu her zaman bulduğunuzdan (bir dereceye kadar) daha iyi bırakmanızdır, bu da lansman sonrası yeniden düzenleme anlamına gelebilir. Ancak, proje ekipleri genellikle bu yaklaşımdan son derece rahatsız olurlar, çünkü yine işe yarıyorsa ve test edilmişse neden düzeltmeliyiz?

Kısacası, kod birçok düzeyde kırılabilir çünkü.

Şu anda işe yaradığı bir şey var. Uzun vadede temiz, uzatılabilir ve bakım yapılabilir olması tamamen farklı bir şeydir.

Daha ayrıntılı yanıtlar için bu konuya bakın .

Görebildiğim ve okuduğum kadarıyla, bu huzursuz bir soru. Bu nedenle, kaçınma cevapları "YAGNI" ve ilk seferinde doğru cevaplar gibi. Gerçek şu ki Agile'de yeniden düzenleme için bir yer yok - ama olması gerektiğini savunuyorum.

Şimdiye kadarki en iyi cevap teknik borçtan bahsediyor. Bu, ne yazık ki, çevik veya çevik olmayan bir metodolojide her şeyin yaygın olduğu şeyleri kapıdan dışarı çıkarmak için acele edilen birçok kuruluşta üzücü bir yazılım gerçeğidir - ancak Agile altında hızlı ve kirli çözümler iyi bir şey olarak rasyonelleştirilir: "asgari iş gereksinimini karşılar" ve "YAGNI" (kodu temiz tutma konusunda).

Herkesin TDD yapması harika olurdu ve tüm geliştiricilerin bir cevap tarafından önerildiği gibi ikinci veya üçüncü kez yeniden düzenlenmesi harika olurdu. Ama bu gerçek dünyada olmaz. Değişen beceri seviyelerine sahip geliştiricilerin neredeyse her zaman hızlı çözümler arayışında köşeleri kestikleri bulunmuştur. Sonuç olarak kod, yeni geliştiricilerin sadece deşifre edilmesi için günler süren ve üretkenliği zedeleyen ve son teslim tarihlerini geciktiren, sürdürülemez kodun dağlarına dönüşüyor. "Untaintainable" ile, kopyala-yapıştır çözümleri, 5000 satır sınıfı vb. Kastediyorum. Ve tüm bu kodlar ve düzeltmelerdeki bu düzeltmeler işin temelini oluşturuyor! - Bu ilave çözüm vakalarında, YAGNI diye bir şey olmadığını savunuyorum! HER ZAMAN temiz bir koda ihtiyacınız olacak. Kod temiz değilse kesinlikle ihtiyacınız olmayacak - kendini gerçekleştiren kehanete bakın? Geliştiriciler bu kodu hiç kullanmamak için büyük çaba sarf ediyorlardı çünkü bakmak çok acı verici. Ve kısır döngü, tüm büyük top-çamur topunun kıkırdaması ve yeniden yazılması gerekene kadar devam eder.

Bu yüzden diyorum ki - kod-yeniden düzenlemenin uygun, farklı, kendi-öykü türünde bir Agile konsepti olmamasına rağmen - yeniden düzenlemeye zaman ayırmalıyız. Bazı dükkanlar şimdi ekiplerin sprintlerinin% 20'sini teknik borç için harcamasını istiyor. İnşallah, çevik savunucular YAGNI hakkındaki fikirlerini değiştirecek ve ayrı bir zaman tahsis edilmiş faaliyet olarak yeniden düzenleme için bir yer oluşturacaklar. Ve eğer daha önce duymuşlarsa ve ben duymamışsam, lütfen tarif edilen yere dikkat edin, çünkü bilmek istiyorum.