İhtiyaçları beklerken özensiz kodun düşük etkili yeniden düzenleme ve kod temizliği


17

Açıkça anlaşılır bir ürün için mevcut bir kod tabanını miras aldım. Temel tasarım ne yazık ki tam bir refaktör (YÜKSEK kuplaj, DÜŞÜK kohezyon, kodun yaygın bir şekilde çoğaltılması, teknik tasarım belgeleri, birim testleri yerine entegrasyon testleri olmadan) hakkında çok az şey yapabileceğim için yetersiz kalıyor. Ürünün geçmişi, riske en az toleransı olan kritik "nakit-inek" müşterilere yüksek maruziyeti, Yunanlıların kızarmasını sağlayacak teknik borç, ÇOK büyük kod tabanı ve karmaşıklığı ve daha önce ekip tarafından hatalara karşı savaştan yorucu bir yenilgi yaklaşımı vardır. ben mi.

Eski ekip gemiyi başka bir bölüme atladı, böylece başka bir projeyi mahvetme fırsatı yakaladılar. Proje Yönetimi Başarısızlığı'nın aksine Teknik Yetersizlik Proje Başarısızlığı yaşamam çok nadirdir, ancak bu gerçekten bu durumlardan biridir.

Şimdilik tek başımayım ama çok zamanım, karar özgürlüğüm ve gelecekteki yönlerim ve sıfırdan bana yardımcı olacak bir takım kurma yeteneğim var.

Benim sorum, fonksiyonel gereksinimleri toplama aşamasında boş zamanlarınız olduğunda böyle bir projede düşük etkili yeniden düzenleme hakkında görüş toplamaktır. Binlerce derleyici uyarısı var, bunların neredeyse tamamı kullanılmamış ithalat, okunmamış yerel değişkenler, tip kontrolünün olmaması ve güvenli olmayan dökümler. Kod biçimlendirmesi o kadar okunamaz ve özensizdir ki kodlayıcı Parkinsons hastalığından muzdaripmiş gibi görünür ve boşluk çubuğunun belirli bir hatta ne kadar basıldığını kontrol edemez. Diğer veritabanı ve dosya kaynakları genellikle açılır ve asla güvenli bir şekilde kapatılmaz. Anlamsız yöntem argümanları, aynı şeyi yapan yinelenen yöntemler vb.

Bir sonraki özellik için gereksinimleri beklerken, düşük etkili düşük riskli şeyleri temizliyorum ve zamanımı boşa harcıyorum mu yoksa doğru şeyi mi yapıyorum diye merak ettim. Yeni özellik, daha önce zaman harcadığım kodu kopyalamak anlamına gelirse ne olur? Çevik bir yaklaşıma başlayacağım ve bunun Çevik gelişim sırasında sürekli olarak yeniden düzenlenmesi için kabul edilebilir ve normal olduğunu anlıyorum.

Bunu yapmak istediğim olumlu ya da olumsuz etkileri düşünebiliyor musunuz?


1
Kurtarmaya değer olanı kurtar, gerisini yeniden yaz ...
SF.

"Proje Yönetimi Başarısızlığına Karşı Teknik Yetersizlik Proje Başarısızlığı yaşaması çok nadirdir [...]" Bu ne kadar doğru, +1.
Gregory Higley

Yanıtlar:


22

Öncelikle, birim testlerinin entegrasyon testlerinin yerini almadığını belirtmek isterim. İkisinin yan yana olması gerekiyor. Entegrasyon testlerine sahip olduğunuz için minnettar olun, aksi takdirde küçük yeniden düzenlemelerinizden biri düşük toleranslı nakit ineklerden birinin size balistik olmasını sağlayabilir.

Derleyici uyarıları ve kullanılmayan değişkenler ve ithalatlar üzerinde çalışmaya başlarım. Önce temiz bir yapı alın. Ardından mevcut davranışı belgelemek için birim testleri yazmaya başlayın, ardından gerçek yeniden düzenleme işlemini başlatın.

Gerçekten olumsuz bir etki göremiyorum. Daha büyük yeniden düzenlemelere yardımcı olacak kod tabanını derinlemesine anlayacaksınız. Yeniden düzenleme yapmak için yeniden yazmaktan hemen hemen her zaman tercih edilir, çünkü yeniden düzenleme sırasında hala çalışan bir ürününüz varken yeniden yazma sırasında yoktur. Ve sonunda ürünün satışı maaşınızı ödemek zorunda.

Gereksinimler gelmeye başladığında, spot ışığı yaklaşımı dediğim şeyi kullanırdım. Her zamanki çevik şeyi yapın (öncelik verin, daha sonra bir yineleme için küçük bir levha kesin ve bunun üzerinde çalışın) ve kod iyileştirmeleri için biraz zaman bırakın. Sonra yine de nerede çalıştığınız refactor. Zamanla bu, kod tabanının geniş alanlarını, kodun o kısmı üzerinde neden çalıştığınızı yönetmeye haklı olarak zorlanacağınız alanlara girmeye gerek kalmadan kapsayacaktır.


Bu cevabı gerçekten çok beğendim. Kod tabanının daha derin bir anlayışına ihtiyacım var ve nakit inekler maaşımı ödüyor ve aynı zamanda sıfırdan başlamak ve en baştan doğru şekilde yapma fırsatını bulduğum diğer müşteriler için daha iyi yeni projeler üzerinde çalışmamızı sağlıyor.
maple_shaft

10

Birim testleri yazmak zamanınızı daha değerli kullanabilir: size kod tabanının mevcut çalışmalarına ilişkin bazı bilgiler verir ve her şeyi sıfırdan yazmak yerine, sahip olduklarınızdan başlamaya karar verirseniz, sağlam bir tabana sahip olursunuz. çok fazla risk almadan değişiklik yapmak. Muhtemelen, birim testleri yazarken, kod tabanında sadece test edilebilir bir şekle getirmek için değişiklikler yapacaksınız; bunlar iyi, çünkü birim test edilebilir genellikle modüler, kapsüllenmiş ve çoğunlukla dış durumdan bağımsız anlamına gelir. Ve hepsinden önemlisi, iyi yazılmış ünite testleri çok değerli teknik belgelerdir. Birim testleri uygulandığında, geçerli kod tabanının ne yapabileceğini ve yapamayacağını yargılamak mümkün olacak, her ihtimale karşı vahşi tahminler yapmak veya yeniden yazmak yerine.


2
O zaman kolay olanlarla başlayın ve yukarı çıkmaya çalışın.
tdammers

2
Bu her zaman benim deneyimimdeki problemdir - böyle bir kod asla teste izin vermek için yazılmamıştır ve ünite testlerine bile izin vermek için açıkça yeniden yazma kodu değilse bile büyük yeniden düzenlemeler yapmak zorunda kalacaksınız .
Wayne Molina

2
Kod testler için tasarlanmamışsa, testlerin etrafından test yapmak için daha fazla sebep vardır - ancak güvenli bir şekilde. Michael Feathers'ın "Eski Kodla Etkili Çalışma" kitabını okuyun; test edilemeyen kodu test edilebilir yapmak için tarifler vardır.
Joe White

1
Katılıyorum; Sadece test olmadığında deneyimlerime göre, ilk etapta testlere hazır hale getirmek için büyük bir yeniden düzenleme başlatmanız gerekir, bu da daha fazla "boşa" yeniden düzenleme sağlar, bu da testlerin yazılmasını zorlaştırır. o zaman her şeyi yeniden düzenlemeyi çok daha zorlaştırır.
Wayne Molina

1
Deneyim ve iyi muhakeme gerektirir. Her şey birim olarak test edilemez (veya edilmemelidir).
tdammers

1

Cevapları karıştırmak - düşüncem testi ve temizliği karıştırmak olabilir - belki 50/50? Bir TDD yaklaşımı yapan bir alan üzerinde çalışıyorsanız - testleri ayarlayın, ünite ve entegrasyon testinin istediğiniz gibi olduğunu bilmeniz ve ardından düzeltmeye başlamanız gerekir. Zamanın izin verdiği şekilde devam edin.

Muhtemelen çok fazla ilerleme kaydetmeyeceğiniz anlamına gelir, ancak en azından bazı alanlarda hoş bir kod tabanına sahip olacağınız ve iyi bir başlangıç ​​tabanınız olacağı anlamına gelir.

Bağırsak tepkim başlangıçta "kırık kodu temizlemek gerçekten zarar verebilir mi?" (aka, derleyici hataları), ancak daha sonra, bir sorunla başa çıkmak yerine, kötü yerlerde bellek bıraktı - aslında kötü bir mola daha da kötü bir hata maskeliyordu çünkü sorunun düzeltilmesi gerçekten bazı gerçekten garip durumlarda işlevselliği bozduğu zamanları hatırladım. Kelimenin tam anlamıyla bir Pandora'nın hoş olmayan sürprizler Kutusu olabilir.

Daha fazla gereksinimi beklerken bunu yaptığınız göz önüne alındığında, kaosu teşhis etmek için yapabileceğiniz her şeyin uzun vadeli akıl sağlığınıza büyük ölçüde katkıda bulunacağını düşünüyorum.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.