Teknik borcu azaltmak için nasıl ödeme alabilirim?

Şu anda teknik olarak karmaşık ürünleri az olan küçük bir şirkette çalışıyorum. Bunlardan biri için tek ve tek geliştiriciyim. Yaklaşık bir yıl önce, ürünün eski versiyonunu aldım ve "desteklemeye" başladım.

Müşteri yalnızca yeni özellik, iş değeri ve bu türden başkalarından bahseder. Sorun, kod C # olmasına rağmen oldukça yordamsaldır. Soyutlama yoktur, sınıflar yalnızca Visual Studio'nun gerektirdiği yerlerde kullanılır - Örneğin Formlar. Bu sınıfların uygulamaları gerçekten korkunç ve kodun korunması gerçekten zor.

Bunca yıl boyunca yeniden düzenleme için kendime zaman ayırıyorum. Son sürümde, oldukça soyutlamalar ve benzeri var. Bazı bileşenleri sıfırdan yeniden uygulamak zorunda kaldım ve bu bileşenlere yeni özellik eklemenin veya davranışı değiştirmenin diğerlerinden çok daha kolay olduğunu hissediyorum.

Sorun şu ki, kendi zamanımı harcıyorum. Sonuçları gerçekten seviyorum ama günde 12 saat çalışmayı sevmiyorum. Hiç benzer duruma gittin mi? Ne denemeliyim? Zaten tartışmayı denedim, ama yine de başarı yok.

Eski kodda çok fazla değişiklik gerektiren yeni özelliği uygulamaya karar verdiğimiz andan korkuyorum. Bu sadece müşteri için şok edici olabilir: neden bu simgeleri değiştirmek için 8 saate ihtiyacınız var? Müşteri, kodda değiştirmem gereken 500 yer olmasını umursamıyor. Ve önce bu 500 yeri de bulmalıyım.

Herhangi bir fikir?

Adım 1: Ücretsiz fazla mesai yapmayı bırakın.

Mevcut kalkınma oranının beklenmesi gerektiğine inanması için müşterinizi ve yöneticinizi bir yıldır eğitmişsinizdir. Bu, "basit" bir şeyin neden tam gün sürdüğünü anlamadıklarının bir parçasıdır. Onları rehin tutmanıza ve projeye zarar vermeye çalışmanıza gerek yok. Ancak beklentilerinin çok yüksek olduğunu ve son geliştirmeden önce başka bir geliştiriciye veya daha fazla zamana ihtiyacınız olduğunu açıklamanız gerekir. Yöneticinize özellikle ücretsiz fazla mesai yaptığınızı ve bunu fazla yapmamanızı planladığınızı belirtin. 9 saat güne kadar kesmiş olsanız bile, fark fark edilecektir. Yöneticiniz size işinizi neden yapmadığınızı sorarsa, onu uyarmak için bir noktaya geldiğinize dikkat edebilirsiniz.

2. Adım: Not alın

Sadece işi yapacak vaktiniz olmadığı için (umarım) iş bittiğinde işinizi kolaylaştıramayacağınız anlamına gelmez. Kodu düzeltmek için sahip olduğunuz fikirleri takip edin ve başkalarının endişelerinizin farkında olması için bunları toplantılara getirin. Sonunda yavaş bir yamaya vuracaksınız ya da insanlar endişelerinizin değeri olduğunu anlamaya başlayacaklar. Bu zaman geldiğinde, kuru bir yere gelmek yerine ne yapmanız gerektiği hakkında bazı temel fikirleriniz olacak, çünkü bir süre kod bölümüne bakmadınız.

... kodun bakımı gerçekten zor.

Bu, yönetimde yolunuz. Hataları düzeltmenin ve yeni işlevler eklemenin "sadece" maliyetinin, kodu yeniden düzenleme ve yeniden yazma maliyetinden daha yüksek olduğunu gösterin.

Örneğin, mevcut kodla yeni bir özelliğin eklenmesi 2 hafta sürecek ve daha sonra sürdürülmesi gereken önemli bir süre (örneğin, haftanın 1 günü), bir hafta yeniden düzenleme ile geliştirmeyi 1 1/2 içinde yapabileceğinizi gösterin ancak bakımı ayda 1 güne (veya daha az) indirirsiniz. Bu rakamlar, kısa vadeli bir maliyet olmasına rağmen yaptığınız şeyin orta ve uzun vadede maliyet etkin olduğunu gösterecektir.

Şirket parayı şimdi harcamaktan hoşlanmasa da, potansiyel faydaların çok daha büyük olduğunu görecekler - yani daha kısa sürede daha fazla kod üreten daha üretken olacaksınız ve bu kod daha kaliteli olacak.

İzci Kuralını uygulayın : Her dokunuşta kodu biraz daha düzenli (yani daha az teknik borçla) bırakın.

Verdiğiniz tüm tahminlerde bunu yapmak için zaman tanıyın. Daha sonra, sihirli bir şekilde, zamanla teknik borç ortadan kalkacak ve bunu ödemeniz için size para verilecek.

Bu yaklaşım, teknik borç için açıkça zaman ayırmaya çalışmaktan (ve dolayısıyla müşterileri / yöneticileri ödemeye ikna etmek) çok daha kolaydır. Size çok daha büyük bir profesyonellik hissi ve "iyi yapılmış bir iş" verir. Ve son olarak, müşterileriniz ve yöneticileriniz, bunun nasıl olduğunu tam olarak anlamadılar bile, uzun vadede size teşekkür edecekler .....

Bu, bakım programlamasının aşağı yukarı üzücü gerçeğidir. Korumak için ne atandığınıza sıkışmışsınız ve faturaları ödeyen kişi, faydasız olarak gördüğü şeyleri ödemek istemiyorsa, bu değişiklikler yapılma eğilimindedir.

Bu değişiklikleri finanse etmek için dava açmak istiyorsanız, en basit güncelleme için bile değiştirmeniz gereken tüm yerlerin bir kaydını tutun. Birkaç değişiklikten sonra, bu günlüğü yöneticinizle görüşün. Belgeleyebiliyorsanız, çanta ipleri olan kişinin gelecekteki değişiklikleri daha ucuz hale getireceği için kodu şimdi temizlemenin uzun vadede aslında daha ucuz olduğunu fark etme şansı (çok ince olsa da) vardır.

Bu artışı satma şansınız, bu ürünün kullanım süresinin uzamasıdır. Üründeki bir arızanın müşteri için bir halkla ilişkiler sorununa neden olması veya müşteri parasına mal olması muhtemel ise, oranlar da artar.

Bunu engellemek, neler yapabileceğinizi öğrenmek ve daha az bakım ile başka bir pozisyona geçmek.

Yönetiminizi, ürünü yeniden düzenlemenin ve başka şekilde iyileştirmenin şirkete nasıl fayda sağlayacağını göstermeniz gerekir.

Müşterinin, kodun çalıştığı sürece güzel veya çirkin olup olmadığını umması olası değildir ve yönetim, müşteriye zaten ödediği şeyin kötü tasarlanmış ve kötü uygulandığını açıklamak istemeyecektir. Aynı zamanda, yönetim, ürünü görünür (faturalandırılabilir) bir şekilde iyileştirmeyen geliştirme zamanının maliyetini yemeye hevesli olmayacaktır.

Yani ... yönetimi, önerdiğiniz değişikliklerin şirkete yardımcı olacağına ikna etmelisiniz:

• Onlara daha iyi bir mimarinin yeni özellikleri daha hızlı eklemenizi sağlayacağını gösterin.
• Mevcut yol boyunca devam ederek kendilerini köşeye boyayacaklarını açıklayın.
• Mevcut sistemde yapılması çok pahalı, ancak daha iyi bir tasarımla basit ve ucuz olan değişikliklere örnekler verin.
• Satılabilir özelliklerin eklenmesi ile eski kodun korunması için harcanan zamanı takip edin. - Mevcut ve gelecekteki müşterilere, mevcut sistem oldukça iyi olmasına rağmen, yeni, modern mimarinin birçok yeni iyileştirmeye, daha iyi güvenilirliğe ve benzeri şeylere izin vereceğini açıklamalarına yardımcı olun.
• Teklif ettiğiniz değişikliklerle ilişkili riski azaltın. Yöneticiler riskten kaçınırlar ve mevcut bir sistemdeki kapsamlı değişiklikler doğası gereği riskli görünür.
  • Maliyet ve faydaya göre çeşitli bileşenlerin modernizasyonuna öncelik verin ve yönetimin önceliklerinize uygun olduğundan emin olun.
  • Modern bileşenlerin kalan eski kodla uyumlu olmasını sağlamak için birim testi kullanın.
• Modernizasyon çabalarının ilerlemesini izleyin. Avantajları mümkün olan en kısa sürede gösterin, ancak tüm taraflara yapacak daha fazla iş olduğunu hatırlatın.

Farkında olmayabilirsiniz, ancak Johnny Cash yeniden düzenleme hareketini tahmin etti ve mevcut büyük bir kod tabanını yeniden düzenlemenin en iyi yolu hakkında bir şarkı yazdı.

Tabii ki, onu bir otomotiv metaforuna sarmak zorunda kaldı, böylece seyircisi onunla ilişki kurabildi.

"Her Seferinde Bir Parça" - Johnny Cash

Uzun vadede değişimin “alması” gereken süre için müşteriyi ücretlendirebilir ve yine de ÇIKIŞ gibi görünebilir.

Kodu temizlemekten hoşlanıyorsanız (ve en azından biraz yaptığınız gibi görünüyorsa) devam edin ve yapmaya devam edin, ancak kendinizi yakmayın. Bu sizi, şirketinizi veya diğer müşterilerinizi iyi yapmaz.

Yönetiminizin ve müşteriyle çalışan herkesin kodun en iyi durumda olmadığını bildiklerinden emin olun, böylece bilinçli bir karar verebilirler. kodla ilgili sorunların farkında değilse işlerini yapamazlar.

Müşterinin başvurusunda bazı teknik borçlar olmasına rağmen, unutmayın, muhtemelen hafif bir indirimle ücretlendirildiler. Bunun farkında olmamış olabilirler, ancak en düşük teklifi aldığınızda olan şey budur.

Özellik değişiklikleri için tam ücreti ödemek isteyip istemediklerine karar vermeleri gerekir. Bu onların seçimi. Karar vermelerine veya ücretsiz çalışmaya devam etmelerine izin verebilirsiniz. Yaptığınız temizlik işini anlatabilir ve tamamlanan iş için hafif bir indirim yapabilirsiniz. Yine, bu onların seçimi.

Buna yaklaşacağım yol, patronlarınıza teknik borç kavramını anlatmalarını sağlamak için açıklamakla başlamaktır. Sonuç olarak, iş perspektifinden yaklaşın. Ne zaman yeni bir özellik talep etseler, üründe biriken teknik borç verimliliğinizi etkiler ve bu nedenle bu borca ​​bağlı olarak her bir özellik biraz daha maliyetlidir.

Ne hakkında konuştuğunuzu anladıktan sonra, teknik borcunuzu azaltmak için biraz zaman ayırmaya çalışın. Şirketimde, teknik borçların azaltılması konusunda çalışmak için her geliştiricinin% 10'una dilekçe vermeyi başardık.

Bunun üzerinde çalışmak için bir süre ayırdığınızda, gerçekten kullandığınızdan emin olun (ve bunu yapmak için sadece% 10 fazla mesai yapmayın - silahlarınıza sadık kalın). Bir teknik borç kalemi kataloğu oluşturun ve bunlara öncelik verin ve oymaya başlayın. Fil her seferinde bir ısırık yemek zorunda.

Ve daha iyi araçları hesaba katmayı unutmayın. Resharper, Visual Studio'ya takılan harika bir yeniden düzenleme aracıdır.