Yazılımın başarı / başarısızlık oranlarının yeniden yazılması ile ilgili herhangi bir gerçek vaka incelemesi var mı?

Uygulamaların yeniden yazılmasının kötü olduğu, insanların burada programcılarla ilgili deneyimleri ve bu konuda Joel Spolsky tarafından hazırladığım bir yazı olduğunu , ancak katı kanıtlar veya vaka çalışmaları ile ilgili çok sayıda yazı gördüm . Joel'in verdiği iki örnek ve burada başka bazı yazılar dışında, kötü bir kod temeli ile ne yaparsınız ve gerçek çalışmalara dayanarak ne yapacağınıza nasıl karar verirsiniz?

Söz konusu durum için, her ikisi de eski eski kodlara sahip olduğunu bildiğim iki müşteri var. İçlerinden ayrılmaya devam ediyorlar çünkü bir tanesinin yazdığı gibi, yeniden yazma bir felaketti, pahalıydı ve gerçekten kodu geliştirmek için çalışmadı. Bu müşterinin yeniden yazanlar hızlıca öğrendiği gibi çok karmaşık bir iş mantığı var.

Her iki durumda da, bunlar şirket için çok fazla gelir getiren önemli uygulamalardır. Yeniden yazma girişiminde bulunan kişi, eski yazılımın gelecekte bir noktada yükseltilmemesi durumunda bir tuğla duvara çarpacaklarını hissetti. Bana göre, bu tür bir risk, başarılı bir yol sağlamak için araştırma ve analiz yapılmasını garanti ediyor.

Bunu araştıran gerçek vaka çalışmaları oldu mu? Gerçek çalışmalara dayanan bazı en iyi uygulamaları, tuzakları ve başarıları bilmeden büyük bir yeniden yazma girişiminde bulunmak istemem.

Sonrasında: tamam, daha fazla arama yaptıktan sonra, vaka çalışmaları hakkında üç ilginç makale buldum:

1. Yeniden Yaz veya Yeniden Kullan . Java'ya dönüştürülmüş bir Cobol uygulaması üzerinde bir çalışma yaptılar.
2. Diğeri Yazılımın Yeniden Kullanımı idi: Geliştiricilerin Deneyimleri ve Algıları .
3. Yeniden Kullanma veya Yeniden Yazma Yeniden yazma ile karşılaştırıldığında bakım maliyetleri ile ilgili başka bir çalışma.

Geçenlerde konuyla ilgili başka bir makale buldum: The Great Rewrite . Orada yazarın bazı önemli meselelere çarptığı görülüyor. Bununla birlikte, önerilen yeni teknoloji yığını kullanarak prototip oluşturma ve cihazların ne kadar hızlı topladıklarını ölçme fikri de vardı. Bunların hepsi, yeniden yazmak için harika bir fikir olduğunu düşündüm.

Bu harika yorumlar için kredi alamam, ancak orijinal yazar tarafından hiçbir zaman bir cevaba girmediler, bu yüzden bunu topluluk wiki olarak işaretliyorum.

Örnek olay incelemeleri bilmiyorum ama bence bir yaklaşımın standart cevabı muhtemelen "birim testleri ve refactor ekle" dir.

Bu muhtemelen mümkün olan en düşük risk yaklaşımı olarak beni etkiliyor. Tabii ki, bunun doğru bir yaklaşım olduğundan emin olmak için yeterince ayrıntı bilmiyorum, ancak şu ana kadar bildiklerime dayanarak, çok daha iyi olması muhtemel olan bir şey bilmiyorum.

Birim testleri yaparlarsa (doğru şekilde - tüm gereksinimleri yakalarlarsa) yeniden yapılanmanın gerçek bir felaketle sonuçlanmasının bir yolunu bulmak zordur. Olabilecek en kötü şey, istediğiniz kadar hızlı ilerlemediğinizdir. Aynı zamanda, eğer kod tabanları sorudan daha iyi şekil alıyorsa, alınan rotadan bağımsız olarak ilerlemeyi sağlamak için ciddi çabaya ihtiyaç duyulması ihtimali oldukça iyidir.

Projelerin yeniden yazma projelerinin başarısızlık oranlarında genel olarak projelere göre anlamlı derecede farklı olmadığını ve en iyi bilgi için en son CHAOS raporuna başvuracağını varsaydım.

Bir süre önce Michael Feathers'ın Legacy Code ile Etkili Bir Şekilde Çalışmasını inceledim ve yazma testleri dahil (eskiden kodun ne olduğunu bilmediğiniz zamanlarda bile) gerçek dünyayı sürdürme pratiğine ilişkin iyi fikirler getirdiğini gördüm . ders yeniden düzenleme / yeniden yazma. Biraz tarihli ama Amazon'da çok derecelendirilmiş.

Tecrübeden bahsetmek ve başlangıçtan beri kurumsal yapıya sahip olmayan bir şirkette yaşamak, dürüstçe söylemek gerekirse, en büyük sorunun kapsamlı bir anlayış geliştirmek olduğunu söyleyebilirim.

Bir sistemin parçalara ayrılabileceği ve ayrı ayrı anlaşılabileceği fikri yanlış. Zamanın bir noktasında, tek bir birey veya birkaç kişi, bütün problemi bütünüyle kavramak zorunda kaldı. Bu problem bir dizi iş problemi ve onları yönlendiren teknolojiler ise; Şirketteki bir kişinin tüm sistemlerini bir felaket veya cevapsız bir gereklilik olmadan değiştirmenin mümkün olduğu bir seviyeye kadar anlaşması birkaç yıl sürebilir. Bu kesinlikle şirketimde Teknoloji Direktörlüğü görevini devraldığımda gerçekleşti. Kendim bir kodlayıcı olduğum gerçeği olmasaydı, kötü organize edilmiş, sıkı bir şekilde bağlanmış, sıkı bir şekilde bağlı mimarinin ve teknolojinin bütünleşmesinin tüm detaylarını yavaşça anlayamazdım. Küçük gizli ise, belgesiz gibi ayrıntılar"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" göz ardı edilirse sonuç felaket olabilir ve bunu bilmenin tek yolu yavaşça hepsini keşfetmek.

Birinden uçuş sırasında motoru bir uçakta değiştirmesi istenirse veya belirli bir ölümle karşılaşılırsa - bireye sensörleri, hidrolik sistemi, yakıt akışını nasıl yönlendireceğinizi bilmesi gereken uygun miktarda araç ve kaynak verildiğinde , asla dıştan veya kokpitten değiştirilmek veya manipüle edilmek üzere tasarlanmamış sistemleri yönetin. Bu, bir iş başvurusunu yeniden yazma olasılığının neye benzeyeceğidir. Uygulama genellikle birçok farklı teknoloji arasında iş dünyasına dökülür.

Sanırım öncelikli noktam, sistemin neredeyse tamamen karmaşıklığı içinde anlaşılması ve yeni sistemin düzgün bir şekilde "üretilmesi" ve sadece "yapılmaması" için tam anlamıyla anlaşılması gerekiyor.

Çerezler yapılır, yazılım (olmalı) tasarlanır.

Netscape gibi, yeniden yazmadan ölen birçok şirket örneği var . Twitter gibi büyük sıkıntı yaşamadan yeniden yazmadan kurtulan şirketler de var .

Ölçülmüş herhangi bir vaka incelemesi yoktur, çünkü yeniden yazmanın iş başarısına karşı yeniden yazmanın iş başarısına baktığınız bir kontrol deneyi yapmak mümkün değildir. Her uygulama farklı.

Yeniden yazmanın mantıklı olduğu bazı bariz durumlar ve olmadığı yerlerde birçok vaka vardır. Yeniden yazmanın sizin için bir anlamı olup olmadığını anlamak için küçük bir tarif hazırladım .

Bence bu yeniden yazmaların bugünlerde daha anlamlı olduğunu düşünüyorum çünkü Rails, Grails, AngularJS gibi istilacı çerçevelerin sürekli geliştirilmesinin omuzlarına hızlıca kodlanıyoruz. Düz js'den Angular'a geçmek istiyorsanız, bir yeniden yazma yapabileceğiniz tek şeydir. Hala tonlarca anlam ifade edebilir. Bir diy uygulamasını bir başkasıyla değiştiriyorsanız ( Joel Spolsky'nin makalesindeki tüm örnekler gibi ) muhtemelen delirmişsinizdir.

Eylem raporlarından sonra başka hiçbir önyargılı olmayan vaka incelemesi bulamayacaksınız - çoğu insan aynı işi en az iki kez yapmak için para ödeyemeyecek (çoğu kez bir yeniden yazma, bir kez yükseltme, en iyisi durum farklı ekipler tarafından birden fazla yeniden yazma / yükseltme olur).

Bulduğun örnek olay incelemesi Fujitsu tarafından yapılmış gibi görünüyor ve şaşırtıcı bir şekilde sonuç Fujitsu'nun araçlarını kullanmanın daha iyi olmasıydı.

Örgütsel bir bakış açısına göre, bir yeniden yazma, yalnızca yeniden yazılmış uygulama çalışmadığında veya proje tamamlanmadan önce proje iptal edildiğinde açıkça bir başarısızlıktır; aksi halde yeniden yazılmış sürümün yayınlanmasında gecikme süresinin olup olmadığını bilmek imkansızdır. çektiğiniz zararın sebebi ya da sadece tesadüfi olabilir. Tamamlanmadan iptal edilirse, genellikle toplam zaman ve kaynak israfı olarak kabul edilir. Bir yükseltme potansiyel olarak aynı soruna sahip olabilir, ancak artımlı olması aynı ölçekte olması muhtemel değildir (paranız için bir şeyler alırsınız).

Programlama açısından en iyi örnek, her ikisini de yapmaktır - yeniden yazarken art arda yükseltme, birbirlerini destekleme ve ilham verme. Farklı takımların yoksa, bu doğal olarak daha uzun sürecek.

Bunun, toplam bir yeniden yazmayı düşünmeniz gerektiğine dair kaba bir rehber olduğunu unutmayın - proje, kolaylıkla yapabileceğiniz kadar küçüktür veya orginizasyon, her ikisini de karşılayabilecek kadar büyüktür, çaba veya öğrenme maliyetini hesaba katar. değerli. Ayrıca, eğer yeniden yazma işlemi asla yeniden işleme başlamazsa, bunun birkaç şey anlamına gelebileceğini, ancak hepsinin eşit olması durumunda, muhtemelen tekrar yazma işleminin gereksiz olduğu anlamına geldiğini unutmayın.