Hatalı kod maliyetlerini hesaplama


13

Yönetimi yeniden düzenleme çabalarına ikna etmek için argümanlar arıyorum.

Biz Jira kullanarak çalışma günlüğü ve her svn-taahhüt bir jira çağrısı ile ilişkilendiririz.

Benim fikrim aşağıdakileri yapmak:

  • son derece kötü uygulanmış, ancak sıklıkla kullanılan bir kod alanını manuel olarak tespit edin: hem User-POV hem de Developer-POV'den (hata düzeltmeleri)
  • JIRA Sorunlarını içeren svn-taahhütlerini alın
  • sorunları bazı kriterlere göre filtreleyin (sorun türü, sürüm, prio vb.)
  • bu böceklere harcanan zamanı / çabayı hesapla
  • Yeniden düzenleme çabalarını ve risklerini tahmin edebilir
  • sayıları gösterin ve düzeltmek için çaba gösterin.

Bunun hakkında ne düşünüyorsun? Böyle bir ölçüm faydalı ve / veya ikna edici olur mu? Artıları ve Eksileri nelerdir?

Yanıtlar:


5

Geçerli sayılar sağlayabilirseniz, yöneticilerin harekete geçme olasılığının daha yüksek olduğunu gördüm. (Eğer mantığı ve maliyeti / faydayı anlayabilirlerse.)

IMHO, ikna edici bir dava açmak için ne kadar kötü olduğunu göstermek için aşağıdakilere ihtiyacınız olacaktır:

  • sorunlar için kaydedilen destek olaylarının sayısı
  • saat bakım / bant yardımlı kötü kod / destek düzeltmeleri yapmak için harcanan zaman
  • bakım / bant yardımcıları / destek yapanların saatlik ücretine göre zaman maliyeti
  • bu öğelerin iş için ne kadar kritik olduğunu göstermenin bir yolu

Ve yeniden düzenleme için dava açmak için ihtiyacınız olacak:

  • bu kötü şeylerin ilk 3'ünün her birini yeniden gözden geçirmek ve uygulamak için zaman tahmini
  • uygulama için maliyet tahmini (yukarıda kullanılanla aynı saatlik ücretler)

Bunlarla, yeniden düzenleme bu en iyi 3 öğenin her biri için 3 olay için destek süresinden çok daha az zaman alıyorsa, zaman tasarrufu için dava açabilirsiniz. Bu daha kısa sürenin harcayacağını iddia edebilirsiniz.

  • n destek olayından daha az olmak
  • bunlar için bu olaylardan daha fazla olmayacak (DAHA İYİ!)

Bununla birlikte, bu satışın en zor kısmı aşağıdaki soruyu cevaplayacaktır, çünkü birçok insan yaptığınız tüm destek için zamanlamalarda zaman ayırmaz:

X ile bu sorunlar üzerinde çalışmak için zaman harcarken, mevcut Y projesinin tamamlanmasını ne kadar beklemek zorunda kalacağım ????? (Gantt grafiklerinde tahmin edilemeyen ve planlanamayan mevcut destek zaman bağlantılarına rağmen)

Bu, karar vericilerle ne kadar iyi iletişim kurduğunuza ve durumu nasıl anladıklarına bağlıdır.

KESİNLİKLE bunun yapmaya değer olduğunu düşünüyorum, bu yüzden metriklerle vakayı inşa etme ve bunun için gitmeseler bile zamandan tasarruf etme pratiği elde edersiniz. Ne yazık ki, verilere rağmen herkes ikna etmek kolay değil. İYİ ŞANSLAR!


2

Yeniden düzenleme işleminin hataları da getirdiğini unutmayın (testinizde yakalayacaksınız, ancak yine de hatalardır ve düzeltilmelidir). Kazara bir Netscape çekmeyin. Kişisel "yeniden düzenleme" tanımınıza bağlıdır. Bazıları için bu, "tüm kodu yeniden yaz" anlamına gelir, "bazı iç öğeleri değiştir" anlamına gelir. Ne tür olduğunu nasıl anlarsın? Kendinize şu soruyu sorun:

Herkese açık arayüzü değiştiriyor muyum?

Cevap evet ise, yeniden tasarım yapıyorsunuz. Cevabınız hayırsa, yeniden düzenleme yapıyorsunuz ve muhtemelen bunu günlük faaliyetleriniz boyunca özel onay almadan yapabilirsiniz. Bu, sorunuzla ilgilidir, çünkü bir yeniden tasarım çok daha fazla hata üretecektir, ancak bir yeniden düzenleme işlemi genellikle daha kolaydır (testleriniz zaten ortak arayüzü kullanacağından ve kendilerinin değiştirilmesi gerekmeyeceğinden).

Bunu yapmak zor bir durumdur, çünkü hiç kimse X'in bir yıl önce yapılan refactor ile veya refraktör olmadan ne kadar tutacağını bilemez. Deneyimlerime göre, pragmatik yöneticiler her zaman bu tür şeyleri vururlar çünkü:

  1. Çabadan doğrudan gelir akışı gelmiyor (finansal maliyet, faturalandırılamaz)
  2. Çirkin çalışma kodu hala çalışma kodu, bunları düzeltmek yerine sorun yaratma riskiniz var (potansiyel kalite maliyeti)
  3. Siz refactor sırasında diğer projeler gecikecek (zaman maliyeti)

+1 normal gelişim sırasında yeniden düzenleme yapmayı önerdiği için.
Kwebble

0

Tüm bu numaralar sonuçta mal olur tahmin miktarını karşılaştırarak senin durumunda, tahminler dayanmaktadır değil bunu mal olacağını tahmin etmek ne vs gözden geçirmeniz için refactor. Yapabileceğiniz en iyi şey, tahminler için bir çeşit sayısal, olgusal temeliniz olduğunu ve oldukça iyi bir tane olduğunu göstermektir.

Profesyoneller, muhtemelen onları yeniden düzenlemenize izin vermeye ikna etmede etkili olacaktır ve iyi gidebilir ve hata sayısını azaltabilir.

Eksileri, hataları düzeltmek için harcanan zaman miktarı en az yeniden düzenleme için harcanan zaman kadar düşmezse, muhtemelen artık refactor için izin verilmeyecek ve muhtemelen "boşa" zaman suçlanacaksınız .

Tüm projenin karmaşıklığını azaltarak veya özellik eklemeyi kolaylaştırarak hata ayıklama zamanından tasarruf etmek, size çok yardımcı olmak için ölçmek çok zor olabilir, ancak bunların varlığından bahsedebilirsiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.