it-swarm.dev

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

Sadece Büyük Yeniden Yazmalar hakkında sor okudum ve kendime cevap vermek istediğim bir soruyu hatırladım.

Bana, eski Java ile yazılmış, Struts 1.0 kullanarak, tutarsız ilişkileri olan tablolar, ya da hiç ilişki yok ve hatta birincil anahtar veya alan olmadan birincil anahtar olması gerekiyordu ama benzersiz değil korkunç bir proje var. Bir şekilde app çoğu "sadece çalışır". Sayfaların çoğu yeniden kullanılır (yapıştırılan kodu kopyalar) ve sabit kodludur. Proje üzerinde çalışmış olan herkes projeyi şu ya da bu şekilde lanetlemiştir.

Uzun zamandır üst yönetime bu korkunç uygulamanın tamamen yeniden yazılmasını önermeyi düşünmüştüm. Yavaş yavaş kişisel zamanı deniyorum ama gerçekten bunun gerçekleşmesi için bazı özel kaynakları hak ettiğini hissediyorum. Büyük yeniden yazmalarla ilgili makaleleri okuduktan sonra ikinci düşüncelerim var. Üstlerimi yeniden yazımı desteklemeye ikna etmek istediğimde bu iyi değil. (Oldukça küçük bir şirkette çalışıyorum, böylece teklifin onaylanma olasılığı var)

TL; DR Cevabı ne zaman büyük bir şekilde yeniden yazıyor ve bunu desteklemek için hangi argümanları kullanabilirsiniz?

288
Jonn

Maalesef, bu uzun olacak, ancak birden çok yeniden yazma projesinde hem mimar hem de geliştirici olarak kişisel deneyime dayanıyor.

Aşağıdaki koşullar bir tür yeniden yazmayı düşünmenize neden olmalıdır. Bundan sonra hangisinin yapılacağına nasıl karar vereceğim hakkında konuşacağım.

  • Geliştirici hızlanma süresi çok yüksek. Yeni bir geliştiriciyi artırmak için aşağıdan (deneyim düzeyine göre) daha uzun sürerse, sistemin yeniden tasarlanması gerekir. Rampa süresiyle, yeni geliştiricinin ilk taahhüdünü (küçük bir özellikte) yapmaya hazır olması için geçen süreyi kastediyorum
    • Üniversiteden yeni çıkmış - 1,5 ay
    • Hala yeşil, ama daha önce başka projelerde çalıştı - 1 ay
    • Orta seviye - 2 hafta
    • Deneyimli - 1 hafta
    • Üst düzey - 1 gün
  • Mevcut mimarinin karmaşıklığı nedeniyle dağıtım otomatikleştirilemez
  • Basit hata düzeltmeleri bile mevcut kodun karmaşıklığı nedeniyle çok uzun sürüyor
  • Yeni özellikler çok uzun sürüyor ve kod tabanının birbirine bağlı olması nedeniyle çok pahalıya mal oluyor (yeni özellikler izole edilemez ve bu nedenle mevcut özellikleri etkileyebilir)
  • Resmi test döngüsü, mevcut kod tabanının birbirine bağlı olması nedeniyle çok uzun sürüyor.
  • Çok az ekranda çok fazla kullanım durumu yürütülür. Bu, kullanıcılar ve geliştiriciler için eğitim sorunlarına neden olur.
  • Mevcut sistemin içinde bulunduğu teknoloji bunu talep ediyor
    • Teknolojide tecrübesi olan kalite 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ı korumanın maliyeti çok yüksek

Bunlar oldukça belirgindir. Tam bir yeniden yazmaya karşı tam bir yeniden yazmaya ne zaman karar verileceği daha özneldir ve bu nedenle daha politik olarak ücretlendirilir. İnançla söyleyebileceğim, kategorik olarak asla iyi bir fikrin yanlış olduğunu belirtmektir.

Bir sistem aşamalı olarak yeniden tasarlanabiliyorsa ve böyle bir şey için proje sponsorluğunun tam desteğine sahipseniz, bunu yapmalısınız. Sorun burada. Birçok sistem aşamalı olarak yeniden tasarlanamaz. İşte bunu engelleyen bazı nedenler (hem teknik hem de politik).

  • Teknik
    • Bileşenlerin birleştirilmesi o kadar yüksektir ki, tek bir bileşendeki değişiklikler diğer bileşenlerden izole edilemez. Tek bir bileşenin yeniden tasarlanması, yalnızca bitişik bileşenlerde değil, dolaylı olarak tüm bileşenlerde de değişikliklere neden olur.
    • Teknoloji yığını o kadar karmaşıktır ki, gelecekteki durum tasarımı çoklu altyapı değişiklikleri gerektirmektedir. Bu tam bir yeniden yazmada da gerekli olacaktır, ancak artımlı bir yeniden tasarımda gerekiyorsa, bu avantajı kaybedersiniz.
    • Bir bileşenin yeniden tasarlanması, bu bileşenin yine de tamamen yeniden yazılmasına neden olur, çünkü mevcut tasarım o kadar tuhaftır ki tasarruf etmeye değer bir şey yoktur. Yine, bu durumda avantajı kaybedersiniz.
  • Politik
    • Sponsorlar, artımlı bir yeniden tasarımın projeye uzun vadeli bir bağlılık gerektirdiğini anlamak için yapılamaz. Kaçınılmaz olarak, çoğu kuruluş, artımlı bir yeniden tasarımın yarattığı bütçe tahliyesine duyulan iştahı kaybeder. Bu iştah kaybı da yeniden yazma için kaçınılmazdır, ancak sponsorlar devam etmeye daha meyillidir, çünkü kısmen tamamen yeni bir sistem ile kısmen eski bir sistem arasında bölünmek istemezler.
    • Sistem kullanıcıları "mevcut ekranları" na çok bağlı. Bu durumda, sistemin (ön uç) hayati bir bölümünü geliştirme lisansına sahip olmayacaksınız. Yeniden tasarım, yeni bir şeyle başladıkları için bu sorunu atlamanızı sağlar. Yine de "aynı ekranları" almakta ısrar edecekler, ancak geri itmek için biraz daha mühimmatınız var.

Tam olarak yeniden yazma işleminin toplam maliyetinin, tam bir yeniden yazma yapmaktan her zaman daha yüksek olduğunu, ancak kuruluşun etkisinin genellikle daha küçük olduğunu unutmayın. Bence, bir yeniden yazmayı haklı çıkarabilirseniz ve süperstar geliştiricileriniz varsa, yapın.

Bunu ancak tamamlanıncaya kadar görmek için politik irade olduğundan emin olursanız yapın. Bu hem yönetici hem de son kullanıcı katılımı anlamına gelir. Onsuz, başarısız olacaksın. Joel'in bu yüzden kötü bir fikir olduğunu söylediğini varsayıyorum. Executive and son kullanıcı katılımı birçok mimar için iki başlı bir Unicorn'a benziyor. Agresif bir şekilde satmanız ve tamamlanıncaya kadar devam etmesi için kampanya yapmanız gerekir. Bu zor ve bazılarının başarılı olmak istemeyeceği bir şey hakkında itibarınızı belirtmekten bahsediyorsunuz.

Başarı için bazı stratejiler:

  • Ancak, mevcut kodu dönüştürmeyi denemeyin. Sistemi sıfırdan tasarlayın. Yoksa vaktini boşa harcıyorsun. Asla sefil olmayan bir "dönüşüm" projesi görmedim ya da duymadım.
  • Kullanıcıları yeni sisteme bir seferde bir ekiple taşıyın. Mevcut sistemle EN acı çeken takımları tanımlayın ve önce onları taşıyın. İyi haberleri ağızdan ağıza yaymalarına izin verin. Bu şekilde yeni sisteminiz içeriden satılacaktır.
  • Çerçevenizi istediğiniz gibi tasarlayın. Asla gerçek kod görmemiş olan bu I-6-ay-ay-inşa-bu çerçeveyle başlamayın.
  • Teknoloji yığınınızı mümkün olduğunca küçük tutun. Fazla tasarım yapmayın. Teknolojileri gerektiği gibi ekleyebilirsiniz, ancak bunları çıkarmak zordur. Ayrıca, ne kadar çok katmanınız varsa, geliştiricilerin bir şeyler yapması o kadar fazla iş demektir. Başından zorlaştırmayın.
  • Kullanıcıları doğrudan tasarım sürecine dahil edin, ancak bunu yapmalarına nasıl dikte etmelerine izin vermeyin. İyi tasarım ilkelerini izlerseniz onlara daha iyi istediklerini verebileceğinizi göstererek güvenlerini kazanın.
328
Michael Meadows

İki büyük rewrite katıldım. Birincisi küçük bir projeydi. İkincisi, bir yazılım şirketinin ana ürünüdür.

Birkaç tuzak var:

  • yeniden yazma işlemi her zaman beklenenden uzun sürer.
  • yeniden yazma işlemlerinin müşteri için doğrudan etkileri/faydaları yoktur.
  • yeniden yazmaya ayrılan kapasite müşteriyi desteklemek için kullanılmaz.
  • % 100 belgeleriniz yoksa yeniden yazma işlevini kaybedersiniz.

Yeniden yazma nadiren gerçek cevaptır. Hiçbir şeyi kaybetmeden ve çok fazla risk almadan kodun çoğunu yeniden düzenleyebilirsiniz.

Yeniden yazma aşağıdaki durumlarda cevap olabilir:

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

Ama yeniden düzenleme kullanarak yavaş yaklaşımı şiddetle tavsiye ediyorum. Daha az riskli ve müşterilerinizi mutlu ediyorsunuz.

112
Toon Krijthe

Şu durumlarda yeniden yazma zamanı:

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

Mevcut olanı korumayı daha pahalı hale getiren bazı faktörler:

  • Dil o kadar eski ki, programlamak için çok fazla para bilen insanlara ödeme yapmalısınız (COBOL).
  • (maalesef, sistem maalesef) Sistem o kadar eski bir donanım mimarisi üzerindedir ki, artık yapılmadıkları için Ebay ve COLLECT parçalarını çalıştırdığı makineye eklemek zorunda kalmaktadırlar. Buna "donanım ömrü desteği" denir ve pahalıdır çünkü parçalar daha kıt hale geldikçe, fiyat yükselebilir (veya kesinlikle) biter.
  • O kadar karmaşık bir hal aldı ki //Here be dragons. yorum kodunuzun her yerinde.
  • Her zaman bu çirkin canavarı yamaladığınız için başka proje yazamaz ve şirkete yeni değer katamazsınız.
74
Ryan Hayes

Projenin mimarisinde temel bir değişikliğe ihtiyacınız varsa, muhtemelen yeniden başlama zamanı.

Bununla bile, potansiyel olarak yeni projenizde tekrar kullanmaya değer büyük kod yığınları olacaktır.

Gerçi adil uyarıyı dikkate alın. Mevcut bir proje, iş kurallarını sıfırdan başlayan bir proje için doğru olmayacak olan sayısız adam saat gerçek kullanımla test edilmiş ve rafine edilmiş olacaktır.

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

17
Dan McGrath

Her ne kadar Kramii'nin cevabı ve Joel'in görüşü ile aynı fikirde olsam da, yeniden yazmanın uygun olduğu zamanlar var. Uzun ömürlü uygulamalarda (10-20 yıl veya daha fazla konuşuyorum), bakım zamanla daha pahalı hale gelir. Bunun nedeni, orijinal mimarinin hızlı bakım yamaları için feda edildiği için kodun giderek daha fazla spagetti-ish olmasıdır. 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ı üstünde çalıştırmak için yeni donanım, işletim sistemleri, çerçeveler vb. Bulmak zorlaşır. Ayrıca, işletmeler gelişir ve büyük olasılıkla daha eski bir sistem kuruluşun iş ihtiyaçlarını karşılamayacak ve yepyeni bir sistem olacaktır.

Bu nedenle, devam eden tüm bakım maliyetinin yanı sıra yeni bir sistemin işletmeye olan faydalarını sıfırdan yeniden yazma maliyetine karşı tartmak zorundasınız. Yeniden yazmanın maliyeti hakkındaki tahminlerinizde çok kötümser olun. Neredeyse her zaman daha pahalı ve düşündüğünüzden daha uzun sürüyor.

12
RationalGeek

Dur! Yeniden yazma neredeyse hiçbir zaman cevaptır. Çoğu zaman, yeniden düzenleme daha iyi bir bahistir.


Elbette, bir yeniden yazma doğrulandığında kez vardır:

  • Taşıma araçlarının mevcut olmadığı (veya yeterince ucuza yazılamadığı) yeni bir platforma geçiyorsunuz.
  • Yeniden yazılacak uygulama önemsizdir.
  • Orijinal uygulamanın kaynak kodu kaybolur ve kurtarma işlemi yeniden yazmaktan daha pahalıdır.
  • Mevcut başvurunun kapsadığı 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ı vardır.
  • Yeniden yazmayı üstlenecek kaynağa (zaman, yetenek ve araçlar) sahipsiniz.
  • Mevcut uygulama, yasal veya pratik nedenlerle üretim ortamında çalıştırılamaz.

Yeniden yazım üzerinde neden yeniden düzenleme yapılmasını önerdiğimi anlamak için, yeniden yazımda nelerin yer aldığını düşünün. Mecbursun:

  1. Mevcut uygulamanın ne yaptığının nüanslarını anlayın. Bu, kapsadığı tüm ince iş kurallarını, içinde çalıştığı ortamı (hem insan hem de teknik) ve mevcut çözümün avantajlarını ve dezavantajlarını dikkate aldığınızda genellikle önemsiz değildir. Daha sık olmamakla birlikte, bu bilgilerin var olduğu tek yer (eğer varsa) mevcut uygulamanın kaynak kodundadır. Bir yeniden yazma işleminin ana nedenlerinden birinin, mevcut kodun anlaşılması ve sürdürülmesinin zor olması talihsiz bir durumdur.

  2. Bu işlevselliği (veya güncelleştirilmiş sürümünü) sınanmış ve güvenilir olan yeni bir uygulamada yeniden oluşturun. Mevcut kod geliştiriciler tarafından anlaşılmayabilir, ancak kullanıcıları tarafından iyi anlaşılabilir. Mevcut iş ihtiyaçlarını karşılamayabilir, ancak en azından uygulamanın çeşitli koşullarda ne yaptığını size söyleyebilirler.

Yeniden düzenlemenin büyük avantajları:

  • Her seferinde küçük bir parça alabilirsin.
  • Herhangi bir değişiklik mevcut, çalışan uygulama bağlamında test edilebilir.
  • Mevcut kodun nasıl çalıştığına dair hipotezler küçük değişiklikler yapıp neler olduğunu gözlemleyerek test edilebilir.
  • Değişiklikler genellikle kullanıcılara aynı anda değil, aşamalar halinde gönderilebilir.
  • Yeniden düzenlemenin ilk aşamalarından öğrenmek, yeniden düzenlemenin sonraki aşamalarını bilgilendirebilir.
  • İşlemi kısmen terk ederseniz, daha temiz bir kod tabanı ( yerine tamamlanması gereken bir yeniden yazma yerine faydalar olacaktır kullanıcıya veya geliştiricilere herhangi bir avantaj sağlar).

Ayrıca, yeniden yazma yaparsanız, yeni kod tabanına birçok yeni hata ve karışıklık getireceğinizi unutmayın.

11
Kramii

Bu grafik yardımcı olabilir, bu uygulamanın kod taban kalitesi ve iş değerinin bir fonksiyonudur:

enter image description here

Grafik, eski yazılımların yeniden yapılandırılmasının ne zaman doğrulandığı ve ne zaman uygun olmadığı konusunda bir rehber gibi davranıyor. Örneğin, yazılımın iş değeri yüksekse ve kodun kalitesi düşükse, yeniden yapılandırma haklı çıkar.

10
Tulains Córdova

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

Şirket birleşmesi, sistem işlevselliğinde büyük çakışma. Birçok, birçok sistem birleştirildi ve emekliye ayrıldı ve diğerleri hala süreçte.

Hala devam eden diğer şirketten bir sistem miras aldım. Kendimize çok benzer, ancak tamamen farklı bir tasarım ve çerçevelere sahip birden fazla departmanı desteklemek için kullanılan büyük bir kod tabanına sahiptir. Kullanmak için sadece bir iş sektörü kaldı, bu da bu şeyi bir zombi durumunda canlı tutacak kadar para kazanıyor. Tüm eski uzmanlık gitti, hiçbir belge yok. Destek yükü yüksektir ve her hafta arızalanır. Şirket sistemlerimizle birleştirilmemiştir, çünkü şirketimiz bu iş sektörünü asla desteklememiştir, bu nedenle işlevsellik veya uzmanlığa sahip değiliz.

Bu yeniden yazmanın gerekli olduğu tek durum gibi görünüyor. Görünüşe göre, bu devi çözmek, bu işe adanmış işlevsellik parçalarını çıkarmak ve mevcut sistemlerimize 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 sefaletinden çıkarılabilir. Yoksa akıl sağlığımı kaybedeceğim.

8
Jay

Y2K'yı işlemek için yükseltilmiş, Windows 16 bitlik bir uygulama olarak yeniden yazılan ve daha sonra tamamen bir ek 'küçük' özellikli 32 bitlik bir uygulama olarak yeniden yazılan birkaç DOS uygulaması olan küçük bir yazılım şirketinde çalıştım (sonuçta yalnızca tüm müşteriyi etkiledi.

16 bit kodunu 32'ye taşımak bir ay içinde bir kişi tarafından yapılabilirdi, ama NOOOOOOOOO, bunu yapmak için yeniden yazmak zorunda kaldık, Soooooooooo çok daha iyi. Bu şey diğer endüstriler için uyarlanabilir, başlamadan önce tam teknik özelliklere ve psuedo koduna sahip olabilir. Teknik özellikler oluşturuldu, ancak gerçek kodu yazmak için zaman bile olmadığı çok uzun sürdü. Geç başladı, 16 bit 'başladı' dan daha fazla hata ile (v.3.0 ve nihayet birisi yeni bir hata bildirmeden neredeyse bir hafta yaptığımız noktaya).

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

Bu, teknik destek başkanı olarak ilk BT işimdi. Dağıtım için yazılım geliştirme konusunda bir kitap yazmalıyım. Açıkçası birçok hata yaptık, ancak başvuruları yeniden yazmaya devam etmemiz uygunsuzluğu artırdı.

7
JeffO

Seninkine çok benzeyen bir dava vardı, sadece kod Struts bile kullanmıyordu. Bunun yerine özellikle boktan ve bir çok soruna neden olan hedef alanlar oldu. Bu hedefli yaklaşım bizi kademeli olarak daha iyi hale getirdi.

2 yıllık bir süre boyunca geliştirme çalışmaları ile birlikte bitleri ve parçaları yeniden düzenleme üzerinde çalıştık. Her zaman bir proje planında 'Sertleştirme' görevi yaptık. İyi çalışmadı belirli alanlarda odaklanarak kova için en patlama var. Çalışan şeyler yalnız bıraktık. Ayrıca kritik olan, bu çalışmanın normal gelişim sırasında yapılması ve serbest bırakılmasıdır. Büyük bir yeniden yazma sorunu bir yıl veya daha fazla gitmek ve daha sonra geri geldiğiniz zaman her şey yine de değişti ve bazı kötü hatalar düzeltildi ve yatırım getirinizi kaybetti.

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

5
Bill Leeper

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

Bu asp programı gibi şeylerle doludur

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

Hafif bir değişiklik yapmamız gerekirse, kabus modunda aynı anda beş kal-toh oyunu oynamak gibidir.

İşlevselliği çoğaltmak ve sektördeki diğer kullanıcılar için özelleştirilebilir ve satılabilir olabilecek bir ürün yapmak için işe alındım. Sorun şu ki, bu şey her bir iş ihtiyacını karşılamak için son 10 yılda yazılmıştır (yine de bunlardan beş veya altı sigma olduğunu söyleyebilirim).

Ürünü satmak istemeseydik, muhtemelen istediklerinin çoğunu yaptığı gibi yeniden yazmaya ihtiyaç duymazlardı - belki de zarif değil, ama değildi Güzel kodu 'aynı şeyi' yapmak için harcamak için ihtiyatlı.

5
Incognito

Mevcut çözüm ölçeklenmiyor.

Sana bakıyorum, MS Access.

4
user21007

Joel Spolsky'nin bu konuda mükemmel bir makalesi var: Asla Yapmamanız Gereken Şeyler, Bölüm I

Söyleyebileceğiniz başlıktan, biraz taraflı (neden asla kod atmamanız gerektiğinden bahsediyor) IMO, çok fazla gerçek var, son zamanlarda bazı geliştiricilerin söylediği Excel'in 25. Yıldönümünde bir kanal9 videosu gördüm, nasıl Bugün bile kaynağa bakarsanız, revizyonu kontrol edersiniz ve Excel'in 20 yıl önce yazdığı koduna geri dönersiniz.

% 100 emin olamazsınız (Netscape bile hata yaptığında (Joels Makalesinden)), [~ # ~] i [~ # ~] Joel'in makalesi Tanrı'nın gönderildiğini hissettim, çünkü kötümser olabilirim ve her zaman ikinci kez daha iyi yazabileceğimi düşünerek kod atmayı sevebilirim, ama şimdi sadece bu lot .

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

Benim gerçek dünyam: Silverlight uygulaması Şimdiye kadar v0.6 geliştiriyorum kod çok kıvrımlı hale async aramaları karışıklık var. Reaktif Uzantılar bu hafta keşfettiğimden beri, kodun çoğunu gerçekten yeniden yazmak istiyorum, ama şimdi müşterime ne söyleyeceğim? Program mükemmel çalışıyor (bazı bellek sızıntıları tho ile) ama umursamıyorlar? Onlara 2-3 hafta daha sürdüğümü söyleyemem çünkü bir şeyleri tekrar yapmak istiyorum. Ancak, kodu şube ve yeniden yazma /onunla oynamak benim ücretsiz zaman.

Sadece 2 sentim tamam !?

4
gideon

"X'e gidersem buradan başlamazdım" konusunda klasik bir şaka var.

Bir kez iş buldum, işverenin asıl motivasyonu iş açısından kritik bir uygulamanın uzun süredir yeniden yazılması için yeteneği gemiye taşımaktı. Sormayı başaramadığım soru, ilk etapta neden bu duruma düştünüz? Sebep olup olmadığı kırmızı bir bayrak olmalıydı

  • canavarı korumak ve aşamalı olarak yeniden düzenlemek için işlevsellik eklemek için çok fazla baskı,

  • departmanda çok az yetenek,

  • artan çalışma için müşterilerden veya yönetimden çok az satın alma,

ya da her neyse, ve bu sorun dayanılmaz bir seviyeye gelene kadar iltihaplanıyor.

Bu yüzden Joel ile büyük bir yeniden yazmanın muhtemelen çok kötü bir fikir olduğu konusunda anlaşacağım - büyük bir yeniden yazımın neden bu kadar gerekli göründüğünün altında yatan tüm nedenlerin kesin bir kanıtı yoksa , sorunu zamanında tekrarlama olasılığınız yüksektir.

2
Julia Hayward

Yeniden yazma, kuruluşun rekabetçi bir Kenar sağlayan bir strateji izlemesine veya mevcut mimarinin uyum sağlayamayacağı bir şekilde müşterilerine daha iyi hizmet vermesine izin verdiği zaman cevaptır.

Bunun yerine, yeniden yazma işlemleri genellikle 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 destekleyecek kaynaklar bulamayacağız veya çok sık
  • on yıl oldu, zamanı geldi.

Bu endişelerin çoğu gerçekleşmeyecek ve eğer öyleyse ele alınabilecektir. 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. Biraz önleyici bakımın nasıl uzun bir yol kat ettiği hakkında ne söylediklerini biliyorsunuz. Bir yatırım olarak, rutin servis (yani yeniden düzenleme ve standartlaştırma) neredeyse her zaman bir yeniden yazma işleminden daha az maliyet taşır.

Ancak, sonunda bir yeniden yazmanın gerekli olacağını tahmin etmeliyiz. Tarihleri ​​belirleyin ve bunu geçici olarak planlayın, ancak tarih, aşağıdaki gibi zorlayıcı bir nedeniniz olana kadar diğer stratejik hedefleri gerçekleştirmek lehine daha fazla gecikme çektiğinden ...

Son yıllarda büyük hesaplar kazanma fırsatını kaybettik çünkü ihtiyaçlarını zamanında veya maliyetli bir şekilde karşılayamadık. Sistemimiz, özelleştirmelerin takılmasına izin veren (ve şu anda yaptığımız gibi kodlanmamış) genişletilebilir bir mimari kullanılarak yeniden yazılacaktır. Bu, özel ihtiyaçları olan müşterileri barındırmanı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.

2
Mario T. Lanza

Bence yeniden yazmayı haklı çıkarmanın temel nedeni platform değişiklikleri. Ö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ı istediğine karar verirse. Her zaman olmasa da, deneyimlerime göre, orijinal geliştiriciler çok modüler ve tekrar kullanılabilir kod yazmadıkça (pek olmazsa) çoğu zaman bu bir yeniden yazma gerektirir.

2
Craig

Joel'e göre, büyük yeniden yazma işlemleri bir şirketin yapabileceği en kötü stratejik hatadır :

Asla Yapmamanız Gereken Şeyler, Bölüm I

... Sıfırdan başladığınızda kesinlikle yaptığınızdan daha iyi bir iş yapacağınıza inanmak için hiçbir neden olmadığını hatırlamak önemlidir. ilk defa. Her şeyden önce, muhtemelen bir sürümde çalışan aynı programlama ekibine sahip değilsiniz, bu yüzden aslında "daha fazla deneyime" sahip değilsiniz. Eski hataların çoğunu tekrar yapacaksınız ve orijinal versiyonda olmayan bazı yeni problemleri tanıtacaksınız.

Eski mantra atmak için bir tane inşa edin büyük ölçekli ticari uygulamalara uygulandığında tehlikelidir. Kodu deneysel olarak yazıyorsanız, daha iyi bir algoritma düşündüğünüzde geçen hafta yazdığınız işlevi kopyalamak isteyebilirsiniz. Bu iyi. Kullanımı kolaylaştırmak için bir sınıfı yeniden düzenlemek isteyebilirsiniz. Bu da iyi. Ancak, tüm programı atmak tehlikeli bir aptallıktır ve eğer Netscape aslında yazılım endüstrisi deneyimiyle yetişkin gözetiminde olsaydı, kendilerini bu kadar kötü bir şekilde vurmamış olabilirler.

2
user3287

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 istemiyorsanız, kod herhangi bir yapıdan yoksundur (bazı PHP web sitesinde çok uzun zaman önce gördüm, yazar dahil/sınıf/fonksiyon yerine sadece kopyala/yapıştırılan spahgetti) ya da başka bir kişiden çok kötü yazılmış bir şeyi devraldınız.

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

2
Slawek

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

"Tamamen yeni": yeniden yazmayı planlıyorsanız ancak aynı platformu kullanmayı planlıyorsanız, yeniden düzenleme ve mantıklı yeniden yapılandırma neredeyse kesinlikle daha iyi bir çözümdür. Burada kullanılan şekliyle "Platform" biraz belirsizdir - dili ve belki de işletim sistemini (Linux'tan Windows'a uzanan veya tersi akla gelen) içerdiğini düşünün, ancak muhtemelen çerçeve değildir (örneğin, Struts'u Spring ile değiştirmek).

"İstenilen işlevselliği sağlamak için gerekli": 2000 civarında, büyük bir sunucu bileşenini yeniden yazmak için bir proje başlattım Java, O zamanlar, C++ için desteklememiz gereken çok sayıda iş parçacığı kütüphanesi vardı ve veritabanı kodumuzun büyük bir kısmının iş parçacığı etkinleştirmesi, toplamda yeniden yazmayı gerektiriyordu. ... eski mimari ile olmayacak.

O zaman bile, mevcut sistemin davranışı hakkında ayrıntılı bilgi sahibi olmam dışında yeniden yazmayı yapacağımdan emin değilim ve 11 yıllık yaşamında çok fazla siğil geliştirmeyen nispeten temiz bir koddu.

1
Anon

Ben sadece mevcut kod tabanını (bucky toplarının sıfır ağırlık ve hacme sahip olduğu varsayımsal durumlar) göz ardı edebileceğim varsayımsal senaryoları hayal edebiliyorum. sistemdeki düzeltmeleri ve sistemin bir o kadar önemsiz ve nefret ettiği bir yerde, her şeyi ve sunucu ordusunu on dakika içinde notepad ++ ve bir netbook ile değiştirebilir ve herkesin üretkenliğini ve ahlakını tahtada artırabilirim.)

Hemen hemen her gerçek dünya senaryosu için sadece yerinde yeniden düzenleme tavsiye ederim. ^ _ ^. Belgelenmemiş yasal ve iş gereklilikleri ortaya çıkmaya başladığında ve son dakika olayları birlikte kesmek son dakika başladığında yeniden yazmak için çok fazla gizli, beklenmedik maliyet söz konusudur.

== Daha iyi mallar için yerinde yeniden düzenleme ve daha fazlası ==

Eski kodu düzenli eski artımlı yaklaşımla yeniden düzenleme,

  1. UML'ye dönüştürme şansınız varsa ve ne kadar az bir mimari olduğunu belgeleyin.
  2. Sürüm denetimindeyseniz, bazı kod karmaşası raporları oluşturmaya ve hangi dosyaların ve dosya bölümlerinin en sık değiştirildiğini bulmaya bakın. Bunları bir yere not edin, çünkü muhtemelen ilk önce uğraşmak isteyeceğiniz alanlar olacaktır.
  3. Herhangi bir kodu değiştirmeden önce her zaman bir test kapsamı eklemeye çalışın (çirkin tam yığın fonksiyonel testler bile yapacaktır). Büyük dağınık yordamsal kod özü mantığı ile uğraşıyorsanız, makul olarak adlandırılmış bir yöntem veya işleve dönüşmeyi planlıyorsanız ve mümkünse yeni yönteminizi doğrulayan bazı test senaryoları ekleyin. ne olursa olsun tanrı berbat kesmek yapmak ve mümkünse değişikliği marjinal genişliği veya başlık gibi tweaked bir şey varsa, bu yüzden bir dahaki sefere güncellemek için biraz daha düz olacak değişiklik paramatize.
  4. Bağdaştırıcı desenini kullanın ve eski kodun kısık parçalarını mantıksal olarak adlandırılmış sınıflar ve yöntemler halısı altında saklamak için çalışın, böylece sizin ve diğer geliştiricilerin gerçekleştirdiğiniz en yaygın görevler için geride olan korkunç bitler hakkında endişelenmenize gerek kalmaz Arkanızdaki eski kodları gizlediğiniz güzel küçük temiz yöntemlerin ve sınıfların arkasındaki sırtınız - deforme olmuş katil zombi eski aile üyelerini ahırlarda tutan ve ailelerin günden güne bozulmaması için Çiftlik . . . normalde.
  5. Isınmaya ve temizlemeye devam ederken, kodun bölümleri test kapsamınızı artırmaya devam eder. Artık daha da derinlere inebilir ve gerektiğinde/istendiğinde daha fazla kodu daha fazla güvenle "yeniden yazabilirsiniz".
  6. Kod tabanınızı iyileştirmeye devam etmek için yineleyin veya ek yeniden düzenleme yaklaşımlarını uygulayın.

Soyutlama ile Dallanma

  1. Kaldırmak istediğiniz koddaki sorunlu noktayı tanımlayın (kalıcılık katmanı, pdf oluşturucu, fatura kayıt mekanizması, widget oluşturucu vb.).
  2. genel işlevselliğin yanı sıra bu işlevselliği hedefleyen kod tabanına karşı bazı işlevsel test senaryolarını (otomatik veya manuel ama otomatik olduğunu biliyorsunuz) çalıştırın (gerekirse yazın).
  3. Bu bileşenle ilgili mantığı varolan kaynak tabanından makul bir arabirime sahip bir sınıfa çıkarın.
  4. Tüm kodun şimdi daha önce kod boyunca rastgele dağıtılmış X etkinliğini gerçekleştirmek için yeni arabirimi kullandığını doğrulayın (kod tabanını açın, yeni sınıfa bir iz ekleyin ve çağırması gereken sayfaları doğrulayın, vb.) Ve tek bir dosyayı değiştirerek hangi uygulamanın kullanılacağını kontrol edebilirsiniz. (nesne kaydı, fabrika sınıfı, ne olursa olsun IActivityXClass = Settings.AcitivtyXImplementer ();)
  5. her şeyin hala çalıştığını doğrulayan işlevsel test senaryolarını yeni X sınıfınıza atanan tüm Etkinlik X'i yeniden çalıştırın.
  6. Mümkün olan yerlerde yeni etkinlik X sarmalayıcı sınıfı çevresinde birim testleri yazın.
  7. eski sınıfla aynı arabirime bağlı eski uygulamadan daha az çılgın spagetti mantığına sahip yeni bir sınıf uygulamak.
  8. yeni sınıfın eski sınıf için yazdığınız birim testlerini geçtiğini doğrulayın.
  9. eski sınıf yerine yeni sınıfı kullanmak için kayıt defterini/factorymethod/yöntemini değiştirerek kodunuzu güncelleyin.
  10. fonksiyonel testlerinizin hala geçtiğini doğrulayın.

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

Bir dereceye kadar sunum, iş ve kalıcılık katmanınızı ayırmak ve eski çözümle tamamen geriye dönük olarak uyumlu yeni bir uygulama yazmaktan veya en azından eski çözüm tarafından girilen verileri işleyebilir. Muhtemelen bu yaklaşımı tavsiye etmem ama bazen zaman/program/kaynaklar/gerekli yeni işlevsellik makul bir uzlaşmadır.

  • En azından sunum katmanını iş ve kalıcılık katmanlarından ayırın.
  • aynı ortak iş 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ünü bozmadığını doğrulayın. (yeni aracın kullanıcıları eski aracın kullanıcılarını kesintiye uğratırsa sıcak suda olacaksınız). Tam geriye dönük uyumluluk için çalışıyorsanız, her şeyi aynı kalıcılık katmanlarına kaydetmelisiniz. Sadece yeni araca uyumluluk sağlamak istiyorsanız, eski sistemde olmayan verileri izlemek için yeni bir veritabanı ve yeni tablolar veya uzantı tabloları kullanın.
  • Yeni işlevsellik ve kalıcılık katmanı ihtiyaçları için yeni tablolar ekleyin ve yöntemler varolan eski mantığı değiştirmez veya varolan tablolara sütun, kısıtlama eklemez. Örneğin. işverenlerin acil durum irtibat bilgilerini izlemeye başlamanız gerekiyorsa ve diğer bazı alanlar mevcut çalışan tablosunu değiştirmezse (eski verilerin bu tablo hakkında ne varsayımlarda bulunduğu hakkında hiçbir fikrimiz yoktur) bir uzantı tablosu ekleyin.
  • Kullanıcıları yavaşça yeni sisteme geçirin. mümkünse eski sistemi salt okunur moda geçirin veya kullanıcılara X tarihinden sonra kullanılamayacağını bildiren bazı uyarılar ekleyin.
  • yeni kullanıcı arayüzünde yüksek öncelikli cevapsız işlevsellik veya iş gereksinimlerini uygulayın
  • kullanıcılar tabanı üzerinden rulo.
  • iş mantığı ve kalıcılık katmanı kullanıcıları diğer yeniden düzenleme yöntemlerini temizlemeye devam eder.
0
Keith Brings

Refactor'da Rewrite uzayına karşı üçüncü bir kategori olduğunu söyleyebilirim ... Bu da dil sürümlerinizi, derleyicilerinizi ve kütüphanelerinizi güncelliyor ... Bazen sadece modern kodlama tekniklerini benimsemenin büyük bir yararı var.

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

Derleyicileri değiştirmek yeni yaşamı eski koda da götürebilir. İşlerin daha kolay çalışmasını ve uygulanmasını kolaylaştırabilecek yeni kütüphaneler de olabilir ... Ağ oluşturma, uygulama zorluğu yelpazesinin harika bir örneğidir.

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

Her zaman bir refactor vs yeniden yazma olmak zorunda değildir .. Mimariniz muhtemelen gelişmeye ihtiyaç duyuyor, ama işe yarıyor ... belki sadece kodunuzun nasıl yazıldığını düşünmeniz gerekir.

0
visc

Başlamanız gereken noktaya karar vermek için, mevcut projenizde devam etmenin değerinin baştan başlama değerinin altına düştüğünü bulmanız gerekir.

Bunun bu kadar zor olmasının nedeni, siz gerçekten başlamadan önce ekibin yeni proje üzerindeki gelişim hızını doğru bir şekilde tahmin etmenizdir. Bununla birlikte, yeni projedeki geliştirme hızınızın ÇOK muhafazakar bir tahminini kullanarak, projenin değerli bir yatırım getirisi sağlaması bekleniyorsa, yeniden başlamak için bir iş vakanız var demektir.

0
Nobody

Metrik ile, bir yeniden yazmayı haklı çıkarmak için iki koşulu yerine getirmelisiniz:

  1. Yeniden yazdıktan sonra yeni özelliklerin yazılması daha kolay/daha hızlı/daha az hata olacak
  2. Yeniden yazma, geçerli yeni özelliği eklemekten daha az veya eşit zaman alır.

O zaman bile yeniden yazımınızın kapsamını sınırlamak istiyorsunuz. Örneğin, C++ 'da modülerlik hakkında bilgi sahibi olmayan bir C programcısının zihniyeti ile yazılmış bir şirkette bazı eski yazılımlarımız vardı. Nihai sonuç, birden çok sınıfa ve DLL'e yayılan sonlu durum makinesi biçiminde speghetti koduydu. Kodda yer alan varsayımlardan çok farklı yeni bir gereksinimimiz vardı ve şirketin patentli katma değerli müşterilerinin bir parçası olacaktık.

Diğer özellikleri uygulayan kod ile zaman geçirdikten sonra, değiştirmek için gereken birkaç anahtar ifadelerinden hangisini bulmanın ne kadar zaman alacağı konusunda gerçekten iyi bir fikrim vardı. Benim önerim, kod bölümünü yeniden yazmaktı. büyük sonlu durum makinesi - mevcut kodu genişletmekten daha az zaman almalı. Bir DLL üç olan ne) birleştirmek ve daha kolay hale getirmek ile birlikte kritik yeni işlevsellik yapmak çok daha kolay hale getirecek çok daha nesne odaklı bir yapı sağlamak mümkün yeni işlevler ekleyin.

Yeniden yazılması gereken kütüphaneleri kullanan üç uygulama daha vardı, bu yüzden bu programları tamamen yeniden yazmak zorunda kalmadım. Kapsam, kütüphane ve kütüphaneyi mevcut yazılıma bağlamak için gerekli olanla sınırlıydı. Tahminlerim çok uzak değildi ve iş kendisi için ödedi. Yeniden tasarlandıktan kısa bir süre sonra, yeni bir özellik eklemekle görevlendirildim. Eski yapı ile beni bir hafta sürecek olan yeni yapı ile sadece bir günümü aldı.

0
Berin Loritsch

OP, projenin kapsamını belirtmez, ancak aldığım ana ipucu, bana "yeniden yazma işleminin temel itici güçleri olan" eski [dil] kullanarak eski [dil/lehçe] ile yazılmış "idi. Aslında, önemli bir pazar ömründe bulunduğum projelerin çoğu, derleyiciler/tercümanlar/işletim sistemleri için yapılan güncellemelerin kod tabanının korunmasında önemli bir görev olduğunu fark eder.

Kısacası, yeniden yazmayı planlıyorum, önce kütüphanelerde güncellemeye öncelik veriyorum. Yol boyunca, diğer optimizasyonlarda gizlice girebilirsiniz, ancak daha sonraki bir aşamada bazı değişiklikleri ertelemeyi planlamanız, programa bağlı kalmak ve "sıkışmak "tan kaçınmak için harika bir yol olabilir.

0
MarkHu