Hızlı Yazılan Kod Neden Geleceğin En Pahalı Hatasına Dönüşür?

Hızlı Yazılan Kod Neden Geleceğin En Pahalı Hatasına Dönüşür?

Bir yazılım ekibinin takviminde bazen şu cümle belirir: “Şimdilik böyle çıkaralım, sonra düzeltiriz.” Bu cümle masum görünür; hatta çoğu zaman doğrudur. Pazar fırsatı beklemez, müşteri demo ister, kritik bir hata gece yarısı çözülmelidir. Sorun hızlı davranmak değildir. Sorun, hız uğruna alınan kararın gelecekte bir maliyet yaratacağını unutmak ya da bu maliyeti kayda geçirmemektir. İşte bu görünmez yükün adı kalıtsal borçtur: Bugünün kod kolaylığı karşılığında yarının geliştirme kapasitesinden alınan kredi.

Finansal borçla benzetme güçlüdür çünkü teknik borç da faiz işler. Bir fonksiyonun içine sıkıştırılmış iş kuralları, kopyalanmış kod blokları, anlamsız değişken adları, test edilmeyen kritik akışlar veya “geçici” diye eklenmiş ama iki yıldır yaşayan bir yapı… Bunların her biri ilk gün küçük bir tasarruf sağlar. Ancak sistem büyüdükçe yeni özellik eklemek zorlaşır, hata ayıklama uzar ve ekip üyeleri kod tabanına dokunmaktan çekinir. Faiz, sadece işlemci zamanı ya da sunucu faturası değildir; geliştiricinin dikkati, motivasyonu ve güveni de bu faizle aşınır.

Newton Bugün Yaşasa: “Devlerin Omuzları”na Pull Request mi Açardı?

Newton Bugün Yaşasa: “Devlerin Omuzları”na Pull Request mi Açardı?

Isaac Newton’un ünlü cümlesi, “Eğer daha ileriyi görebildiysem, devlerin omuzlarında durduğum içindir”, çoğu zaman alçakgönüllülüğün parlak bir örneği diye sunulur. Fakat bu sözün daha teknik, daha kışkırtıcı bir anlamı vardır: Bilgi tek kişinin mülkü değildir; önceki zihinlerin bıraktığı yapılar üzerinde yükselen ortak bir altyapıdır. Bugün bu fikrin laboratuvar kokmayan, çalışan ve tıklanabilir karşılığı GitHub’dır. Her fork, her commit ve her pull request, Newton’un cümlesini kod biçiminde yeniden yazar.

Bilginin görünür merdiveni

Bilimsel ilerleme uzun süre makaleler, mektuplar, konferanslar ve kurumlar üzerinden birikti. Ancak bu birikimin önemli bir bölümü yavaştı, pahalıydı ve erişim engelleriyle çevriliydi. Açık kaynak dünyası başka bir mekanizma önerdi: Yalnızca sonuca bakma; sonucun nasıl üretildiğini de incele. Bir yazılımın çalıştırılabilir hâlini vermek yerine kaynak kodunu açmak, bilimsel yöntemin dijital akrabasıdır. İddia vardır, yöntem vardır, veri akışı vardır ve en önemlisi denetleme imkânı vardır.

Kusursuz İnsan Bekleyen Yazılım Neden Kusursuz Biçimde Çöker?

Kusursuz İnsan Bekleyen Yazılım Neden Kusursuz Biçimde Çöker?

Bir sistem tasarlarken yapılabilecek en tehlikeli hata, kullanıcıların talimatları okuyacağını, geliştiricilerin hiçbir ayrıntıyı atlamayacağını ve sunucuların daima sözünde duracağını varsaymaktır. Bunların üçü de teknik gereksinim değil, iyimserlik biçimidir. İnsan yanlış düğmeye basar, parolasını unutur, aynı işlemi iki kez gönderir; makine ise diski bozar, paketi düşürür, zaman aşımına uğrar. Hata toleransı, bu kusurları yok etmeye çalışmak yerine onları sistemin doğal iklimi kabul etme sanatıdır.

Hata istisna değil, girdidir

Acemi tasarımcı mutlu yolu çizer: Kullanıcı formu doldurur, ödeme gerçekleşir, sipariş kaydedilir. Deneyimli tasarımcıysa karanlık sokaklara bakar: Ödeme alınır ama yanıt gelmezse ne olur? Kullanıcı sabırsızlanıp düğmeye tekrar basarsa iki sipariş mi oluşur? Veritabanı yazma sırasında çökerse hangi kayıt gerçektir? Sağlam yazılım, yalnızca doğru adımların sonunda doğru sonuç üretmez; yanlış, eksik veya yinelenmiş adımlar karşısında da anlaşılır bir duruma döner.

Sisteminiz Çökünce Daha Güçlü Uyanabilir mi?

Bir bilişim sisteminden genellikle güvenilir, hızlı ve kesintisiz olması beklenir. Sunucular susmasın, veritabanı tökezlemesin, kullanıcılar hata ekranıyla karşılaşmasın isteriz. Fakat gerçek dünya steril bir laboratuvar değildir: diskler bozulur, ağlar yavaşlar, trafik aniden yükselir, insanlar yanlış düğmeye basar. Bu nedenle asıl soru, sistemin stresten kaçıp kaçamayacağı değil, stresle karşılaştığında neye dönüşeceğidir. Kırılgan sistem darbe alınca bozulur; dayanıklı sistem darbeye rağmen aynı kalır; antikırılgan sistem ise darbe sayesinde öğrenir ve güçlenir.

Dayanıklılıktan fazlası

Antikırılganlık, her arızadan mucizevi biçimde kazanç çıkarmak değildir. Daha teknik bir ifadeyle sistemin hata sinyallerini bilgiye, bilgiyi de yapısal iyileştirmeye dönüştürebilmesidir. Bir servis çöktüğünde yalnızca yeniden başlatılıyorsa dayanıklılıktan söz ederiz. Çöküşün nedeni otomatik olarak saptanıyor, benzer yükler kontrollü biçimde yeniden üretiliyor ve mimari aynı hatanın etkisini küçültecek şekilde değiştiriliyorsa antikırılganlığa yaklaşırız. Arıza artık yalnızca düşman değil, pahalı fakat dürüst bir test uzmanıdır.

Kodun Altında Kim Var? Yorum Satırlarında Saklanan Geliştirici Zihinleri

Eski bir yazılım projesini açmak, terk edilmiş bir binaya girmeye benzer. Dosyalar odalardır, fonksiyonlar koridorlar, veritabanı ise bodrumda uğuldayan eski kazandır. Fakat geçmişte burada yaşayan insanların sesleri en çok yorum satırlarında duyulur. // Bu geçici çözüm daha sonra düzeltilecek cümlesi, teknik bir açıklamadan fazlasıdır. O, yıllar önce ekran karşısında oturan bir geliştiricinin umut, yorgunluk ve kendini kandırma kapasitesini aynı anda muhafaza eden küçük bir zaman kapsülüdür.

Yorum Satırı Neyi Saklar?

Kod çoğunlukla ne yapıldığını gösterir; yorum ise geliştiricinin yaptığı şeyi nasıl anlamlandırdığını anlatır. Bu ayrım önemlidir. Bir algoritmanın davranışı testlerle ölçülebilir, fakat onu yazan kişinin neden savunmacı, aceleci ya da aşırı açıklayıcı davrandığı ancak dilde görünür hâle gelir. // Buraya dokunmayın diyen biri yalnızca teknik risk bildirmiyor olabilir. Belki sistemin kırılganlığından utanıyor, belki geçmişte yaşadığı bir arızanın tekrarından korkuyor, belki de ekip arkadaşlarına duyduğu güveni çoktan kaybetmiştir.