BÜYÜK cevap ne zaman yeniden yazılır?

Sadece Büyük Yazılar hakkındaki soruyu okudum ve kendime cevap vermek istediğim bir soruyu hatırladım.

Eski Java ile yazılmış, Struts 1.0, tutarsız ilişkileri olan tablolar veya hiç bir ilişki yok, hatta birincil anahtar veya alanları olmayan, ancak birincil anahtar olması gereken tabloları olmayan benzersiz bir projem var. Her nasılsa uygulamanın çoğu "sadece çalışıyor". Sayfaların çoğu yeniden kullanılır (yapıştırılan kodu kopyala) ve kodlanmış. Projede daha önce çalışmış olan herkes bir şekilde ya da diğerinde lanetledi.

Şimdi uzun zamandır bu korkunç uygulamanın tamamen yeniden yazılmasını üst yönetime önermeyi düşünmüştüm. Yavaş yavaş kişisel zamanımı deniyorum ama bunun gerçekleşmesi için bazı özel kaynakları hak ettiğini gerçekten hissediyorum. Büyük yeniden yazma hakkındaki yazıları okuduktan sonra ikinci düşüncelerim var. Üstelik üstlerimi tekrar yazmaya destek olmaya ikna etmek istediğimde bu iyi değil. (Teklifin onaylanma olanağına sahip olması için oldukça küçük bir şirkette çalışıyorum)

TL; DR Cevabı ne zaman büyük bir cevap yazar ve bunu desteklemek için hangi argümanları kullanabilirsiniz?

Üzgünüz, bu uzun sürecek, ancak çoklu yeniden yazma projelerinde hem mimar hem de geliştirici olarak kişisel deneyime dayanıyor.

Aşağıdaki koşullar bir tür yeniden yazma düşünmenize neden olacaktır. Bundan sonra hangisinin yapılacağına nasıl karar verileceği hakkında konuşacağım.

• Geliştirici rampa süresi çok yüksektir. Yeni bir geliştiriciyi hızlandırmak (deneyim seviyesine göre) aşağıdan daha uzun sürerse, sistemin yeniden tasarlanması gerekir. Hızlanma süresine gelince, yeni geliştiricinin ilk taahhüdünü yapmaya hazır hale gelmesi için geçen süreyi kastediyorum (küçük bir özellikte)
  • Üniversiteden yeni çıkmış - 1.5 ay
  • Hala yeşil, ancak daha önce diğer projeler üzerinde çalıştım - 1 ay
  • Orta seviye - 2 hafta
  • Deneyimli - 1 hafta
  • Kıdemli seviye - 1 gün
• Var olan mimarinin karmaşıklığı nedeniyle dağıtım otomatikleştirilemez
• Var olan kodun karmaşıklığı nedeniyle basit hata düzeltmeleri bile çok uzun sürüyor
• Yeni özellikler çok uzun sürüyor ve kod tabanının birbirine bağımlılığı nedeniyle çok pahalı (yeni özellikler izole edilemiyor ve bu nedenle mevcut özellikleri etkiliyor)
• Resmi test döngüsü, mevcut kod tabanının birbirine bağımlılığı nedeniyle çok uzun sürüyor.
• Çok az ekran üzerinde çok fazla kullanım durumu yürütüldü. Bu, kullanıcılar ve geliştiriciler için eğitim sorunlarına neden olur.
• Mevcut sistemin talep ettiği teknoloji
  • Teknolojide tecrübesi olan kaliteli geliştiricileri bulmak çok zor
  • Kullanımdan kaldırıldı (Daha yeni platformları / özellikleri desteklemek için yükseltilemez)
  • Çok daha etkileyici bir üst düzey teknoloji mevcut.
  • Eski teknolojinin altyapısını koruma maliyeti çok yüksek

Bu şeyler oldukça açıktır. Tam bir yeniden yazmaya karşı ne zaman karar verileceğine karar verilirken, artan bir yeniden oluşturma işlemi daha özneldir ve bu nedenle politik olarak daha fazla ücret uygulanır. İnanç ile söyleyebileceğim şey, kategorik olarak asla iyi bir fikrin olmadığını söylemektir.

Eğer bir sistem kademeli olarak yeniden tasarlanabilirse ve böyle bir şey için proje sponsorluğunun desteğini alıyorsanız, bunu yapmalısınız. İşte sorun, yine de. Birçok sistem artan şekilde yeniden tasarlanamaz. İşte bunu engelleyen nedenlerden bazıları (hem teknik hem de politik).

• Teknik
  • Bileşenlerin bağlanması o kadar yüksektir ki, tek bir bileşene yapılan değişiklikler diğer bileşenlerden izole edilemez. Tek bir bileşenin yeniden tasarlanması, yalnızca bitişik bileşenlerde değil, tüm bileşenlerde dolaylı olarak bir değişiklik dizisine neden olur.
  • Teknoloji yığını o kadar karmaşık ki, gelecekteki devlet tasarımı birden fazla altyapı değişikliği gerektiriyor. Bu, tam bir yeniden yazmada da gerekli olacaktır, ancak artan bir yeniden tasarımda gerekliyse, bu avantajı kaybedersiniz.
  • Bir bileşeni yeniden tasarlamak, yine de o bileşenin yeniden yazılmasına neden olur, çünkü mevcut tasarım o kadar basittir ki, kurtarılmaya değer bir şey yoktur. Yine, bu durumda avantajı kaybedersiniz.
• siyasi
  • Sponsorlar, artımlı bir yeniden tasarımın projeye uzun vadeli bir taahhüt vermesi gerektiğini anlamak için yapılamaz. Kaçınılmaz olarak, çoğu kuruluş, artımlı bir yeniden tasarımın yarattığı süregelen bütçe tahliyesi için iştahını kaybetti. Bu iştah kaybı, yeniden yazma için de kaçınılmazdır, ancak sponsorlar, kısmen yeni bir sistem ve kısmen eski bir eski sistem arasında bölünmek istemedikleri için, devam etmeye daha yatkın olacaktır.
  • Sistemin kullanıcıları da “mevcut ekranlara” eklenmişlerdir. Bu durumda, sistemin hayati bir kısmını (ön uç) geliştirme lisansına sahip olmayacaksınız. Yeniden tasarım, bu sorunu aşmanıza olanak tanır, çünkü yeni bir şeyle başlıyorlar. Yine de "aynı ekranları" almakta ısrar edecekler, ancak geri itmek için biraz daha cephaneniz var.

Artımlı olarak yeniden toplam maliyetinin her zaman tam bir yeniden yazma yapmaktan her zaman daha yüksek olduğunu, ancak kuruluş üzerindeki etkisinin genellikle daha küçük olduğunu unutmayın. Bence, bir yeniden yazımı haklı çıkarabilirseniz ve süperstar geliştiricilere sahipseniz, o zaman yapın.

Ancak bunu, tamamlanıncaya kadar görecek siyasi irade olduğundan emin olabilirseniz yapın. Bu hem yönetici hem de son kullanıcı katılımcısı anlamına gelir. O olmadan başarısız olursun. Sanırım bu yüzden Joel bunun kötü bir fikir olduğunu söylüyor. Yönetici ve son kullanıcı katılımları, birçok mimarın iki kafalı tek boynuzlu atlarına benziyor. Agresif bir şekilde satmanız ve tamamlanana kadar devamlılığı için kampanya yapmanız gerekiyor. Bu zor ve bazılarının başarılı görmek istemeyeceği bir şeyle ilgili itibarınızı vurgulamaktan bahsediyorsunuz.

Başarı için bazı stratejiler:

• Ancak, mevcut kodu dönüştürmeyi denemeyin. Sistemi sıfırdan tasarlayın. Aksi halde zamanını boşa harcıyorsun. Sefil bir şekilde bitmeyen bir "dönüşüm" projesini hiç görmedim veya duymadım.
• Kullanıcıları her seferinde bir takıma yeni sisteme taşıyın. EN ÇOK acı çeken ekipleri mevcut sistemle tanımlayın ve önce onları geçirin. İyi haberi ağzından söyleyerek yaymalarına izin verin. Bu şekilde yeni sisteminiz içerden satılacak.
• Çerçevenizi istediğiniz gibi tasarlayın. Asla gerçek kod görmemiş olan bu çerçeveyi, harcadığım 6 ay boyunca inşa etmeye başlamayın.
• Teknoloji yığınınızı olabildiğince küçük tutun. Fazla tasarım yapma. Gerektiği gibi teknolojileri ekleyebilirsiniz, ancak bunları çıkarmak zordur. Ek olarak, ne kadar çok katmana sahipseniz, geliştiricilerin bir şeyler yapması o kadar fazla iş yapar. Baştan itibaren zorlaştırmayın.
• Kullanıcıları doğrudan tasarım sürecine dahil edin, ancak nasıl yapacaklarını dikte etmelerine izin vermeyin . İyi tasarım ilkelerini izlerseniz onlara daha iyi ne istediklerini verebileceğinizi göstererek güvenlerini kazanın.

İki büyük yeniden yazıma katıldım. İlk olarak küçük bir projeydi. İkincisi, bir yazılım şirketinin ana ürünüydü.

Birkaç tuzaklar var:

• yeniden yazmak her zaman beklenenden daha uzun sürüyor.
• Yeniden yazarların müşteriye doğrudan bir etkisi / avantajı yoktur.
• yeniden yazma için ayrılan kapasite müşteriyi desteklemek için kullanılmaz.
• % 100 dokümantasyonunuz olmadığı sürece yeniden yazma fonksiyonunu kaybedersiniz.

Yeniden yazmak nadiren gerçek cevaptır. Herhangi bir şey kaybetmeden ve çok risk almadan kodun çoğunu yeniden düzenleyebilirsiniz.

Yeniden cevap yazarsa cevap olabilir:

• başka bir dile veya platforma geçiyorsunuz.
• çerçeveleri / harici bileşenleri değiştiriyorsunuz.
• varolan kod temeli artık sürdürülemez.

Ancak refactoring kullanarak yavaş yaklaşımı şiddetle tavsiye ediyorum. Daha az riskli ve müşterilerinizi mutlu ediyorsunuz.

Ne zaman yeniden yazma zamanı geldi:

Uygulamanın yeniden yazılmasının maliyeti + yeniden yazılan uygulamanın sürdürülmesi, mevcut sistemin zaman içinde sürdürülmesinin maliyetinden daha azdır.

Mevcut olanı daha pahalı kılan bazı faktörler:

• Dil o kadar eski ki, programlamak için çok para tanıyan insanlara ödemek zorundasınız (COBOL).
• (maalesef tecrübeden, maalesef) Sistem, üzerinde çalıştığı makineye eklemek için Ebay ve COLLECT parçalarını taramak zorunda kaldıkları o kadar eski bir donanım mimarisi üzerine kuruludur; Buna "donanım ömrü desteği" adı verilir ve pahalıdır, çünkü parçalar daha az olduğu için fiyat artışına neden olabilir veya (kesinlikle) zamanla tükenir.
• O kadar karmaşık hale geldi ki, //Here be dragons.yorum kodunuzda.
• Bu çirkin canavarı her zaman yamaladığınız için başka projeler yazamaz ve şirkete yeni değer katamazsınız.

Eğer projenin mimarisinde temel bir değişiklik gerektiriyorsa, öyle muhtemelen yeni bir başlangıç zamanı.

Bununla birlikte, yeni projenizde tekrar kullanılmaya değer büyük miktarda kod potansiyeli olacaktır.

Yine de adil bir uyarı al. Mevcut bir projenin, iş kurallarını test edilmiş ve sayısız insanın saatlerce süren fiili kullanımında iyileştirilmiş olması gerekirdi;

Bir zaman dilimi veya bağırsak duygusunun böyle sert bir önlemin uygun bir ölçüsü olduğundan şüpheliyim. Bu eylem sürecinde yer almak için açık , savunulabilir ve iyi anlaşılmış nedenleriniz olmalıdır.

Kramii'nin cevabı ve Joel'in görüşü ile aynı fikirde olmama rağmen, yeniden yazma yapmanın uygun olduğu zamanlar vardır. Uzun ömürlü uygulamalarda (10-20 yıl veya daha fazla konuşuyorum), bakım zamanla giderek daha pahalı hale geliyor. Bunun nedeni, orijinal mimari hızlı bakım yamaları için feda edildiğinden, kodun giderek daha fazla spagetti-hale gelmesidir. Ayrıca, eski teknolojiler için geliştiriciler daha nadir ve daha pahalı hale gelir. Son olarak, donanım yaşlanmaya başlar ve eski uygulamayı üzerine çalıştırmak için yeni donanım, işletim sistemleri, çerçeveler vb. Bulmak zorlaşır ve zorlaşır. Ayrıca, işletmeler gelişir ve büyük olasılıkla eski bir sistem, yepyeni bir sistemin yapabileceği gibi organizasyonun iş ihtiyaçlarını da karşılamayacaktır.

Bu nedenle, devam eden tüm bakım maliyetlerini ve yeni bir sistemin işletmeye getirdiği potansiyel faydaları, işi sıfırdan yeniden yazma maliyetine karşı tartmanız gerekir. Yeniden yazmanın maliyeti hakkındaki tahminlerde çok karamsar olun . Neredeyse her zaman maliyeti daha fazla ve düşündüğünüzden daha uzun sürüyor.

Dur! Yeniden yazma neredeyse hiç cevap değil. Çoğu zaman, yeniden yapılanma daha iyi bir bahistir.

Tabii ki, orada olan bir yeniden yazma haklı zamanlar:

• Geçiş araçlarının olmadığı (veya yeterince ucuza yazılamayan) yeni bir platforma geçiyorsunuz.
• Yeniden yazılacak başvuru önemsizdir.
• Özgün uygulamanın kaynak kodu kaybolur ve kurtarma işlemi yeniden yazmaktan daha pahalıdır.
• Mevcut uygulama tarafından kapsanan iş kurallarının büyük çoğunluğu artık geçerli değildir.
• Mevcut kodun az sayıda aktif kullanıcısı var.
• Yeniden yazmak için gerekli kaynağa (zaman, yetenek ve araçlar) sahipsin.
• Mevcut başvuru yasal veya pratik nedenlerden dolayı üretim ortamında çalıştırılamaz.

Yeniden yazma konusunda neden yeniden gözden geçirmeyi önerdiğimi anlamak için, yeniden yazma işlemine neyin dahil olduğunu düşünün. Mecbursun:

1. Mevcut uygulamanın yaptıklarının nüanslarını anlayın. Bu, kapsadığı tüm ince iş kurallarını, içinde bulunduğu ortamı (hem insan hem de teknik) ve mevcut çözümün avantaj ve dezavantajlarını hesaba kattığınızda önemsiz değildir. Çoğu zaman, bu bilginin var olduğu tek yer (eğer varsa) mevcut uygulamanın kaynak kodundadır. Yeniden yazma yapmak için ana nedenlerden birinin mevcut kodun anlaşılması ve sürdürülmesi zor olması talihsiz bir durumdur.

2. Bu işlevselliği (veya güncellenmiş bir sürümünü) test edilmiş ve güvenilir yeni bir uygulamada çoğaltın. Mevcut kod, geliştiriciler tarafından anlaşılmayabilir, ancak kullanıcıları tarafından genellikle anlaşılır. Mevcut işletme ihtiyaçlarını karşılamayabilir, ancak en azından uygulamanın çeşitli koşullar altında ne yaptığını size söyleyebilirler.

Yeniden yapılanmanın büyük avantajları:

• Her seferinde bir parça küçük şeyler alabilirsin.
• Herhangi bir değişiklik mevcut çalışan uygulama bağlamında test edilebilir.
• Var olan kodun çalışma şekli hakkındaki hipotezler, küçük değişiklikler yaparak ve ne olduğunu gözlemleyerek test edilebilir.
• Değişiklikler genellikle kullanıcılara aynı anda değil, faz olarak iletilebilir.
• Yeniden yapılandırmanın erken aşamalarından öğrenmek, yeniden yapılandırmanın sonraki aşamalarını bilgilendirebilir.
• Süreci kısmen terk ederseniz, daha temiz bir kod tabanı açısından faydalar devam eder (kullanıcıya veya geliştiricilere herhangi bir yarar sağlamak için tamamlanması gereken yeniden yazmak yerine ).

Siz de bir yeniden yazma yaparsanız, yeni kod tabanına bir sürü yeni hata girip karışıklığa neden olacağınızı unutmayın.

Bu grafik yardımcı olabilir, uygulamanın kod temel kalitesinin ve işletme değerinin bir işlevidir:

Grafik, eski yazılımların yeniden yapılandırılmasının ne zaman gerekçelendirildiği ve ne zaman yapılmayacağı konusunda bir rehber gibi görünmektedir. Örneğin, yazılımın işletme değeri yüksekse ve kodun kalitesi düşükse, yeniden yapılanma doğrulanır.

Sanırım kariyerimde büyük yeniden yazmanın cevabı olduğu tek durumdayım:

Şirket birleşmesi, sistem işlevselliğinde büyük örtüşme. Pek çok, birçok sistem birleştirildi ve emekli edildi ve diğerleri hala süreçte.

Diğer şirketten hala devam eden bir sistemi miras aldım. Kendimize çok benzeyen birden fazla departmanı desteklemek için kullanılan, ancak tamamen farklı bir tasarım ve çerçeveye sahip devasa bir kod tabanına sahiptir. Bunu kullanan tek bir iş sektörü kaldı, bu da bu şeyi bir zombi durumunda canlı tutan yeterli para kazanıyor. Bütün eski uzmanlık bitti, dokümantasyon yok. Destek yükü her hafta başarısızlıkla sonuçlanıyor. Şirketlerimizin sistemlerine dahil edilmemiştir, çünkü şirketimiz bu iş sektörünü hiçbir zaman desteklemediği için işlevsellik veya uzmanlığa sahip değiliz.

Yeniden yazmanın gerekli olduğu durum bu gibi görünüyor. Görünüşe göre, bu kargaşayı çözmek, bu işe adanmış işlevsellik parçalarını çıkarmak ve var olan sistemimize eklenmesi gereken parçaları yeniden yazmak zorunda kalacağım. Bu yapıldıktan sonra, mevcut sistemlerimiz bu yeni sektörü destekleyebilir ve bu canavar onun mutsuzluğundan çıkarılabilir. Aksi halde aklımı kaybedeceğim.

Y2K'yi işlemek için yükseltilmiş, Windows 16 bit uygulaması olarak yeniden yazılmış ve daha sonra bir ek 'küçük' özelliği olan 32 bit uygulaması olarak tamamen yeniden yazılmış bir çift DOS uygulaması olan küçük bir yazılım şirketi için çalıştım (sonuçta yalnızca bir kişi tarafından kullanıldı) bir müşteri) bu bütün yapıyı etkiledi.

16 bitlik kodu 32'ye çıkarmak bir ay içinde bir kişi tarafından yapılmış olabilirdi, ancak NOOOOOOOOO, Soooooooooo'yu daha iyi yapmak için yeniden yazmak zorunda kaldık. Bu şey diğer endüstriler için uyarlanabilir, daha başlamadan önce tüm özelliklere ve psuedo koduna sahip olacaktı. Teknik özellikler yaratıldı, ancak çok uzun sürdü, gerçek kodu yazmaya bile zaman yoktu. 16 bitlik 'bit' ile başlayandan daha fazla hatayla geç bırakıldı (v.3.0 ve son olarak da neredeyse birileri yeni bir hata bildirmeden bir hafta içinde yaptıkları noktaya kadar).

Aynı uygulamayı 3-4 kez yeniden yazmanın bazı iyileştirmeler getireceğini düşünürdünüz, ancak bir GUI ön uçunun bu kadar haklı olduğunu düşünmüyorum.

Bu benim teknik destek sorumlusu olarak ilk BT işimdi. Dağıtım için yazılım geliştirmeme konusunda bir kitap yazmalıyım. Açıkçası birçok hata yaptık, ancak uygulamaları yeniden yazmaya devam ettiğimiz gerçeği, yetersizliği artırdı.

Seninkine çok benzeyen bir durum vardı, sadece kod Struts bile kullanmıyordu. Bunun yerine, özellikle çirkin olan ve birçok soruna neden olan hedef bölgelerdi. Bu hedeflenen yaklaşım bizi giderek daha iyi hale getirdi.

2 yıllık bir süre zarfında, geliştirme çalışmaları ile birlikte yeniden parçalama parçaları ve parçaları üzerinde de çalıştık. Her zaman bir proje planında 'Sertleştirme' görevi yaptık. İşe yaramayan belirli alanlara odaklanarak, para için en fazla patlamayı elde ettik. İşe yarayan şeyler yalnız kaldı. Ayrıca kritik olan bu çalışmanın normal gelişim sürecinde yapıldığı ve serbest bırakıldığıdır. Büyük bir yeniden yazma problemi, bir yıl veya daha fazla bir süre boyunca ortadan kalkar ve sonra geri döndüğünüzde her şey yine de değişti ve bazı kötü böcekler düzeltti ve yatırım getirinizi kaybettiniz.

Her şeyi bir daha asla yazmadık. Yine de bu platformu yeni işler için kullanmayı bıraktık ve büyük bir proje için yeni bir platform belirledik. Bu onaylandı ve makul bir sürede harika bir ürün teslim ettik.

İşte burada masamda oturuyorum, bu büyük bir aspx dosyasının mutlak karışıklığı için kodunu yeniden yazmaya başladım, arkasındaki veritabanını ve MS Access arayüzünü MsSQL ile değiştirmeye başladım.

Bu asp programı gibi şeyler ile çevrili

• include(close.aspx) İçinde son açık veritabanı bağlantısını kapatan tek bir kod satırı vardır.
• Eski kod sadece rastgele yorum yaptı
• Güvenlik için dikkate alınma
• Spagetti kodu, binlerce satır. Hepsi bir dosyada.
• İsimlerinin arkasında net bir anlamı olmayan fonksiyonlar ve değişkenler

Hafif bir değişiklik yapmamız gerekirse, kabus modunda eşzamanlı olarak beş kal-toh oyunu oynamak gibi bir şey.

İşlevselliği çoğaltmak ve sektördeki diğer kişilere özelleştirilebilir ve satılabilir bir ürün yapmak için işe alındım. Sorun şu ki, son 10 yılda her iş ihtiyacını karşılamak için yazılmıştı (yine de yaklaşık beş veya altı sigma diyebilirim).

Eğer ürünü satmak istememiş olsaydık, muhtemelen istediklerinin çoğunu yaptığı gibi tekrar yazmaya gerek kalmayacaktı - belki şık bir şekilde değil, ama parayı güzel bir kod yapmak için harcamak akıllıca değildi. 'aynı şeyi yap.'

Joel Spolsky'nin bu konuda harika bir makalesi var: Asla Yapmamalısınız, Kısım I

Söyleyeceğiniz başlıktan, bir tarafa (neden asla kod atmamanız hakkında konuşur) IMO, bunun için çok fazla doğruluk var, yakın zamanda bazı devlerin söylediği Excel'in 25. Yıldönümü'nde bir kanal 9 videosu gördüm. Bugün bile kaynağa baksanız, revizyonu kontrol eder ve 20 yıl önce kullanılmış olan excel koduna geri dönersiniz.

Sen% 100 (hatta Netscape Joels Madde) dan (hata yapar iken) emin olamaz ben Joel'in makale Tanrı gönderildiği gibi karamsar olabilen ve kod düşünme hep ikinci iyi yazabilir atmadan seviyorum çünkü keçe zaman, ama sadece şimdi fark ettim ki bu çok pahalı .

Somut bir cevap vermek için, kapsamlı bir Maliyet-Değer analizi yapmanız gerektiğini söyleyebilirim .

Gerçek dünyam: Silverlight uygulaması Im şimdiye kadar v0.6 geliştiriyorum, kodu bu kadar kıvrımlı kılan zaman uyumsuz çağrıların bir karmaşası var. Bu hafta Reaktif Eklentileri keşfettiğimden beri kodun çoğunu yeniden yazmak istiyorum, ama şimdi müşterime ne söylerim? Program mükemmel çalışıyor (bazı bellek sızıntıları var) ancak umursamıyorlar mı? Muhtemelen onlara söyleyemem 2-3 hafta daha sürüyorum çünkü bir şeyler yapmak istiyorum. Bununla birlikte, boş zamanlarımda kodu dallandıracağım ve onunla yeniden yazacağım / oynayacağım .

Sadece 2 sentim tamam mı?

Mevcut çözüm ölçeklenmiyor.

Sana bakıyorum, MS Access.

Joel’e göre, büyük yeniden yazma bir şirketin yapabileceği en büyük stratejik hata.

Asla Yapmamanız Gerekenler, Bölüm I

... Sıfırdan başladığınızda , ilk defa yaptığınızdan daha iyi bir iş yapacağınıza inanmak için hiçbir neden olmadığını unutmamak önemlidir . Her şeyden önce, muhtemelen ilk versiyonda çalışan aynı programlama ekibiniz bile yok, bu yüzden aslında "daha fazla deneyime" sahip değilsiniz. Eski hataların çoğunu tekrar yapacak ve orijinal versiyonunda olmayan bazı yeni problemleri ortaya çıkaracaksınız.

Eski mantra , atmak için bir tane inşa ederken, büyük ölçekli ticari uygulamalara uygulandığında tehlikelidir. Eğer deneysel olarak kod yazıyorsanız, daha iyi bir algoritma düşündüğünüzde geçen hafta yazdığınız fonksiyonu sökmek isteyebilirsiniz. Bu iyi. Kullanımını kolaylaştırmak için bir sınıfı yeniden yansıtmak isteyebilirsiniz. Bu da iyi. Fakat bütün programı atmak tehlikeli bir saçmalıktır ve Netscape'in yazılım endüstrisi deneyimi konusunda yetişkin gözetimi altında olması durumunda, kendilerini bu kadar kötü vurmamış olabilirler.

Asla, her zaman refactor - gerçek şu ki, kod sizin tarafınızdan yazılmışsa - daha iyisini yapamazsınız.

Teknolojiyi değiştirmek istemediğiniz sürece, kod herhangi bir yapıya sahip değildir (çok uzun zaman önce bazı PHP web sitelerinde gördüm, yazar sadece / class / function yerine spahgetti'yi kopyaladı / yapıştırdı) veya başka bir kişiden bir şey aldınız. çok kötü yazılmış.

Her şey bir kara kutu olarak tasarlanmalı. Modüler, Basit API, içeride ne var ... bu daha az önemli :) Spagetti'niz varsa, onu bir kara kutu içinde kapatabilirsiniz, bu nedenle iyi bir kodu kirletmez.

Bence yeniden yazımları haklılaştıran ana sebep platform değişimleri için. Örneğin, bir Windows masaüstü GUI uygulamanız varsa ve şirket sahibi bir sonraki sürümün web tabanlı bir uygulama olmasını istediklerine karar verir. Her zaman olmasa da, asıl geliştiricilerim çok modüler ve yeniden kullanılabilir kodlar yazmadıkça (zorlukla olur), deneyimlerime göre çoğu zaman bu bir yeniden yazma gerektirir.

"Ben XI'ye gideceksem buradan başlamazdım" hakkında klasik bir şaka var.

Bir keresinde bir iş buldum, işverenin asıl motivasyonunun, iş açısından kritik öneme sahip bir uygulamanın uzun süre önce yazılmış bir yeniden yazmasını başlatmak için gemiye yetenek getirmek oldu. Sormadığım soru şuydu, neden bu duruma en baştan geldin? Nedenin olsaydı, kırmızı bayrak olmalıydı

• canavarı korumak ve adım adım düzeltmek için işlevsellik eklemek için çok fazla baskı yapılması,

• Bölümde çok az yetenek var,

• artımlı iş için müşterilerden veya yönetimden çok az giriş yapılması,

ya da her neyse, ve bu sorun dayanılmaz bir düzeye ulaşana kadar iltihaplanmaya neden olur.

Bu yüzden Joel ile büyük bir yeniden yazmanın muhtemelen çok kötü bir fikir olduğu konusunda hemfikir olacağım - önemli bir yeniden yazmanın neden bu kadar gerekli göründüğünün altında yatan tüm nedenlerin altında bulunduğuna dair kesin bir kanıt bulunmadığı sürece , tamamen olabilirsiniz. Sorunu vadede tekrar edeceğim.

Yeniden yazma, kuruluşun rekabet avantajı sağlayan bir stratejiyi izlemesine izin verdiği veya mevcut mimarinin dayanamadığı bir şekilde müşterilerine daha iyi hizmet etmesine izin verdiği zaman cevaptır.

Bunun yerine, yeniden yazma sık sık yönetim endişelerini hafifletir:

• her şey .NET'te olmalı,
• geliştiricilerimiz kodumuzun berbat olduğunu söylüyor
• teknik olarak geride kalıyoruz
• sistemimizi desteklemek için kaynak bulamayacağız veya çok sık
• on yıl oldu, bu yüzden zamanı geldi.

Bu kaygıların çoğu gerçekleşmeyecek ve eğer yaparlarsa ele alınabilirler. Ancak sonuncusu, en kötüsü. Esasen: Bir nedenimiz yok.

Evet, araba gibi bir sistem de aşınma belirtileri göstermeye başlayacak. Bu rutin servis işlemleri ile hafifletilebilir. Önleyici bakımın ne kadar uzun sürdüğü hakkında neler söylediklerini biliyorsun. Bir yatırım olarak rutin servis (yani yeniden düzenleme ve standartlaştırma), her zaman yeniden yazmaktan daha az maliyet taşıyacaktır.

Ancak, sonunda bir yeniden yazmanın gerekli olacağını öngörmek zorundayız. Tarihler belirleyin ve geçici olarak planlayın, ancak tarih sizin gibi zorlayıcı bir neden olana kadar diğer stratejik hedefleri gerçekleştirme lehine daha yakın bir gecikme çektiği için ...

Son yıllarda, büyük hesaplar kazanma fırsatını kaybettik çünkü ihtiyaçlarını zamanında veya masraflı bir şekilde karşılayamadık. Sistemimiz, özelleştirmelerin bağlanmasına izin veren genişletilebilir bir mimari kullanarak yeniden yazılacaktır (ve şu anda yaptığımız gibi kodlanmamıştır). Bu, müşterileri özel ihtiyaçları olan karşılamanın zamanını ve maliyetini önemli ölçüde azaltacaktır. Daha fazla hesap kazanacağız ve mevcut müşterilerimizin ihtiyaçlarını daha iyi karşılayacağız.

Tamamen yeni bir teknolojiye geçerken istenen işlevselliği sağlamak için gereklidir.

"Tamamen yeni": yeniden yazmayı planlıyor ancak aynı platformu kullanıyorsanız, yeniden düzenleme ve makul yeniden yapılandırma neredeyse kesinlikle daha iyi bir çözümdür. Burada kullanıldığı şekliyle "Platform" biraz belirsizdir - dili ve belki de işletim sistemini (Linux'tan Windows'a genişletmek veya bunun tersi akla gelir) içerdiğini düşünün, ancak çerçeveyi değil (örneğin Struts'u Spring ile değiştirmek).

"İstenilen işlevselliği sağlaması gerekiyor": 2000 civarında, kullanıma hazır iş parçacığı, nesne önbelleği ve istemci tarafından kontrol edilen işlemleri etkinleştirmek için Java'da C ++ 'daki büyük bir sunucu bileşenini yeniden yazmak için bir proje başlattım. O zamanlar, C ++ için desteklemesi gereken çok sayıda thread kütüphanesi vardı ve veri tabanı kodumuzun çoğunu çalıştırabilmek, toplam bir yeniden yazmak gerekliydi. Müşteri kontrollü işlemler gelince ... eski mimaride olmaz.

O zaman bile, mevcut sistemin davranışı hakkında ayrıntılı bilgi sahibi olmam dışında, yeniden yazma işlemini yapacağımdan emin değildim ve 11 yıllık ömrü boyunca çok fazla siğil geliştirmemiş olması nispeten temiz bir koddu.

Başlamak istediğiniz noktaya karar vermek için, mevcut projenizde devam etmenin değerinin başlangıçtaki değerin altında kaldığı yerde çalışmanız gerekir.

Bunun bu kadar zor olmasının nedeni, yeni projedeki takımın gelişim hızını tam olarak başlatana kadar doğru bir şekilde tahmin etmenizdir. Bununla birlikte, yeni projede gelişim hızınızın ÇOK muhafazakar bir tahminini kullanarak, projenin yatırım için değerli bir getiri sağlayacağı tahmin edilirse, o zaman baştan başlamak için bir iş durumunuz vardır.

Metrikimle birlikte, bir yeniden yazımı doğrulamak için iki koşulu yerine getirmelisiniz:

1. Yeniden yazma işleminden sonra yeni özellikler daha kolay / daha hızlı / daha az buggy yazacak
2. Yeniden yazma, geçerli yeni özelliği eklemekten daha az veya eşit bir zaman alacaktır.

O zaman bile tekrar yazma kapsamınızı sınırlamak istiyorsunuz. Örneğin, modülerliği bilmeyen bir C programcısının zihniyeti ile C ++ ile yazılmış bir şirkette bazı eski yazılımlarımız vardı. Sonuçta birden fazla sınıf ve DLL içeren sonlu durumlu bir makine şeklinde speghetti kodu oldu. Yasaya dahil edilen varsayımlardan çok farklı olan ve şirketin patentli katma değerinin bir parçası olacak yeni bir gereksinimimiz vardı.

Diğer özellikleri uygulayan kodla zaman geçirdikten sonra, değiştirmem gereken birkaç anahtar ifadesinin ne kadarını bulmamın ne kadar zaman alacağı konusunda gerçekten çok iyi bir fikrim vardı. büyük sonlu durumlu makine - mevcut kodu uzatmaktan daha az zaman almam gerekiyor. Eskiden üç olanı tek bir DLL'de birleştirebildim ve kritik işlevsellik yapmayı çok daha kolay hale getirecek ve yeni işlevsellik eklemeyi daha kolay hale getirecek çok daha fazla nesne yönelimli bir yapı sağlayabildim.

Yeniden yazma ihtiyacı olan kütüphaneleri kullanan başka üç uygulama vardı, bu yüzden bu programları tamamen yeniden yazmak zorunda kalmak istemedim. Kapsam kütüphaneyle sınırlıydı ve kütüphaneyi mevcut yazılıma bağlamak için gerekenler sınırlıydı. Tahminlerim çok uzak değildi ve iş bunun için ödendi. Yeniden tasarlamadan kısa bir süre sonra yeni bir özellik eklemekle görevlendirildim. Eski yapı ile bir hafta beni ne alırdı sadece yeni yapı ile bir gün sürdü.

OP projenin kapsamını göstermiyor, ancak aldığım asıl ipucu benim için yeniden yazmanın ana itici güçleri olan "eski [dil / lehçe] eski [libs] kullanarak yazılmış" idi. Aslında, önemli bir piyasa ömründe bulunduğum çoğu proje sonunda derleyicilere / tercümanlara / işletim sistemlerine güncellemeleri dahil etmenin kod tabanının korunmasında önemli bir görev olduğunu fark eder.

Kısacası, ilk önce lib'lerdeki güncellemeyi öncelik sırasına alarak yeniden yazmayı aşamalar halinde planlayacağım. Yol boyunca diğer optimizasyonlara gizlice girebilirsiniz, ancak daha sonraki bir aşamada bazı değişiklikleri ertelemeyi planlamanız, programa devam etmenin ve "takılmayı" önlemenin harika bir yolu olabilir.

Mevcut kod tabanını (sadece bucky toplarının sıfır ağırlık ve hacme sahip olduğu varsayımsal durumlar) atlayabileceğim varsayımsal senaryolar hayal edebiliyorum, gözden kaçan özellikler ve hatalar eklerken çabalıyorsak haftalarca veya aylarca verim kaybetmemize kimsenin umrunda değil sistemdeki düzeltmeler ve sistemin çok önemsiz ve nefret ettiği bir organizasyon tarafından onlardan bir dakikada sunucuların her şeyi ve ordusunu notepad ++ ve bir netbook ile değiştirebilir ve herkesin verimliliğini ve ahlaki değerini artırabilirim.)

Neredeyse tüm gerçek dünya senaryoları için sadece yerinde yeniden düzenlemeyi tavsiye ederim. ^ _ ^. Belgelenmemiş yasal ve ticari gereksinimler ortaya çıkmaya başladığında ve son dakikada bir araya geldiklerinde son dakika ortaya çıkmaya başladığında, yeniden yazmak için çok fazla gizli, beklenmeyen maliyetler olma eğilimindedir.

== Daha iyi mallar için Yerinde Yeniden Düzenleme ==

Düzenli eski artımlı yaklaşımla eski kodun yeniden düzenlenmesi,

1. UML'ye dönüştürme şansınız varsa ve çok az mimarinin varlığını belgeleyin.
2. Sürüm kontrolü kullanıyorsanız, bazı kod karma raporları oluşturmaya ve en sık hangi dosya ve dosya bölümlerinin değiştirildiğine karar vermeye bakın. Bunları not edin, çünkü öncelikle ilgilenmek isteyeceğiniz alanlar olacaktır.
3. Herhangi bir kodu değiştirmeden önce daima bir test kapsamı eklemeye çalışın (çirkin tam yığın fonksiyonel testler bile yapacaktır). Büyük dağınık yordamsal kod ayıklama mantığı ile ilgileniyorsanız, makul şekilde adlandırılmış bazı yöntem veya işlevlere geçmeyi planlıyor ve mümkünse yeni yönteminizi doğrulayan bazı test durumları ekleyin. hangi tanrıyı hacklemek zorunda olursanız olun, eğer mümkünse, eğer marj genişliği veya unvanı gibi ince ayarlanmış bir şeyse değişimi paramatize edin.
4. Bağdaştırıcı desenini kullanın ve eski kodların nadir bitlerini mantıksal olarak adlandırılmış sınıflar ve yöntemler altında saklayın, böylece çoğu ortak görev için siz ve diğer geliştiricilerin performansları sizi geride bırakacak korkutucu bitler için endişelenmenize gerek kalmayacak arkanızda gizlenmiş zahmetli zombi eski aile üyelerini ahırlarda sakladığın o güzel küçük temiz yöntem ve sınıfların ardında arkanızda - gün geçtikçe günleri bozulmaması için Çiftlik . . . normalde.
5. Karıştırıp temizlemeye devam ettikçe kodun bölümleri de test kapsamınızı arttırmaya devam eder. Artık daha derin bir şekilde kazıp daha fazla güven ile ihtiyaç duyulduğunda / istendiğinde daha fazla kodu "yeniden yazabilirsiniz".
6. Kod tabanınızı geliştirmeye devam etmek için yineleyin veya ek yeniden düzenleme yaklaşımları uygulayın.

Soyutlama ile Dallanma

1. Kaldırmak istediğiniz koddaki sorun noktasını (kalıcılık katmanı, pdf oluşturucu, fatura taksit mekanizması, widget oluşturucu vb.) Tanımlayın.
2. genel işlevselliğin yanı sıra bu işlevi hedefleyen kod tabanına karşı bazı işlevsel test durumlarını (otomatik veya manuel, ancak otomatik olarak biliyorsunuzdur) yazınız.
3. Bu bileşenle ilgili mantığı, mevcut kaynak tabanından makul bir arayüze sahip bir sınıfa çıkarın.
4. Tüm kodun şimdi kod boyunca rastgele dağıtılmış X etkinliğini gerçekleştirmek için yeni arabirimi kullandığını doğrulayın (Kod tabanını grepleyin, yeni sınıfa bir iz ekleyin ve onu çağırması gereken sayfaları doğrulayın vb.) Ve Tek bir dosyayı değiştirerek hangi uygulamanın kullanılacağını kontrol edebilirsiniz. (nesne kayıt defteri, fabrika sınıfı, ne olursa olsun IActivityXClass = Settings.AcitivtyXImplementer ();)
5. Herşeyin hala yeni sınıfınıza girdiği tüm Activity X'lerle çalıştığını doğrulayan işlevsel test durumlarını yeniden çalıştırın.
6. Yeni aktivite X sarıcı sınıfının etrafına mümkün olduğunca ünite testleri yaz
7. eski sınıf ile aynı arayüze bağlı eski uygulamadan daha az deli spagetti mantığı ile yeni bir sınıf uygulamak.
8. Yeni sınıfın, eski sınıf için yazdığınız ünite sınavlarını geçtiğini doğrulayın.
9. eski sınıfı yerine yeni sınıfı kullanmak için kayıt defterini / fabrika yöntemini / neyi değiştirerek kodunuzu güncelleyin.
10. işlevsel testlerinizin hala başarılı olduğunu doğrulayın.

Açık Kapalı Prensip ve Ortak Bir İş Mantığı / Kalıcılık Katmanı

Bir dereceye kadar sunumunuzu, iş ve sebat katmanınızı ayırmak ve eski çözümle tamamen geriye dönük olarak uyumlu bir uygulama yazmak veya en azından eski çözüm tarafından girilen verileri idare etmekle baş edebiliyor olabilirsiniz. Muhtemelen bu yaklaşımı tavsiye etmem ama bazen zaman / program / kaynaklar / gerekli yeni işlevsellik için makul bir uzlaşmadır.

• En azından sunum katmanını iş ve kalıcılık katmanlarından uzak tutun.
• aynı ortak işletme ve kalıcılık katmanını kullanan yeni bir kullanıcı arayüzü ve daha iyi bir sunum katmanı uygulayın.
• Yeni kullanıcı arayüzü ile oluşturulan verilerin eski kullanıcı arayüzü bozmadığını doğrulayın. (yeni araç kullanıcıları eski araç kullanıcılarını rahatsız ederse sıcak suda olacaksınız). Geriye tam uyumluluk için çabalıyorsanız, her şeyi aynı kalıcılık katmanlarına kaydetmeniz gerekir. Yalnızca yeni araca ileriye dönük uyumluluk istiyorsanız, eski sistemde olmayan verileri izlemek için yeni bir veritabanı ve yeni tablolar veya uzatma tabloları kullanın.
• Yeni işlevsellik ve kalıcılık katmanı gereksinimleri için yeni tablolar ekleyin ve yöntemler mevcut eski mantığı değiştirmez veya mevcut tablolara sütunlar, kısıtlamalar eklemez. Örneğin, işverenlerin acil durum irtibatlarını izlemeye başlamanız gerekiyorsa ve diğer bazı alanlar mevcut çalışan tablosunu değiştirmiyorsa (eski verilerin o tablo hakkında ne varsayımları olduğunu bilmiyoruz) bir eklenti tablosu ekleyin.
• Kullanıcıları yavaşça yeni sisteme taşıyın. mümkünse eski sistemi salt okunur moda getirin veya kullanıcılara X tarihinden sonra kullanılamayacağını bildiren bir uyarı ekleyin.
• yeni kullanıcı arabiriminde herhangi bir öncelikli cevapsız işlevsellik veya iş gereksinimi uygulamak
• kullanıcıların tabanını devirmek.
• iş mantığı ve kalıcılık katmanı kullanıcılarının diğer refactoring metodolojilerini temizlemeye devam ediyor.

Refactor vs Rewrite space 'de üçüncü bir kategori olduğunu söyleyebilirim ... Dil sürümlerinizi, derleyicileri ve kütüphaneleri güncelliyor ... Bazen sadece modern kodlama tekniklerini benimsemenin büyük faydası var.

Örneğin, C # al, v7 kodu v2'den çok daha temiz, daha güvenli ve daha özlü yazar. Elvis ve boş birleştirme operatörü gibi şeyler tonlarca yardımcı olur.

Derleyicileri değiştirmek, yeni bir hayata daha eski kodlara nefes verebilir. Bu yüzden işlerin çalışılmasını ve uygulanmasını kolaylaştıracak yeni kütüphaneler olabilir ... Ağ oluşturma, uygulama zorluğu için mükemmel bir örnektir.

Ayrıca gömülü linux sistemleri ... svn'den git'e gitmek için yeni araçlar kurmayı düşünün. veya sisteminize Vi vb. ekleyin.

Her zaman yeniden yazmak için bir refaktör olmak zorunda değildir.

İnsanları eski bir uygulamayı yeniden yazarken gördüğümü sanmıyorum .

Olan şey şu ki, insanlar önceki nesille ortak özelliklere sahip farklı mimarilere, teknolojilere vb. Sahip yeni uygulamalar yazıyorlar. Ve buna uygulama 2.0 adı verilir, ancak aslında orijinaliyle çok az ortak noktaları vardır.

Ancak bu, gerçekten özellik paritesine ulaşmaya çalıştığınız anlamda orijinalin bir "yeniden yazımı" değildir.