Bir üretim ERP’sinde yıllarca çalışırken, bir özelliği eklemek için harcadığımız eforu hep hesaplardık. Ancak o zamanlar, eklediğimiz her kod satırının aslında sürekli bir borç senedi gibi cebimizde kalacağını, bakım, test ve operasyon yükünü katlayacağını tam olarak idrak edemiyorduk. Yıllar içinde gördüm ki, en iyi kod, yazmadığın koddur; çünkü o kodun sıfır hatası, sıfır bakımı ve sıfır ek maliyeti vardır.
Bu basit gerçeği anlamak, yazılım geliştirme ve sistem mimarisindeki birçok stratejik kararı temelden değiştiriyor. Her yeni özellik veya çözüm, beraberinde bir karmaşıklık getirir ve bu karmaşıklığın bedeli, sadece geliştirme sürecinde değil, projenin tüm yaşam döngüsü boyunca ödenir. Bu yüzden, bir sorunla karşılaştığımda ilk düşündüğüm şey, “Bunu kod yazmadan nasıl çözebilirim?” oluyor.
Kodun Görünmez Maliyetleri Nelerdir?
Yazdığımız her kod satırı, ilk bakışta sadece fonksiyonellik sunuyor gibi görünse de, aslında ardında bir dizi görünmez maliyet gizler. Bu maliyetler, projenin büyümesiyle katlanarak artar ve çoğu zaman gözden kaçar.
Yeni bir raporlama modülü yazdığımızda veya mevcut bir entegrasyonu genişlettiğimizde, ilk başta işlevselliğin sorunsuz çalıştığını görürüz. Ancak zamanla, bu yeni kodun başka modüllerle etkileşimi, performans üzerindeki potansiyel etkisi veya gelecekteki değişikliklere ne kadar dirençli olduğu gibi konular ortaya çıkar. Test otomasyonu, loglama, monitoring ve hatta güvenlik açıkları gibi ek sorumluluklar, her yeni kod bloğuyla birlikte artar.
Geçen yıl kendi yan ürünümün birinde, kullanıcıların belirli veri setlerini dışa aktarması için karmaşık bir filtreleme ve formatlama özelliği eklemeye karar vermiştim. Kodlaması birkaç gün sürdü, ancak sonrasında gelen performans sorunları, yanlış formatlanan veriler ve kullanıcıların istediği esnekliği sağlayamama durumu, beni bu özelliği baştan tasarlamaya zorladı. Keşke en başta, bu kadar karmaşık bir özelliği gerçekten gerekli olup olmadığını daha iyi sorgulasaydım veya mevcut araçlarla daha basit bir dışa aktarma seçeneği sunsaydım.
Basitlik Neden Bu Kadar Zor Geliyor?
Basit çözümler üretmek, genellikle en zorudur; çünkü bu, sadece teknik bilgi değil, aynı zamanda disiplin ve vizyon gerektirir. Birçok geliştirici ve mimar olarak, çoğu zaman “ne kadar çok özellik, o kadar iyi” veya “karmaşık çözümler daha akıllıca” yanılgısına düşüyoruz.
Bunun birkaç nedeni var bence. Birincisi, geliştiricinin “ego”su. Karmaşık bir algoritma yazmak veya yeni bir teknoloji entegre etmek, genellikle tatmin edicidir ve bizi “uzman” hissettirir. İkincisi, belirsizlik korkusu. Gelecekteki olası ihtiyaçları tahmin etmeye çalışırken, “ne olur ne olmaz” diyerek gereğinden fazla özellik ekleme eğilimimiz olur. Üçüncüsü ise, “yeniden icat etme” hevesi. Var olan bir kütüphaneyi veya hizmeti kullanmak yerine, aynı işlevi kendimiz yazarak daha iyi bir çözüm üretebileceğimize inanırız. Oysa ki, çoğu zaman açık kaynaklı ve topluluk destekli bir çözüm, bizim yazdığımızdan daha sağlam ve bakımı daha kolaydır.
Kod Yazmamak Bir Stratejidir: Ne Zaman Durmalı?
Kod yazmamak, sadece tembellik değil, stratejik bir karardır. Bu karar, projenin hedeflerini, mevcut kaynakları ve uzun vadeli sürdürülebilirliği göz önünde bulundurarak alınmalıdır.
Birincil kuralım: Bir sorunu mevcut bir araç, servis veya basit bir konfigürasyon değişikliği ile çözebiliyorsam, asla yeni bir kod yazmam. Örneğin, Nginx kullanarak bir reverse proxy ve rate limiting ayarlamak, aynı işlevi sıfırdan bir Python servisi yazmaktan çok daha hızlı, güvenli ve bakımı kolaydır. Veya bir PostgreSQL trigger’ı ile basit bir loglama yapmak varken, yeni bir mikroservis geliştirmeye gerek yoktur. İkinci kuralım: Eğer yazılacak kod, mevcut karmaşıklığı azaltmıyor veya önemli bir iş değeri sağlamıyorsa, o koda “hayır” demeyi öğrenmek gerekir. Bu “hayır” demek, sadece kod yazmaya değil, aynı zamanda gereksiz toplantılara, özellik isteklerine ve projenin odağını dağıtan her türlü aktiviteye de olabilir.
Bir keresinde, bir müşteri projesinde, kullanıcıların belirli raporları kendi istedikleri formatta ve sütunlarla dışa aktarma talebi gelmişti. Ekip, bunun için dinamik bir raporlama motoru yazmayı önerdi. Ancak ben, bu talebin aslında standart bir BI aracıyla (SQL sorguları ve basit bir kullanıcı arayüzü ile) çok daha hızlı ve daha az kodla çözülebileceğini savundum. Sonuç olarak, mevcut bir açık kaynak BI aracı entegre ettik ve bu sayede hem geliştirme süresinden hem de gelecekteki bakım maliyetlerinden önemli ölçüde tasarruf ettik. Bu, kod yazmamakla kalmayıp, doğru aracı seçerek karmaşıklığı en baştan engellemenin bir örneğiydi.
Sonuç: Kod Yazmamak Bir Sanattır
Kariyerim boyunca öğrendiğim en değerli derslerden biri, yazılım geliştirmenin sadece kod yazmakla ilgili olmadığıdır. Asıl marifet, doğru zamanda, doğru miktarda ve doğru kalitede kod yazmak, hatta bazen hiç yazmamaktır. Bu, sürekli bir denge ve trade-off mücadelesidir.
Geliştirici olarak görevimiz, sadece işlevselliği sağlamak değil, aynı zamanda sistemin uzun vadeli sağlığını ve sürdürülebilirliğini de gözetmektir. Bu da, çoğu zaman “hayır” deme cesareti göstermeyi, basit çözümleri tercih etmeyi ve her yeni kod satırının getireceği potansiyel maliyetleri öngörmeyi gerektirir. Unutmayın, en hızlı çalışan, en az hata veren ve en kolay bakımı yapılan kod, hiç var olmayan koddur.