Bir uygulamanın kötü bir kod temeli üzerine inşa edildiğini nasıl ispat edersiniz?

Şu anda daha önce işimde çalışan bazı geliştiriciler tarafından oluşturulan bir sistemi inceliyorum. Sistem, kullanıcının bakış açısından oldukça iyi çalışıyor, ancak kod incelemesine geçerken çok karışık bir durum. Kullanımın yüksek artışlarına rağmen, uygulamanın oluşturulma şeklinin gelecekteki güncellemeler için geçerli olmayacağına ikna oldum.

Sorun şu ki, ne kadar kötü olduğunu bildiğimden ama üstlerim bilmiyor. Yöneticime ispat edebilirim, böylece sorunu gerçekten görüyor ve mevcut kod tabanında minimum triyaj yapmaya ikna edilebilir ve yakın gelecekte uygulamanın bir sonraki sürümü için yeni bir geliştirme çizgisine başlayabilir?

'Ama şimdi çalışıyor', yazılım mühendislerinin meşru hayal kırıklıklarına verilen standart yönetim yanıtıdır. Yapacağım ilk şey, belgeleri (varsa) derlemek ve kod ile belgeler arasındaki çelişkileri göstermek için kullanmaktı.

Yapabiliyorsanız, kapsamlı bir birim test paketi hazırlayın. Bunları her değişiklikle çalıştırın, böylece mevcut kod tabanında suçlanabilecek gerilemeleri belgeleyebilirsiniz.

Son olarak, bir geliştiriciyi işine güvendiğiniz başka bir departmandan çekebilirseniz, kodun üzerine ikinci bir çift göz atın. 'Bu saçmalık' diyen bir geliştiricinin görevden alınması kolaydır, bir süredir etrafta olan üst düzey bir geliştiricinin kendisi için kefil olup, 'Hayır, Jim, haklıdır. Bu boktan bir krakerin saçmalıkları. '

Tabii ki, hepsi ortamınıza, şirket büyüklüğünüze vb. Bağlıdır.

Eğer okumadıysanız, Pragmatik Programcı'ya her zaman bir göz atmanızı öneririm . Sadece her yazılım uzmanı için okumaya ihtiyaç duyulmamalı, aynı zamanda yazılım mühendisliğini bir zanaat olarak görmeyen yönetim, meslektaşlar, kullanıcılar vb.

Yönetim açısından bakıldığında, sistemde yanlış olan bir şey yok ve sadece şikayet ediyorsunuz çünkü [sadece yeniden yazmak istiyorsunuz / önceki mühendislerin ne yaptığını anlamadınız / işinizin kolay olmasını istiyorsanız]. Biraz saman adam, ama tepedeki biri şu anda işlerin iyi yürüdüğünü gördüğünde, yaptığınız bir krizi görmekten kaçınırlar (eminim orada bir yerde bir iklim değişikliği alegorisi var ...) .

Bir dereceye kadar, bir noktaya sahipler. Yönetim, sürümler orijinal tahmininin çok ötesine geçtiğinde sorunları görüyor, tahminler yapılan iş için çok yüksek görünüyor, "bu bizim mevcut kod tabanımızla mümkün değil" ve QA'dan geçen hataların yüksek oranda görülüyor. İşler güzelce sarılıyorsa, kafanıza dokunmak ve elinizden gelenin en iyisini yapmanızı söylemek kolaydır, çünkü bu durum alt çizgiyi etkilemez.

Ne yapacağınız, kuruluşunuza ve yazılımın kendisine bağlıdır. Temel olarak, yine de, kötü eski kuralların bir sonucu olarak ortaya çıkan her komplikasyonun belgelenmesini öneririm. Görevleri tahmin ederken, eski kod tabanının hangi yönlerinin bu ek maliyeti eklediğine dair ayrıntılı açıklamalar ile neden bu kadar uzun süreceğini düşündüğünüzü açık bir şekilde belirtin. Hatalar koda girildiğinde, bu hatanın neden kaymaya başladığının nedenlerini ve eski kod tabanındaki sorunların nasıl sorumlu olduğunu dahil edin.

Endişelerinizi paydaşlara, yazılımın orijinal tasarımını geçtiğini ve şimdi de geliştirmeye devam etmekte sorun yaşayacağını önerecek şekilde ifade etmenizi öneririm.

Kod kapsamı ve kod incelemesi yapabilen çeşitli araçlar vardır. Teknolojinize uygun Google araçları, bunlar normalde endüstri standardı araçlardır. Bu araçları kullanmanızı ve kod kalitesi raporunu bulmanızı ve Yöneticiye sunmanızı öneririm. Eleştirinizin yapıcı ve politik olmadığından emin olun.

Yönetimin basit bir değişim talebi olduğunu düşündüğü yeri anlaması kolay bir örnek seçin, ancak mevcut tasarım nedeniyle bu çok daha zor.

Özel istekleri yerine getirmelerini istemiyorsunuz, ancak HERHANGİ bir değişiklik talebinin nasıl olacağını bilmelerini sağladığınızdan emin olun. Kimse bir uygulama ile köşeye boyanmak istemez. Geliştiriciler YAGNI'ye inanıyor, ancak yönetim CYA'ya inanıyor.

Yük testi için öneriler iyi bir yaklaşım olabilir, ancak artan kullanım endişelerinin herhangi bir gerçek dünya büyüme potansiyelini karşıladığına ikna olmayabilirler (Şirket bir yılda iki katına çıkmayacak).

Her şey görecelidir. Vaktinizi harcayabileceğiniz daha önemli projeler için planları olduğunda kaynakları bu projeye koymak istemeyebilirler. Büyük resmi görmemiş olarak etiketlenmeyin.

Bir şeyi kanıtlamak hakkında konuştuğunuzda, tüm bu bilimsel yöntem olayları devreye giriyor ve bunun ne anlama geldiğinin bir kısmı, doğru olanın kararlaştırılmasının nesnel standartlarını kabul edecekseniz, soruşturma üzerine, sinir bozucu gerçeklerin olasılığını kabul etmelisiniz. senin yanında olmadığın ortaya çıktı.

Senin durumunda, kanıtlanması gereken 2 şey olduğunu düşünüyorum.

İlk olarak, geçerli kod temeli "kötü" dür. Muhtemelen kanıtlayabileceğiniz şey, "bu kodu inceleyen hemen hemen tüm geliştiricilerin profesyonel görüşü kötüdür" dür.

İkincisi, şirketin kod tabanını yeniden yazmaktan daha iyi olacağı. Bu bir sorun çünkü ilk nokta doğru olsa bile, ikinci olmayabilir. Ayrıca, bu belirlemeyi yapacak kadar bilginiz yok. Bu, yönetimin işidir ve birinci nokta hakkındaki profesyonel yargınıza saygı duymalarını istiyorsanız, ikincisi ile ilgili olanlara saygı göstermelisiniz.

Ancak verdiğiniz bilgiler olmadan ikinci nokta hakkında karar veremezler. Koddaki sorunların işletmeyi nasıl etkileyeceği ve yeniden yazmanın işletmeyi nasıl etkileyeceği hakkında bildiklerinizi bildirmeniz gerekir. Bu zordur, çünkü ikisi de belirsizliği olan bir geleceği tahmin etmeyi içerir.

Ancak sorunu ticari açıdan belirtmeye çalışabilirsiniz. Değişiklik ve gerileme için ne kadar zaman harcanıyor? Yeniden yazma maliyeti ne olur? Yeniden yazılmamışsa, mevcut sistemin maliyetleri zaman içinde ne kadar hızlı artacaktır? Peki ya kullanımda bir artış varsa, mevcut kod tutulursa bir felaket şansı nedir? Bunların hiçbirini gerçekten bilemezsiniz, ancak diğerlerinden daha iyi bir tahmin verebilirsiniz. Bunları ne kadar doğru tahmin edebileceğinizi düşündüğünüzü iletmek için bir aralık veya bir şey verin.

Çoğu geliştirici berbat kodu korumayı sevmez. Bu nedenle, geliştirici bakış açısıyla yeniden yazmak için akıllı olmayan bir kodun, işletme perspektifinden yeniden yazmaya değmeyeceği durum ne yazık ki olabilir.

Örneğin, yeniden yazma karlı olsa bile, parayı şirketin başka bir yerinde geçirmenin fırsat maliyetinden daha düşük olabilir. Veya kötü kod tabanının değiştirilmesi ve daha fazla gerileme olması daha uzun sürebilir, ancak yeniden yazma işlemini karlı hale getirmek için yeterli olmayabilir. Önümüzdeki birkaç ay içinde satın alınmayı düşünüyor olabilirler ve bir tekrar yazmaya para harcamak kitaplarda görünecek, ancak buggy yazılımı başaramayacak.

İş perspektifinden düşünmeye çalışın ve istediğinizi elde etmek için sayıları pişirmeyin. Büyük bir yeniden yazma neredeyse hiç bir zaman iş dünyasından bir fikir sahibi değildir. Doğrudan kanıtlanamayan bir şeyi ispatlamak istiyorsanız, bunu ispatlamak için elinizden geleni yapın. Eğer bir yol ile gelip için elinizden geleni denemeye devam ederse değil sıfırdan ama yoktan yeniden yazmak için belki, markaları duygusu ile gelip sonra gerçekten sıfırdan yeniden yazmak için zamanı. Ve bu çabayı göstermek, kendinize değil (kendinizin değil, şirketin çıkarlarını temsil ediyorsunuz, değil mi?) Şirketinizin çıkarlarını temsil etme konusunda ciddi olduğunuzu gösterecektir.

Sanırım kod tabanı ile ilgili neyin kötü olduğuna bağlı. "Benim yaptığım gibi olmaz" olmak, kötü bir kod tabanı olduğu anlamına gelmez.

Aslında kötü bir kod tabanı yapan şeyler:

• Güvenlik açıkları

  Sunucuyu, uygulamayı ve / veya verileri savunmasız bırakan sorunlar. Özellikle hassas şirket, müşteri veya müşteri verilerini risk altında bırakan herhangi bir şey. Bunların belgelenmesi kolay olmalıdır.

• Kırık Çalışma

  Çalışıyor, çünkü verilere masaj yapıyorsunuz ve çalışmaya devam etmesi için uygulama üzerinde neredeyse sürekli çalışıyorsunuz. Gidecek olursan ve kimse durmazsa, artık işe yaramayacaktı. - Bunu yapmak için ne kadar zaman harcadığınızı belgeleyin. Ve ne kadar tasarruf edebileceğinizi unutmayın. Oldukça sık bu işlemler kullanıcılar için de yetersizdir ve siz de bunu belgeleyebilirsiniz.

• Aslında çalışmıyor

  İşe benziyor ancak sonuçlar yanlış. Bu genellikle, çizginin aşağısındaki sayıların eşleşmemesi, yüksek hata oranı vb. Gibi sorunlara neden olur.

Kötü kod temeli değil (sadece iyi değil):

• Eski desteklenmeyen teknoloji üzerine yazılmış. (VB6, COBOL, .net1.1 Vb.)

Yeni bir teknolojiye geçmenin avantajlarına dikkat edin. Riski en aza indirebilmeniz ve kullanıcı ve yönetim güvenini oluşturabilmeniz için parçaları tek tek hareket ettiren bir geçiş yolu bulmaya çalışın. Mantığın temelde orijinalle aynı olduğundan emin olun.

• Belgelenmemiş / kötü biçimlendirilmiş kod

Bu, sizin için düzeltmesi en kolay olanıdır çünkü genellikle yorum ekleyebilir ve biçimlendirmeyi düzelterek kodu gerçekten etkileyerek düzeltebilirsiniz. Ancak yeniden yazma gerektirmez. Bunun diğer sorunlarla birleştirildiğini düşünüyorsanız, yapılacak ilk şey bunu düzeltmektir, böylece kodun uygulanabilirliğini daha iyi değerlendirebilirsiniz.

Bir şekilde kendi sorunuzu cevapladınız.

Onları sisteme para harcamaya ikna etmenin yolu, kullanıcı için iyi çalışmaz hale gelene kadar beklemektir. Ölçeklemeyeceğini düşünüyorsanız, bunun olmasını bekleyin veya kanıtlamak için bir yük testi yapın.

Bu daha sonra basit bir temizlik önerisi, ölçeklendirmek X saate mal olacak.

Bu zor bir durum çünkü kullanıcının bakış açısından her şey artık kabul edilebilir ve istikrarlı bir noktada. Öncelikle teknik olmayan yöneticilerle, şu anda endişelenecek bir şey yok, ancak kod tabanının yeniden yazılmasını istemek muazzam bir karar, özellikle de bekar bir erkeğin (kendin) fikrinde ve çabalarında hafifçe alınmaması gereken bir karar. .

Bu yüzden, zorlu teknik borç nedeniyle yeniden yazmak için dava açmaya çalışıyorsunuz (sizce, bizim için hiçbir örneğimiz yok ve bunun için sözünüzü almak zorundayız) ve en zor durumdasınız. bu sisteme özellikler ekleme ve ekleme zorluğu yaşamaktadır.

Yeni özelliklere ilişkin tahminleriniz yüksek olacak, bu yüksek rakamları gerçeklerle doğrulayın, bu şeylerin gerçekten çok zaman alacağını kanıtlayın. Bunu doğru bir şekilde iletmezseniz, yöneticiniz yetersiz olduğunuzu varsayabilir ve kesinlikle bunu istemezsiniz. Yüksek tahminleri sorgularken, biriken teknik borcun neden mevcut yazılıma hızlı ve ucuz bir şekilde özellikler ekleyebilme yeteneğini engellediğini düşündüğünüzü açıklayın. Yöneticinizde birlikte sürmek için iki beyin hücresi varsa, çok hızlı bir şekilde anlamaya başlayacaktır.

Mesele şu ki, yöneticinizi ikna etmeye çalışmamalısınız, ancak müdürünüzü, yeniden yazmanın kabul edilebilir bir kurs olduğuna ikna edebileceği uygun (ve dikkatlice seçilmiş) bilgilerle yönlendirin . Yöneticiye başından beri onun fikri olduğunu düşünmesini sağlamalısın.

Öncelikle kod tabanınızdaki birikmiş teknik borcu belirleyin. Ardından , devam etmeden önce yönetimi teknik borcu ödemeye nasıl ikna edeceğinizin açıklandığı bu soruya ve cevaplara bir göz atın .

Bütün olgun yazılımların karışıklık gibi görünmesinin bir nedeni var :

1. Bütün bu karışıklık, işletmenin güvendiği kritik mantığı kodluyor. Onsuz hiçbir şey işe yaramaz. Her sorunu kullanıcı problemini çözmek için gerekliydi.
2. Biraz modası geçmiş bir teknoloji kullanıyor. Mevcut programcılar, bazı şablon sihirlerini kullanmazlarsa, bunun sadece bir karışıklık olduğunu düşünüyor gibi görünüyor. Bu bozuk bir manzara. Tüm detayları öğrenirken daha büyük bir projeye geç gelen herkes bu aşamada olacaktır.
3. Bir süre önce kritik olan gereksinimler artık o kadar kritik değil. Bunun nedeni, yazılımın zaten bu sorunları çözmesidir. Projeye geç geliyorsa, yazılım iyi bir neden olmadan karmaşık görünüyor - sorun artık yok, ancak koddaki karmaşıklık hala var.