XP, TDD ve vibe coding: Kent Beck’in Programmatic Engineer röportajından bazı bölümlerin çevirisi
(stdy.blog)- XP ve TDD’nin babası Kent Beck’in Programnatic Engineer röportajındaki beni etkileyen birkaç bölümü özetliyorum
- Kent Beck’i sevenlere tam sürüm videoyu izlemelerini tavsiye ederim
S. XP’nin özü nedir?
Şu dört etkinliği yapmaktır.
- Ne yapılması gerektiğini anlamak
- 1’i yapabilmemizi sağlayacak yapıyı anlamak
- 2’yi kullanarak 1’i gerçekleştirmek
- 3’ün beklendiği gibi çalışıp çalışmadığını doğrulamak
Hepsi bu. Ve zamanı çok küçük parçalara bölersin; her saat bu dört etkinliğin hepsini biraz biraz ama mutlaka yaparsın.
S. O zaman pair programming XP’de zorunlu değil mi?
İlk kez bir XP ekibi yürüttüğüm dönemde, her 3 haftada bir sürüm çıkarıyorduk ve elbette hatalar oluyordu.
Yayın sonrası bulunan hataların örüntüsünü analiz ettiğimizde, bu hataların tamamının tek başına geliştirilen koddan çıktığını gördük. Tersinden söylersek, pair olarak geliştirilen kodda üretim ortamında raporlanan hiçbir kusur yoktu.
S. Yani zorunlu değil ama güçlü biçimde öneriliyor, öyle mi?
O da değil. Deney yapın diyorum. Normalde nasıl geliştiriyorsanız öyle geliştirebilirsiniz. Yeter ki farkında olarak.
Sürekli tasarım, sürekli doğrulama, sürekli gerçekleştirim ya da müşteriyle sürekli etkileşim; her neyse, bunun getirisini almak istiyorsunuz ama hep yaptığınız gibi yaptığınız için olmuyorsa, yöntemi değiştirmeniz gerekir.
Biri gelip bana “Kent, ben TDD yapmıyorum” derse, ben de şöyle cevap veririm: “Ee yani?”
Mevcut kodunuzdaki kusur yoğunluğundan ve tasarım kararlarına dair geri bildirim düzeyinden memnunsanız sorun yok. Ama memnun değilseniz, pair programming’i de TDD’yi de deneyin diyorum.
S. Madem konu açıldı, TDD’yi neden yarattın?
Ben çok kaygılı ve endişeli biriyim; benim için programlama da sürekli bir kaygı kaynağıydı. Acaba neyi unuttum? Acaba neyi bozdum?
Ama TDD ile geliştirdiğimde bu kaygı kayboluyor. Artık başarısız olabilecek başka bir test senaryosu aklıma gelmiyor mu? O zaman programımın çalıştığına güvenebilirim. En ufak bir huzursuzluk mu doğdu? O zaman gidip bir sonraki test senaryosunu yazarım.
Elbette kusur yoğunluğunu azaltmak, tasarım kararlarıyla ilgili geri bildirimi daha hızlı almak, uygulama tasarımını evrimleştirmek gibi TDD’nin pek çok teknik faydası var. Ama programlamaya dair kaygıdan özgürleşmiş olmak, programlamanın yarattığı duygusal deneyimin tamamen değişmiş olması... Benim için en önemlisi bu. TDD’yi yaratma nedenim buydu.
S. TDD yapınca iyi tasarımın araya girecek alan bulamadığına dair John Ousterhout eleştirisi hakkında ne düşünüyorsun?
(Onu aktaran kişinin notu: John Ousterhout, önemli bir eser olan Philisophy of Software Design kitabının yazarıdır ve birkaç ay önce Programmatic Engineer podcast’ine katılarak TDD’ye eleştirel bir bakış da sunmuştu.)
Onun yanlış anladığı bir nokta var. Bu sadece bir kararın sonucu. Eğer TDD’yi sadece Red-Green döngüsünün tekrarı olarak görürseniz, elbette orada tasarımın araya girecek alanı kalmaz.
Bir TDD pratiği uygulayıcısı olarak ben her zaman soyutlamanın farklı seviyeleri arasında gidip gelirim. Örneğin:
- Şu an Red durumundayım. Bir sonraki test senaryosunu geçirmek için (Green) bunu nasıl gerçekleştirmeliyim?
- Bir şey zor geliyor. Neden zor?
- Green’e ulaşacak implementasyonu kolaylaştırmak için tasarımı nasıl değiştirmeliyim?
- Bu fikri ne zaman devreye almalıyım? Şimdi mi, sonra mı?
- Şimdi alacaksam ne kadarını yapmalıyım? O anda yapabileceğim kadar küçük mü, yoksa daha büyük bir parça hâlinde mi?
Yani testi yazmadan önce ben her zaman bir tasarım anı yaşarım.
Gerçekleştirmeden önce arayüzle ilgili kararlar alırım, Red testi oluştururum ve Red durumunu sevmediğim için mümkün olan en kısa sürede Green yaparım. Green olduktan sonra kaygı bir süreliğine çekilir ve düşünmek için alan açılır. “Hımm, geçti ama bu başka durumlarda çalışmayacak. Uygulamayı daha genel hâle getirmeliyim.”
Red mi? Green yaparım. Green mi? Bir nefes alır ve düşünürüm. Benim TDD döngüm bu.
S. Bazen implementasyon bana çok bariz geliyor; önce implementasyonu yazıp sonra Red-Green testlerini yaptığım oluyor. Bu yaklaşım hakkında ne düşünüyorsun?
Bunun nedeni muhtemelen “bu implementasyon biçimi doğrudur” varsayımıyla hareket etmen. Bu varsayım ne kadar doğruysa, testleri önce yazmanın sağlayacağı fayda da doğal olarak o kadar azalır.
Ama ben hep şöyle düşünürüm: “Ben öğrenmeye ve deneyim kazanmaya devam edeceğim; şu an da hayatımın en cahil anındayım.”
Yani sürekli öğreneceğimi ve durumun değişeceğini varsayıyorum. Ne kadar çok şey öğrenmem gerekiyorsa ve koşullar ne kadar çok değişiyorsa, kararları olabildiğince sonraya bırakmak isterim. Bu genel bir ilkedir. Flörtte de böyledir, yemek yaparken de.
Ne kadar çok şeyi öngörebilirsen, o kadar büyük sıçramalar yapabilirsin. Ama programlama yaparken en sevdiğim an şu: Her şeyi bildiğimi sanıp hızla ilerlerken bir anda çok daha iyi bir implementasyon yolu olduğunu fark ettiğim an. Ben bu anları olabildiğince sık yaşamak istiyorum. Bu yüzden TDD yapıyorum.
Kafamda resim netse ve hangi girdinin hangi çıktıyı üreteceğinden eminsen, tabii ki gidip doğrudan implementasyonu yazabilirsin. Ama ne kadar çok hata yapıyorsan, ne kadar çok öğreniyorsan ve dünya ne kadar öngörülemez biçimde değişiyorsa, kendini şimdi bağlamayıp kararı sonraya bırakmak o kadar avantajlı olur.
S. Yapay zeka ile birlikte kod yazarken de eskisi gibi TDD ile mi geliştiriyorsun?
Bunu basitçe cevaplamak zor.
Ben testleri, yapay zekayla iletişim kurmanın bir aracı olarak; daha çok da yapay zekanın neyi yanlış yaptığını ona söylemenin bir yolu olarak kullanıyorum. Bu arkadaş sürekli testlerimi silmeye ya da değiştirmeye çalışıyor; ben de her seferinde onu azarlıyorum. Testlerim doğru, işini düzgün yap diyorum.
Yapay zeka uzun vadede kötü kararlar verme eğiliminde. Bağımlılığı azaltmakta ve kohezyonu artırmakta da gerçekten zayıf. Ne yapması gerektiğini çok net söylersen bazen başarabiliyor ama genel olarak tasarım konusunda iyi olduğunu söyleyemem.
Bu yüzden çok fazla test hazırlıyorum. Bunları, yapay zeka bir şeyleri dağıtıp bozuyor mu diye yakalamak için kullanıyorum.
(Onu aktaran kişinin notu: Kent Beck’in vibe coding içinde TDD’yi nasıl kullandığıyla ilgili şu yazıya bakabilirsiniz.)
S. “Testleri asla düzeltme, test geçmiyorsa geçene kadar sadece implementasyon kodunu değiştir” gibi agent kuralları yaygınlaşırsa işler daha rahat olacak gibi geliyor. Bugünler, 2000’lerde önemli olan şeyleri yeniden keşfettiğimiz bir dönem gibi de hissettiriyor. Ne düşünüyorsun?
Deney yapmaya devam etmek gerekiyor. Mümkün olan her şeyi denemeliyiz. Çünkü şu anda gerçekten en iyi olanın ne olduğunu bilmiyoruz.
Neyin “ucuz”, neyin “pahalı” olduğuna dair ufuk tamamen değişti. Eskiden pahalı ya da zor diye yapılmayan pek çok şey artık saçma denecek kadar ucuz hâle geldi.
Bir gün otomobillerin aniden bedava olduğunu düşünsenize. Elbette bir şeyler değişir; ama bunun ikinci, üçüncü dereceden etkileri ne olur? Bunu kimse öngöremez. O yüzden şu anda yapabileceğimiz tek şey, çeşitli şeyleri deneyip görmek.
S. 50 yılı aşkın süredir programlama yapıyorsun ama bugünlerde en çok eğlendiğin dönemin bu olduğunu söyledin. Ne demek istiyorsun?
Büyük fikirlerimi hayata geçirmek her zamankinden daha kolay hâle geldi. Bu fikri yapay zekanın uygulayıp uygulayamayacağını, nasıl uygulayacağını izlemek ve yönlendirmek inanılmaz derecede bağımlılık yapıcı. Ne zaman iyi sonuç vereceğini pek bilmiyorsun; sihir gibi çalıştığında da insanı mest ediyor. Bu yönüyle slot makinesine benziyor. Yürüyüşe çıkmadan ya da öğle yemeğine gitmeden önce bile, bu şeyi çalıştırıp kendi hâline bırakmak için bir prompt daha yazsam mı dürtüsüne sürekli kapılıyorum.
İki yıl önce şu tweet’i atmıştım: “ChatGPT kullanmayı denemekte isteksizdim, nedenini bugün anladım. Sahip olduğum becerilerin %90’ının değeri artık $0 oldu. Geriye kalan %10’un etkisi ise 1000 kat arttı. Becerilerimi yeniden ayarlamam gerekiyor.”
> I've been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant.
>
> The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.
>
> -- Kent Beck 🌻 (@KentBeck) April 18, 2023
(Onu aktaran kişinin notu: Bu tweet o dönemde çok konuşulunca Kent daha sonra biraz daha uzun bir yazı da yazmıştı.)
O zamanlar %90’ın ne, %10’un ne olduğu konusunda hâlâ keşif aşamasında olduğumu söylemiştim; artık buna kısmen cevap verebiliyorum. Cesur bir vizyona sahip olmak, o vizyona giden kilometre taşlarını koyabilmek, tasarımı sürekli ayarlayarak ilerlemek ve ilerlerken karmaşıklığı kontrol altında tutmak. Belirli bir dilin sözdizimini bilmekten (örneğin Rust’ta &, *, [ işaretlerini nereye koyacağını bilmekten) çooook daha önemli beceri bu.
Henüz yorum yok.