Teknik borçla ilgili bu yazının aşağıdakiler de dahil olmak üzere bazı iyi noktaları vardır:

"Teknik meseleler" üzerinde çalışmak, hikayeler tarafından yönlendirildiğinde en iyi sonucu verir. Kod tabanının muhtemelen her yerde çalışmaya ihtiyacı vardır, ancak ödeme yalnızca kodun kullanıcının karşılaştığı nedenlerden dolayı çalışılacağı durumlarda alınacaktır. Herhangi bir küfür alanından hiçbir hikaye geçmeyecekse, üzerinde çalışmak büyük oranda israf olur.

Bu nedenle, her zamanki gibi öykü almayı (ancak muhtemelen daha azını) ve kampı bulduğunuzdan daha iyi terk etmenin “izci kuralını” izlemeyi tercih ediyorum. Başka bir deyişle, hikayeler bizi nereye götürürse götürsün, daha çok test yazalım, yeniden daha agresif bir şekilde yeniden düşünelim.

Bu yaklaşımın en azından bu avantajları vardır:

• “mantıklı olan” hikaye akışını sürdürür;
• Tüm takım yeteneklerinden yardım sağlar;
• tüm ekibin kodun nasıl temiz tutulacağını öğrenmesini sağlar;
• tam olarak ihtiyaç duyulduğu yerde iyileştirmeye odaklanır;
• ihtiyaç duyulabilecek iyileştirmeyi boşa harcamaz;

Kod kalitesinin uzun vadeli verimlilik üzerinde çok büyük bir etkisi olduğunu gördüm, bu yüzden teknik borcun dikkate alınması gerektiğine inanıyorum. Sanırım yukarıdaki yazı mantıklı ama son iki noktadan pek emin değilim. Kullanıcı hikayeleriyle alakalı olmasa bile, teknik borcun temizlenmesinden elde edilen faydaların gerçek deneyimlerini öğrenmekle ilgileniyorum.

Kod tabanınızı temizlemekten ve kendinizi teknik borçtan kurtarmanın hangi olumlu yararlarını gördünüz? İşi yapmak için hangi yöntemleri kullandınız?

Size deneyimimden bir örnek verebilirim.

Yaklaşık 10 veya 12 yıl önce, şirketten ayrılan (buraya gelmek için çok uzun ...) bir ekip geliştiricisinin başvurusunu devraldım. Sistem, evde yetiştirilen büyük bir ara katman rapor oluşturma sistemidir. Her hafta gece çalıştı ve bir Fortune 500 şirketinin üst düzey yöneticileri için yaklaşık 2 düzine Excel raporu hazırladı. Miras aldığımda çalıştırmak 5-6 saat sürdü ve herhangi bir hafta boyunca en az 2 gece başarısız oldu.

Bu karışıklığı verdiğim için mutlu bir kampçı değildim.

Başlangıçta planım sadece kanamayı durdurmak ve başarısızlıkların ana nedenini düzeltmekti. Kod üssü ile daha rahat hale geldikten sonra, yeniden düzenleyebileceğim ve istikrar ve performans ekleyebileceğim yerler aramaya başladım. 2 yıl veya daha fazla bir süre boyunca sistemde birçok değişiklik yaptım. Bu sistemi birkaç yıl önce emekli ettik ve bu noktada tüm sürecin çalışması 45 dakika sürdü ve yıllarca herhangi bir sorun yaşanmadı.

Teknik borçların ödenmesi için çok fazla iş yapıldı, ancak buna değdi. Sistemin başarısız olduğu gecenin ortasında herhangi bir telefon görüşmesi yapmamak güzeldi. Büroya ofise gelmek ve günlüklerde iyi haberler dışında hiçbir şey görmemek güzeldi.

(Bir kenara ... Birkaç yıl sonra bu sistemin ana geliştiricilerinden birine rastladım. Bana nasıl olduğunu sordu ve ona sistemin ne kadar kötü olduğunu söyledim. Gerçekten özür diledi ve bunun olacağını bildiğini söyledi. ayrıldıktan ve daha iyi bir iş yapmasını diledikten sonra destek için bir avuç.

Kod temizlemenin yararlarının, temizliğin yapılmadığı yerlerde kodu korumam gerektiğinden en çok göze çarpan deneyimim oldu. Temizliğin yapıldığı yerde değişikliklerim kodun okunmasından, değiştirilmesi gereken bir veya iki yerin tespit edilmesinden ve oradan devam etmekten ibarettir. Temizleme işlemi yapılmadıysa, kodu birkaç kez okumak ve yazarın (bazen benim) yazarken ne düşündüğünü anlamaya çalışmak için ilk adımı ekleyin.

teknik borcun ortadan kaldırılması, daha az teknik destek sağlar ve geliştirmeler için daha iyi bir temel sağlar.

her zaman

Yaşadığım bir deneyim, önceki işverenimde bir Site Performansı ekibini yönetirken oldu. Her gece bir ila iki saatlik bir süre boyunca ekibimin izlemekte olduğu web sitesi, bir botun siteden hızla bilgi alması nedeniyle kabul edilebilir performans eşiğinin altına düşecektir. Ekibin buna yönelik aldığı önlemler manuel bir yönetici sistemine giriş yapmak ve sorunlara yol açan IP adreslerini engellemekten ibaretti. Söylemeye gerek yok, bu neredeyse her gece takım saatlerinin bir üyesine mal oldu. Ne olduğunu farkettim ve ne kadar kötü olduğunu görmek ve ekibime biraz dinlenmek için telefonla BlackBerry'yi birkaç günlüğüne aldım.

Birkaç gün sonra, sadece ekibin işletme sahibine gittim ve onlara otomatik bir engelleme sistemi uygulamazsak, botların sitenin performansını etkileyen çok daha zor bir zaman alacağı, muhtemelen kaybedeceğimizi bildirdim. bazıları ise tüm ekip üyelerinin yorgunluk ve tükenmişlikten dolayı olmadığını. Kabul ettiler ve geceleri uyumamıza izin veren bir sistem uyguladık. İşletme sahibi, birkaç gün veya bir haftalık bir geliştirme maliyetinin, yeni mühendislerin işe alınma / eğitim maliyetine kıyasla minimum düzeyde olduğunu anlamıştı.

Son iki konuya gelince : Orijinal yazısında açıklandığı gibi nereden geldiğini anlıyorum :

Veya, ekibin geri kalanı kullanıcı odaklı işlerle devam ederken, bazı geliştiricilerin bu teknik meseleleri halletmeleri için atamaları mümkün müdür? Bu takım hızını etkileyebilir, peki ne?

“Öyleyse ne demek” eşittir: ürün sahibi ve diğer iş tarafı insanları mutsuz olur. Ve annem mutsuz olduğunda, herkes mutsuzdur.

Ancak, yapılması gerekenler ile yapılabilecekler arasındaki çizgi oldukça belirsizdir. Kullanıcının karşılaştığı alan çok geniştir ve performans ve hata oluşumu içermektedir. Ancak, bazı durumlarda, düşük performansın ve yüksek hata oluşmalarının altında yatan problem kodda daha derinlerde bulunmaktadır. Onun sözleriyle söylemek gerekirse: Bir hikaye crufty alanından geçmeyebilir, ancak crufty bölgesi, yanındaki temizlenmiş yolda hikayeye saldıran bazı kötü şeyleri gizleyebilir.

Genel performansı etkilemeyen şeyler temizlemek için daha az ilgi çekicidir, ancak bu noktaların etkisini çok dikkatli değerlendirmek gerekir. Çoğu zaman, oldukça önemli olabilecek dolaylı bir etkiye sahip değildir.

Bir kuruluşun teknik borcu geri ödemesinin bir sonucu olarak alacağı en büyük fayda, bileşik faizden kaçınmaktır. Aşağıdaki blog girişinde teknik borçtan anapara borcunun sadece beş yılda 160 bin dolardan 430 bin dolara çıktığını gösteren bir örnek var. Tam zamanlı bir programcı yalnızca bu miktarda borca ​​hizmet etmeye adanmıştır. Bu karar vericiler için perspektifi ortaya koymaya yardımcı olacak!

Gönderen blog.acrowire.com .