Paralel Evrenlerin Programcıları

Bir önceki yazımda frontend ve backend programcılığı arasındaki ayrımın kalkacağından bahsetmiştim. Kendi programcılık kariyerim için bu yazımı bir dönüm noktası olarak görüyorum. Yirmi birinci yüzyılın yazılımcılığında bir dönüm noktasına gelmiş bulunuyoruz. Bu yazımda bunun sebebi açıklamaya çalışağım.

Java’nın ilk günlerinden beri programcı olarak bu dille ekmek paramı kazanıyorum. Son on beş yılda birçok Java çatısı (framework) ile çalıştım. Kendimi daha çok backend tarafında gören bir yazılımcıydım ta ki yukarıda linkini verdiğim yazıyı yazana kadar. Bir backend yazılımcısı değil, kendi programcı evreninde yaşayan bir programcıymışım ve paralel programcı evrenlerinin farkında bile değilmişim. Ne oldu da birden yazılımcı evreninin merkezinde olmadığımı, başka evrenlerinde var olduğunu keşfettim? Anlatmaya çalışayım.

Ağaçlara bakmaktan ormanı göremez hale gelmişiz…

Yıllardır o çatı senin, bu çatı benim diye yazılım yapıyoruz. Bugün bir kurumsal projeye göz atın, içinde en az on beş tane çatı bulabilirsiniz. Artık çatı olmadan yazılım yapılamıyor. Ne yazık ki geldiğimiz durum bu. Çatı yok, proje yok! Bundan daha vahim bir durum olabilir mi? Ne yedügü belirsiz bir ton kodu projene çekiyorsun ve onların üzerine birşeyler inşa etmeye çalışıyorsun. Hasbelkader çalışıyor! Çoğu zaman çalışmıyor, neden çalışmıyor diye kafandaki saçları yoluyorsun. Çatı kullanımı teknik borçlanma türevlerinden birisidir, er ya da geç tasarlanmadığı bir senaryo ile karşılaşıldığında, workaroundlar kaçınılmazdır. Her workaround bir teknik borçtur. Neyse, konumuzdan fazla sapmayalım…

Ben çatılarla büyümüş bir yazılımcı jenerasyonuna dahilim. Kullandığım diller statik veri tipli ve derlenen diller. Kendimi en çok böyle dillerde güvende hissediyorum. Yazdığım kod bana daha bi deterministik geliyor. Neden derleyici varken bir değişkene doğru veri tipinde bir değer atadım mı diye kendim kontrol edeyim ki! Ne gerek var…

Yazdığım kodun derlenmesi için belli bir zamana ihtiyacım var. Bunun üzerine çatıların çalışma şekilleri, konfigürasyonları ve kodumu test etmek için çalışır hale getirirken geçen zaman eklenince, en ufak bir değişikliğin bile derlenen dillerde ne kadar büyük zaman kaybına açabileceğini düşünebilirsiniz. İki binli yılların başında EJB (Enterprise Java Bean) uygulamalarını çalışır hale getirmek için onlarca dakika beklemek zorunda kaldığım günleri unutmadım. Bunları neden yazıyorum?

Çalıştığımız projelerde artık sorgulamadan belli kalıpları takip eder olmuşuz. Yeni bir proje mi var, hemen Spring, Hibernate, o çatı, bu çatı… Bu kalıpların dışına çıkamıyoruz, hep aynı şekilde hareket ediyoruz, çünkü içinde bulunduğumuz evren bu araçlardan oluşuyor. Hep bunlarla çalışmışız, bir mazohist gibi acı çekmeye alışmışız, ama onlardan vazgeçmemiz söz konusu bile olamaz, öyle değil mi?

Tipik bir Spring uygulamasını alın. Basit bir konfigürasyon yapacağım derseniz, elli dereden su getirmek gerekiyor. Peki Spring nasıl oluştu? Spring’in tek varoluş nedeni, Java EJB teknolojisinin çok hantal olmasıydı. Spring çatısını geliştirenler ortaya çıktılar ve “arkadaşlar bırakın şu saçma, sapan EJB, MJB leri, bizde uygulama sunucusu olmadan bile çalışabilen yeni bir çatı var, yazılım yapma hızınızı çok artıracak, bu çatıyı lütfen deneyin” dediler. Bizde sazan gibi atladık, çünkü başka bir alternatif yoktu.

Daha hızlı yazılım yapma iddasi ile ortaya çıkmış olan bu çatıya şimdi bir bakın. Ne hallere gelmiş durumda! Grails bünyesindeki spring/resources.groovy içinde Spring Bean DSL bazlı bir cronjob tanımlaması ihtiyacı duyan bir task için bir saat konfigürasyonla ugraşmak zorunda kaldım. “Aga böyle olmadı” deyip, durdu Grails sunucusu. Kafayı sıyırtacak seviyeye getirdi kısacası. Şu içine düştüğümüz duruma bir bakın hele.

Bize vaad edilen hızlı yazılım geliştirme araç, gereçleri idi. Bir çatının asıl vazifesi, programcısını angaryadan kurtarmaktır. Kullandığımız çatılar angaryadan kurtarmıyor değiller. Ama oradan kazandığımız zamanı uygulamaları çalışır hale getireceğiz, kodu derleyeceğiz, konfigüre edecegiz diye harcıyoruz. Hızlı yazılım geliştirmek için yanlış araçları kullanıyoruz.

Bu cümbüşün içinde birileri gelip “AngularJS, NodeJS gibi teknolojileri denesenize abi, çok daha hızlı uygulama geliştirirsiniz” diyor. Bıyık altından pis, pis gülüyoruz. “O da neymiş yahuuu, biz burada çok ciddi enterprise, menterprise teknolojileri ile uygulama geliştiriyoruz” diyoruz. Yalan mı? Ama o da ne, paralel bir evren mi gelişiyor orada yoksa! Bak, bak hele… bize hiç haber etmemişler. NodeJS de neymiş ki?

Adam bize neden haber etsin ki. Bir defa senin gibi teknoloji içine çakılıp, kalmamış. Tek derdi hızlı bir şekilde müşteri isteğini koda döküp, çalışır hale getirmek. Senin gibi teknoloji fanatiği değil. İki nokta arasındaki mesafenin bir çizgi olduğunu biliyor. Bizim gibi iki noktayı otuz beş köşe üzerinden birleştirmiyor. He mi gelip sana anlattığında, nazarı dikkate alacak mısın? Almayacağının en büyük nedenini söyleyeyim mi? Kullandığın araçlar ve teknolojilerin üstünlüğüne inanmışsın. Başkaları daha ileri teknolojiler oluşturuyor ya da kullanıyor olamaz! Burada sen diye hitap ettiğim kendi şahsımdır, üzerinize alınmayın.

Bir tarafta köklü ve gelenekli proje geliştirme yöntem ve teknolojileri, diğer tarafta hızlı ürün geliştirmek için oluşmaya başlayan teknolojiler. Bir tarafta teknolojiden gözü körleşmiş yazılımcılar, diğer tarafta yazılımın daha kolay yapılabileceğine inanan ve ihtiyaç duydukları araçları oluşturan yazılımcılar. Bir tarafta backend, frontend ayrılmalı diyen yazılımcılar, diğer tarafta aynı teknoloji ile backend ide yazarım diyen pragmatik frontend yazılımcıları. İki ayrı evren…

Ne vahim durumda olduğumuzu gösterir başka bir örnek vermek istiyorum. IBM mainframe üzerinde çalışan Cobol programcılarına neden kolay kolay nesneye yönelik programlama tekniklerinin öğretilemeyeceğine değinelim. Cobol dilinde funksiyonlar bile yok. Cobol programcısının network ya da desktop tecrübesi yoktur ya da çok azdır. Cobol programları structured programming teknikleri ile yazılır. Bir Cobol programcısı işletme mantığı dendiğinge gözünde birçok şeyi canlandırabilirken, kalıtım, o, bu demeye başlandığında, söylenenler bir kulagından girer, diğer kulağından çıkar, çünkü görüş alanında son otuz yıldır kullandığı teknikler, yöntemler ve teknolojiler vardır, OOP yoktur.

Kurumsal projelerde çalışan biz yazılımcılar da aynı duruma düşmüş durumdayız. Birileri bize gelip, olup, bitenlerden bahsetmeye çalışıyor, lakin bunlar bir kulağımızda giriyor, diğer kulağımızdan çıkıyor, çünkü gidişatı kavrayamıyoruz, sadece kullandığımız çatılara odaklanmış durumdayız. Ağaçlara bakmaktan, ormanı göremiyoruz. Sadece bir evrenin olabileceğine inanıyoruz. Paralel evrenlerin farkında değiliz. Ama içinde yaşadığımız evren yok olma tehlikesi altında.

Biz kendi evrenimizde frontend, backend programcılığının ayrımını tartışa duralım, fullstack developer bize çok radikal bir fikir gibi gelsin, her şeyi çatıların üzerine inşa etmeye devam edelim, oluşmakta olan paralel evrende adamlar hızlı yazılım geliştirme filozofisini frontend den alıp, backende taşımak üzereler. Bizim 5 günde yaptığımız işi 2 saat içinde yapacak seviyeye geldiklerinde, bizim evrendeki işsizlik oranı çok yükselecek gibi.

Maksadım içinize korku salmak değildi. Sadece yorumlamaya çalışmaya çalıştığım gidişati sizlerle paylaşmaya çalışıyorum. Daha önce kendisine gönderilen iş ilanlarında Javascript ibaresini gördüğünde burun kıvıran bir yazılımcı olarak, kafamızı kaldırıp, etrafımızda olup, bitenleri takip etmemiz, onlara kulak vermemiz gerektiği düşüncesindeyim. NodeJS, AngularJS, BackboneJS ve ReactJS yolculuğun nereye gittiğine işaret ediyorlar. Daha şimdiden bizim bildiğimiz backend teknolojilerine gerek kalmadan Javascript ile katmanlı mimariler oluşturmak mümkün. Javascript artık öğrenilmesi mecburi bir dil haline geldi. Javascript oluşmakta olan paralel evrenlerin sadece bir tanesinde kullanılan bir dil. Daha böyle birçok paralel evren oluşmadığı ne malum.

EOF (End Of Fun)
Özcan Acar