Yeni özelliklere odaklanan bir projede kırılmayan mevcut kodu yeniden gözden geçirmeli misiniz?

Uygulamaya yeni işlevsellik eklemeyi amaçlayan küçük bir proje göz önüne alındığında, getirilen değişiklikler, bazı alanlarda bunların güncellenmesini içeren mevcut kodlara değinmektedir. Uygulama sırasında, güncellenen bu kodların bazılarının yeniden düzenleme için adayları olduğunu gördüm.

Bu, etkilenen bileşenler için regresyon testini gerektiren (böylece muhtemelen projenin bir parçası olmayan kapsamı getirecek) refactor için uygun bir zaman mı? Ya da ertelemeli, işlevselliği tamamlamalıyım ve belki de yeniden düzenleme için ayrı bir projem olmalı mı (iş kullanıcıları kod bakımına değer vermedikçe herhangi bir işlevsellik eklemeyen bir projeye tam olarak sponsor olamayacaklarından biraz tereddüt etmeme rağmen ...)?

Kesinlikle.

Yeniden düzenleme, çalışan ve "geçen" bir projede yapılmalıdır. Tüm testleriniz (ünite, sistem ve kabul seviyelerinde) geçtiğinde, ürününüzün gereksinimleri karşıladığını bilirsiniz. Refactor olduğunuzda, tüm testlerin geçmeye devam ettiğini onaylamaya devam edebilirsiniz. Herhangi bir test başarısız olmaya başlarsa, yanlış bir şey yaptınız ve düzeltmeniz gerekiyor. Başarısız testleriniz varsa, yeniden düzenleme işleminden önce bunları düzeltmelisiniz, böylece yeniden düzenleme işleminizin sistemin işlevselliğini değiştirmediğinden emin olabilirsiniz.

Bu aynı zamanda yeniden düzenleme için mükemmel bir zamandır, yeniden düzenleme işlemini yürütmek için zaman ve kaynaklara sahip olduğunuzu varsayarak, yine de zaman ve bütçeye göre teslimat yaparsınız. Yeniden düzenleme artık sisteminizi anlamayı ve bakımını kolaylaştıracak, böylece daha fazla yeni özellik ekledikçe daha kolay hale geliyor. Kod çürümesine ve yazılım entropisine karşı savaşmanız gerekiyor .

As Joel Etherton yorumlarda işaret, sen üstlenmeden kapsamını yönetmesi gerekir. Sistemin yakında özellikler ekleyeceğiniz bölümlerini yeniden düzenlemeye odaklanın, birlikte çalışmayı kolaylaştıracak veya yeni özellikler ekleyecek yeniden düzenleme işlemleri gerçekleştirin. Statik analiz, metrik araçları ve kod incelemelerinin kullanımı, en kritik alanları belirlemenize yardımcı olabilir. Son başvuru tarihlerini kaçırmak istemezsiniz çünkü yeniden düzenleme yapıyordunuz - müşteriye değer katmaya devam etmeniz gerekiyor.

Müşterinin yeniden düzenleme konusunda değer görmediğinden bahsediyorsunuz. Genellikle, müşteri kodun kalitesini değil, ürünün kalitesini umursar. Yeniden düzenleme, yüksek ürün kalitesini korumanızı ve müşterinin değişen ihtiyaçlarını karşılayan bir ürün sunmaya devam etmenizi kolaylaştıracaktır. Programınıza yeniden düzenleme yapmak için zaman görüşmeye çalışın (müşteri Y gün içinde X özelliğini istiyor, Y + Z günlerini mi yoksa XN özelliklerini mi alamayacağınızı görmeye çalışın, böylece tasarım, yeniden düzenleme ve uygulama için zaman harcayabilirsiniz) Yapabilmek.

Aşağıdaki soruları yanıtlamayı düşünün, o zaman kararı vermeniz kolay olacaktır. Bilgelik "eğer kırık değilse düzeltmeyin" cazip ama profesyonel çalışma için her zaman doğru değildir.

0-Bu kodla ilgili bir müşteri şikayeti var mı?

1-Bu uygulamanın işlevselliği için gerekli mi

2-Mevcut kod zararlı mı?

3-Değişim maliyeti buna değer mi?

4-Maliyeti karşılayabilir misiniz?

5-Becerilerinizi organizasyona en iyi şekilde kullanmak bu mu?

6-Değişiklikleriniz için kullanıcının yeni değişikliği yeniden yüklemesi gerekir - Bunu müşteriye haklı gösterebilir misiniz?

7-Kötü bir düzeltme riskini tolere edebilir misiniz?

8-Değişiklik projeniz dışındaki diğer kodları etkiliyor mu?

9-Bu gelişen bir ürün mü yoksa istikrarlı bir ürün mü? Gelişiyorsa, değişiklikleri bir sonraki sürümde ekleyebilir misiniz?

Yakında refactor, sık sık refactor.

Eğer karşılayabiliyorsanız (zaman, para, vb.) Yapmalısınız.

Bunu söylüyorum, çünkü bazen zamanınız tükenebilir veya bir kod bakım müdahalesi için para almamanız gibi ya da projenizi mümkün olan en kısa sürede tamamlamak ve daha genel olarak yeniden düzenleme kaynaklara ihtiyaç duyduğu için. Ancak bunun dışında her zaman yeniden düzenleme için iyi bir zaman.

Güncel bir kod istiyorsunuz ve özellikle yeni işlevler eklerken kodunuzun gerçekten bazı değişikliklere ihtiyacı olduğunu düşünüyorsanız, kodu değiştirmeniz gerekir.

Bir sürüm kontrol sistemi ile projenizi yeni bir şubeye ayırabileceğinizi unutmayın, böylece mevcut kodunuzu hiç etkilemezsiniz.

Yeni işlevselliği uygulamak için yeniden düzenleme gerekliyse, yeni geliştirmenin bir parçası olarak yapılmalı ve hesaba katılmalıdır.

Yinelenen kodlara sahip olmak, düzenlemelerin bir yere değil başka bir yere yapıldığından uzun vadede size (hem kişisel hem de şirket) daha pahalıya mal olacaktır.

Bir dizi teste ihtiyacınız vardır - ya otomatik ünite testleri ya da var olan işlevsellik sorunlarının olmadığını kanıtlayan regresyon testleri.

Yeniden düzenleme sadece bir "yapmak güzel" - yani yeni işlevsellik doğrudan etkilenen kodda değilse o zaman ben yalnız bırakın. Değişim uğruna bir değişiklik yapıyorsunuz.

Kodun yeniden düzenlenmesi yeni özelliklerin eklenmesini kolaylaştıracak gibi görünüyor; teori bu. Bunu yeni özellikler kapsamına dahil edin. İşletme kullanıcılarından bu şekilde satın alma olasılığınız daha yüksektir. Bu durumda, zorlayıcı bir tartışma yapmalı ve yeniden düzenleme zamanını haklı göstermelisiniz. Umarım bunun gelişim sürecinin gerekli bir parçası olduğunu ve daha az itirazda bulunacağını anlayacaklardır. Bu doğrudan avantajı her zaman gösteremeyebilirsiniz.