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
Pratik Spring Core
Ücretsiz!
Design Patterns
Ücretsiz!
Pratik Git
Ücretsiz!
Pratik Agile
Ücretsiz!
Özcan Acar Blog Yazıları
Ücretsiz!
Özcan Acar Blog YazılarıErtuğrul tarafındanPratik Spring CoreÖzcan Acar tarafındanÖzcan Acar Blog Yazılarıfaruk hoca tarafındanPratik Spring CoreCem Hancı tarafındanPratik Spring CoreAdnan tarafından
bir önceki yazınızda yazılım dünyasında taşlar yeniden yerinden oynamaya başladı demiştiniz. burada da o taşları açıklamışsınız, gayet yerinde bir tesbit, elinize sağlık hocam. ancak bizim ülkemizde maalesef bu taşları yerinde sıkı sıkı tutmak isteyen insanlar maalesef çok çok fazla. yeniliğe o kadar kapalıyız ki, ne var sa eskilerde var diyoruz ve o yolda devam ediyoruz. sanki programlama da “atalar dinini” yaşıyoruz. dünya farklı bir noktaya ilerlerken hala eski teknolojileri kullanmaktan zevk alıyoruz(!).
en ufacık bir programcık için bile kos koca framework’u kullanmanın ne gereği var. bu işi daha hızlı yapmanın yolları varken neden hep en uzun ve en masraflı yolu seçiyoruz. (eskidir, oturmuştur, kullanılan araçlar çoktur mantığı artık işlemiyor, özcan hocam’ın dediği gibi adamlar 5 dakikada artık hazır sistemi elimize veriyor).
javascript’e dil olarak bakmayan kişiler artık bunun öğrenilmesinin mecbur olduğuna zorda olsa inanmaya başladılar. ancak artık bu dilde yeterli değil diyerek, dilin zorluklarından sıkılanlar da kendini başka başka paralel evrenlere atmaya başladılar. bunlardan biriside go dili. mutlaka denk gelmişinizdir. docker gibi efsana olma yolunda ilerleyen bir sistem bu dilde yazıldı.
express framework’un mimarı nodejs’i bırakıp, bu dile geçti, artık buradan devam edeğini açıkladı.
yani biz daha neyi bekliyoruz hala anlam veremiyorum.
bence taşlar yerine oturmadan, daha doğrusu taşların altında ezilmeden, artık buralara doğru yol almamız gerekiyor.
go, nodejs, meteor, mean, bunlardan sadece birkaçı, artık “yelkenler fora” deme zamanı geldi geçiyor.
Eline emeğine sağlık Reis.
Yazı için teşekkürler. Oluşmakta olan bambaşka bir evren görmek isterseniz Haskell dünyasına bir göz atın derim. Backend + frontend olayını çok aşıyor o evren. Bu arada statik type’larla ilgili vardığınız sonuçlar tamamen Java’nın tümörleri.
Ruby dili tam size göre,sınırsız kodlama şekli ve kolaylık,aynı işi yapıyor