Hızlanmak İçin Yavaşla

Bir tarihi tutturmak için temizliği atlamak o an hızlı hissettirir ve tek bir sprint boyunca çoğu zaman gerçekten öyledir. Sorun şu: testi, küçük refactor’ü ya da kararsız pipeline düzeltmesini atlamak o işi silmez. İşi faizle erteler ve faiz size hatalar, yeniden iş ve yangın söndürmeye giden zaman olarak geri döner. Sezgisel okuma şudur: bakım, gönderime harcanmayan zamandır, o halde sizi yavaşlatmalıdır. Teslimat performansı üzerine yapılan araştırma tam tersini gösteriyor: kodunu ve pipeline’ını temiz tutan ekipler daha sık gönderim yapar. Buradaki öneri şu: varsayılan olarak istikrarlı, bakımı içine alan bir tempoyu seçin ve teknik borcu bir kaza olarak değil, bilinçli ve takvime bağlı bir karar olarak ele alın.

Bu iddianın etrafında dolaşan birkaç eski fikir var ve devam etmeden önce bir kez adlarını anmaya değer. Festina lente, yani “yavaşça acele et,” imparator Augustus’un sevdiği bir sözdü: daha erken varmak için ölçülü hareket et. Talim dünyasından gelen “yavaş pürüzsüzdür, pürüzsüz hızlıdır” sözünün sağlam bir kökeni yoktur, bu yüzden onu olsa olsa bir sezgi aracı olarak alın; panik yerine kontrol ister ve gerçek anlamda yavaşlamakla ilgisi yoktur. Stephen Covey’nin yedinci alışkanlığı “testereyi bile,” baltasını bilemek için duran bir oduncu hakkındaki popüler hikâyenin alıntılanabilir versiyonudur. O balta hikâyesi sık sık Abraham Lincoln’a atfedilir, ama söylediğine dair sağlam bir kanıt yoktur, bu yüzden alıntı yerine Covey’ye yaslanın.

Yeniden iş vergisi#

Ward Cunningham “teknik borç” terimini 1992 tarihli bir deneyim raporunda ortaya attı ve benzetme hâlâ geçerli. İlk seferde yazılan kodu göndermek borca girmek gibidir, diye yazdı: “Az miktarda borç, hızla bir yeniden yazımla geri ödendiği sürece geliştirmeyi hızlandırır” ve “tam-doğru-olmayan koda harcanan her dakika, o borcun faizi olarak sayılır.” Faiz soyut değildir. Testi olmadan giden bir özellik bugün ucuzdur. Onun yakınındaki sonraki üç değişikliğin her biri bir şeyi bozma riski taşır ve her düzeltme, testin alacağından daha uzun sürer. Yeniden iş vergisi budur: haftanızın, bir sonraki şeyi inşa etmek yerine yakın zamanda gönderilen işi onarmaya giden payı.

Yangın söndürme bunu katlar. Bakımı sürekli atlayan bir ekip, haftanın daha büyük kısmını olaylara, hotfix’lere ve “bu neden yavaş” araştırmalarına harcar. O zaman doğrudan yol haritasından çalınır. Bir kod tabanında, bir ödeme uç durumu etrafında atlanan bir entegrasyon testi, sonraki haftalarda bir dizi üretim düzeltmesine dönüştü. Her biri acildi ve her biri planlı işi böldü. Testi yazmak ucuz olurdu. Faiz planlanmamış zaman olarak ödendi.

Borcu bilerek almak#

Zıt yöndeki hata, her kestirmeyi bir başarısızlık gibi görmektir. Değildir. Cunningham’ın kendi çerçevesi zaten borcun, hemen geri ödenirse sorun olmadığını varsayıyordu; tehlike, asla geri ödenmeyen borçtur. Martin Fowler bunu iki eksenli bir dörtgenle netleştirdi: borç bilinçli ya da farkında olmadan olabilir ve ihtiyatlı ya da pervasız olabilir. Pervasız-farkında olmadan alınan borç, yani “katmanlama da ne?” türü, bir ekibi sessizce gömen şeydir. İhtiyatlı-bilinçli borç ise meşru bir araçtır: temiz tasarımı bilirsiniz, şimdi gönderip sonuçlarıyla ilgilenmeyi seçersiniz ve sonucu yazarsınız.

Pratik kural buradan çıkar: borcu bilerek alın ve bir takvime göre geri ödeyin.

Eklemeden önce refactor et#

Kod size direndiğinde sezgi, yeni özelliği üstüne eklemek ve sonra temizlemektir. Temizlik nadiren gelir, çünkü “sonra”nın hiçbir zaman boş vakti olmaz. Daha iyi sıralama Kent Beck’in 2012’de paylaştığıdır: “değişikliği kolaylaştır, sonra kolay değişikliği yap.” Yeni kodun temizce oturması için önce dağınık kısmı refactor edin, sonra ekleyin. Fowler bunu hazırlık amaçlı refactoring olarak belgeler ve ekonomisi basittir: temizlik bedelini, her gelecekteki değişikliğe faiz ödemek yerine, zaten dokunmak zorunda olduğunuz kod üzerinde bir kez ödersiniz.

Bu en iyi küçük ve sürekli adımlarla işler. Büyük patlamalı yeniden yazım, daha şık bir takım elbise giymiş borç tuzağıdır: geç teslim edilir ve mevcut kodun zaten idare ettiği eski hataları geri getirir. Daha hafif bir alışkanlık daha çok fayda sağlar. Bu koda yakında yine dokunacaksanız ve o size direniyorsa, dokunduğunuz kısmı temizleyin ve onu bulduğunuzdan biraz daha iyi bırakın. Bir ekipte, bir özelliğe başlamadan önce yapılan küçük bir yeniden adlandırma ve kısa bir metot çıkarma, yavaş ve riskli görünen bir değişikliği hızlı bir değişikliğe çevirdi, çünkü özellik artık kodun şekliyle boğuşmuyordu.

Testler ve CI ürünün parçasıdır#

Testler, korkusuzca hızlı hareket etmenizi sağlayan şeydir. Onlarsız her değişiklik, üç dosya öteki bir şeyin az önce bozulup bozulmadığı üzerine bir kumardır. Onlarla, aynı gün refactor eder ve gönderirsiniz, çünkü test paketi yanıldığınız anda size söyler.

Pipeline da sayılır. Kararsız testler, yavaş build’ler ve atlanan kontroller kendi başlarına birer teknik borçtur ve tüm ekibin yaptığı her commit’i vergilendirir. Rastgele başarısız olan bir build, insanları hataları okumayı bırakmaya alıştırır ve bir kez kimse okumaz olunca, gerçek bir regresyon fark edilmeden içeri sızar. Pipeline’ı düzeltmeye, ürünü düzeltmeye ayırdığınız gibi zaman ayırın, çünkü kırmızı ya da yavaş bir build herkesin, her push’ta ödediği bir maliyettir. CI sağlığını birinci sınıf bir sinyal olarak panoya alın ve onu yeşil tutan işi takvime bağlayın.

Kahramanlık yerine sürdürülebilir tempo#

Aynı mantık, bir ekibin haftalarını nasıl geçirdiğine kadar ölçeklenir. Agile Manifesto bunu sekizinci ilkesinde açıkça söyledi: “Agile süreçler sürdürülebilir geliştirmeyi teşvik eder. Sponsorlar, geliştiriciler ve kullanıcılar sabit bir tempoyu süresiz olarak koruyabilmelidir.” Extreme Programming bu fikrin tohumunu daha sert bir versiyonla attı. Kent Beck’in Extreme Programming Explained kitabı kırk saatlik bir hafta ve üst üste iki hafta fazla mesai yapmama kuralını getirdi. Topluluk sonra bunu “sürdürülebilir tempo” olarak yeniden çerçeveledi, ki bu, sabit bir sayıdan daha iyi bir nüans yakalar.

Bir kriz temposu (crunch), bir sonraki sprintin kapasitesinden kötü bir kurla borç alır. Tarih tutturulur ve sonraki haftalar, krizin yarattığı hatalara ve talep ettiği toparlanmaya gider. Daha kötüsü, tekrarlanan kahramanlıklar ekibe ve paydaşlarına kahramanlık beklemeyi öğretir, böylece istisna plan hâline gelir.

DORA korelasyonu#

Sezgisel itirazın doğrudan karşılanması gereken yer burasıdır. Bakım gönderime harcanmayan zamansa, bakımı ağır bir ekip elbette daha az gönderir. Accelerate kitabında özetlenen DORA araştırma programı bunun tersini buldu. Dört teslimat anahtarı şunlardır: gönderim sıklığı, değişiklikler için lead time, değişiklik başarısızlık oranı ve başarısız gönderimden toparlanma süresi. Üretkenlik anahtarları, istikrar anahtarlarıyla ödünleşmek yerine birlikte hareket eder. Sık gönderim yapan ekipler aynı zamanda daha az başarısız olur ve daha hızlı toparlanır.

Mekanizma, baştan beri anlatılan şeydir. Temiz kod ve güvenilir bir pipeline, sık ve düşük riskli gönderimleri mümkün kılan şeydir; sık ve düşük riskli gönderimler ise lead time’ı kısa tutan şeydir. Bu sitedeki ayrı bir rehber aynı madalyonun üretkenlik yüzünü işler, commit’ten üretime lead time’ı azaltmak, ve aynı bulguya varır: ikisini de aynı pratikler kazandırır.

Ne zaman istisna yapmalı#

Varsayılan, istikrarlı ve bakımı içine alan bir tempodur. Temizliği atlamayı haklı çıkaran üç dar durum vardır ve istisnanın istisna kalması için adlarını anmaya değer.

Silinecek olan atılabilir bir prototipi temizlemeye değmez; bütün mesele öğrenip atmaktır. Canlı bir olay altındaki bir güvenlik ya da erişilebilirlik hotfix’i şimdi gitmelidir, temizlik kaydedilip aynı hafta geri ödenmek üzere. Ve bilinen, kısa vadeli bir kestirmeyle gerçek bir son tarih, ihtiyatlı ve bilinçli borcu haklı çıkarabilir: yazın, geri ödemeyi planlayın ve ekibe söyleyin. Bu üçünün dışındaki her şey yaygın durumdur: küçük temizliği şimdi yapın.

Disiplinin kırıldığı yerler#

Yükselen story point’ler ile yükselen bir değişiklik başarısızlık oranı bir uyarı işaretidir: sayı artıyor ama arkasındaki iş kötüleşiyor. Değişiklik başarısızlık oranı ve diğer DORA ölçütleri bunu yakalar; story point toplamları yakalamaz. Son tarih baskısı altında testleri ve CI’ı isteğe bağlı saymak aynı hatanın başka bir yerdeki hâlidir. Pipeline ürünün parçasıdır ve sıkışık bir takvim bunu değiştirmez.

Dörtgeni kullanın ve ihtiyatlı, bilinçli borcu bilerek alın. Tekrarlanan kahramanlıklar ekip düzeyinde aynı tuzağı yaratır. Herkes kriz beklemeyi öğrenir.

Neyi ölçmeli#

İstikrarlı bir tempo bir yatırımsa, getirisini görebilmeniz gerekir. Birkaç sinyal yardımcı olur ve çoğunu izlemeye başlamak hiçbir şeye mal olmaz.

• Değişiklik başarısızlık oranı: düzeltme gerektiren bir arızaya yol açan gönderimlerin payı, dört DORA anahtarından biri. Atlanan bakım bunu yukarı iter.
• Değişiklikler için lead time ve gönderim sıklığı: üretkenlik anahtarları. Sağlıklı bir tempo bu ikisini korumalı ya da iyileştirmelidir.
• Başarısız gönderimden toparlanma süresi: yangın söndürme yükünün doğrudan bir okuması; bakım arttıkça düşmelidir.
• Yeniden iş oranı: yakın zamanda gönderilen işi onarmak olan işin payı, atlanan temizliğe ödediğiniz faiz için iyi bir göstergedir.
• Kapasitenin payı olarak bakım bütçesi: açık bir dilim adlandırmak, onun sıkıştırılıp bir kenara itilmesini önler. Kapasitenin beşte biri gibi bir kısmı ayırmak yaygın bir ekip tercihidir; bir sektör kıyaslaması olmadığı için sayıyı kopyalamak yerine bilinçle belirleyin.
• CI sinyal sağlığı: build süresi ve kararsız test sayısı, pipeline borcunun üretime ulaşmadan önce görünen öncü göstergeleridir.

Varsayılan, bu üç durumun dışında geçerlidir ve geri ödeme genellikle bir sprint yerine bir çeyrek boyunca görünür hâle gelir. Pratik bir sonraki adım, sürekli uzak durduğunuz o kod parçasını bir dahaki sefere içindeyken temizlemektir.

Kaynaklar#

• FranklinCovey: The 7 Habits of Highly Effective People (7. Alışkanlık, Testereyi Bile) (yeni sekmede açılır) - Covey’nin yenilenme alışkanlığı: kesmeye devam etmek için durup aracı bile. Lincoln alıntısı yerine çerçeve için sağlam kaynak.
• Ward Cunningham: Borç metaforunu açıklıyor (c2 wiki) (yeni sekmede açılır) - Cunningham’ın kendi sözleriyle, teknik borç metaforunun ne demek olduğu ve ne demek olmadığı.
• The WyCash Portfolio Management System, OOPSLA ‘92 (ACM) (yeni sekmede açılır) - “Teknik borç” teriminin ortaya atıldığı 1992 tarihli deneyim raporu; birincil kaynak.
• Martin Fowler: TechnicalDebtQuadrant (yeni sekmede açılır) - Her borcun eşit olmadığını gösteren bilinçli/farkında olmadan ve ihtiyatlı/pervasız çerçevesi.
• Martin Fowler: Hazırlık amaçlı refactoring örneği (yeni sekmede açılır) - Kent Beck’in “değişikliği kolaylaştır, sonra kolay değişikliği yap” sözünü belgeler; eklemeden önce refactor.
• Agile Manifesto: Manifesto’nun ardındaki ilkeler (yeni sekmede açılır) - Sürdürülebilir tempo üzerine 8. ilke: “sabit bir tempoyu süresiz koruyabilmek.” Birincil kaynak.
• DORA: Yazılım teslimat performansı metrikleri (dört anahtar) (yeni sekmede açılır) - Dört anahtar ve hız ile istikrarın ödünleşmek yerine birlikte yükseldiği bulgusu.
• Quote Investigator: “baltanı bilemeye zaman ayır” (yeni sekmede açılır) - Lincoln atfının uydurma olduğunu doğrular; en erken eşleşmeler sözü Lincoln yerine anonim bir oduncuya verir.
• slow is smooth, smooth is fast (Wiktionary) (yeni sekmede açılır) - İfadenin talim dünyasındaki kullanımını ve belirsiz kökenini kaydeder; onu folklor olarak ele almayı destekler.
• Ron Jeffries: Extreme Programming ve sürdürülebilir tempo (yeni sekmede açılır) - XP’nin kırk saatlik hafta pratiği, sonra sürdürülebilir tempo olarak yeniden çerçevelendi.
• Accelerate (Forsgren, Humble, Kim) (yeni sekmede açılır) - DORA’nın ardındaki araştırma; yüksek performanslıların hızı ve istikrarı birlikte elde ettiğine dair kitap boyu kanıt.