Hatalar teknik borcun bir parçası mı?

Scrum Master'ımız hataları teknik borç olarak adlandırıyor. Haklı mı? Çevik dünyada hataların teknik borç olduğu düşünülüyor mu?

Buradaki cevabın oldukça basit olduğunu düşünüyorum - teknik borcun kilit özelliği, seçtiğimiz bir şey olması.

Belirli hedeflere daha erken ulaşmak için bize daha sonra sorun çıkarmamızı beklediğimiz mimari, tasarım veya uygulama kararlarını vermeyi seçiyoruz.

Bir hata, kodumuzda seçmeyi seçtiğimiz bir şey değildir - bu yüzden teknik borç değil fiilen.

Elbette, keşif sonrası yapılan seçimlerle ilgili her türlü ilginç (ve muhtemelen geçerli) argümanlar yapılabilir, ancak temelde (ve özellikle de soru bağlamında) hayır, böcekler teknik borç değil - bana buzzword bingo kötüye kullanılması gibi geliyor.

Bir dipnot olarak - Teknik borcun kendi içinde hatalara yol açacağı yönündeki iddiaların, yapılan seçimlerin doğası hakkında birçok varsayıma yol açacağı iddiasına katılmıyorum. Örneğin, erken teslimat için yine de mimari açıdan ödünç veren iyi yazılmış, iyi yapılandırılmış, test edilmiş kodlara sahip olabilirsiniz. Benzer şekilde, yerleştirme işlemlerinizi otomatikleştirmeyip, hatalara yol açmayacak, ancak muhtemelen çok fazla stres ve acıya neden olacak şekilde seçebilirsiniz. Elbette eğer borç, katı (ya da her neyse) katı olmayan kodunuzu yazdıysanız, evet ... ama bu asla olmaz.

Evet.

Teknik borç (tasarım borcu ya da kod borcu olarak da bilinir), bir kod tabanı içindeki kötü ya da gelişen yazılım mimarisi ve yazılım geliştirmenin nihai sonuçlarını ifade eden neologistik bir metafordur.

Kaynak: Wikipedia

Teknik borcu, daha iyi bir iş akışına (örneğin kodlamaya başlamadan önce mimariyi düzgün bir şekilde yapmak, TDD, vb.), Daha iyi kodlama uygulamalarına vb. Sahip olmaktan kaçınabileceğiniz bir şey olarak okuyun.

Çoğu gözden geçirme ya da daha resmi yöntemlerin kullanılmasıyla böceklerden kaçınılabilir. Her şeyden önce yapamayacağınız her şeyi yapmadan, projenin ani / kısa vadeli maliyetini düşürürsünüz, ancak teknik borcu arttırırsınız.

BЈовић'nin cevabını okuduktan sonra , düşündüğüm kadar kolay olmadığını görüyorum.

• Örneğin, böcekler teknik borcun bir parçası mı? yalnızca bildiğiniz ancak düzeltmemeye karar verilen hataların teknik borcun bir parçası olduğunu iddia eden makale.

• Başka bir örnek, Christopher'ın Teknik Borç Üzerine Düşünceleri, bir parçanın değil, teknik borcun bir sonucu olarak hataları nitelendiriyor . Bu, "yeni özellik uygulama maliyeti" gibi listelenen sonuçların çoğunun böcek sayısından etkilendiği söyleniyor.

• Son olarak, ABCDE-T teknik borç modelini oluştururken , hataları altı faktörden biri olarak dahil ettim, ancak farklı sayılıyorlar. Odak böceklerin kendileri üzerinde değil, onların toplanma, önceliklendirme ve çözülme şekilleri üzerinedir. Hatalar, teknik borcun bir sonucu olarak ortaya çıkar (önceki örnekte olduğu gibi), ancak hiçbir zaman kendilerini teknik borcun bir faktörü olarak görmezler.

Bu söyleniyor, hala hataların - herhangi bir hata - teknik borcun bir parçası olduğunu cevaplamaya meyilliyim.

İlk argüman:

Jeff Atwood'un teklifini okuyarak çoğu böcek şöyle nitelendiriyor:

hızlı ve kirli tasarım seçimi nedeniyle gelecekteki gelişimimizde yapmamız gereken ekstra çaba

İş uygulamalarında hemen hemen her hata hızlı ve kirli tasarım seçiminden veya kötü uygulamalardan kaynaklanmaktadır (test eksikliği, geliştiricilerin yeterince bilmediği teknolojilerin kullanımı, iletişim eksikliği, etki alanını anlama eksikliği, vb.) Bu, "hızlı ve kirli tasarımın daha iyi tasarıma yeniden yansıtılmasıyla" ve daha iyi uygulamaları uyarlayarak işletmelerin hatalarının çoğunu çözebileceği anlamına gelir.

İkinci argüman:

Bir şirketin bir başkasına satıldığı zaman hesaba katılması gereken bir şirketin normal borcu ile bir proje başka bir şirkete satıldığında veya verildiğinde hesaba katılması gereken aynı derecede önemli olan teknik borç arasında bir paralellik varsa Başka bir ekibe, yeni ekibin yapacağı gibi böceklerin teknik borcun bir parçası olduğunu kolayca görebiliriz:

• Yeni özelliklerde bulunmadan önce bu hatalarla başa çıkmanız gerekir (Joel Test 5. Maddesi: Yeni kod yazmadan önce hataları düzeltir misiniz?)

• Veya teknik borcu bu şekilde koruyarak / artırarak böcekleri saklayın.

Jeff Atwood, Teknik Borcunu Ödemek başlıklı makalesinde , teknik borcun ne olduğu konusunda oldukça güzel bir cevap veriyor:

teknik borç, hızlı ve kirli tasarım seçimi nedeniyle gelecekteki gelişimimizde yapmamız gereken ekstra çaba biçimindeki faiz ödemelerini içeriyor. Faizini ödemeye devam etmeyi seçebilir veya hızlı ve kirli tasarımı daha iyi tasarıma yeniden yerleştirerek müdürü ödeyebiliriz. Anapara ödeme maliyeti olsa da, gelecekte faiz ödemelerinin azalması ile kazanıyoruz.

Kesin konuşursak, daha fazla yazılım geliştirmeyi yavaşlatmazlarsa (bazı şeyleri değiştirmek, yeni özellikler eklemek, vb.) Teknik borçların bir parçası değildir. Bunlar yazılım hatalarıdır.

Ancak, bir hatayı düzeltmek çok pahalı olduğunda veya sizi bu konuda çalışmaya zorlar (ve daha fazla teknik borç verir), o zaman teknik borcun bir parçası olur.

Bir hata teknik borç değildir. Teknik borç kaliteden yoksun, yokluğundan değil. Yazılım, ilk başta içinde böceklerle birlikte teslim edilmemelidir. Bilirsin, bütün çalışan yazılım kapsamlı bir dokümantasyon meselesi.

Teknik borcun en büyük suçluları "geçici hata düzeltmeleri" dir, testten geçmek ve hikayeyi kabul etmek için koyduklarınızı bilirsiniz. Kendine söz verdiğinizleri daha sonra yeniden değerlendireceksiniz, fakat sonra asla yapmazsınız. Bu geçici düzeltmeler, yamalar ve diğer şeyler biriktikçe, kod gereksiz yere dağılır, güncellenmesi ve test edilmesi zorlaşır ve genel olarak bir kabustur, ama yine de işi yapar.

Bu görüşü desteklemek için doğrudan kaynağa gittim, Ward Cunningham. Bununla ilgili olarak, Ward bir süre önce Capers Jones ile iyi bir röportaj yaptı, izlemeye değer.

Ward Cunningham ve Capers Jones ile Teknik Borç Tartışması

Okunmaya değer bir diğer makale Martin Fowler

Teknik Borç Üzerine Martin Fowler

Martin'in makalesinde, lütfen Ward Cunningham'ın OOPSLA92'den teknik borcunun asıl söz konusu olduğu bağlantıyı bulun:

WyCash Portföy Yönetim Sistemi

Yukarıdaki makaleden bir alıntı:

Her ne kadar olgun olmayan kod ince iş ve müşteri tamamen kabul edilebilir , fazla miktarları programcı aşırı uzmanlık ve son olarak bir katı ürüne giden, bir program unmasterable yapacaktır. İlk kez kargo yapmak borç almak gibi.

Sonunda, Teknik Borç bazı insanlar için hatalar içermeye başlamış olabilir ve sanırım bu iyi. Bunun asıl niyetinin olduğunu sanmıyorum.

Açıkça konuşursak, sorunuzun cevabı Hayır.

Teknik borç, hatalara yol açabilir (ve muhtemelen de olabilir), ancak herhangi bir hatanın teknik borcun bir sonucu olduğu sonucuna varmak, iki gerçek arasında bir yorum getirdiği sonucuna varmaktadır : bir hata var ve teknik borç var (bunun varsayım olarak sonuçlanabileceğini varsayarak).

Eğer Scrum Master'ınız, hataların teknik borcun bir sonucu olduğunu 'teori olarak' belirtiyorsa, o köşeyi kesiyor. Bunu tekrarlanmaya devam eden belirli hatalar hakkında söylüyorsa, haklı olabilir - kod kalitesini buradan göremiyoruz ;-)

Ayrıca, teknik borç hakkında kendisini dinlemeyen ve dolayısıyla her böceği teknik borç olarak etiketleyen insanlar hakkında sürekli bir şikayeti olabilir, ancak şimdi spekülasyon yapıyorum.

Bana göre, böceklerin teknik borcun bir parçası olup olmadığını söylemeniz gerçekten önemli değil.

Asıl gerçek, mevcut böceklerin gelecekte düzeltilmesi veya çevrelerinde çalışması için yapılması gereken ilave işleri temsil etmesidir .

Teknik borç (etiket genellikle kullanıldığı gibi) ayrıca gelecekte yapılması gerekebilecek ekstra işleri de temsil eder ... bir şekilde.

Bildiğiniz (veya bilinmeyen) böceklerin teknik borç olduğunu ya da söylememesini söylemek ... gerçekten sadece bir tanım meselesidir. Hiçbir olmadığından Ve yetkili tanımı ¹ "teknik borç", tüm tartışma tür anlamsız olduğunu.

Lewis Carroll'un yazdığı gibi:

“Bir kelime kullandığımda,” dedi Humpty Dumpty, oldukça kaba bir tonda, “demek istediğim tam olarak ne demek istediğim - ne daha fazla ne de az”. .

Aslında doğal dil böyle çalışıyor. Kelimeler, insanların ne anlama geldiğini düşündüğü anlamına gelir. Sözlük tanımları ve benzerleri, yalnızca kelimelerin kullanılma şeklini belgelemektedir ve bunlar mutlaka doğru belgeler değildir. Eğer Scrum Master'ınız bilinen böcekleri teknik borç olarak belirtmek isterse, "yanlış" olduğunu kim söyleyebilir?

^{1 - Ward Cummingham ve Caper Jones gibi insanlardan alıntı yapmak da yardımcı olmaz. En iyi ifadesi, bize (kullandıklarında) ifadesini ne zaman kullandıklarını (veya ne anlama geldiklerini) söyler. Bu cümleyi "kendi" değiller. Bu konularda şüphesiz otoriteler olsalar da, bu hala sadece onların görüşü.}