Önce çalışsın, sonra doğru olsun, en son hızlansın

Bu cümle aklımın bir köşesinde kalmış. Eskiden çok okurdum bu tip Medium postlarını ve kitapları vs. Yıllardır zihnimin köşesinde bir yerde kalan bu sıralamayı çokça kişiyle paylaşmışımdır. Ben bunu nereden hatırlıyorum ve ne zaman alıştım diye sorduğumda biraz daha detaylı araştırdım ve cümlenin Kent Beck’e mal edildiğini gördüm, ama aslında daha eskiymiş. Stephen Johnson ve Brian Kernighan 1983’te Byte dergisinde C üzerine yazdıkları yazıda aynen şunu söylüyor: “strateji kesinlikle şu: önce çalıştır, sonra doğru yap ve en son hızlandır.”

Çoğu kişi bunu yapılacak üç şey gibi okuyor. Ben bir sıra olarak okuyorum: her adımın kendi “bitti” tanımı var ve her biri bir sonrakini güvenli hâle getiriyor.

Fig. 1 · Üç kapı, her birinin kendi "bitti"si. Hız kısmı bir ölçüm döngüsü. Çalışan koddan doğrudan hızlıya atlayan kestirme de tam kaçınman gereken yol.

Önce çalışsın

“Bitti” demek, ihtiyacın olan davranışın testleri geçiyor demek. Güzel olması gerekmiyor, hızlı olması hiç gerekmiyor. Doğru olması ve bunu gösterebilmen gerekiyor, çünkü bir sonraki adım o testlere bağlı.

Sonra doğru olsun

Şimdi ortalığı toparlıyorsun ve testler bu sırada yeşil kalıyor. Bu, ilke 01’deki dar anlamıyla refactor: yapı yeni, davranış aynı.

Ward Cunningham’ın 1995’te açtığı ilk wiki, C2 wiki, extreme programming ve design pattern’ların ilk tartışıldığı yerlerden biri. Orada “doğru”nun ne demek olduğu üzerine uzun bir tartışma var. Kimine göre temiz tasarım, kimine göre uç durumların düzgün ele alınması. Bence ikisi de: özel durumlar halledilmiş ve gelecek ay seve seve değiştireceğin bir kod.

En son hızlansın

Bu adım için bizi zaten uyarmış iki isim var, ikisi de bunu söylemeyi fazlasıyla hak etmiş insanlar.

Donald Knuth, 1974: “Küçük verimlilikleri, diyelim ki zamanın yaklaşık %97’sinde unutmalıyız: erken optimizasyon bütün kötülüklerin anasıdır. Yine de o kritik %3’teki fırsatları kaçırmamalıyız.” İkinci cümle genelde atlanıyor. Knuth optimizasyona karşı değildi, nereyi optimize edeceğini tahmin etmeye karşıydı.

Rob Pike, 1989: “Bir programın zamanını nerede harcayacağını bilemezsin. Darboğazlar beklenmedik yerlerde çıkar, o yüzden darboğazın orası olduğunu kanıtlamadan tahmin yürütüp hız hilesi eklemeye kalkma.” Bir sonraki kuralı tek kelime: “Ölç.”

Kendin dene:

Fig. 2 · Örnek bir profil, gerçek bir ölçüm değil. Asıl mesele şekil: bir parça diğerlerini ezip geçiyor ve genelde herkesin bahse girdiği parça o olmuyor.

Ölçümün olunca “hızlı” bir döngüye dönüşüyor: sıcak kısmı değiştir, yine ölç, hedefi tutturunca dur. O son kısım önemli. Hedef yoksa ne zaman bittiğini hiç bilemezsin.

Sıra neden önemli?

Doğru olmadan hızlandırmak en belirgin hatalardan biri. Dağınık kodun üstüne zekice numaralar koyunca hepsi birbirine yapışıyor, bir sonraki değişiklikte hem dağınıklıkla hem de o numaralarla uğraşıyorsun. Çalışmadan doğru yapmaya uğraşmanın da bir bedeli var: henüz işini yapmayan bir kodu cilalıyorsun.

Yıllardır aklımda duran bu üç adımı ilk kim söyledi diye araştırınca 1983’te C üzerine yazan iki kişiye vardım. Kırk küsur yıl geçti, diller değişti, kodun çoğunu artık agent’lar yazıyor ama sıra hâlâ aynı. En son ne zaman bir şeyi hızlandırdın, ve öncesinde bir ölçüm yapmış mıydın?