- Açık kaynak bir kütüphanedeki bir bug'ı izlerken debugger'ın çalışmaması sorunu ortaya çıktı
- Kod çalıştırılmış olmasına rağmen breakpoint'lerin yok sayılması durumu görüldü ve sorunu başka yöntemlerle bulmaya çalıştı
- Log çıktısı eklemek gibi dolaylı tanı denemeleri yapıldı ancak istenen içgörü elde edilemedi
- Sonunda debugger yapılandırma hatası düzeltilince programın davranışı ayrıntılı biçimde gözlemlenebildi ve bunun sayesinde bug çözüldü
- Sorunu çözmeye odaklanırken aracın kendisindeki kusuru gözden kaçırma deneyimi üzerinden, geliştiricilerin verimli sorun çözümü için önce araçlarını düzeltmesi gerektiği vurgulanıyor
Bug teşhisi sırasında ortaya çıkan sorun
- Bakımı yapılan açık kaynak kütüphanedeki bir bug'ı ararken debugger'ın breakpoint'leri yok sayması sorunu yaşandı
- Kodun ilgili satırı çalıştırdığı kesindi ama program durmadan tamamlanıyordu
- Sorunu çözmeye odaklanıldığı için debugger problemi görmezden gelinip başka yaklaşımlar denendi
- Kod değişiklikleri ve log ekleyerek teşhis girişimleri yapıldı ancak faydalı bilgi elde edilemedi
Debugger'ı düzeltme ve sorunu çözme
- Debugger sorununu çözmeye karar verildi ve tek satırlık bir yapılandırma değişikliğiyle sorun giderildi
- Düzeltmeden sonra programın davranışı ayrıntılı olarak gözlemlenebildi
- Bu bilgiye dayanarak bug başarıyla çözüldü
Farkındalık ve çıkarılan ders
- Bug'ı düzeltme tutkusu yüzünden aracın sorununu gözden kaçırmaya yol açan paradoksal durum fark edildi
- Araç düzgün çalışmadığında sorun çözme verimliliğinin düştüğü bizzat deneyimlendi
- Geliştiricilerin ihtiyaç duyduğu şeyin, sorundan önce aracı kontrol etme ve düzeltme alışkanlığı olduğu vurgulandı
- “Fix your tools” sözüyle, tüm programcılara araçların önemini hatırlatan bir mesajla yazı son buluyor
1 yorum
Hacker News görüşleri
30 yıllık deneyimim var ama bugünlerde geliştirme araçları fazla bozuk
Linux'ta Clio ile kod yazıyorum; yıllardır hatalar giderek kötüleşiyor
Artık sadece “olmuyorsa olmuyordur” deyip geçiyorum. Hayat kısa; başkasının kodunu da düzeltmeye ayıracak vaktim yok
Bir sorunu düzeltmeye çalışınca sonunda "yak shaving" tuzağına düşüyorsun
Küçük bir sorunu çözmeye çalışırken birbirini tetikleyen sayısız ayrıntılı işle uğraşmak gerekiyor
İlgili videoyu burada izleyebilirsiniz
Bazen araçları ve kütüphaneleri toparlamak üretkenliği patlatıyor, başka zamanlarda ise doğrudan hardcode etmek daha hızlı oluyor
Yapay zeka araçları cilalamaya yardımcı oluyor ama aynı zamanda kapsamı da büyütüyor; sonuçta yine araç yönetimine benzer miktarda zaman harcıyorsun
Sonuçta bu bir duygusal erteleme (procrastination) meselesi. Büyük resmi düşünmek istemediğin için küçük düzeltmeleri tekrar edip duruyorsun ya da tam tersine genel tasarımı erteliyor, sadece araçların ayrıntılarıyla uğraşıyorsun
Aslında bu, gerekli sürtünme ve rahatsızlıkla başa çıkma süreci de olabiliyor
Ama bu rahatsızlığın gerçekten gerekli olup olmadığını sürekli sorgulamak lazım
Tekrarlanan işleri otomatikleştirmek ya da kısaltmak için 10-15 dakika harcamak, aslında gelecekteki zamandan satın almak demek
Sonuçta teknik borç er ya da geç ödenmek zorunda; bu yüzden onu azar azar ödeme alışkanlığı edinmek gerekiyor
Mühendislik sonuçta sürekli bileyi taşı sürmek gibi bir süreç
Kent Beck'in dediği gibi “önce değişikliği kolay hale getir, sonra kolay değişikliği yap” yaklaşımını seviyorum
Sadece özellik eklemektense kodu iyileştirmek çok daha tatmin ediciydi
Yapay zeka aynı kodu defalarca tekrar etse de bunda bir gariplik görmüyor; bu yüzden yapılandırma ve yeniden kullanım oluşmuyor
Gerçekte daha mantıklı olan, iş sırasında köreldiğinde tekrar bilemek
“Şu an çok yoğunum, baltayı bilemeye vaktim yok!” deyip durarak verimsiz şekilde çalışmayı sürdürüyorlar
“Bir bug'ı düzeltme hırsı, aslında önce aracı düzeltmek gerektiği gerçeğini gizliyordu” sözü etkileyiciydi
Kenneth Stanley'nin Why Greatness Cannot Be Planned kitabında da bu olgu ele alınıyor
Harika bir tavsiye. Ben de bunu her gün uygulamaya çalışıyorum
Ama ardından gelen “artık araç düzeltmeyi bırak ve gerçek sorunu düzelt” tavsiyesine pek uyulmuyor
Ben de böyle durumları sık yaşıyorum
Küçük sürtünmeleri giderince sonra zaman kazanıyorsun ama bir yandan da sonsuza kadar sadece araçlarla oyalanma tuzağı var
Asıl zor olan, “bu kadarı yeter” deyip devam etme noktasını doğru belirlemek
Araçlar, harcanan çabayı katlayan şeylerdir
Ama "yak shaving" ile gereksiz el işi arasında denge kurmak zor
Uzun vadede aynı araçları kullanmayı planlıyorsan, %1'lik bir iyileştirmenin bile birikimli etkisi büyük olacağından düşündüğünden daha fazla yak shaving tarafına eğilmek gerekebilir
En büyük ders, all-in-one araçların çoğunun pek iyi olmadığı
İçerik pipeline'ı için Make, Airtable, n8n gibi no-code araçların hepsini denedim ama belli bir ölçeğin üstünde hepsi bozuluyor
Sonunda API'leri doğrudan çağıran Python script'leri çok daha güvenilir çıktı
Asıl çözüm, karmaşık araçları düzeltmek değil, onları daha basit ve şeffaf araçlarla değiştirmekti
Kodun akışını debugger ile doğrudan görmek çok faydalı
Statik analizden çok daha sezgisel bir anlayış sağlıyor
Değişkenleri ya da breakpoint'leri sürekli değiştirirken sorunun özünü kaçırmak kolay
Debugger'ı yalnızca hipotez doğrulama aracı olarak kullanmak gerekir. Aksi halde “ilerleme kaydediyormuşsun gibi” bir yanılsamaya kapılırsın
Böyle yazıları seviyorsanız, şaka olsun diye Emacs'i sakın kurmayın derdim