Eski kod temeli için kalite standartlarının düşürülmesine nasıl karşı çıkılır? [kapalı]

Burada hayal edemediğiniz kötü kodlu büyük bir eski kod tabanımız var.

Şimdi bazı kalite standartlarını belirledik ve bunları tamamen yeni bir kod tabanında, ancak aynı zamanda eski kodlara dokunursanız yerine getirmek istiyoruz.

Ve bunları zaten binlerce ihlal eden Sonar (kod analiz aracı) ile zorluyoruz.

Şimdi tartışma bu mirası ihlalleri azaltmak için geldi. Çünkü bu miras.

Tartışma, okunabilirlik kuralları hakkındadır. Mesela kaç tane iç içe geçmiş ifs için olabilir.

Şimdi kodlama kalitemizi eski kodlara düşürmemize nasıl karşı çıkabilirim?

Kod sadece bir amaç için bir araçtır. Bunun sonu değişebilir, ama tipik olarak kâr.

Kar ise; daha sonra başarılı bir şekilde tartışmak istediğiniz her şeyi karı artıracağını - örneğin satışları artırarak, bakım maliyetlerini azaltarak, geliştirme maliyetlerini azaltarak, ücretleri azaltarak, yeniden eğitme maliyetlerini azaltarak vb. karı artırmak; O zaman çoğunlukla sadece tuvalete para atmanın eğlenceli bir yolu olacağını söylüyorsunuz.

Ben, ben ve ben, hem üretici hem de eski kuralların koruyucusuyuz. Eğer aracınız "binlerce ihlal" yaratıyorsa (veya bu konuda yüzlerce kişi bile varsa), aracı unutun, bu durum için geçerli değildir ...

Orijinal geliştiricilerin uzun zaman önce gittiğini ve tartışma için uygun olmadığını düşünüyorum. Bu yüzden etrafta kim olduğunu ve tasarım ve kodlama stilini nereden bilen yok. Yüzlerce veya binlerce ihlalin düzeltilmesi burada ve oradaki birkaç kod satırının yeniden yazılmasıyla ilgili değildir. Bunun yerine, şüphesiz ki yeniden yapılandırma / yeniden fonksiyonel ayrıştırma gerektirir. Bunu, mevcut tasarımını tam olarak anlamadan, varolan herhangi bir büyük kod tabanına yapmayı denersiniz ve yepyeni bir hata / sorun / vb. Seti ortaya koymak zorundasınız. Sadece yeni bir solucan kutusundan, şimdi sahip olduğunuzdan daha da kötü (veya aletinizin şimdi sahip olduğunuzu düşündüğü <<'den daha kötü).

“Binlerce ihlali” ele almak için tek mantıklı yaklaşım sıfırdan yeniden yazmak olacaktır. Uzun ve pahalı bir çaba ve yönetime satmak neredeyse imkansız. Ve bu durumda muhtemelen haklılar ...

Eski kod genellikle sadece tweaks gerektirir. Y2K için olduğu gibi, ya da hisse senetleri 256'sından ondalık basamağa geçtiğinde. İkisinden de bir sürü yaptım. Ve diğer pek çok benzer şey. Bazen kötü stil, kötü işlevsel ayrışma, kötü vb. "Okuyabileceğiniz" ve değiştirilmesi gereken yerlerin koleksiyonunu bulabileceğiniz tipik olarak oldukça "belirleyicidir". Ve sonra, “bu yerler arasında” olan, yani, daha yüksek seviyeli akış olan, sizin için gizemli kalabilir. Sadece değiştirdiğiniz yerelleştirilmiş işlevselliği anladığınızdan emin olun ve ardından herhangi bir yan etkiyi test etmek, test etmek, test etmek, vb., Yerelleştirilmiş bilginiz tahmin edemez.

Böyle bir kodda yolunuzu göremiyorsanız, eski kodu korumak için en iyi kişi olmayabilir. Bazı insanlar boş bir ekrandan başlayabilir ve güzel programlar yazabilir, ancak başkalarının kodlarından oluşan büyük bir kod tabanı ile başlayamaz ve sürdüremez. Diğer insanlar kodu koruyabilir, ancak sıfırdan başlayamaz. Bazıları ikisini de yapabilir. Doğru kişilerin eski kodunuzu koruduğundan emin olun.

Eski kod üssünüzü sıfırdan yeniden tasarlamak ve yeniden yazmak isteyebileceğiniz zamanlar, işletme (veya diğer) gereksinimlerinin pantolonun oturduğu koltuğun "çırpması" nın artık değişen gereklilikleri karşılayamayacağı ölçüde değişmesidir. . Ve bu noktada, tüm paydaşların yerlerinde olduğundan emin olarak, ilk önce yeni bir işlevsel gereksinimler belgesi yazarak başlayabilirsiniz. Temel olarak tamamen yeni bir oyun adı.

Yapılması gereken tek ve tek >> yanlış şey, eski kod bakımını yeni bir geliştirme için yaptığınız gibi ele almayı denemek. Ve bu yanlış bir şey tam olarak inmek istediğiniz yol gibi görünüyor :) Bunun için söz ver, yapmak istediğin bu değil.

Soru, bu kodun ne kadar iyi ya da kötü olduğu değildir. Sorun, ne kadar yatırımdan ne kadar fayda sağladığınızdır.

Yani beğenmediği binlerce şeyi bulan bir aracın var. Aracın sonuçlarını gözardı etme veya binlerce şeyi değiştirmek için işe yatırım yapma seçeneğiniz vardır. Çok fazla şey var. İnsanlar değişiklik yaparken değil, gözden geçirirken de odaklanmayacaklar ve bu doğru bir şekilde test edilmeyecek çünkü her değişikliğin nasıl test edileceğini (veya sadece denemeyi) anlamaya çalışmak zaman alıyor, bu yüzden hatalar olacak. Böylece, bu hataları bulana ve düzeltene kadar, genel olumsuz sonuçlarla çok fazla zaman ve para yatırdınız.

Öte yandan, araçlar sadece “sevmedikleri” değil aynı zamanda böcek veya potansiyel böceklerdir. Eski kod hala geniş kullanımdaysa, doğru araç aslında hataları bulabilir. Dolayısıyla derleyici uyarılarını birer birer açmak, yararlı olup olmadıklarını kontrol etmek (hepsi yararlı değil) ve bu uyarıları düzeltmek faydalı olabilir.

Kırılmadıysa tamir etmeyin

Bu hemen hemen unutmamak için her yazılım geliştiricisine ve yöneticisine dövülmeli.

Evet, tüm modern kodlama kurallarını ihlal ediyor. Evet, FORTRAN-77’de C’de bir sarmalayıcı ile yazılmıştır, böylece Python’dan çağrılabilir. Evet, bunlar yapılandırılmamış GOTO'lar. Evet, üç bin satırlık bir rutin var. Evet, değişken isimleri yalnızca bir Hırvatça anlamlıdır. vesaire vesaire.

Ancak, on yıldan uzun bir süredir öfkeyle test edilmiş ve geçmişse, onu rahat bırakın! Gerekli değişiklik küçükse, mümkün olduğu kadar küçük ve mümkün olduğu kadar yerel tutun. Başka bir şey, düzeltilmesi gerekmeyen bir şeyi kırma riskini artırır.

Tabii ki, bazen bunun gerçekten sürdürülemez bir tokatlama olduğunu ve “küçük” değişiklik yapmanın tek yolunun sıfırdan yeniden yazmak olduğunu görüyorsunuz. Bu durumda, değişiklik isteyen kimseye geri dönüp ona ne kadara mal olacağını söylemelisiniz (yeniden yazma için hem dolar hem de adam-saatlerinde ve kaçınılmaz yeni hatalar için kan ter ve gözyaşlarında).

Uzun zaman önce Digital'in disk sürücülerinden birinin arızalarında bir döküntü vardı. Ne kadarını hatırlıyorlardı ve hepsini yerine koyuyorlardı. Anlaşılan, HDA'nın içinde bir filtreyi tutan bir tutkal bloğu vardı. Mühendislik tezahürü "parametrik olarak belirtilmemiş, HİÇBİR YEDEK KABUL EDİLEMEBİLİR" tutkalından bahsetti. Fasulye-sayaç, başka bir yapıştırıcı tedarik ederek disk başına bir kuruşun altında “kurtarıldı”. HDA içinde bir kaç yıl çalıştıktan sonra sürücüyü öldüren bir buhar verdi. Onarıncaya kadar kırılmadı. Kuşkusuz "sadece küçük bir değişiklikti ..."

Eski kodun kalite seviyesini düşürmenin kesinlikle bir anlamı yoktur. Ayrıca derhal uyarıları düzeltmeye gerek yoktur. Projenizin her bir bileşenindeki tüm "yeni" değişikliklerin yüksek kalite standardını takip etmesini sağlayın. Yani hiçbir taahhüt, uyarı sayısını asla arttırmamalıdır.

Bu tek tip ve ölü basit bir yaklaşımdır.

Eski eski kodun olduğu gibi çalışmasını sağlar (çünkü üzerinde hiçbir gereksiz değişiklik yapılmaz). Yeni kodun yüksek kalitede olmasını sağlar. Ek bir maliyet yoktur.

Risk kontrolü….

• Eski kod kod tabanındaki kod, en azından yazılımın gerçek kullanım ömrü ile test edilmiştir.
• Eski kod kod tabanındaki kodun otomatik birim testleri tarafından kapsanması pek olası değildir.
• Bu nedenle, eski eski kod tabanında soğukta herhangi bir değişiklik yapılması yüksek risklidir.

Maliyet….

• Kod yazarken, kodun bir kod denetleyicisini geçmesi ucuzdur
• Bunu daha sonraki bir durumda yapmak çok daha maliyetlidir

Yarar

• Kodlama standartlarına uymanın daha iyi bir kod tasarımına yol açacağını umarsınız.

• Ancak, kodlama standart bir kontrol aracından sadece uyarıları kaldırmak için kodunu değiştirmek için bir hafta boyunca harcama yapan birisinin kodun tasarımında bir iyileşme ile sonuçlanması pek olası değildir.

• Basit kod daha açıktır ve karmaşık kod, onu anlamayan biri tarafından kısa yöntemlere bölünmediği sürece anlaşılması daha kolay olur .

Tavsiye….

• Bir kod bölümünün içinde çok fazla hata olduğu gösteriliyorsa veya ek işlevler eklemek için çok fazla değişiklik yapılması gerekiyorsa, zamanının% 100'ünü ne yaptığını anlamak için harcarsınız.
• Ayrıca, onlara kanıtlanmış bir gereksiniminiz olduğundan, kodun bu bölümüne iyi bir birim testi eklemek için zaman harcayın.
• Daha sonra, kodu yeniden düzenlemeyi düşünebilirsiniz (şimdi anlıyorsunuzdur), böylece yeni kod kontrolünü de geçti.

Şahsen deneyim….

• Programcı olarak çalıştığım diğer 20 yıl boyunca, tüm çıktıları yeni bir kodlama standardı denetleyicisinden çıkarmak için yaşça büyük ölçüde değiştirmenin, kendisine talimat verilen müteahhitlerin gelirlerini arttırmanın dışında bir faydası olmadığı hiç bir zaman görmedim.
• Aynı şekilde, eski kodun yeni kodlama standardı gibi görünmesini gerektiren kod incelemelerini (TickIt / ISO 9001 yanlış yapıldı) geçmek için eski kodun yapılması gerektiğinde.
• Kodlama standart kontrol araçlarının yeni kod üzerinde kullanılmasının devam eden maliyetleri düşürerek büyük faydalar sağladığı birçok durum gördüm.
• Bir şirketin, bir üründe kullanılan çok sayıda müşteriyle birlikte kullanılan eski kodun korunma maliyetinde başarısız olduğunu hiç görmedim.
• Şirketin piyasaya çok yavaş girerek müşterilerden gelir elde edemediği için başarısız olduğunu gördüm.

Aracın eşiklerini düşürme konusundaki tartışma mı? ... ya da yanlış anladım. Kafa karıştırıcı bir şekilde yazılmış. Değilse, lütfen cevabımı atın.

IMHO, aletin duyarlılığını azaltmak iyi bir fikirdir. Niye ya? Çünkü en kıllı kod parçalarını vurgulayacaktır. Alternatif, binlerce ihlalden oluşan raporlar üretmektir, büyüklüğü itibariyle işe yaramaz hale gelir.

... bunun dışında, bununla ilgili insanlarla konuşun ve nedenlerini de duyun.

Eski kodu yeni temiz koddan ayırmaya çalışırdım. Örneğin Eclipse'de bunu birbirlerini kullanan farklı projelere koyarak yapabilirsiniz. 'temiz' projesi ve 'eski' projesi .

Bu şekilde her iki projeyi de sonarda farklı kalite standartlarında analiz edebilirsiniz. Standartlar sadece kuralların önemi bakımından farklılık göstermelidir. Kuralların kendisi aynı olmalıdır. Bu şekilde “eski” projede “temiz” projenin standartlarını karşılamak için neyin “düzeltilmesi” gerektiğini görebilirsiniz .

Bazı eski kodları daha yüksek standartlara yükseltmeyi başardığınızda, onu 'temiz' projeye taşıyabilirsiniz.

Her gün yaptığınız işte zaman kaybettiğiniz için dokunduğunuz her sınıfı 'temiz' proje standartlarına yükseltmeyi başaramazsınız. Ancak, her dokunduğunuzda eski kodu biraz geliştirmeye çalışarak oraya küçük adımlarla ulaşmaya çalışmalısınız.