Yeni projeler üstlenmek ve yenilikçi fikirlerle işbirliği yapmak için her zaman heyecanlıyım.

Telefon

+90 536 603 81 42

E-posta

ahmetsuatpinar@gmail.com

GitHub

github.com/ahmetsuat67

Konum

Sancaktepe / İstanbul, Türkiye
Blog Listesine Dön

Görünmez Maliyet: Teknik Borç ve Sürdürülebilir Yazılım Mimarisi

2 dakika
Görünmez Maliyet: Teknik Borç ve Sürdürülebilir Yazılım Mimarisi

Bir yazılım projesinin başarısı, "yayına alındığı gün" ile ölçülmez. Asıl başarı, projenin 6 ay, 1 yıl veya 4 yıl sonra; yeni özellikler eklendiğinde, ekip büyüdüğünde veya teknoloji değiştiğinde ayakta kalıp kalamadığıdır.

4 yıllık Frontend serüvenimde öğrendiğim en acı ama en değerli ders şudur: "Çalışan kod" ile "yaşayan kod" arasında dağlar kadar fark vardır.

Bugün, spagetti kodun tatlı cazibesine neden kapılmamamız gerektiğini ve "Temiz Kod" (Clean Code) prensibinin neden sadece bir estetik değil, bir iş zorunluluğu olduğunu konuşacağız.

1. "Hızlı Olsun, Çirkin Olsun" Yanılgısı

Startup dünyasının hızı bazen bizi "şimdilik çalışsın, sonra düzeltiriz" tuzağına çeker. Yazılım literatüründe buna Teknik Borç (Technical Debt) diyoruz. Tıpkı finansal bir borç gibi; o an işinizi çözer, sizi hızlandırır. Ancak faizi vardır.

Eğer o kodu zamanında refactor etmezseniz (yapılandırmazsanız), faiz işlemeye başlar. Bir süre sonra basit bir butonu değiştirmek bile, tüm sistemi kırabilecek riskli bir operasyona dönüşür. Benim geliştirme felsefemde, ilk günden "modüler" ve "okunabilir" bir yapı kurmak, gelecekte ödenecek bu faiz yükünü sıfırlamaktır.

2. Kodunuzu Gelecekteki Size Yazın

Yazdığınız bir fonksiyonu 6 ay sonra açtığınızda ne hissettiğiniz, o kodun kalitesini belirler. Eğer "Bunu ben mi yazdım, ne yapıyor bu?" diyorsanız, orada bir sorun vardır.

Benim için Clean Code, kodun üzerine yorum satırları yazmak değil; kodun kendisinin bir hikaye gibi okunabilmesidir.

  • Değişken isimlendirmeleri (const data yerine const userProfile),

  • Fonksiyonların tek bir işi yapması (Single Responsibility Principle),

  • Ve bileşenlerin (components) tekrar kullanılabilir olması (DRY - Don't Repeat Yourself).

Bu prensipler, ekibe yeni katılan bir geliştiricinin projeye adaptasyon süresini haftalardan günlere düşürür.

3. Ölçeklenebilirlik: Sadece Sunucu Değil, Proje Yapısı da Ölçeklenmeli

Genellikle ölçeklenebilirlik denince akla sunucu kapasitesi gelir. Oysa Frontend mimarisinin de ölçeklenmesi gerekir. 10 sayfalık bir proje için kurduğunuz klasör yapısı, 100 sayfaya çıktığında çökmüyorsa doğru yoldasınız demektir.

Modern projelerimde (ister Next.js olsun, ister başka bir yapı), klasör yapısını ve veri akışını kurgularken her zaman şunu sorarım: "Bu proje seneye 5 kat büyürse, bu dosya yapısı hala mantıklı olacak mı?"

Sonuç: Kod Yazmak Bir İletişim Biçimidir

Yazılım geliştirmek, bilgisayarlara emir vermek gibi görünse de, aslında insanlarla iletişim kurmaktır. Yazdığınız kod, sizden sonra gelecek geliştiriciye bıraktığınız bir mektuptur.

Hızlı çıktı üretmek önemlidir, ancak sürdürülebilir, hataya kapalı ve genişlemeye açık bir mimari kurmak; bir şirketin uzun vadeli en büyük kârıdır. Ben projelerimde günü kurtarmayı değil, geleceği inşa etmeyi hedeflerim.

Çünkü en iyi kod, sadece bugün çalışan değil, yarın da değişime direnmeyen koddur.

Blog Listesine Dön

İletişime Geçelim

WhatsApp / Telefon

+90 536 603 81 42

E-posta

ahmetsuatpinar@gmail.com

GitHub

github.com/ahmetsuat67

LinkedIn

ahmet-suat-pinar

Konum

Sancaktepe / İstanbul