Temelde yapısı olmayan bir proje nasıl düzeltilir?

5 yıldan uzun süredir solo çalışan bir yazılım projesi üzerinde çalışıyorum. Başlamak için bir karmaşa vardı (üzerinde çalışmakta olan üçüncü veya dördüncü geliştiriciyim) ve şu anda daha az karışık olmasına rağmen hala inanılmaz şekilde dağınık durumda. Kontrol altına almadaki ilerleme oranı buzullu ve içinde bulunduğu durum karşısında umutsuz hissetmeye başladım. Gerçekten düzeltmeye nasıl başlayabilirim?

Projenin özellikleri: MySQL arka ucu ve C # ile yazılmış bir raporlama motoru ile neredeyse tamamen Visual Basic Classic'te (VB6) yazılmış bir satış programıdır. C # raporlama modülü üzerinde çalışmak bir zevkti, sadece son birkaç yılda yazılmıştı ve bundan önce tüm raporlar Crystal Reports 9'da yapıldı (evet, hala ona dayanan bazı raporlarımız var).

Ancak asıl programın kendisi tam bir felakettir. Toplamda 90k LOC yoktur ve yaklaşık 10k yorum satırı vardır (çoğunlukla dokümantasyon değil, yorumlanan eski kod). 158 form dosyaları ve 80 modül dosyaları. Bunların ne kadarının kullanıldığı hakkında hiçbir fikrim yok, çünkü programın bazı özellikleri basitçe kullanımdan kaldırılmış ve ilgili kod programdan kaldırılmadan böyle bir şekilde belirtilmiş. Kodun yalnızca% 50'sinin fiili üretken kullanımda olduğunu tahmin ediyorum.

Sadece bir çok müşterinin güvendiği bir şeyi kırıp kırmadığımdan emin olamadığımdan, kodun çoğuna dokunmaktan korkuyorum, sayabileceğimden daha fazla vesile oldu. Sanırım kod boyunca mayınlar dağılmış gibi.

Projede gerçekten bir yapı yok. Şimdiye kadar reform yapmak için sabrım olan birkaç yer dışında, nesne odaklı değil. Bir formda veri almanız gerekiyorsa, bir veritabanı nesnesini başlatır, sorgunuzu burada işlevinde açıklar, yürütür ve veri kümesiyle ne yapacağınızı yaparsınız.

Proje üzerinde çalışmaya başladığımda, kullanımda hiçbir kaynak kontrolü yoktu. Kullanmaya çalıştığım diğer insanları cesaretlendirmeye çalıştım, ama ben yeni bir adamdım ve insanları yıkmak için kullanmaya çalıştım ama başarısız oldum. Şirketin lider geliştiricisi, son birkaç yıl içinde nihayetinde büyük bir hata yakaladı ve şimdi tüm geliştiricilerin tüm projeler için kaynak kontrolünü kullandığından emin oldu, bu yüzden en azından bu bir gelişme.

Eğer projeyi tam zamanlı olarak yeniden düzenlemek için çalışabilseydim, iyi bir ilerleme sağlayabileceğimi ve hatta projenin tam anlamıyla makyaj yapmamın ne kadar süreceği konusunda bir tahminde bulunabileceğimi düşünüyorum. Sürekli olarak yangın söndürmesi, hataların giderilmesi, özelliklerin eklenmesi vs.

Peki bu projeyi gerçekten düzeltmeye nasıl başlarım? VB6'yı başka bir dille mi kullanmaya çalışıyorsunuz? Boş zamanlarımda programı yeniden yazmaya çalış. Yoksa bu tamamen umutsuz mu?

Güncelleştirme

Bu görevden sonra, yenilenen coşkuyla projeye geri döndüm, ancak bu kadar yavaş bir ilerleme gördükten sonra birkaç ay içinde umutsuzluğa geri döndüm. Sonra bir sonraki yıla kadar bu döngüyü 2 veya 3 kez daha tekrarladım.

O zamandan beri farklı bir işe taşındım. Her ne kadar uzun yıllar sonra vb6 ve sadece diğer teknolojilerle olan çevresel deneyimlerden sonra arama zordu ve yol boyunca birçok reddetme ile karşı karşıya kaldım (bir yıl boyunca yaklaşık bir düzine görüşme). Bu durumda başkalarına tavsiyem, sadece bu faktör için ayrılmayı düşünmektir. Bunun gibi çıkmaz bir pozisyonda kalarak kariyerinize verebileceğiniz zararı göz önünde bulundurun.

Artık kaynak kontrolünde olduğu için, yorumlanan koddan kurtulabilirsiniz.

Burada benzer bir durumda (80KLOC VB6 uygulaması, kaynak kontrolü olmayan, gerçek bir yapıya sahip değil, hemen hemen her şeyi olay işleyicilerinde yaptım) başladım.

Yaklaşık 2 yıl sonra, C # 'ya dönüştürülen yarıdan fazlasını kazandım (genellikle önemli yeni özellikler gerektiğinde). Tüm yeni C # kodlarının birim test kapsamı vardır. Yine de C # 'ya dönüştürmek kesinlikle daha uzun sürüyor. Eğer önemli yeni modüller eklemezseniz, o rotadan aşağı inmezdim.

Yaptığım şeylerden biri, veritabanından otomatik olarak oluşturulan ilkel veri erişim katmanı oluşturmaktı. Bu, en azından bir tablo sütunu adının değiştiği yerde sorun çıkardı ve koddaki tüm yerleri bulamadım. Ayrıca, iş mantığını yavaşça form olay işleyicilerinden modüllere taşıdım.

Bununla birlikte, başvurunun yalnızca iç olması avantajına sahiptim. Dağıtılacak tek bir sitem olduğu için, sizden çok daha büyük riskler alabilirim. Eğer bir hata yaptıysam, düzeltmek genelde büyük bir iş değildi. O kadar lüksün yok gibi.

Bence en iyi seçeneğin şu yaklaşımı benimsemektir:

1. Her detayı şaşırtıcı bir şekilde öğrenin. Bu, istemeden bir şeyleri kırmanızın daha az olası olmasını sağlar.
2. Refactor ayrılığı ve yapıyı acımasızca geliştirmek için, ancak orada nesne yönelimli programlama gibi yeni bir metodolojiye geçmeyi denemeyin, çünkü VB6 onu emiyor.
3. Bunu bir öğrenme deneyimi olarak kabul edin. Daha düşük bir yol görmemiş olsaydınız, farklı bir yolun daha iyi olduğunu nasıl bildin?
4. Yazılacak büyük bir modülünüz yoksa, yeni bir dilde / çerçevede / platformda yeniden yazmayın. O zaman bile dikkatlice düşünün.

Unutmayın, programın amacı şirketinizi para kazandıran bir ürün olmaktır. Kusursuz bir sanat eseri olmak zorunda değildir (ve ben mükemmeliyetçiyim, bu yüzden bunu kabul etmem gerçekten zor). Bazen pragmatizmi kucaklamak daha iyidir.

Çok sayıda COBOL programcısı olduğu ve büyük miktarlarda eski kuralları koruduğu söyleniyor. Hepsi yeni bir dilde yeniden yazmak için delice çalıştıklarından şüpheliyim. :)

Yapmanız gereken şey yeniden düzenlemektir. Böyle bir durumda ünite testi olmadan, hiçbir şeyi kırmadığınıza dair güven veren yeniden düzenleme yapmak neredeyse imkansızdır. Bu nedenle, birim testleri oluşturmaya başlayın. Kodun davranışını belgeleyin - (yalnızca) kağıda değil, ancak daha fazla kodda - birim test eder. Testleri yaptıktan sonra, kodu yeniden yapılandırmaya başlayabilirsiniz.

David Agan'ın " Hata ayıklaması " ndan bir kural akla geliyor: Düşünmeyi bırak ve bak. Elinizde çok miktarda metin işleme kapasitesine sahip bir makine var. Artık hangi kodun kullanılmadığını kesin olarak belirlemek için kullanın ve merhametsizce kaldırın. Bir hata yaparsanız, kaynak kontrolü bu içindir.

Bu kolay kısmı. Gelecek hakkında düşünmeniz gereken şey, nasıl fil yersiniz? Bir seferde bir ısırık. Martin Fowler'in " Refactoring " ini alın ve işlevine göre, dosya halinde kaydedin. Bir şeyi tamamen sıyrılmayın ve gereksinimlerin ne olduğunu düşündüğünüzden yeniden yazmayın. Bir dağcı gibi çalışın, bir sonraki yerine kadar önceki güvenliğinizi asla kaldırmayın.

Yeterli metafor var mı? Mesele şu ki, yavaş ve istikrarlı bir şekilde alırsanız, bir işlevi yeniden adlandırmak veya bölmek kadar basit bir çok gelişmeyle birlikte, yıllar içinde yapılan hata ayıklama ve özellik istekleri boyunca oluşturulan iyi kısımlarını yok etmeden kodun kötü kısımlarını iyileştirebilirsiniz. . Kodun her zaman taşınabilir durumda kalmasını istiyorsunuz. Daha modern bir dile taşırken bunu yapmak mümkün ise, onun için gidin.

Söylemekten nefret ediyorum ama bitmeyen bir yama / geliştirme döngüsüne devam etmenin ve hiçbir şeyin kırılmayacağını ümit etmenin ötesinde "tamamen umutsuz" ile giderdim. Tanımladığınız gibi pek çok VB6 projesi gördüm ve bunları yeniden ateşlemeye / yeniden yazmaya / tekrar yapmaya çalışıyorum. NET'i yeniden kovma girişiminde bulunmaktan, çoğu zaman kovulma girişiminden sorumlu olan kişilerle korkunç bir şekilde başarısız oluyor.

Mesele şu ki, sıfırdan başlayarak tamamen yeniden yazma gerekli olacak er ya da geç. İyi destekleyen VB6 ve Windows sürümleri düşüşe geçti. VB6'nın ilginçliklerini bilen ve bunun gibi programlar üzerinde çalışmaya istekli geliştiriciler bulmak daha da azalıyor. VB6'nın dahili limitleri bunun gibi devasa programlarda etkilenerek garip hatalara yol açacaktır.

Toplam için iyi bir fikir birliği ve taahhüt varsa, bu noktada yeniden topraklayın, yeniden tasarlayın ve yeniden yazın, üzerinde çalışmaya başlayın ve devam eden bakımı başka birine (müteahhitler, küçük programcılar, sizin için ne işe yararsa) verin. Eğer insanlar buna başlamak için yeterince ikna olmazlarsa, acının yeterince büyük hale gelmesi için bekleyin ya da daha yeşil meralara geçin.

Burada zaten bazı iyi cevaplar, bir şey eklemek istiyorum. Her şeyi yeniden yazmaya çalışmak yerine, belki de bu modüllerin en azından bir kısmını çoğunlukla 1: 1'e VB.NET'e taşıma şansına sahip olacaksınız (elbette, bunu yaparken de çok dikkatli olmalısınız)? Deneyimlerime göre, bu tür taşıma işlemleri mevcut tüm işlevselliği sıfırdan yeniden oluşturmaya çalışmaktan ~ 5-10 kat daha az çaba ile yapılabilir. Ve taşıdıktan sonra , iyi bir birim test araçları, otomatik yeniden düzenleme araçları, gerçek OOP vb.

Benzer bir durumdaydım, eski bir 16 bit C ++ programını (150k LOC), kullanılan orijinal GUI çerçevesinin artık mevcut olmadığı 32 bit dünyaya geçirmek zorunda kalıyordum. Yeniden yazmanın gerçekçi olmadığını anlamamız biraz zaman aldı, ancak bu şeyi .NET dünyasına aktarmaya karar verdikten sonra, C ++, C ++ / CLI ve C # kullanarak, bunun gerçekleşmesi için sadece 9 aya ihtiyacımız vardı (yaklaşık 1 dev ile) bu proje üzerinde tam zamanlı çalışma). GUI parçası için birim testimiz yoktu, tüm bu parçaları manuel olarak test ettik.

Her ne kadar yapılması gereken çok önemli bir şey olsa da, VB6'da yapılması oldukça zor olan bir şey olsa da, uygulamanızı ünite testine çok fazla önem vermesine rağmen, Steven McConnell böyle bir projede nasıl başa çıkılacağı hakkında mükemmel bir kitap yazdı.

Ona bir göz atın:

Steven C. MCCONNELL: Legacy Code, Second Edition ile Etkili Çalışma. Microsoft Press, Haziran 2004.

Temel olarak, amacı her seferinde bir parça olmak üzere yavaşça almaktır. Ayrıca, herhangi bir şeyi kırması muhtemel olmayan yeniden yapılandırma tekniklerini kullanarak, bazen kısa vadede biraz daha kötü hale getirerek başlamasını ve kod daha temizledikçe ve onu destekleyecek ünite testlerine sahip olduğundan daha ileri teknikleri kullanmaya başlamasını önerir.