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 az değil, 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 değil, bilinçli ve takvime bağlı bir karar olarak ele alın. Bu, bir özellik gönderip sonra çıkan dağınıklıkla yaşamış, junior’dan senior’a çalışan mühendisler için bir pratik rehberdir. Borcun neye mal olduğunu, bir refactor duraklamasının ne zaman geri ödeme yaptığını, testlerin ve CI’ın neden gerçek iş olduğunu ve sürdürülebilir üretkenliğin kahramanlık sprintlerini neden geçtiğini anlatır.

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 bir gerçek değil, bir sezgi aracı olarak alın; gerçekten yavaş olmak demek değildir, panik yerine kontrollü olmak demektir. 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ıya değil Covey’ye yaslanın. Yazının geri kalanı bu sözleri geride bırakıp mühendislik pratiğinde kalıyor.

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 olmadı ve var olan en kötü para birimiyle ödendi: planlanmamış zaman.

Her borç kötü değildir: bilerek al

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örtgene keskinleş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. Mesele “asla borç alma” değildir. Mesele “bilerek al ve bir takvime göre geri öde”dir. Adını koyduğunuz, süresini belirlediğiniz ve ekibe söylediğiniz bir borç bir karardır. Sessizce, geri dönme planı olmadan alınan aynı kestirme ise sadece son tarihli bir çürümedir.

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, büyük patlamalı bir yeniden yazımla değil, küçük ve sürekli adımlarla işler. 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 çıkarım, 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. Duraklamanın aynı görevin içinde geri ödeme yapması budur.

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. Son tarih baskısı altında testleri atlamak, var olan en yüksek faiz oranıyla borç almaktır.

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ığı birinci sınıf bir sinyaldir, sakin bir öğleden sonrasının angaryası değil.

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 fikri daha sert bir versiyonla ekti. 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. Çürüyen yüksek çıktı hız değildir. Bir borçtur.

Hız ve istikrar bir ödünleşme değildir

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. Hız ve istikrar birlikte yol alı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: hızı, istikrardan feragat ederek satın almazsınız, ikisini de aynı pratiklerden alırsınız.

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, ki orada şimdiki küçük temizlik, sonraki faizden daha ucuzdur.

Yaygın tuzaklar

• Hareketi ilerlemeyle karıştırmak. Yükselen story point’ler ile yükselen bir değişiklik başarısızlık oranı, hız değil çürümedir. Puan sayılarını değil, sonuçları izleyin.
• Büyük patlamalı yeniden yazım. Tüm temizliği gelecekteki bir “yeniden yazım çeyreğine” ertelemek genelde geç teslim eder ve eski hataları geri getirir. Küçük, sürekli refactor’leri tercih edin.
• Testleri ve CI’ı isteğe bağlı saymak. Son tarih altında onları bırakmak en yüksek oranla borç almaktır. Pipeline ürünün parçasıdır.
• Ya hep ya hiç borç. Her borcun kötü olduğuna inanmak aşırı cilaya götürür; borcun bedava olduğuna inanmak çöküşe götürür. Dörtgeni kullanın ve ihtiyatlı, bilinçli borcu bilerek alın.
• Balta hikâyesini gerçek diye alıntılamak. Popüler ama uydurmadır. Onu ihtiyatla belirtin ve bunun yerine Covey’yi kaynak gösterin.
• Krizi varsayılan yapmak. Tekrarlanan kahramanlıklar beklenen plan hâline gelir. Sürdürülebilir tempoyu norm, krizi ise nadir ve bilinçli bir istisna tutun.

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ı: iyileştirme 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 bunları takas etmemeli, 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ı değil, bu yüzden bir sayıyı kopyalamak yerine onu bilinçle belirleyin.
• CI sinyal sağlığı: build süresi ve kararsız test sayısı, o borç üretime ulaşmadan görünen, pipeline borcunun öncü göstergeleridir.

Varsayılan olarak istikrarlı, bakımı içine alan bir tempoyu seçin ve borcu, bilerek aldığınız ve bir takvime göre geri ödediğiniz bir karar olarak ele alın. İstisnaya yalnızca üç dar durumda başvurun: atılabilir bir prototip, canlı bir olay ya da borcun adını koyup geri ödemesini planladığınız gerçek bir son tarih. Geri ödeme tek bir sprintte değil, bir çeyrek boyunca görünür, ki paydaşlarla dürüst iletişim zorluğu tam da budur. Sıradaki adım küçüktür: sürekli uzak durduğunuz o kod parçasını seçin ve bir dahaki sefere içindeyken dokunduğunuz kısmı temizleyin.

Kaynaklar

• FranklinCovey: The 7 Habits of Highly Effective People (7. Alışkanlık, Testereyi Bile) - 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) - Cunningham’ın kendi sözleriyle, teknik borç metaforunun ne demek olduğu ve ne demek olmadığı.
• The WyCash Portfolio Management System, OOPSLA ‘92 (ACM) - “Teknik borç” teriminin ortaya atıldığı 1992 tarihli deneyim raporu; birincil kaynak.
• Martin Fowler: TechnicalDebtQuadrant - 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 - 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 - 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) - Dört anahtar ve hızla istikrarın bir ödünleşme değil, ilişkili olduğu bulgusu.
• Quote Investigator: “baltanı bilemeye zaman ayır” - Lincoln atfının uydurma olduğunu doğrular; en erken eşleşmeler Lincoln’a değil, anonim bir oduncuya aittir.
• slow is smooth, smooth is fast (Wiktionary) - İ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 - XP’nin kırk saatlik hafta pratiği, sonra sürdürülebilir tempo olarak yeniden çerçevelendi.
• Accelerate (Forsgren, Humble, Kim) - 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.