Yeni bir ekip olarak sürdürülebilirlik sorunları olan bir projeye öncülük etmek için ne yapmalı?

Ben sadece sürdürülebilirlik sorunları olan bir kod projesinden sorumlu tutuldu. Projeyi sağlam bir temelde oturtmak için ne yapabilirim?

Kendimi, birim testleri, IOC, MEF, çok fazla statik sınıf, saf veri seti vb. sadece 24 ama neredeyse üç yıldır buradayım (bu uygulama 5 yıldır geliştirilmektedir) ve çoğunlukla zaman kısıtlamaları nedeniyle sadece diğer saçmalıklara daha fazla bok ekliyoruz. Boş zamanlarımda bir dizi proje yaptıktan sonra, tüm bu kavramların ne kadar önemli olduğunu anlamaya başladım. Ayrıca çalışan kayması nedeniyle kendimi şimdi bu projede takım lider olarak bulmak ve gerçekten bu uygulamayı geliştirmek için bazı akıllı yollar bulmak istiyorum. Değerin yönetime açıklanabileceği yollar. Ne yapmak istediğime dair fikirlerim var ama hepsi çok açık bir kazanç olmadan çok ezici görünüyor. İnsanların bununla nasıl başa çıktığı veya nasıl başa çıkacağı ile ilgili her hikaye çok ilginç bir okuma olacaktır. Teşekkürler.

Teknik borca ​​saldırmak için bütçe süresi. Sadece yapmalısın. İlk olarak hangi parçalara saldırdığınız, geliştiricilerinizin şu anda en çok nerede harcadığına bağlıdır, ancak başlamak için ideal şeylere başlamak daha önemlidir. Scrum kullanıyorsanız, birikiminize belirli teknik borç parçaları koyun ve bunlarla başa çıkana kadar onlara özellik gibi davranın.

Eski Kod ile Etkili Çalışma şiddetle tavsiye edilir ve muhtemelen faydalı olacaktır. Okumadım, ancak birim testlerini eski koda dönüştürmek hakkında çok fazla bilgiye sahip gibi görünüyor, böylece onu değiştirebilir ve güvenle güncelleyebilirsiniz.

Kredi kartı benzetmesini yönetim ile birlikte kullanın - yaptığınız her şeye "faiz ödüyorsunuz" çünkü her şeyi başarmak çok zor. Teknik borcunuzu öderseniz, bu kaynakları serbest bırakacak ve gelecekte yeni işlevleri daha hızlı geliştirebileceksiniz. Bunu yapmazsanız, "faiz ödemeleriniz" (geliştirme süresinde ödenir) birikmeye devam eder ve ekibiniz yeni işlevleri daha yavaş üretir.

Belki de her döngünün teknik borca ​​karşı mücadele etmek için harcadığınız zamanı tahmin etmeye başlayarak onlara ne kadar birikmiş olduğuna dair bir fikir verin. Sürdürülebilir bir sistemde bir düzeltme veya özellik değişikliğinin nasıl olacağını, gerçek sistemde nasıl göründüğünü ve hangi değişikliklerin yapılması gerektiğini veya oraya ulaşmak için ilk adımların iyi olabileceğini açıklayın.

Teknik borcu hata düzeltmelerine ve ek özelliğe dönüştürün.

İyileştirmeye yinelemeli bir yaklaşım buldum, en iyi sonucu verir. İşimdeki mantra, her dokunduğunuzda kodun kalitesini artırmaktır. Bir hata düzeltme veya özellik olsun, her iş parçası neyin düzeltilebileceğini / yeniden düzenlenebileceğini / temizlenebileceğini analiz eder. Refactor'u tamamlamamız gereken işe eşit (ölçekli) yapmaya çalışıyoruz.

Kod tabanındaki sorunların sıralı bir listesini oluşturun. Herkesin listeden ve öncelik sırasından haberdar olduğundan emin olun. Ne zaman bir iş parçası olsun, üzerinde çalışacağınız koda bağlı listeden bir sorun aramak gerekir.

Bu her şeyi düzeltmeyecek. Büyük miktarda zaman ve kaynak gerektiren bazı refactors veya düzeltmeler vardır. Genelde bunları fayda sağlayacak diğer büyük iş parçalarına bağlamaya çalışıyorum.

Sadece bariz olanı söylüyorum, ama hey.

Sorunları olan bir kod yığınını uygulayan küçük bir birim testi yazın, ardından testin hala geçip geçmediğinden emin olarak demeti yeniden düzenleyin. Yeni oluşturduğunuz katı zeminin bu küçük kısmından en kolay şekilde erişebileceğiniz başka bir kod parçasına geçin. Köpürtün, durulayın, tekrarlayın.

Bu aynı zamanda kod tabanına biraz daha aşina olmanıza yardımcı olacaktır.

Bunu bir süre yaptıktan sonra, biraz daha genişletilmiş yeniden düzenleme yapma zamanının geldiğini anlayacaksınız. Yinelenen kodu bulmak, KURU prensibinin ihlali ... bilirsiniz, olağan şeyler. O zamana kadar, yöntemleri karıştırmanıza, arayüzleri ve tüm bu olanaklara sahip olmanızı sağlayacak tartışmalı bir kod kapsamına sahip olacaksınız.

Kod tabanını her zaman içine girmeye başlamadan önce olduğundan biraz daha iyi bırakın. Eminim ki çok da uzun vadede bile ödeyecek küçük bir yatırım.

Bu projenin nereden başlayacağına dair tek bir fikri için sahip olduğu teknik borcu açıklamaya çalışabilirsiniz . Ayrıca, çalışanların değişmesi nedeniyle, kodun hızlandırılması için biraz zaman harcanması gerektiği konusunda pazarlık yapmaya çalışabilirsiniz ve bu, testlerin hataları önlemeye ve işleri daha kolay hale getirebileceğinden gelecekteki daha iyi gelişmeyi sağlamak için bazı testler yapmak anlamına gelir. yeni insanlar muhtemelen proje üzerinde çalışmak.

Bu gibi durumlarda, projeyi olabildiğince düzene sokmaya çalışıyorum. İlerlemek için hangi özelliklerin kesinlikle gerekli olduğunu öğrenin. Uzun zamandır var olan herhangi bir sistemin büyük olasılıkla çok uzun bir biriktirme listesi vardır. Bu öğelerin birçoğu kritik olacak ve birçoğu sadece "çan ve ıslık" olacak.

Test ile ilgili olarak, birim testleri kesinlikle yardımcı olacaktır, ancak bazı teknik olmayan personelin teste katılmasını ve ekip üyelerinize hata göndermesini isteyebilirsiniz.

İyi şanslar.

Seçeneklerden biri özgeçmişinizi temizlemek ve iş aramaya başlamaktır.

Kendinize sormanız iyi bir soru, bu kötü yürütülen projenin tüm şirketin nasıl yürütüldüğünün bir göstergesi olup olmadığıdır. Cevabınız evet ise, kötü çalışan bir şirkette kalmak için yeterince para alıp almadığınızı sorun.

Birçok kez üst yönetim tarafından yeniden düzenleme zorlayabilirsiniz, eğer bir performans yükseltmesi olacağını veya mevcut bir hatayı düzelteceğini söyleyebilirseniz. Sadece işe yarayacak bir şeyi değiştirmek için, özellikle de işe yararsa, yeniden faktörlü olmayın. Hata düzeltme süresi, zaten orada olduğunuz için bazı yeniden düzenlemelere uymak için iyi bir yol olabilir. İddialı olun ve diğer kodlayıcılarınızdan daha genç olduğunuza bakmayın. Bazı birim testlerine girmek gibi küçük bir şeyle başlayın ve oradan çalışın, size başka şeyler için döngü sağlamak için yönetim alabilen bazı hataları ortaya çıkarabilirsiniz.

Şu anda .NET'te Brownfield Uygulama Geliştirme'yi okuyorum , temel olarak, şu anda sahip olduğunuz sorunlarla nasıl başa çıkacağınızla ilgili. Şimdiye kadar söylediklerinin çoğunu beğendim (her şey değil - ama bu, tamamen kuralcı olmayı amaçlayan değil, problemlerle kendi yolunuzu düşünmenize yardımcı olacak bir tür kitap). Birkaç şekilde yardımcı olabilir - yalnız olmadığınızı gösterir; Umarım bazı sorunların nasıl ele alınacağına dair ipuçları verir.

Temel olarak yaklaşımların çoğuna katılıyorum - her şeyi bir gecede düzeltemezsiniz, ancak çok küçük adımlarla aşamalı olarak geliştirebilirsiniz. Ve evet - Teknik Borç, kullanmanız gereken metafor.

Sonuçta insanların projede ne kadar iyi olduğuna bağlı. Eğer karışıklığı yaratan aynı mürettebatsa, aynı grupla daha iyi hale getirme şansınız azdır. Personelinizi analiz edin, en zayıf üyelerinizi bulun ve değiştirin (eğer bunu yapabiliyorsanız).

"Bir ekmek kulağından ipek bir çanta yapamazsın".