Kodu temizlemek için düzenli zaman planlamak iyi bir fikir midir? [kapalı]

Küçük bir geliştirici ekibi yönetiyorum. Çoğu zaman kodumuzu temizlemek için bir iki gününü harcayacağımıza karar veririz.

Düzenli bir zaman planlamak, her 2 ayda bir 1 hafta söylemek, sadece kod tabanımızı temizlemek için iyi bir fikir olabilir mi?

Hayır.

Üzerinde çalışırken düzeltin:

• Üzerinde çalıştığınız parçayı yeniden canlandırmayı beklerseniz, bu konuda çok şey unutursunuz ve tekrar tanımak için zaman harcamanız gerekir.
• Gereksinimler değiştiği için hiç kullanılmayan biten "altın kaplama" kodunu kullanmayacaksın

Kişisel fikrim: Projelerin% 90'ı için kesinlikle gerekli .

Özellikle satışlarla yoğun olarak yürütülen projeler için, genellikle her sürümde yeni özellikler eklemek için büyük bir zorunluluk vardır ve kaçınılmaz olarak, daha iyi içgüdülerinizden ödün vermek zorunda kalmazsınız ve burada ve orada birkaç küfür / saldırı ortaya koymak zorunda kalırsınız.

En sonunda, bu küçük ödünç verme yoluyla, kod tabanındaki kusurların etrafında çalışmak için adil bir süre harcamanız ve bunun tam potansiyelini kullanamamanız konusunda yeterli miktarda 'teknik borç' tahakkuk ettirdiniz.

Genellikle bu şekilde üretilen iki tür sorun vardır:

• Kolayca çözülebilen ancak sistemik olabilecek küçük olanlar, örneğin yanlış adlandırılmış parametreler, eksik hata işlemesi vb. Bunlarla başa çıkmanın en iyi yolu kod incelemeleri ve kodu yazarken / değiştirilirken kontrol etmektir. Diğerlerinin de belirttiği gibi, bu hataları düzeltmek için özel bir refaktör döngüsü ayarlamaya gerek yoktur.
• Eksik şartnamelerden veya erken tasarım kararlarından doğmuş olabilecek büyük olanlar veya aynı sorun için iki farklı çözüm üreten iki geliştirici / ekip. Bunlar genellikle düzeltilmesi daha zordur ve düzeltmek için uyumlu bir çaba gerektirir. Sonuç olarak sürekli bir sıkıntı haline gelinceye kadar genellikle ertelenirler. Bu tür meselelerin giderilmesi için özel bir süre gerekir.

Genellikle her 3 ila 4 devirde saf bir yeniden yapılandırma / hata düzeltme döngüsü için zaman ayırmaya çalışıyorum. Her zaman geliştiricilerimden, kod tabanından ne kadar sıkıntı duyduklarını söylemelerini isterim. Her geliştirici temizleme çabası üzerinde çalışmak zorunda kalmaz - genellikle ekipleri biraz (ancak her zaman değil) biraz şaşırtabilirsiniz, bu nedenle herhangi bir zamanda sadece bir takım temizlik üzerinde çalışır.

Geliştiricilerim, check-in işleminden (Subversion) ya da ana geliştirme şubesiyle (Git) birleşmeden önce kodlarını değiştiriyor.

Aşağıdakileri yapmalarını sağladım:

• Alakasız yorumları kaldır
• Yöntemlerinin, argümanlarının ve değişkenlerinin uygun şekilde adlandırıldığından emin olun
• Sınıflarında bir yapı olduğundan ve öğelerin olması gerektiği gibi kapsüllendiğinden emin olun
• Okunabilirliği artırmak ve kod kokularını azaltmak için refactor

Daha büyük projeler için, kod, geliştirme branşından ana şubeye birleştirilmeden önce resmi olarak gözden geçirilir.

Bence "zaman ayırmanın" ertelenebilecek ya da söz konusu iş nedeniyle ertelenebilecek bir şey olduğu anlamına geleceğini düşünüyorum. Geliştiricilere bunu bir check-in (JIRA’daki bir değişiklik isteğine / konusuna eşittir) yapmak suretiyle yaptırmak daha kolay yönetilebilir.

Bence değil. Teknoloji borcuyla karşılaştığınızda ve onu düzelttiğiniz zaman arasında çok fazla zaman geçmesine izin verirseniz, sorunun ne olduğu bağlamını kaybedersiniz. Düzeltilmesi daha uzun sürüyor ve daha da kötüye gitme eğiliminde. En önemlisi, insanlar kırık camları terk ediyorlar çünkü “haftada temizlik” değil.

Kişisel olarak, sprintte daha önce bir miktar yarattığımızı biliyorsanız, her bir sprint teknik borç temizliği için pazarlık ederim. İnsanların kafasında borcu taze tutar. Yeniden kodlamanın daha kolay olması için, sorun kodunu kullanarak kod miktarını sınırlar. Teknik borcun birikmesini önler. Ve geliştiricilerin sadece bir şeyleri tokatlamasını engellemeye yardımcı olur, çünkü onları hemen sonraki sprint yapmalarını sağlayacağım (bu yüzden ilk etapta da doğru yapabilir).

Kesinlikle evet diyebilirim, şartlı olarak: sık sık, tercihen haftalık olarak yapılmalıdır. Programlı düzenli bir kod incelemesinin, kod incelemesinden çıkan öğeler üzerinde etkili bir şekilde çalışmasının çok hızlı bir şekilde sonuçlandığına inanıyorum. Pswg'nin cevabına bakınız.

2 ayda bir 1 hafta kesinlikle yeterli değildir. Bu, sorunuza 'Hayır' cevabını veren diğer cevapların çoğundan bahseder. Bu cevapların çoğunun özü, çok uzun süre beklerseniz, artık kodla temasta kalmayacağınız ve genellikle düzeltmenin / temizlemenin / düzelticinin daha uzun sürmesidir.

Arada bir ek kodla temizleme egzersizi yapmak istemeniz net değil. Bu anlamda, evet. Ne takip ettiğimiz uygulamaları, her zaman bazı bozulmalar meydana gelir.

Bunu, ilk olarak doğru şeyi [SOLID ilkelerini uygulama, ilgili birim testleri, denetimler vb.] Yapmamak için mazeret olarak kullanmamalısınız.

Ben şu anda iki popüler "Hayır" "Evet" cevabının aynı gerçeğin iki yönü olduğunu düşünüyorum. OP'nin yönettiği bir gruptan bahsettiğini, sadece bir birey olarak olmadığını unutmayın. Gruptaki tüm geliştiricilerin temiz ve kolay okunur kodlar yazabilecek kadar disiplinli olduklarını varsayamayız; ve dış baskı ve çevik stil metodolojileri sorunu var. Ayrıca, insanların en iyi çabalarıyla bile, stildeki farklılıklar, birbirlerinden ayrıldıklarında temiz olarak kabul edilebilecek, ancak diğer insanlarla birlikte düşünüldüğünde kirli olmayan kodlar yazabilecekleri anlamına gelir (garip arayüzlerden bahsetmeden).

Öte yandan, "üzerinde çalışırken düzeltmek" bence arzu etmek için bir ideal. Kodunuzu daha "sabit" hale getirerek yapabilirsiniz

• dikkatli akran CRing
• birim testlerini kodun kendisi ile birlikte yazma
• kodlama kurallarını kabul etmek
• otomatik biçimlendirici ve işaretleyicileri kullanma (ancak YMMV)
• vb.

Şimdi, eğer OP ekibi yukarıdakileri benimsediyse ve astlarını - örneğin kod incelemeleri sırasında ve periyodik kod temizleme oturumları sırasında - sübvansiyonları öngörmeyi ve çirkinliği önceden önlemeyi denemek için zaman içinde daha azına ihtiyaç duyacaklarını umarsa temizlik zamanı. (Ve o zaman bu süreyi dokümantasyona, daha derin yeniden düzenlemeye ve yazdıkları ve birleştirdiklerinin bilgi paylaşımına ayırabilirler.)

Düzenli zaman planlamanın, bunun düzenli bir şelale tarzı bir projede mi yoksa çevik bir hikayede mi yapılacağı konusunda çok iyi olduğunu düşünüyorum. Belirli bir zamana sahip olmak, programınıza göre çalışmak kadar değerli olmayabilir. Bu, projenin gerisindeyken temizleme gününü iptal etme vs. zamanlamanın bir parçası olarak halletmenizi sağlar.

Muazzam miktarda kod borcu olan bir projeyi yönetmiş olmak, bunları düzenli olarak çalışmak, işlerin sorunsuz yürümesinin anahtarıydı. Bazılarımız büyüktü, bazıları küçüktü.

Bu tür bir çalışma ayından sonra, operasyon ekibimiz liderliğin her şeyin ne kadar düzgün çalıştığını söyledi.

Her madde çok fazla görünmeyebilir, ancak tüm borçlar gibi reklam yapar.

İdeal cevap Hayır, çünkü bunu bir zorunluluk haline getirmekten kaçınmak için gerekli adımları atıyorsunuz (daha önce belirtilen birkaç nedenden ötürü temizleyin).

Sonunda amaç bu olabilir, ancak bunu uygulamaya koymaktan uzak bir ekibiniz olabilir.

Yöneticiler biraz sorumluluk almak zorundadır Her zaman geliştiricinin hatası değildir. Yöneticiler bir şey söyleyebilirler, ancak projelerin bitmesi ve kötü uygulamaları teşvik eden önerilerde bulunmaları için baskı yapmaya başlarlar. Kelimenin tam anlamıyla, "daha sonra temizleriz" diyebilirler veya işe yararsa, bu yeterli olacaktır.

Bunun önemli olduğunu göstermek için belirli bir zaman ayırmaya başlamanız gerekebilir. Ekibinizin kodlarını (verilenleri değil) temizleyebildiğini öğrendikten sonra, daha sık dahil etmeyi deneyebilirsiniz.

Sonunda, bir zaman ayarlamak zorunda kalmamalısınız.

Kişisel olarak, yeni bir problem çözme ve işleri düzenli tutmaya çalışırken işe alma konusunda mücadele ediyorum. Bu konuda daha iyi oluyorum, ancak genellikle bilinçli bir mola verip olayları temizliyorum. Bu benim için farklı bir zihin seti. Sonunda, katı uygulamalar alışkanlık haline gelir.

Hayır, kodlama yaparken bunu yapmalısınız. TDD kullanıyorsanız buna refactoring denir. Kodunuzu düzeltmek ve temizlemek için bir veya iki ay beklediğiniz sorun, kod davranışınızı değiştirebilmenizdir, çünkü kodunuzun her bir parçasını hatırlamıyorsunuzdur.

Öncelikle bir şeyin çalışmasını sağlamak için gerekli kodu kodlamaya dayanan ve yeniden tasarladığı, optimize ettiği ve güzelleştirdiği yeniden yapılanmayı öneririm.