Size kirli kod hakkında bazı sorular sormak istiyorum. Orta dereceli bir projeye kod yazmış bazı acemiler var. Kod çok büyük bir çamur topudur. Gelişmiş programcılar değiller. Sadece biraz java hakkında klavyeyi kullanmayı biliyorlar. Ana sınıflarında 12 000 satırlık kod yazdılar, ancak 6 000 satır NetBeans'a ait.

Benim işim kodu analiz etmek ve kodu korumanın iyi bir yolunu önermek. Benim fikrim projeyi hurdaya çıkarmak ve OOP metodolojisi ile yeni bir proje başlatmak. Son zamanlarda sorun hakkında bazı notlar ve fikirler topladım, bu siteden ve diğerlerinden.

Şimdi, aşağıdaki soruları var:

1. Kodu tamir edip bir OOP olarak değiştirmeli miyiz? Şimdi hata ayıklıyoruz.
2. Kodda yorum yok, dokümantasyon yok, özel programlama stili yok. Bunu değiştirmek gerçekten pahalı ve zaman alıcı. Bu konuda ne yapabiliriz?
3. Onlara tüm kuralları takip etmeyi nasıl öğretebilirim (yorum yapma, OOP, iyi kod kalitesi vb.)?
4. Kod hatalı ve hata eğilimli. Ne yapabiliriz? Test yapmak? Düzeltme için neredeyse iki ya da üç A4 kâğıt yazıyoruz, ancak bu sonsuz görünüyor.

Onlarla yeni olduğumu söylemeliyim. Sanırım projeye çok geç insan ekleme konusunda da kuralları çiğnediğimi düşünüyorum. Onları bırakmam gerektiğini mi düşünüyorsun?

Adım 0: SCM'ye Yedekleme

Çünkü, yorumlarda JBRWilkinson tarafından belirtildiği gibi, sürüm kontrolü (geri dönüşü olmayan) felakete karşı ilk savunma hattınızdır.

Ayrıca yedekleme yazılımı yapılandırma ayrıntılarını, çıktılar oluşturma prosedürlerini vb.

1. Adım: Önce Test Et

Ardından testler yazmaya başlayın :

• ne işe yarıyorsa
• ve başarısız olan şey için.

Ne yapmaya karar verirsen ver, işin bitti. Şimdi ikisini de yapabilirsiniz:

• sıfırdan başlamak ve yeniden yazmak ,
• veya düzelt .

Tavsiyem , genel mimariyi sıfırdan başlatmak , ancak kontrol noktalarını doğrulayan parçaları karışıklıktan çıkarmak ve uygun gördüğünüz şekilde yeniden yansıtmak olacaktır.

Adım 2: Doğrulayın ve İzleyin

Sürekli Bir Entegrasyon sistemi kurun ( adım 0 ve adım 1'i tamamlamak için ) VE Sürekli Denetim sistemi ( adım 4'e hazırlamak için ).

Adım 3: Devlerin Omuzlarında Durun

(her zaman gerektiği gibi ...)

• Kalıplara Yeniden Bakmak
• Yeniden düzenleme: Mevcut Kod Tasarımını Geliştirin .
• Eski Kod ile Etkili Çalışma ( Jason Baker tarafından önerilen şekilde )
• üstlenmeden

4. Adım: Temizleyin

Bu tür söylemeye gerek yok, ancak kodun kendisiyle dolaşmak yerine, tasarımdaki ve uygulamadaki hataları bulmak için basitçe kodları / statik analizörleri ve kırık kod tabanında diğer araçları çalıştırmak isteyebilirsiniz.

O zaman temizlik hizmetinde biraz yardımcı olacak bir kod formatlayıcı çalıştırmak isteyebilirsiniz.

5. Adım: İnceleme

Yenileme yaparak veya temizlik yaparak küçük böcekleri kolayca ortaya çıkarabilirsiniz . Bir tuşa yalnızca yanlış bir seçim ve hızlı bir şekilde basmak yeterlidir ve ilk başta farketmeden oldukça önemli bir şeyi silebilirsiniz. Ve bazen etki sadece aylar sonra ortaya çıkacaktır. Elbette, yukarıdaki adımlar bundan kaçınmanıza yardımcı olur (özellikle güçlü bir test kablo demeti uygulayarak), ancak ne yapıp ne kaymayacağını asla bilemezsiniz. Bu nedenle, yeniden yansıtmalarınızın en az bir diğer özel göz topu çifti (ve tercihen bundan daha fazlası) tarafından incelenmesini sağlayın.

Adım 6: Gelişim Sürecinizi Gelecek Belgesi

Yukarıdakilerin hepsini alın ve eğer değilse, normal gelişim sürecinizin doğal bir parçası haline getirin. Bunun saatinizde tekrar olmasına izin vermeyin ve sürecinizde güvenceleri uygulamak ve politikalarınızda bunu (hatta mümkün ise) uygulamak için ekibinizle birlikte çalışmayın. Temiz Kod üretmeyi öncelikli yapın.

Ama gerçekten, test et . Çok fazla .

Şahsen, ben bu projeye Legacy Code ile Etkili Çalışmanın bir kopyası elime geçene kadar başlamazdım . Cidden, bu tür bir şey için yazılmıştır. Zor kodlarla baş etmek için stratejilerle dolu ve size burada verebileceğimden çok daha fazla ayrıntıya giriyor.

Orada birkaç kez bulundum. Kuralım şudur: yazılım önemsiz değilse (sahip olduğunuz kaynak için 1 haftadan daha fazla iş varsa) ve çalışıyorsa, o zaman saklayın ve artımlı yeniden düzenleme işlemine geçin.

Yazılım gerçekten işe yaramazsa (çok fazla hata, net olmayan gereklilikler vb.) Sıfırdan yeniden yazmak daha iyidir. Aynı oldukça küçükse.

Yeniden yapılanmadaki nokta (Fowler's kitabında ve Kerievsky'ninki gibi bir http://www.industriallogic.com/xp/refactoring/ ) sistemin çalışmasını sürdürmesi, belki de yeniden yapılanmanın iki kez sürmesi, ancak risklerin sıfır olmasıdır.

Sıfırdan yeniden yazmak, yanlış anlama gereksinimlerinden yanlış uygulamaya kadar (takımın çoğu aynı olacaksa) birçok risk oluşturabilir.

Aslında iki kez sıfırdan başlayarak karmaşık bir prosedür gördüm ve hala beklendiği gibi çalışmıyor.

Tamamen tekrar yazardım. Bazen böyle bir kodu onarmak imkansızdır. Başka bir seçenek de yeni özellikler eklemeden çalışmasını sağlamaktır. Ekibe iyi kod yazmayı öğretmek (iyi tasarlanmış, belgelenmiş, testlerle), şimdi sahip olduğunuz kodu düzeltmelerini sağlar. Herkesin, onun yerine değil, diğer geliştiricilerin kodlarını düzeltmesine / incelemesine izin verin. Bazı denemelerden sonra, bu tür kodları gözden geçirmenin / düzeltmenin neredeyse imkansız olduğunu anlayacaklardır.

İnsanları geç projelere eklemek çok nadiren yardımcı olur. Genellikle son teslim tarihlerini keser. Projeyi başarılı bir şekilde bitirmek için elinizden geleni yapmalı ve sonra ayrılmayı düşünmelisiniz.

Tavsiyem tüm kodu tamamen silmek değil. Bu, her gelişim ekibinin karşılaştığı günlük yaşam sorunudur. Bir seferde kodun bir bölümüne saldırın. Düzelt, temizle, belgele. Ve sonra diğer tarafa geç. Asıl mesele her zaman elinizin altında bazı gönderilebilir kod tutmaktır. Kodun tamamını sıfırdan yeniden yazmak, şu ana kadar harcanan zamanın miktarını alır ve geçerli olandan daha iyi olacağının garantisi yoktur.
Fakat aynı zamanda insanlar kodu bu şekilde yazmaktan kaçınmalıdır. Kod incelemelerinde biraz daha zaman harcayın. Bazı tek tip kodlama stiline uyarlayın. Önce tasarımı tartışın ve sonra kodu yazın. Böyle basit şeyler büyük değişiklikler yapacaktır.

Netscape'in neden gevşek olduğunu anlatan Nice Blog

Çalışırsa, yeniden yansıtın. Bunu yapmanıza yardımcı olacak araçlar var. Çalışmazsa, büyülü kod geliştirme komutunu kullanın, örneğin deltreeWindows'ta. rm -rfLinux'ta.

Kodu tamir edip bir OOP olarak değiştirmeli miyiz? Şimdi hata ayıklıyoruz. [... hata içeriyor, belgeleme yok ...]

Ben orada bulundum, sende benim sempati var. Bununla ilgili bir bakış açısı elde etmenize yardımcı olabilecek bir makale bile yazdım . Ancak kısaca:

Kod içeriyorsa çok fazla çoğaltma , yeniden yazmalısınız. Eğer ayırt edilebilir bir yapı yoksa (açık arayüzler, spagetti), yeniden yapılanma başarısız olur ve muhtemelen tekrar yazmalısınız.

Onlara tüm kuralları takip etmeyi nasıl öğretebilirim?

Kişisel olarak ne kazanabileceklerini göstererek, neden bunu yapmak isteyebileceklerini açıklamaya başlayın. Bununla hemfikir olduklarında ve öğrenmeye istekli olduklarında, onlara shuhari kullanarak öğretmeye başlayın .

Önerim @ duros'un & @Manoj R'nin cevaplarının bir birleşimidir.

Sıfırdan başlayın, bu kez iyi kod / OOP / yorumladı / etc oluşturmak için aklınızda bulundurun, eski kodunuzdan / kopyalayıp yapıştırın. Eski kodunuzun kötü bölümleriyle karşılaştığınızda, onları yeniden yazın / yeniden düzeltin.

Geliştiricileriniz iyi eğitilmemişlerse, bunları kurslara göndermenin iyi olacağını düşünüyorum. Hızlı değişen BT endüstrisinde düzenli yeniden eğitim için önemlidir