Kodu Yazdınız, Local'de Çalışıyor. Sonrası Ne?

Yazılıma yeni başlayan bir developer için bir özelliğin "bittiği" an bellidir: lokalde çalışıyor, ekranda istediğin gibi görünüyor, ara sıra bir kullanıcı akışı simüle ediyorsun ve her şey yolunda. "Hadi merge edelim, ben işim bitirdim."

Yıllar geçtikçe fark edersin ki o an aslında yolun yarısından az. Özellik gerçekten bittiğinde çok farklı bir liste tamamlanmıştır. Bu yazı o listeyi çıkarıyor.

"Bende çalışıyor" sendromu

Lokalde çalışan bir şey production'da çalışmayabilir. Sebepler:

• Veri farkı — lokalde 10 satırlık test verisi, production'da 10 milyon satır. N+1 query lokalde 2ms, production'da 12 saniye.
• Trafik farkı — tek kullanıcı vs 10.000 eşzamanlı. Race condition, lock, kuyruk.
• Environment farkı — Node 20 lokalde, Alpine 18 container'da. Tiny fark, büyük kırık.
• Bağımlılık farkı — lokalde Redis 6, prod'da Redis 7 cluster mode. Komutlar aynı değil.
• Ağ farkı — lokalde localhost, prod'da Istio mesh arkasında. Timeout davranışı farklı.

Bu 5 boyuttan en az biri neredeyse her zaman sizi şaşırtır. Disiplinli bir dev, bunu beklediği için sürprize düşmez.

Tamamlanmış özellik listesi — benim versiyonum

Bir özelliği "tamamlandı" demek için şu adımlar geçer:

1. Test

• Unit testler — iş mantığının temelleri
• Integration testler — gerçek DB, gerçek HTTP, gerçek timing
• Ara sıra e2e — happy path'in bir kere de gerçek tarayıcıda çalıştığını doğrulayın

Test yazılmamış bir özellik lokalde çalışıyor olsa da bitmiş değildir. Cümle.

2. Observability

Hata olduğunda nereye bakacağınızı önceden planlayın:

• Yeterli log var mı? Özellikle input'lar, hata durumları, önemli state geçişleri?
• Metric var mı? (istek sayısı, süresi, hata oranı — en azından)
• Trace var mı? (en azından üretimdeki kritik yolların tracing'i)

"Canlıya aldık, patladı, neyin patladığını anlayamıyoruz" en sık gördüğüm incident pattern'i. Çözüm: daha fazla log yazmak değil, önceden doğru yerlere log koymak.

3. Alarm

Özellik kırılırsa birisinin haberi olsun. Sentry'ye yakalanacak bir error, ya da Grafana üzerinde bir threshold alarm — tam olarak "nasıl öğreneceğiz hata olduğunu?" sorusunun cevabı net olsun.

Manuel test etmek bir alarm değildir. Kullanıcının e-postayla şikayet etmesi bir alarm değildir.

4. Rollback planı

Eğer canlıya aldıktan sonra sorun görürseniz 5 dakika içinde geri alabiliyor musunuz? Feature flag var mı? Eski versiyona revert basit mi? DB migration'ı geri alınabilir mi?

Bu soruya "bilmiyorum" cevabı çıkmaması gereken bir cevaptır. Canlıya almadan önce yanıtı net olmalı.

5. Dokümantasyon (minimum seviyede)

Kimse "dokümantasyon yazın" demekten zevk almaz ama kendin için yaz bir README satırı. "Bu özellik X senaryoda Y sorunu çözer, Z endpoint'iyle çalışır." 3 ay sonra tekrar açtığında kendine teşekkür edersin.

6. Güvenlik gözden geçirmesi

• Kullanıcı input'u validate ediliyor mu?
• Authorization kontrolleri doğru mu? (authentication değil — authorization)
• Sensitive bilgi loglanıyor mu, ifşa oluyor mu?
• Rate limit / abuse koruması düşünüldü mü?

Senior-level bakış: özellik büyük değilse bile bu 4 soru her zaman sorulur.

7. Performance sınırlarını düşünmek

Ölçeklendiğinde ne olur? 1.000 kullanıcıda sorunsuz, 100.000 kullanıcıda ne? N+1 query var mı? Database index doğru mu? Dış API'den kaç çağrı yapıyorsun?

Büyük şirkette bile bu soruyu yanıtlamayanlar hâlâ var. "Gelecek bir sürprize kadar beklerim" diyenlerin başı çok derde girer.

Senior dev için "bitmiş özellik" formülü

Benim kafamda şöyle bir test var:

Eğer bu özelliği canlıya aldıktan sonra iki hafta tatile çıksam, ekibin geri kalanı sorun olduğunda ne yapacağını biliyor mu?

Eğer evetse özellik bitmiş. Eğer hayırsa, gerçekten bitmemiş — sadece yazıldı ve merge edildi.

Sonuç

"Local'de çalışıyor" bir başlangıç noktasıdır, bir bitiş değil. Gerçek işin büyük kısmı kod yazıldıktan sonra başlar: test, observability, alarm, rollback, güvenlik, performans, dokümantasyon. Senior developer'ları senior yapan kısım büyük oranda budur.

Bu listeye 5 dakika daha ayırmak, sonra 5 saatlik incident'ı önleyebilir. Matematik basit.