Belirli bir kalite standardını karşılamak için eski bir kod tabanını nasıl güncelleyebilirim?


10

Eski kod tabanlarını iyileştirmeye yönelik araçlar ve teknikler hakkında çok fazla bilgi var, ancak başarılı bir gerçek dünya vaka çalışması ile karşılaşmadım. Çoğu tavsiye mikro düzeydedir ve yardımcı olsa da, makro düzeyde yardımcı olabileceğine dair kanıt eksikliği nedeniyle birçok insanı ikna etmez.

Özellikle tam bir yeniden yazma değil, bugünün kalite standartlarını karşılamak için büyük bir eski kod tabanını güncellerken gerçek dünyada başarılı olduğu kanıtlanmış artan iyileştirmeleri arıyorum.

Önce:

  • Büyük: 1MLOC'den büyük
  • Eski: otomatik test yok
  • Düşük kalite: yüksek karmaşıklık, yüksek bağlantı, yüksek kaçış kusurları

Sonra

  • Otomatik testler
  • Daha kolay güncelleme / bakım
  • Yüksek kalite: azaltılmış karmaşıklık, ayrıştırılmış kod, birkaç kaçış hatası

Gerçek dünyada, büyük bir eski kod tabanını kalite standartlarının üzerinde, yeniden yazma işleminden geçmeden başarılı bir şekilde güncellemek için ne tür artımlı adımlar kanıtlanmıştır?

Mümkünse, yedeklemek için cevabınıza "başarılı" bir kalite iyileştirme sürecinden geçmiş büyük bir eski projeye örnek bir şirket veya vaka çalışması ekleyin.




7
Tüm finansal endüstri? Çoğu 40 yıllık FORTRAN kodunda çalışır. Netscape'in aksine, onu chuck edemezler ve sıfırdan yeniden yazamazlar, bu yüzden bu zaman boyunca yavaş yavaş gelişiyor.
MattDavey

2
POV'umda, Netscape başarılı bir örnek olarak neredeyse hiç kullanılamıyor - proje şirketi sona erdi ..... o zamanlar kar amaçlı bir ticari organizasyondu. Hissedarlar o gün üst rafı kabarcıklı açık çatlamak düşünemiyorum ...... aslında mükemmel bir çalışma olarak Netscape kullanarak "Ne yapmamalı" satırları boyunca iyi bilinen bir beyaz kağıt var ....
mattnz

2
Merhaba @mikelong Sorunuzu yeniden denemek ve yeniden açmak için düzenledim. StackExchange standartlarına göre "yapıcı olmayan" kabul edilen örnek bir liste isteyen orijinal sorunuz. "Yüksek kalite" ile ne demek istediğiniz hakkında daha fazla ayrıntı eklemek veya bir hata yaptıysam ifadeyi güncellemek için daha fazla düzenlemekten çekinmeyin . :)
Rachel

Yanıtlar:


8

Http://www.amazon.com/Working-Efftively-Legacy-Michael-Feathers/dp/0131177052 gibi kitaplar , sektörde ne kadar büyük ve eski düşük kaliteli kod tabanlarının yaygın olduğuna tanık olmalıdır.

Neden duymadığınızı veya görmediğinizi tahmin ediyorum ve daha da önemlisi, siz kendiniz üzerinde çalışana kadar onları muhtemelen duymayacaksınız, kimse çeşitli nedenlerden dolayı temiz çıkıp kodlarını söyleyemez. temel önemsiz yansımalarla karşılaşmadan yukarıdakilerin hepsiydi.

Bu, bahsettiğiniz çalışmaların eksikliğini açıklayabilir. Peter van der Linden'in Derin C Sırları gibi yeterli kitap okursanız, projenin hangi bölümünün eksik olacağı yaklaşık milyon dolarlık hataları okuyacaksınız.

NOT: Bunu bir yorum yapmak istedim, ama çok uzundu. Bunun soruyu tam olarak cevaplamadığını anlıyorum.

DÜZENLEME: C ++ 11 & GCC'nin uzun vadeli uygulanabilirliği sorgulanır - geliştiriciler GCC'yi yeniden düzenler ve LLVM / clang olarak daha fazla sayılabilir yaparsa, iyi bir örnek sağlayabilir. Tartışma, bazı yerlerde belgelerin zayıf olduğunu ve yeni geliştiriciler için giriş engelini daha yükseğe ittiğini belirtiyor.


4

3 Şubat 2013 tarihinde, LibreOffice geliştiricilerinden Michael Meeks birkaç gün içinde "LibreOffice: dev bir kod tabanını temizleme ve yeniden çarpanlara ayırma ya da yeniden yazma işleminin neden daha kötü olacağı" başlıklı bir konuşma yapıyor. ." Tam olarak sorduğunuza benziyor: birim testleri, karışık bir yapı altyapısı ve yirmi beş, Almanca olarak kapsamlı bir şekilde yorumlanmış, iyi anlaşılmamış, devasa bir kod tabanı almak için neler yaptıklarının tartışılması yıl ödenmemiş teknik borç "ve modernize.

Sunum çevrimiçi olarak yayınlanabilir ve (sanırım) kayıtlar ileriki bir tarihte yayınlanacaktır.


1
Bundan birkaç gün sonra planlandığını anlıyorum, ancak yayınlandıktan sonra, bu bağlantıların herhangi bir şekilde ölmesi durumunda, kod tabanlarını modernize etmek için aldıkları sürecin bir özetini ekleyebilir misiniz?
Rachel

@Rachel - Yayını yakalayabilirsem, kesinlikle yaparım. Teşekkürler.
Josh Kelley

4

Aslında kariyerimde üç kez oldukça önemli bir yeniden düzenleme yaptım. Kodun çürümeye eğilimi vardır, bu nedenle kod tabanınız yeterince uzunsa, büyük bir refactor hemen hemen kaçınılmazdır. Tüm örneklerim özel kod tabanlarındaydı, bu da genel örneklerin neden bulunmasının zor olduğunu açıklayabilir.

İlk kez, ister inanın ister inanmayın, sadece nokta vuruşlu yazıcılarla çalışmasını sağlayan temel bir mimariye sahip bir uygulamadır. Şirketim artık şerit tedarik edecek bir satıcı bulamadığında, bir lazer yazıcıyla çalışmasını sağlamak için beni görevlendirdiler.

İkinci kez, kısmen daha iyi platformlar arası kabiliyete ihtiyaç duyduğumuz ve kısmen yeni C geliştiricileri işe almanın zorlaştığı için C'den Java'ya yüzlerce otomatik test komut dosyasının taşınmasıydı.

Üçüncü kez hala ortasındayım, bu, kuplajı azaltarak ve çapraz platform amaçları için birim testine izin vermek için büyük bir monolitik uygulamayı modüle ediyor.

Bir dağa tırmanma çabasını karşılaştırıyorum. Önünüzde bu büyük hedef var, ancak makro düzeyde bununla başa çıkmıyorsunuz. Bir seferde bir tutamak alırsınız, her zaman yakın bir geri dönüş konumuna sahip olursunuz, bir sonraki güvenlik yerine kadar önceki güvenlik bağlantısını asla kesmezsiniz. Sadece küçük artımlı iyileştirmeler yapmaya başlıyorsunuz ve bir süre sonra geri dönüyorsunuz ve aniden bu güzel manzara var.

Diyelim ki 60.000 yüksek kodlu dosyanız var. Ünite testine girmeye başlamak istiyorsunuz, ancak bağımlılıklar bunu imkansız hale getiriyor. Nasıl tamir edersin? Bir dosyayı ayırırsınız . Otomatik testler eklersiniz. Devam etmeden önce sağlam zemine dönersiniz. 59.999 kez tekrarlayın.

O sesler basit olursa, yıllardan bu çünkü olduğu basit. Kolay değil, ama basit. İlk başta herhangi bir gelişme olduğunu görmek zor. İmkansız bir refactor gibi görünen iki yıltayız ve bitene kadar büyük olasılıkla önümüzde yıllar var, ancak geriye dönüp baktığımızda aniden kodun ne kadar daha iyi hale geldiğini anlıyoruz ve yeni işlevler sunmaya devam edebildik bu arada müşterilerimize.

Diğer iki kez aynı şekilde çalıştı. Uygulamayı her zaman çalışır durumda tutarak, atabileceğiniz en küçük güvenli adımı bulursunuz ve uygularsınız. Sadece doğru yönde ilerlediğinizden emin olmak için büyük resimden endişe ediyorsunuz. Tüm eylemleriniz küçük, istikrarlı ve artımlıdır.


1

Milyonlarca satır kod tabanı üzerinde çalışan kişisel deneyimimden işe yarayan birkaç strateji buldum.

Tüm hatalara (kapalı olanlara bile) bakın ve bunları kategorilere ayırmaya çalışın. Özellikle ait oldukları bileşen tarafından parçalara ayırmak için. Birden fazla bileşene aitlerse yaptıklarına dikkat edin. Bunu yaptıktan sonra hangi kovanın en büyük olduğuna bakın ve nereden başlayacağınızı belirlemek için bunu kullanın. Ayrıca, en çok neyin değiştiğini belirlemek için dosyaların düzeltme geçmişine bakabilir ve bunu nereden başlayacağınıza dair bir rehber olarak kullanabilirsiniz. Temelde yapmaya çalıştığınız şey en kırık olanı bulmak ve tekrarlamaktır. Buna ek olarak, her şeyi aynı anda düzeltmeye çalışmanın daha fazla soruna neden olduğunu buldum.

"Sistem" sorunlarının bir göstergesi olan ve çok sıkı bir şekilde bağlanmış koda veya yenilenmesi gereken bir API'ye işaret edebilecek birden fazla bileşene ait birçok şey bulursanız.

Ben çok zaman geçirdim başka bir alan mevcut kod tabanı test ediyor. Burada birden fazla strateji var ve hepsinin değeri var ama hiç kimse soruna tam bir çözüm değil.

  • Ünite testi işe yarayabilir, ancak sık sık birleştirilmiş kod nedeniyle ünitenin test edilebileceği zamanlar sınırlıdır. Ancak bunu yapabildiğiniz yerde yapın.
  • Dış testler başka bir yol. Muhtemelen buna zaten sahip olduğunuzu varsayıyorum ve eğer değilse, onu oluşturmak için biraz zaman harcayacağım. Ek olarak, benim için işe yarayan bir şey, sisteme rasgele hata / olay enjekte etme yeteneğini eklemektir. Buna ek olarak, aynı anda birden fazla şey enjekte etmeye çalışın ve yeni yollarla başarısız hale getirmeye çalışın.
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.