Yazılım dünyasında bir problem çıktığında artık ilk refleks çoğu zaman kod yazmak değil.

Framework aramak.

Bir şey yapılacak.

Bunun için hangi framework kullanılacak?

Bir arayüz mü yapılacak? Framework.

API mi yazılacak? Framework.

Form mu oluşturulacak? Framework.

Basit bir web sitesi mi yapılacak? Yine framework.

Sanki bilgisayar programlamanın temel amacı problem çözmek değil, doğru framework’ü bulmakmış gibi bir noktaya geldik.

Bir problemi birkaç satır kodla çözmek neredeyse şüpheli karşılanıyor.

“Bunu kendin mi yazdın?”

Evet.

“Niye kütüphane kullanmadın?”

Çünkü gerekmedi.

Bu cevap artık bazı yazılımcılara neredeyse kişisel hakaret gibi geliyor.

Her şeyi sıfırdan yazmak elbette saçma

Burada mesele bütün framework’leri çöpe atmak değil.

Büyük ve karmaşık projelerde hazır araçların ciddi faydası var.

Kimse gidip HTTP protokolünü yeniden yazmak zorunda değil.

Veritabanı yönetimi, kimlik doğrulama, karmaşık arayüz sistemleri veya büyük ölçekli uygulamalarda hazır çözümler ciddi zaman kazandırabilir.

Sorun başka yerde.

Framework kullanmak gerektiğinde kullanılmasından değil, artık neredeyse her durumda kullanılması gerektiğinin düşünülmesinden bahsediyoruz.

Bir çekiç faydalıdır.

Ama evdeki her şeyi çekiçle yapmaya çalışırsanız sonunda çividen başka bir şey göremezsiniz.

Yazılım dünyası da biraz buna döndü.

Eskiden problem vardı, çözüm yazılırdı

Basit bir problem düşünün.

Bir sayfada birkaç form alanınız var.

Girilen veriyi kontrol edeceksiniz.

Bir fonksiyon yazarsınız.

Biter.

Bugün ise önce proje yapısı konuşuluyor.

Framework seçiliyor.

Paket yöneticisi çalıştırılıyor.

Bağımlılıklar kuruluyor.

Konfigürasyon dosyaları hazırlanıyor.

Build sistemi ayarlanıyor.

Lint sistemi ekleniyor.

Test sistemi kuruluyor.

Sonra form alanına geliniyor.

Ve insan ister istemez soruyor:

Biz form mu yapıyoruz, yoksa yeni bir işletim sistemi mi geliştiriyoruz?

Framework’ün kendisi bazen problemin yarısı

Bir framework size standart bir yapı sunar.

Bu güzel.

Fakat beraberinde kendi kurallarını da getirir.

Dosyalar belli yerde olacak.

Kod belli şekilde yazılacak.

Belirli yöntemler kullanılacak.

Belirli araçlar devreye girecek.

Framework’ün nasıl çalıştığını öğrenmeniz gerekecek.

Sonra framework güncellenecek.

Yeni sürüm eski yöntemi değiştirecek.

Bir süre sonra asıl probleminiz ortadan kalkacak ve framework ile uğraşmaya başlayacaksınız.

Başlangıçta:

“Bir uygulama yapacağım.”

demiştiniz.

Birkaç ay sonra:

“Framework neden bu component’i render etmiyor?”

diye forumlarda dolaşıyorsunuz.

Framework öğrenmek bazen yazılım öğrenmenin önüne geçiyor

Yeni başlayan birinin karşısına bugün inanılmaz bir teknoloji yığını çıkabiliyor.

Programlama dili.

Framework.

CSS framework’ü.

State management.

Routing.

Build tool.

Package manager.

Testing framework.

Linting.

Formatter.

Container.

CI/CD.

Bulut servisi.

Veritabanı.

Bir insan bunların hepsini öğrenmeye çalışırken programlamanın temel mantığı arada kaybolabiliyor.

Çünkü artık soru:

“Program nasıl çalışıyor?”

olmaktan çıkıp:

“Bu framework’te bunu nasıl yapıyoruz?”

haline geliyor.

Bu ikisi aynı şey değil.

Framework bilgisi ile programlama bilgisi aynı değil

Bir framework’ün API’sini ezberlemek sizi otomatik olarak iyi bir yazılımcı yapmaz.

Bir framework size hazır bir yapı verir.

Ama problemin ne olduğunu hâlâ sizin anlamanız gerekir.

Kötü mimariyi framework düzeltemez.

Yanlış veri modelini framework düzeltemez.

Gereksiz özelliği framework ortadan kaldırmaz.

Kötü algoritmayı framework sihirli şekilde iyi hale getirmez.

Hatta bazen tam tersine, kötü kararları daha büyük bir kod tabanının içine gömer.

Sonuçta ortaya çalışan ama neden böyle çalıştığı anlaşılmayan bir sistem çıkar.

“Best practice” adı altında gereksiz karmaşıklık

Yazılım dünyasında “best practice” kelimesi de bazen tehlikeli hale geliyor.

Çünkü iyi bir uygulama, bağlamdan bağımsız evrensel bir emir değildir.

Küçük bir proje ile milyonlarca kullanıcıya hizmet veren bir sistem aynı mimariyi gerektirmez.

Fakat internette bir teknoloji trendi popüler olduğunda herkes aynı yapıyı kullanmaya başlıyor.

Çünkü kimse eski kafalı görünmek istemiyor.

“Ben bunu düz PHP ile yaptım.”

demek yerine:

“Modern full-stack architecture kullandım.”

demek daha havalı.

Sonra ortaya üç sayfalık web sitesi için kurumsal teknoloji ordusu çıkıyor.

Basitlik neden bu kadar korkutucu?

Çünkü basit çözüm gösterişli değildir.

Bir dosya.

Birkaç fonksiyon.

Bir veritabanı bağlantısı.

Biraz HTML.

İş bitti.

Bununla konferansta 40 dakikalık sunum yapmak zor.

Yeni bir teknoloji adı yok.

Grafik yok.

Mimari diyagram yok.

“Scalable event-driven component-based architecture” diye anlatabileceğiniz bir şey yok.

Ama kullanıcı açısından önemli olan başka bir şey var:

Site çalışıyor.

Bazen yazılım dünyasının unutmaya başladığı şey tam olarak bu.

Framework bağımlılığı zamanla teknik borca dönüşebilir

Bir framework projeye girdiğinde sadece bugünkü geliştirme sürecini etkilemez.

Geleceği de etkiler.

Framework desteklenmeye devam edecek mi?

Yeni sürümler çıkacak mı?

Topluluk devam edecek mi?

Kullandığınız eklentiler güncellenecek mi?

Bir gün framework’ü bırakmak isterseniz ne olacak?

Çünkü framework’e ne kadar çok bağımlı hale gelirseniz çıkış maliyeti de o kadar yükselir.

Başlangıçta size hız kazandıran şey, birkaç yıl sonra sizi aynı teknolojiye zincirleyebilir.

Framework’lerin en güzel numarası: “Bunu düşünmene gerek yok”

Framework’ler geliştiriciye çok cazip bir teklif sunuyor:

“Bunları sen düşünme. Biz hallettik.”

Bazen gerçekten de halletmiş oluyor.

Ama bazen bunun karşılığında başka bir şey veriyorsunuz:

Kontrol.

Framework’ün kararlarını kabul ediyorsunuz.

Framework’ün çalışma biçimini öğreniyorsunuz.

Framework’ün sınırlarına göre tasarım yapıyorsunuz.

Framework’ün güncellemelerini takip ediyorsunuz.

Ve sonunda kendi uygulamanızın bazı bölümlerini değil, kullandığınız framework’ü yönetmeye başlıyorsunuz.

Küçük projeler neden özellikle zarar görüyor?

Büyük projelerde framework kullanmak çoğu zaman anlaşılabilir.

Fakat küçük projelerde durum daha komik.

Basit bir web sitesi için devasa bir geliştirme ortamı.

Küçük bir API için onlarca bağımlılık.

Basit bir yönetim paneli için karmaşık frontend mimarisi.

Bir süre sonra projenin kendisinden daha fazla altyapı kodu ortaya çıkıyor.

Sadece bir vida sıkmak için yanında takım çantası değil, kamyonet getiriyorsunuz.

Sonra kamyonetin bakımını yapmak için başka bir kamyonet gerekiyor.

Bazen en iyi framework hiçbir framework kullanmamaktır

Bu cümle bazı geliştiricileri rahatsız edebilir.

Ama bazen gerçekten doğru.

Bir proje framework gerektirmiyorsa framework kullanmamak gayet geçerli bir tercihtir.

Birkaç yüz satırlık bir uygulamayı devasa bir teknoloji yığınına dönüştürmenin teknik olarak zorunlu hiçbir tarafı yok.

Hatta bazı durumlarda framework kullanmamak daha temiz olabilir.

Daha az bağımlılık.

Daha az güncelleme.

Daha az sürüm problemi.

Daha az öğrenilecek şey.

Daha az teknik borç.

Daha fazla kontrol.

Ve en önemlisi:

Kodun neden çalıştığını bilirsiniz.

Yazılım dünyasının biraz “hayır” demeyi öğrenmesi gerekiyor

Her yeni probleme yeni bir framework bulmak zorunda değiliz.

Her küçük iş için paket kurmak zorunda değiliz.

Her projeyi ölçeklenebilir bir teknoloji canavarına çevirmek zorunda değiliz.

Her uygulama milyonlarca kullanıcıya hizmet edecekmiş gibi tasarlanmak zorunda değil.

Bazen bir program sadece küçük bir programdır.

Bazen bir web sitesi sadece bir web sitesidir.

Bazen birkaç fonksiyon yeterlidir.

Ve bazen en iyi mimari, üzerinde saatlerce konuşulmayacak kadar basit olandır.

Çünkü yazılımın amacı framework kullanmak değil.

Problemi çözmektir.

Framework bu işe yardımcı oluyorsa kullanılır.

Yardımcı olmuyorsa sırf herkes kullanıyor diye projeye sokmanın pek bir anlamı yok.

Her sorunun bir framework’ü olmak zorunda değil.

Bazen sorunun çözümü sadece birkaç satır koddur.