BÜYÜK bir Yeniden Yazıma hiç katıldınız mı? [kapalı]

Joel Spolsky ünlü görevlerinden birinde şöyle dedi:

Herhangi bir yazılım şirketinin yapabileceği en büyük stratejik hata: kodu sıfırdan yeniden yazın.

Chad Fowler yazdı:

Videoları, web günlüğü gönderilerini ve yutturmacalarını gördünüz ve ürününüzü Rails'te (veya Java veya .NET veya Erlang, vb.) Yeniden uygulamaya karar verdiniz.

Dikkat. Bu, beklediğinizden daha uzun, daha sert, hataya açık bir yoldur.

BÜYÜK bir Yeniden Yazıma hiç katıldınız mı?
Bu trajik konu hakkındaki deneyiminizle ve özellikle (varsa) başarılı bir şekilde tamamlanan herhangi bir büyük yeniden yazma ile ilgileniyorum.

Kariyerim hakkında birkaç yazı yazdım ve hepsi felaketti. Bence hepsi aynı sebeplerden dolayı başarısız

• Çok az çaba gösterilmesi gerekiyor: Birisi yeniden yazmak istediğinde, eski sistemin eski teknolojiyi kullanması ve bakımı zor olması nedeniyle. Göz önünde bulundurmadıkları şey, yaşlarından dolayı, bunun içinde 30-40 adam yıllık bir geliştirme çabası olabileceğidir. Daha sonra 6 ay içinde her şeyi yeniden yazabileceğinizi düşünmek 5 kişilik bir ekiple saçma.
• Kayıp bilgi: Eski sistem çok uzun süredir var, çok şey yapıyor ve her şeye bağlı. Güncel bir dokümantasyon yoktur ve sistemin yaptığı her şeyi bilen tek bir otorite yoktur. Belirli departmanlardaki belirli kullanıcılarla bilgi parçaları olacak ve hepsini bulmak zor ya da imkansız.
• Kötü Yönetim Kararları: İçinde bulunduğum yeniden yazımların yönetimden benzer beklentileri vardı: Yeni sistem 'yapılmalı' ve eski sistem belli bir tarihte basitçe kapatılabilirdi. Başka hiçbir seçenek kabul edilebilir değildi. Sanırım bunu kafasına soktular, çünkü bu kadar parayı bu dev proje için yeni insanlara kiralamak için harcıyorlar. Gerçekte, daha iyi bir risk azaltma stratejisi, eski sistemin ana işlevlerini yeniden yazmak, eski sistemin% 50-75'inin ilk sürüm için üstesinden gelmek olduğunu ve bunun nasıl çalıştığını görmektir! Yukarıdaki 1 ve 2 numaralı maddeler nedeniyle, kaçırılan özelliklerden bazılarını ve eski sistemi kapatmak için neyin gerekli olduğunu öğrendiğimiz için bu muhtemelen daha iyi sonuç verecektir.

Doğru şekilde kapsamlarsanız, yeniden yazma çok başarılı olabilir . Bunların "BÜYÜK" (TM) projeleri eşiğinizle uyuşup uyuşmadığını bilmiyorum, ancak size daha başarılı birkaç yeniden yazmamı anlatayım.

1. Proje

Çalıştığım firma perakende raflarında gördüğünüz etiketleri planogram denilen bir şeyden üretmek için kullanılan bir raf şeridi baskı sistemine sahipti . Planogram endüstri standardı yazılımda üretildi ve araçlarımız bu belgeyi, hedef mağaza için bir şablon kullanarak raf şeritleri oluşturmak için okudu. Şablonlama yazılımı, çeşitli sınıflar ve 3 DLL içeren iç içe geçmiş sonlu durum makineleriyle ilgili bir karışıklıktı. Peg panoları yapmak için (o zaman) patent bekleyen yaklaşımı uygulama zamanı geldiğinde, mevcut kodun ne yapmak istediğimizi destekleyemediği açıktı.

Çözüm: Yeniden yazma işlemini sadece şablon motorunun kapsamına aldık. Mevcut gereklilikleri yerine getirmek için uygun OO tasarımını kullandık, aynı zamanda yeni sabitleme tahtası gereksinimlerini de karşıladık. Yeniden yazma zamanı 1 aydı. Alet zincirinin tamamını yeniden yazılmış bir şekilde yapsaydık, bir yıl boyunca iyi sonuç alacaktı - ama buna ihtiyacımız yoktu.

Proje 2

Ekibimizin sıfırdan oluşturduğu bir web uygulaması özgün tasarımını geliştirmeye başlamıştı. Müşterimiz ayrıca siteyi kullanıcılarımız için daha iyi hale getirecek yeni bir gereksinimlere sahipti. Mevcut tasarımımızı şu an sahip olduğumuz çerçevede ayakkabı boynuzlu tutabilmekle birlikte, bakım bir kabustu. Uygulamayı çok yakından biliyorduk ve hangi bölümleri öne çıkarmamız gerektiğini ve hangi bölümlerin yeni sürümün bir parçası olarak gittiğini biliyorduk.

Çözüm: Ekibimizin tamamlanması 3 ay sürdü - önemsiz değildi. Son ürün daha hızlı, daha ölçeklenebilir ve son kullanıcılar için daha zevkliydi. Müşterilerimizin beklentilerini aştık. Bununla birlikte, ekibimizi ikiye bölmek zorunda kaldık, böylelikle daha acil hata düzeltmeleri ve yara bandı yamaları mevcut sistemde yapılırken, diğer yarısı yeni sistemde çalışacaktı. Kapsamlı testler yaptık ve sürecin başlarına dahil ettik. Bunun bu kadar iyi sonuçlanmamasının nedeni, bu uygulamayı ve müşterimizi yakından tanıdığımızdır.

Proje 3

Buraya bir başarısızlık eklemek zorundayım. Afet / kriz durumlarında kullanmak için bir bilgi yönetimi aracına ihtiyaç duyan bir müşteriyi destekliyorduk. Orijinal geliştiricilerin gerçekten Swing'i anlamadan yazdıkları bir Java Swing uygulamasını devraldık. Bununla birlikte, Sun'ın Swing'le başa çıkma ve kullanıcı arayüzünü düzgün bir şekilde yönetme konusundaki önerilerini takip etmediklerini, sonuç olarak sonsuz olay döngülerine ve diğer tuhaf ve izlenmesi zor olan konulara gireceğinizi söylüyorum. Sonuç olarak, hatalar, kullanıcı arayüzü sorunları vb. İle doluydu. Bu çok karmaşık bir uygulama oldu. Akıl sağlığımızı korumak için, zayıf yazılmış Swing uygulamasını iyi yazılmış bir Swing uygulamasına yeniden yazmaya çalıştık.

Çözüm: Yeniden yazımı yaklaşık 3 ayda tamamladığımızda yaklaşık 4,5 ayda tamamladık. Uygulama, kullanıcı arayüzünde ve ne kadar veri işleyebileceği konusunda daha iyi performans gösterdi. Sonra 2004 yılında tsunami oldu. İzlemeleri gereken insan sayısının büyüklüğü, Swing'in gerçekten ihtiyaç duydukları şey için yanlış teknoloji olduğunu gösterdi . Performans ayarlamalarımıza ayak uyduramadık ve sonunda aracı, sahip oldukları Oracle ekibi tarafından oluşturulan bir araya getirilmiş bir web uygulaması lehine bıraktılar. Tabii biz biz zaman vardı bilgiye dayalı vermedi şeyi haklı olabilir, ama yeniden yazma yeterince agresif değildi ve biz durumda olanların sayısı için onların gereksinimleri olduğunu müşterimizi anlatmak için başarısız muhtemelen gerek de vardı izlenecek düşük.

Sonuç

Yeniden yazmak bazen gerekli olabilir ve doğru planlıyorsanız başarıyla tamamlanabilir. Bir sistemin bölümleri için hedeflenen yeniden yazma işlemiyle, tümüyle yeniden yazılmış yeniden yazma işlemlerinden daha fazlasını alabilirsiniz. Son olarak, bir projenin başarısız olmasına neden olan mutlaka kendini yeniden yazmak değildir. Asla bekar olamamaya rağmen, en kötü durum senaryolarını bulabiliriz. Sistemlerimi, aklıma gelen en kötü senaryoyu iki kez destekleyecek şekilde tasarlamayı öğrendim. Kriz yönetim sistemi için bu yeterli değildi - gerçek rakamlar bize verdiğimiz en kötü senaryodan 20 kat daha fazlaydı. Ancak bu, aklımıza gelen en kötü senaryo değildi.

• Yeniden yazmak uğruna yeniden yazmak senin arkadaşın değil. Görmediğiniz her zaman çok fazla karmaşıklık vardır ve gördüğünüz çirkin şeylerin müşteriniz için eğitim araçları olduğunu görürsünüz. Mevcut ilerlemenizi her zaman düzenli aralıklarla müşterinize gösterin, böylece en kötü suçları yakalamanıza yardımcı olabilirler.
• Hedeflenen yeniden yazma, kod üssünüzdeki en kötü suçlarla başa çıkmak için kullanışlıdır. Kapsamı sınırlayabilir ve sorunlarınızın çoğuna hitap edebilecekseniz, yeniden yazma işlemini tamamlamayın.

VB6'dan .NET'e kadar birçok yeniden yazma işindeyim. 2 vakada yeniden yazma sorunsuz geçti ve programın gerisinde kaldık. Diğer yeniden yazma beklenenden daha uzun sürdü, ancak büyük sorunlar olmadan tamamlandı.

Bizim özel durumumuzda yeniden yazma şirketimizin alabileceği en kötü karar değildi. Nihai sonuçlar aslında orijinallerden çok daha istikrarlıydı ve bizi daha iyi bir yere koydu.

Mevcut bir sistemi yeniden yazarken en büyük tuzaklardan biri "Yeni sistemin ne yapması gerektiğini belirtmemize gerek yok - çok basit, sadece eski sistemin ne yaptığını yapması gerekiyor!" .

Sorun şu ki, hiç kimse eski sistemin ne yaptığını tam olarak bilmiyor ve eski sistemdeki farklı kullanıcıların çalışması gerektiğini düşündüğü şekilde yeni sisteminizin çalışmasını sağlamak için sayısız zaman harcayacaksınız. Eski sistemin orijinal gereksinimleri de büyük olasılıkla mevcut değil.

Benimki bir "başarı" hikayesidir. Projem bağımsız olarak yönetilen / yazılan 4 uydu siteli (üzerinde farklı uygulamalar bulunan alt alanlar) olan bir birincil siteyi içeriyordu. 4 ayrı kullanıcı tabanımız vardı (hepsi ayrı ayrı aktif dizinlerde) ve hiçbirinde ortak bir doğrulama sistemi yoktu. Üçü tanınmış ve silo'd uygulamalardı ve dördüncü uydu yepyeni idi ve kod üssünün çoğunu en köklü sitemizden kopyaladı.

Hedef: 4 etki alanındaki hesapların kimliğini doğrulayabilecek ve etki alanlarının 1'indeki hesapları (self-servis ile) tam olarak yönetebilecek kurumsal bir kimlik sistemi uygulamak. Net, uydulara zaten uygulandığı için, "giriş" olarak hizmet veren klasik asp sitesinin yeniden yazılması, kimlik yönetiminin eklenmesi ve tüm sitelerin hiçbir hizmetin etkilenmemesini sağlamak için regresyon testine ihtiyaç duyulması gerekirdi.

Kaynaklar: 3 ana mimar - programcı, kimlik yönetimi, proje yöneticisi. Yaklaşık 20 geliştirici, 10 analist, 10 testçi.

Tamamlanma süresi (bitmeye başlama): 1.5 yıl

Başlatma Başarısı: Yakın Arıza

Uzun Ömür Başarı: Müthiş

Kimlik yönetimi mimarıydım, bu yüzden tüm uyduların etkileşime gireceği veritabanları, alt sistemleri ve mantıksal arayüzleri tasarladım. “Programcı” mimarı, tüm uydular hakkında geniş bir iş bilgisine ve uygulamalarla ve bu noktadaki gelişmelerle ilgili deneyimine sahip lider bir geliştiriciydi.

Şirketimizdeki çeşitli bölümlerden 50 ya da daha fazla farklı kişiyle toplanan birkaç ay süren gereksinimden sonra, mantıksal mimariyi ütülenip kodlamaya başladık. Değişimin doğası gereği, kendi web sitemizi ve içerdiği tüm işlevselliği yeniden yazmak zorunda kaldık. Bazı durumlarda bu sadece yeniden yapılanma meselesiydi. Çoğu durumda, onu çevreleyen işlemlerin tam bir tekrarı ile ilgiliydi. 2 vakada orjinal özelliği sadece önemsiz olarak bıraktık. Bu süreçte 2 son tarihi kaçırdık (ancak önerdiğim orijinal son tarihi - ancak zorlukla). Fırlatma gününde hiçbir şey işe yaramadı. Bir Cumartesi günü başlattık, böylece etki oldukça azdı, ancak bütün günümü günlükleri taramak, parçaları yeniden yazmak ve sunucu yüklerini değerlendirmek için harcadım. Daha fazla test yardımcı olabilir.

İlk günün sonunda, tüm siteler çalışıyor ve çalışıyordu ve her şey çalışıyordu (nominal bir başarı olduğunu söyleyebilirim). Son 2,5 yıl boyunca her şey müthiş bir başarı oldu. Tüm sitelerimizi ortak bir yapı tabanı ile ortak bir mimaride kullanmak geliştirme ve çapraz-geliştirici işlerini çok daha kolaylaştırdı. Sitemize 2.5 yıl önce yazdığım (yeniden yazmamız sırasında) o zamandan beri birkaç uydu siloları tarafından görülmüş / kabul edilmiştir.

Günlük kaydı, kullanıcı takibi, çalışma süresinin artması, kimlik doğrulama / yetkilendirme / tanımlamadan sorumlu tekil bir uygulama geliştirdik. Uydu siloları tamamen uygulamalarına odaklanabilir ve kimlik yönetimi uygulamasında herhangi bir kimlik doğrulama / yetkilendirme sorununun mevcut olduğuna güvenebilir.

Projemiz bir sürü hayal kırıklığı, gönül yarası ve felaketti. Sonunda ödedi ve sonra bazı. Joel Spolsky'nin yeniden yazma değerlendirmesini genel bir kural olarak değerlendirmesine% 100 katılıyorum, ancak her zaman istisnalar da var. Yeniden yazmak istiyorsan, ihtiyacın olan şeyin kesinlikle olduğundan emin olman gerekir. Eğer öyleyse, o zaman onunla birlikte gelen tüm ağrılar için hazır olun.

Şimdi büyük bir kod yazımı ile uğraşıyorum ... tek sorun, üzerinde çalışan tek kişi benim! Mevcut yazılımımızın bakım maliyetleri çok çirkin, çok fazla hata var ve kendimizi oluşturmaya karar verdiğimiz için 1 FT çalışanımız var.

Çok daha yavaş, sonra olmasını bekledim ama sonuçta çok daha iyi olacağını düşünüyorum çünkü gelecekte kendi kod tabanımız olacak, böylece gelecekte istedikleri herhangi bir değişiklik kolayca uygulanabilir (yazılımın sürekli uyum sağlaması gerekir şimdiki zamanlar). Ayrıca, yeniden yazarken tasarımda bazı önemli değişiklikler yapıyoruz.

Önceki işimde tam bir yeniden yazıma katıldım. Ve bunu yaptığımız için çok mutluyuz. Diyelim ki bazen kod temeli o kadar çürümüş ki, yeniden başlamak daha iyi.

Aslında bir iç uygulama oldu - asıl iş uygulaması.

2. sürümü yazdığımız gibi eski sistemi koruduk. Doğru hatırlıyorsam, yaklaşık bir yıl sürdü (iki programcı, sonra üçüncüsü). Yine de veritabanına dokunmamız gerekmedi, bu yüzden en azından veri taşıması bir sorun değildi.

Her şey değişir. Benim durumumda Joel Spolsky'nin tavsiyesine uydum ve yanılmışım . Bir Sigorta Web sitesi ile ilgiliydi. Site korkunçtu ve işte ne yaptım, sonra ne yapmalıydım:

Kötü strateji: 4 öğrenci grubunu denetledim:

• Öğrenci # 1 - güvenli olmalarını sağlamak için veritabanı erişimini / sorgularını yeniden yazdı
• Öğrenci 2 - tüm css'leri "yukarı" olarak taşıdı
• Öğrenci # 3 - tüm sayfaları w3c ile uyumlu hale getirdi
• Öğrenci # 4 - bekleyen tüm hataları çözdü
• Kendim: Tüm php uyarıları ve berbat şeyler kaldırıldı (yinelenen kod vb.)

2 ay sürdü. Sonra siteyi yeniden tasarladık. Sonra çok dilli yaptık. Sonuçta biz berbat kodun büyük bölümünü tutmak zorunda kaldı ve veritabanı yapısı aynı kaldı. Bu yüzden hala bir senedir berbat şeyler üzerinde çalışıyorum ve tam bir yeniden yazma kararı verilinceye kadar asla bitmeyeceğiz, ki bu asla gerçekleşmeyecek.

İyi strateji:

• Tüm siteyi inceleyin, iyi bir "Ürün gereksinimleri belgesi" oluşturun.
• Veritabanını uygun şekilde yeniden tasarlayın
• Sıfırdan kendi çerçevemle başla (ki zaten çalışıyor)
• Siteyi yeniden tasarladım.
• Çok dilli yap.

Süreceği zaman: iki ay ( belki daha az ).

• İyi kod
• İyi bakım.
• Üretkenlik.
• "Bunu yapamayız, Web sitesi bu ürünleri kaldıramaz" gibi bir cevap yok.

Öyleyse, son sözlerim: hepsi yeniden yazmak zorunda olduğunuz şeylerin karmaşıklığına bağlı .

Gönderiyi İngilizce yapmak için düzeltmek için tereddüt etmeyin lütfen, çok teşekkür ederim

Olivier Pons

Çalıştığım bir şirket kod temeli konusunda büyük bir refactör başlattı.

Takımın yarısı refactor üzerinde çalışmaya ayarlandı ve diğer yarısı mevcut ürünü korumaya ve iyileştirmeye devam etti.

Tahmin edebileceğiniz gibi, refactor hiçbir zaman hiçbir şeyin işe yaramadığı bir noktaya gelmedi - bu sadece sürekli olarak devam eden bir süreçti; ancak kendisi için gösterecek hiçbir şeyi yoktu.

Buradaki fikir, yeniden yapılandırılmış kod tabanının birlikte çalışmasının daha iyi olacağı ve ekibin mevcut ürüne yaptıktan sonra eklediği yeni özelliklerden sadece "düşebileceğimizi" ve "yetişebileceğimizi" düşünmemizdi.

Ancak şirketin çöküşü oldu.

Son 3 yıldır büyük bir yazı yazıyordum. Orijinal projenin 2 yıl süreceğini tahmin ettik. Temel fikir, donanımı değiştirmek, mevcut bir işletim sistemi kullanmak, iş mantığını yeniden yazmak (c'den CPP'ye), yeni bir IO kartı oluşturmak ve yeni bir kullanıcı arayüzü yazmaktı.

Yol boyunca bazı korkunç kararlar aldık. CPP'de gerçek bir tecrübeye sahip değiliz ve bunu iyi öğretecek bir akıl hocamız yoktu. Win32 tabanlı bir UI çerçevesi oluşturmaya çalıştık. Donanım ucuzdu ve BSP hatalarla kusurlu. Yazılım süper esnek ancak bakımı zordu. Geçen yıl evde yetiştirilen UI'yi attık ve .net'te bir UI geliştirdik. Kalıcılık mekanizmamızı ve veri iletişim protokolümüzü de tamamen yeniden yazdık.

Çok fazla çaba harcadı, ancak şimdi proje neredeyse bitti ve ilk birimler sahada test edildi. Proje, başarılı olma konusunda herhangi bir değişikliğe uğrama riskini aldı. Proje ile ilgili bazı olumlu şeyler vardı, SVN kullanmaya başladık (VSS yerine), birim testleri yazmak için zaman harcadık ve bir gece oluşturma uyguladık. Daha iyi bir süreç için scrum kullanmaya da başladık.

Geçmişe bakıldığında, iş mantığının yeniden yazılmasının gerekli olmadığını düşünüyorum, sadece en çirkin parçaları yeniden ele almalıydık. Ve sıfırdan bir kullanıcı arayüzü yazmak için sizin temel işiniz olmadığı sürece yapmayın.

Aslında büyük bir yeniden düzenlemeye başlıyorum. 4MLocs muhtemelen 800KLocs ya da daha azına inmektedir. Bu projede çok sayıda Kopyala ve Yapıştır, yanlış anlama dili özellikleri, çok sayıda ve tekrarlayan işe yaramaz yorumlar, kötü kararlar, geçici hack ve daha fazla hack kalıcı (geçici çözümler dahil), Bilgisayar Bilimi veya Yazılım Mühendisliği ile ilgili temel ilkeler konusunda tam bilgi sahibi değil . Muhtemelen 32 kötü programcının bakım ekibinin yerine, refactoring işleminden sonra 2 iyi takım yerleştirilecektir.

3 hafta içinde bir blog motoru yazdım. 8 saat içinde yeniden yazdım.

Önceden planlama yapmak, başarılı bir yeniden yazmak için anahtardır . Sistemin içinde ve dışında olduğunu bilmek de bir avantajdır.

On yıldan biraz daha uzun bir süre önce, yaşlanan çekirdek ürünlerinin "yeniden tasarlanmasına" karar veren bir şirkette çalıştım. O zamandan beri, "yeniden tasarlama" kelimesini kullanmak cezalandırılabilir bir suçtur. Beklenenden çok daha uzun sürdü, belli ki daha pahalıya mal oldu ve yeni ürün eski ürüne başlangıçta planlandığından çok daha benzerdi.