Kod Yazmak ile Mühendislik Arasındaki Görünmez Duvar

Yazılım dünyasında, projenin başında herkesin hemfikir olduğu ancak projenin ortasında herkesin birbirini suçladığı o kritik anı defalarca gördük. Bir fikir masaya konur, heyecan doruktadır ve odayı kaplayan o sabırsız soru sorulur:

"Ne zaman kod yazmaya başlıyoruz?"

Bu soru, kulağa en doğal, en iş odaklı ve en sonuç odaklı soru gibi gelir. Sonuçta bir yazılım projesi yapıyoruz, değil mi? O halde birilerinin klavyenin başına geçip o sihirli satırları yazması gerekir. Ancak bizim sektörde "başlamak" eylemi, çoğu zaman "hazır olmak" ile karıştırılır.

Bir inşaata başlamak için çimentoyu dökmek gerekmez; önce zemin etüdünün yapılması, statiğin hesaplanması ve mimarinin çizilmesi gerekir. Yazılımda ise bu görünmez duvar çoğu zaman yok sayılır. Buradaki temel problem, yazılım geliştirme (software development) ile kodlama (coding) kavramlarının eş anlamlı sanılmasıdır.

Kodlama, tanımlanmış bir mantığın makine diline çevrilmesidir. Yazılım geliştirme ise; o mantığın ne olması gerektiğini, hangi sorunu nasıl çözeceğini ve sistemin hangi sınırlarda yaşayacağını belirleyen mühendislik sürecidir. Sadece kod yazarak bir uygulama çıkarabilirsiniz, ancak sadece kod yazarak sürdürülebilir bir ürün çıkaramazsınız.

Bizim deneyimimiz net bir gerçeği gösteriyor: Projeler teknik yetersizlikten değil, "neyi yaptığımızı biliyoruz" varsayımıyla, teknik detaylar netleşmeden gaza basılmasından dolayı batıyor. Başlangıçta kazanıldığı sanılan o birkaç hafta, projenin sonunda aylar süren hata düzeltme (bug fixing) ve kapsam değişikliği (refactoring) süreçlerine dönüşüyor.

İlerleme İllüzyonu: Neden Ekranda Bir Şeyler Görmek İsteriz?

İnsan psikolojisi somut verilerle tatmin olmaya programlıdır. Bir toplantı odasında saatlerce iş akış şemaları (flowchart) çizmek, veritabanı ilişkilerini tartışmak veya kullanıcı senaryolarını (user stories) metne dökmek, birçok girişimci ve yönetici için "patinaj çekmek" gibi hissettirir. Çünkü günün sonunda elinizde "çalışan" bir şey yoktur. Sadece dokümanlar, diyagramlar ve notlar vardır.

Oysa bir yazılımcının "Giriş ekranını yaptım, butona basınca anasayfa açılıyor" demesi ve bunu size göstermesi, beyinde dopamin etkisi yaratır. "İşliyor! İlerliyoruz!" hissi, projenin en büyük uyuşturucusudur. Bu his, o kadar güçlüdür ki, arkada dönen kaosun üzerini örter.

  • Giriş ekranı var ama kullanıcı yetkilendirme matrisi (Role-Based Access Control) belli mi?
  • Butona basınca sayfa açılıyor ama veritabanında o kayıt bütünlüğü (Data Integrity) nasıl sağlanıyor?
  • İlerliyoruz ama nereye?

Bu İlerleme İllüzyonu (Illusion of Progress), özellikle çevik (agile) metodolojilerin yanlış anlaşılmasıyla daha da derinleşti. "Kervan yolda düzülür" anlayışı, yazılım mühendisliğinde "Teknik borç yolda birikir ve sonunda iflas ettirir" gerçeğine karşılık gelir. Erken aşamada kod görmek istemek, bir binanın temelini atmadan pencere siparişi vermeye benzer. Pencereler geldiğinde çok mutlu olursunuz, ancak onları takacak bir duvarınız olmadığında o mutluluk paniğe dönüşür.

Yüzde 90 Sendromu: Projeler Neden Son Düzlükte Ölür?

Erken kodlamanın en büyük belirtisi, sektörde sıkça şakası yapılan ama aslında trajik olan %90 Sendromudur. Proje takviminin ilk yarısı harika geçer. Ekranlar hızla çıkar, demolar yapılır, her şey yolundadır. Projenin %90'ı bitmiş gibi görünür. Ancak kalan o son %10'luk kısım, projenin toplam süresinin iki katını yer.

Neden?

Çünkü o ilk %90, Happy Path dediğimiz, her şeyin yolunda gittiği senaryolardır. Kullanıcı doğru tuşa basar, internet kesilmez, sunucu hata vermez, kredi kartı limiti yeterlidir. Bunu kodlamak çok kolaydır.

Ancak son %10, gerçek dünyadır ve yazılım mühendisliğinin asıl başladığı yerdir:

  • Kötü Senaryolar (Edge Cases): Kullanıcı ödeme yaparken internet koparsa, para çekilip sipariş oluşmazsa sistem ne yapacak? (Transaction Management)
  • Yük Altında Davranış: 5 kişi test ederken çalışan sistem, 5.000 kişi geldiğinde veritabanını kilitlerse (Deadlock) ne olacak?
  • Veri Kirliliği: Kullanıcı forma emoji, SQL injection kodu veya beklenmedik karakterler girerse sistem bunu nasıl temizleyecek?

Erken kod yazmaya başlayan ekipler, bu soruları başta sormadıkları için, projenin sonunda tüm mimariyi değiştirmek zorunda kalırlar. Bir hata durumunu yönetmek (Exception Handling) için yazdığınız kod, çoğu zaman işi yapan koddan daha uzundur. Eğer bunu baştan tasarlamadıysanız, son düzlükte kodunuzu yamalamaya başlarsınız. Yamalı bohçaya dönen bir proje ise asla canlıya çıkamaz, çıksa da "Zombi Proje"ye dönüşür; ne ölür, ne de yaşar.

Veritabanı Şeması Affetmez

Yazılımda kod değiştirmek kolaydır, arayüz değiştirmek çok kolaydır; ancak veritabanı şemasını (Database Schema) değiştirmek çok zordur ve maliyetlidir. Projenin başında yapılan aceleci bir veritabanı tasarımı, projenin kaderini mühürler.

Örneğin, bir e-ticaret projesinde aceleyle "Ürün" ve "Fiyat" tablolarını birleştirdiğinizi varsayalım. 6 ay sonra iş birimi gelip "Biz artık ürüne göre değil, müşteri grubuna göre veya saate göre dinamik fiyat göstermek istiyoruz" dediğinde, o basit tablo yapısı artık ayağınızdaki prangadır.

"Veri, koddan daha uzun yaşar. Kodunuzu silebilirsiniz, ama verinizi silemezsiniz."

O değişikliği yapmak için geriye dönük yazılmış binlerce satır kodu değiştirmeniz, tüm raporları yeniden yazmanız ve canlı veriyi riske atarak göç (migration) işlemi yapmanız gerekir. Bu yüzden, kod yazmaya başlamadan önce verinin nasıl akacağını, nerede depolanacağını ve nasıl ilişkilendirileceğini kağıt üzerinde simüle etmek zorundasınız. Bu aşamada harcanan 1 gün, gelecekte harcanacak 1 ayı kurtarır.

Davranışsal Tuzak: "Sonra Düzeltiriz" Yalanı

Sıkışık takvimlerde geliştiricilerin en sık sığındığı liman "Şimdilik böyle çıkalım, sonra refactoring (iyileştirme) yaparız" cümlesidir. Bu, yazılım dünyasının en büyük beyaz yalanıdır. Ticari dünyada, çalışan bir koda geri dönüp para harcamak, hiçbir zaman iş biriminin (Business Unit) önceliği olmaz.

Bu geçici çözümler, kodun içinde birikir. Biz buna Teknik Borç (Technical Debt) diyoruz. Tıpkı finansal borç gibi, teknik borcun da faizi vardır. Kirli kodun üzerine eklediğiniz her yeni özellik, daha yavaş geliştirilir ve daha çok hata çıkarır. Bir süre sonra faiz ödemekten (hata çözmekten), anaparayı ödemeye (yeni özellik geliştirmeye) vakit kalmaz. Ekip yavaşlar, motivasyon düşer ve proje bataklığa saplanır.

Teknik borç, kötü niyetten değil, "hız" baskısı altında verilen "kalite" tavizlerinden oluşur. Ve bu tavizler, en çok projenin başında, henüz ne yapacağımızı tam bilmeden kod yazmaya başladığımızda verilir.

Yanlış Suçlamalar: Teknoloji mi, Mimari mi?

Proje tıkandığında genellikle suçlu aranır ve fatura teknolojiye kesilir:

  • "PHP ile yazdık ondan oldu, Go ile yazsaydık uçardı."
  • "Monolitik yaptık, Mikroservis (Microservices) yapmalıydık."
  • "SQL yerine NoSQL kullansaydık bunlar olmazdı."

Bu yaklaşımlar, sorunu kökünden kaçıran savunma mekanizmalarıdır. Kötü mimari, dünyanın en hızlı dilinde de kötü sonuç verir. İyi tasarlanmış bir Monolitik yapı, kötü tasarlanmış bir Mikroservis yapısından çok daha performanslı, yönetilebilir ve ucuzdur.

Sorun kullandığınız çekiçte değil, o çekici kolon yerine cama vurmanızdadır. Teknolojik trendlere (Hype) kapılıp, projenin gereksinimine uymayan kompleks yapıları projeye dahil etmek, sadece bakım maliyetini artırır. Basitlik, yazılım mühendisliğinin en zor ulaşılan seviyesidir ve bu seviyeye acele ederek değil, düşünerek ulaşılır.

Çözüm: Sıkıcı Yazılım (Boring Software) Manifestosu

Heyecan verici teknolojilerle, plansızca kod yazmak eğlencelidir ama sonu hüsrandır. Sürdürülebilir başarı, Sıkıcı Yazılım prensibindedir. Bu prensip şunları emreder:

1. Kod Yazmadan Önce Şemayı Dondur

Verinin nasıl akacağı, koddan daha önemlidir. Veritabanı tasarımını ekibinizle tartışın, tahtaya çizin, uç durumları simüle edin. ER (Entity-Relationship) diyagramı çizilmemiş bir projeye başlamayın.

2. Sınırları Belirle (Boundaries)

Hangi modülün ne iş yapacağı kadar, neyi yapmayacağı da net olmalıdır. Kapsam kayması (Scope Creep), sınırları çizilmemiş projelerin kaçınılmaz sonucudur. "Bunu da ekleyelim" dediğiniz her özellik, test ve bakım maliyetini geometrik olarak artırır.

3. İstisnaları Tasarla

Mutlu yolu (Happy Path) herkes kodlar; stajyerler bile. Siz, sistemin bozulacağı anları düşünün. İnternet koptuğunda, servis cevap vermediğinde, kredi kartı limiti yetmediğinde sisteminiz kullanıcıya "Bilinmeyen Hata" mı diyecek, yoksa süreci kurtaracak mı?

Yazılım projesine başlamak için acele edenler, aslında başarısızlığa acele ederler. Doğru soru "Ne zaman kod yazıyoruz?" değil; "Neyi kodlayacağımızdan ve risklerden emin miyiz?" olmalıdır. Kağıt üzerinde çözülmemiş bir problemi, kod editöründe çözemezsiniz. Asıl zaman kaybı, düşünmek için durmak değil, yanlış yöne doğru koşmaktır.