Öncelike backend/frontend nedir, backend/frontend programcısı ne yapar sorularına cevap vermeye çalışarak başlamak istiyorum.
Bir tiyatro oyununu düşünelim. Sahnede gördüklerimiz uygulamanın ön yüzü yani frontend, sahne arkasında olup bitenlerin hepsi arka taraf yani backend dir. Katmanlı mimarilerde her uygulamanın bir arka tarafı, bir ya da daha fazla ön tarafı olur. Uygulamanın görsel tarafında çalışan programcılara frontend, sahne arkasında olup, bitenlerden sorumlu olan programcılara backend programcısı denir.
Uygulamanın görsel kısmını geliştirmek için bu konuda uzmanlaşmış frontend yazılımcıları ile çalışmanız gerekiyor. Bu yüzden her ekip içinde frontend/backend programcısı diye ayrım yapılır. Bunun başlıca sebebi, her iki katmanda ayrı teknoloji ve çatıların (framework) kullanılması ve değişik türde programcı yeteneklerine ihtiyaç duyulmasıdır. Backend karmaşık işletme mantığına ev sahipliği yaparken, frontend daha ziyade son kullanıcıların uygulama ile olan interaksiyonlarını mümkün kılan katmandır.
Yapı itibari ile backend daha karmaşık (complex) gibi görünse de, bu karmaşa uygulamanın görsel katmanında da mevcut. Aradaki tek farklılık, kısa bir zaman öncesine kadar frontend programcılarının bu karmaşa ile baş edebilmek için gerekli araç, gereç ve tekniğe sahip olmamalarıydı. Ama bu konuda bir dönüm noktasına gelmiş bulunuyoruz. Oyunun kuralları değişiyor. Bunun hem frontend hem de backend programcıları farkında mı acaba? Bu sorunun cevabını bulmaya çalışalım.
Backend programcıları ne yapar? Backend programcıları kendilerini yazılımcı ve yazılım mimari olarak görürler. Uygulamanın tüm mimarisinden yazılımcı olarak onlar sorumludurlar ya da bundan sorumlu olmak isterler. Frontend kısmını pek kaleye almadan, hayatlarını sürdürüp giderler. Tipik bir backend programcısına Javascript kodu yazdıramazsınız. O sadece backend bilir, orada kalır, kendini orada rahat hisseder. Buna karşın bir backend programcısının kelime hazinesinde tasarım şablonları (design patterns), tasarım prensipleri, bağımlılıkların enjekte edilmesi (dependency injection), katmanlı mimari, test güdümlü yazılım, esnek bağ, nesneye yönelik programlama, refactoring, tekrar kullanılabilirlik ve temiz kod gibi terimler bulabilirsiniz. İdeal bir backend programcısı çevik yazılım metotları yardımı ile bakımı ve geliştirilmesi kolay bir backend oluşturabilir. Uygulama ne kadar karmaşık olursa olsun, backend programcısı bu karmaşa ile baş edebilecek yetileri sahiptir (ya da olmalıdır, aksi taktirde backend programcısı ünvanını hak etmez). Ya frontend programcıları nasıl çalışıyor?
Bu sorunun cevabını vermeden önce şunu belirtmek isterim. Maksadım frontend programcılarını küçümsemek değil. Yanlış anlaşılmak istemem. Onlar da benim gibi yazılımcılar. Ben de birçok projede frontend programcısı olarak çalıştım. Neticede aynı meslekten olup, uzmanlık alanları değişik olan programcılar bir araya gelerek, müşterinin gereksinimlerini tatmin etmesi beklenen bir uygulama ortaya koyuyorlar. Lakin bir backend programcısı olarak son 15 yılda öğrendiğim ve uyguladığım yöntem ve tekniklerin yeni yeni frontend programcıları tarafından keşfedildiklerine şahit oluyorum. Bugün frontend yazılımcılığına baktığımızda, MVC (Model View Controller) çatılarının ‘state of the art’ olduklarını görmekteyiz. Bundan önce ne vardı? Bilimum modern yazılım teknikleri göz ardı edilerek oluşturulmuş, prosedürlerden oluşan Javascript ambarları! Aynı şey PHP ya da benzeri çatılarla geliştirilmiş uygulamalar için de geçerli. Hangi çatı olursa, olsun bir controller yapısını açıp, içine baktığınızda, tüm işletme mantığının orada olduğunu görebilirsiniz. JSP sayfalarına gömülmüş JDBC kodları görmüşlüğüm bile mevcut. Frontend programcılığı günümüzde çok iptidai yöntemlerle yapılıyor. Geniş çaplı bir yazılım metodolojisinin uygulandığııi görmek mümkün değil. Sadece MVC tasarım şablonunu kullanarak, modern bir frontend yazılımı yapıyorum demek doğru olmaz. Yazılımın bilinmesi ve uygulanması gereken birçok boyutu bulunmaktadır. Backend programcıları bunun çok iyi bilincindeler, ama uygulayıp uygulamadıklari tartışılır.
Uygulamanın görsel katmanının frontend programcıları tarafından sadece bir katman olarak değil, orada katmanlı bir mimarinin uygulanabileceği bir saha olarak görülmesi zaruri. Aksi taktirde frontend katmanında oluşan karmaşa ile baş etmeleri imkansız. Bunu nasıl yapabilirler?
Klasik katmanlı bir mimaride görsel, servis ve veri katmanı olarak en az üç katman mevcuttur. Backend genellikle servis ve veri katmanını altında bulunduran bir REST, Webservis ya da EJB katmanıyla kullanıma açılır. Bu yapı oluşturulurken birçok yazılım tekniği, prensibi ve metodolojisinden faydalanılır. Bunların hepsinin frontend programcılığında da öne çıkan öğeler olması gerekmektedir. Backend programcısı yazılım yapmak için gereken hangi bilgiye sahipse, frontend programcısının da aynı bilgiye sahip olması gerekmektedir. Backend yazılım tekniklerini frontend bünyesinde uygulamaya çalışan AngularJS gibi çatılar oluşmaya başladı. Peki frontend programcıları bu geçişe hazırlar mı?
Şimdi bunun tam tersini irdeleyelim. Eğer yakın zamanda frontend yazılımcılığını backend yazılımcılığında uygulanan teknik ve yöntemlerle yapmayı mümkün kılan seviyeye gelecek isek, frontend programcılarına ihtiyaç var mı? Bu durumda ihtiyaç ortadan kalktı gibi görünüyor. Peki bu boşluğu kim doldurmak zorunda? Bu boşluğu backend programcısı doldurmak zorunda! Peki backend programcısı bu geçişe hazır mı?
Yıllarca Javascript ve türevlerine sıcak bakmayan bir backend yazılımcısı olarak, bir backend programramcısını frontend programcısına dönüştüremeyeceğinizin garantisini verebilirim. Backend programcısı frontend bünyesinde uygulanan programcılığı programcılık olarak görmez. Bu onun kibirli olduğunun göstergesi değildir. Bu standartlarda frontend programcılığı backend programcılığının 15 sene gerisinden gelmektedir. Backend programcının eline frontend yazılımı yapabilmesi için gerekli araç, gereçleri vermeniz gerekiyor. Bu araçlar oluşmaya başladı. Örnek mi?
Günümüzde kullanılan web tarayıcıları EcmaScript 5 spesifikasyonunu destekliyor. EsmaScript Javascript programlama dilini oluşturmak için kullanılan dil spesifikasyonudur. EsmaScript 5 bünyesinde nesneye yönelik programlama konseptleri yok. Bu yüzden JavaScript bünyesinde funksiyonlar ya da değişken referansları yardımı ile sınıf vari bir şeyler tanımlayabiliyorsunuz. Örneğin şöyle:
[sourcecode language=”java”]
var car = {
brand: "ford",
model: "fiesta",
getCarInfo: function () {
return this.brand + " – " + this.model;
}
// ya da
function car (brand, model) {
this.brand = brand;
this.model = model;
this.getCarInfo = getInfo;
}
function getInfo() {
return this.brand + " – " + this.model;
}
[/sourcecode]
EcmaScript 5 bazlı Javascript ne sınıf, ne interface, ne soyutluk ne de kalıtım tanıyor. Prototype değişkeni üzerinden kalıtım oluşturmaya çalışmayı kalıtım olarak görmüyorum. Böyle teknikler kodun daha da kötü okunur hale gelmesini sağlıyor.
Şimdi EcmaScript 6 yı baz alan TypeScript örneğine bir göz atalım:
[sourcecode language=”java”]
class Tire{
}
class Vehicle {
private tires:Tire;
}
class Car extends Vehicle {
private brand:string;
private model:string;
constructor(brand:brand, model:model){
super();
}
public getBrand():string {
return this.brand;
}
public getModel():string {
return this.model;
}
}
interface Driver{
isDriving:bool;
startDriving:void;
stopDriving:void;
}
class Person implements Driver{
public isDriving:bool;
constructor() {
this.isDriving = false;
}
public startDriving():void {
console.log("now driving….");
this.isDriving = true;
}
public stopDriving():void {
console.log("stopping the car….");
this.isDriving = false;
}
}
[/sourcecode]
TypeScript in safkan nesneye yönelik programlama dili olduğunu görüyoruz. Bu altyapıyı kullanarak gösterim (model, view, controller), servis ve veri katmanını sınıflardan yararlanarak oluşturabiliriz. Bunu yapmamızı mümkün kılan çatıların başında AngularJS geliyor. Yazılımda karmaşayı önlemenin tek yolu böl ve yönet tekniğinin uygulanmasıdır. Burada modüler yapılar ve tek sorumluluk prensibi öne çıkıyor.
AngularJS bir Javascript MVC çatısı. 1.x sürümü EcmaScript 5 destekleyen web tarayıcılarında çalışıyor. AngularJS 2.x TypeScript bazlı olacak. AngularJS bünyesinde MVC konsepti yanı sıra işletme mantığının yer aldığı servisler, bağımlılıkların enjekte edilmesi (dependency injection) ve modüler yapılar mevcut. AngularJS in temelinde yatan asıl arzunun frontend yazılımcılığına backend yazılımcılığından tanıdığımız konseptleri getirmek olduğunu görebiliyoruz.
Bunun yanı sıra işveren de frontend bölümünde modern yazılım tekniklerinin uygulanması gerekliliğinin farkına varmış durumda. Uygulamalar için yapılan yatırımlar uygulamaların geliştirilebilirliklerinin yüksek tutulması sayesinde korunabilir. Artan müşteri gereksinimleri ile büyük bir karmaşa ve kargaşa içinde batıp gitmiş bir frontend katmanında yapılan yatırımın korunabileceği söylenemez, çünkü bu durumda uygulamanın ileri versiyonlarının oluşturulamaması tehlikesi mevcuttur. Bu sebepten dolayı frontend için modern yazılım tekniklerinin uygulanması gerekliliği doğmaktadır.
Benim görüşüm kısa bir zaman sonra backend, frontend programcısı ayrımının ortadan kalkacağı yönünde. Frontend programcıları ileri yazılım tekniklerini uygulamaya başladıkları andan itibaren, backend programcılığı için gerekli yazılımcı yetilerini kazanmaya başlayacaklar. Frontend programcısı için bu bilgi çıtasının yükselmeye başladığı anlamına geliyor. Bu duruma ayak uydurmak zorundalar, aksi taktirde onları büyük bir tehlike bekliyor: backend programcıları onların yerlerini almak zorundalar!
Aynı durum backend programcıları için de geçerli. Frontend için ileri seviye teknikler uygulanmaya başlandığında, işverenler bu tekniklere sahip programcılarla çalışmak isteyecekler. Bu durumda sadece backend programcılığı yapabiliyorum demek yeterli olmayacaktır. Teknoloji olarak birbirine yakınlaşmış backend ve frontend yazılımcılığı için her iki sahada aktif olabilecek yazılımcılara ihtiyaç duyulmaktadır. Tek bir tarafa hakimiyet yeterli olmayacaktır. Gidişat artık terim olarak pek sevmesemde fullstack development yönündedir. Bu frontend programcılığını ortadan kaldıran bir akım olacak. Programcı olarak hayatlarını sürdürmek istiyorlar ise, frontend programcıları arkaya, backend programcıları da öne doğru uzanmak zorundalar. Piyasa bunu istiyor gibi görünüyor.
Yazılım sektöründe yine taşlar yerinden oynamaya, bilinen şeyler eskimeye ve yeniliklere olan gebelik artmaya başladı. Marifet bu gidişata ayak uydurabilmekte. Ben olsam yavaş yavaş Javascipt 6 öğrenmeye başlardım 🙂
EOF (End Of Fun)
Özcan Acar
Yorumlar
“Neden Frontend ve Backend Programcısı Tarihe Karışıyor” için 15 yanıt
Üstad öncelikle aklıma gelip birleştirmediğim noktaları yazıya dökmüşsünüz. Elinize sağlık. Fakat bazı katılmadığım noktalar var piyasa daha çok daha fazla işi yapan(nasıl yaptığı önemli değil – bu benim gördüğüm) en kısa zamanda teslim edebilen sorunsuz olacak(!) görev dağılımı olmayan bilinçsiz uygulamalar geliştirilen patladığında da neden çalışmıyor diye kurban arayışlarına başlanılan süreçlerden ibaret. Piyasaya bakarsak herşeyi ister ama piyasa Full Stack geliştiricisinin bedelini ödemeye hazır mı? Full Stack çatısı altında ps’de tasarım dahi yaptırtan görev tanımı bile olmayan ve adamı işinden bezdirten durumlar mevcut. Dünya belki hazırdır ama Türkiye kesinlikle değil.
Typescript i başından beri takip ediyorum ama bence backend i backend yapan javascript ya da türevi kütüphaneleri kullanması değil, bizzat siteyi çalıştıran arkaplan kodlarını yazmasıdır..
http://www.serkancamur.com
Merhabalar, ben de yıllarca backend ağırlıklı çalıştım ve son bir yıldır angularjs ile ilgileniyorum. Modern programcılık tekniklerinin frontend tarafına rahatlıkla uygulanabileceğini düşünenlerdenim. İyi bir tesadüftür ki blogda son yazılarımı ağırlıklı olarak angularjs üzerine yayınladım. Bunun nedeni angularjs altyapısının temiz ve modüler kodlama yapmaya imkan sağlaması ve component gibi hafif sıklet yapıların oluşturulabiliyor olmasıdır. Bu sayede frontend projelerimin zamanla genişlemesi benim için hiç bir karmaşıklığa yol açmıyor. Size de bu noktada iyi bir yere temas edip bu makaleyi hazırladığınız için teşekkür ederim. Ben konuyu bir adım daha ileri götürerek şunu tahminimi de belirtmek isterim ki, sunucu tarafında aspx, jsf, php v.s gibi her talepte(request) tümüyle HTML web sayfa halinde içerik sunan yapılar bir süre sonra çöpe gidecek. Çünkü artık sunucu üzerindeki yükün önemli bir kısmı istemci bilgisayarlara yükleniyor ve sunucular sadece JSON tarzı hafif veriler oluşturmakla REST servislerle meşgul oluyor. Örneğin kompleks aspx sayfalar yerine daha hafif olan angularjs+web api tercih edilebiliyor. Son olarak diyebilirim ki web tarafının desktop programlaması artık angularjs tarzı teknolojilerdir.
öncelikle açıklığa kavuşturmak istediğim nokta “tool matters, (teçhizat önemlidir) but not that much(ama o kadar da değil)” yazınızda belirttiğiniz teknik bilgiler günümüzün gerçekleri olmakla birlikte amaç ve sonuçları ancak bu kadar yanlış anlaşılabilirdi. frontend ve backend ayrımına mutfak ve sunum demeyi tercih ediyorum ve yazımın devamında bu terimleri de kullanacağım. Mutfak da kullanılan araçlar (frameworkler(iş çatıları/çerçeveleri)) ve sunumda kullanılanılan araçların yapı itibarı ile benzerlik gösterdiğini ve bu sebeple iyi bir mutfak çalışanının sunum iyi bir sunum çalışanının da mutfak işleri yapabileceğini savunmaktasınız peki bugüne kadar user experience(kullanıcı tecrübesi) kelimesini belleğinin yakınından geçirmemiş mutfak çalışanı sunum yapmaya çalıştığında frameworkler bu açığını kapatacakmı bootstrap angularjs belki createjs user experience konusunda ne kadar yardımcı olacak ya diğer tüm twitter benzeri siteler gibi devasa ve alışıldık tipografilerle ve uyumlu bilindik renklerle bi şeyler ortaya çıkacak(ki bilindikliğin marka değerini düşürmesi kaçınılmaz) yada yeteri kadar çalışılırsa çirkin tipografilerle uyumsuz renkler ilk izlenim namına bir şey bırakmayacak(bkz. sanatçı ruhlu backend çalışanları) tamam bi de tersten bakalım bugüne kadar güvenlik kelimesine yeterli önemi vermiş frontend developera rastladınızmı yada server trafiğiyle uğraşmaya gönüllü olanına, doğru araçlarımız çok gelişti hem backend hem frontend araçları metotlarını ve biçimlerini daha kolay yönetilen şekillerde geliştirdi ama unutmayın ki sunum araçlarını “ben iş çatısı olmayan yerde iş yapmam!” diyenler değil işin ne olduğunu anlayanlar geliştirdi ve sunum çatılarının ne yaptıklarını da en iyi o işi yapanlara anlatabilirsiniz
eleştirim özellikle yazının geneline yayılmış olan frontend developerlar yeni gelişen teknolojiye ayak uyduramaz yada büyük zorluklar çekerek ayak uydurur ama biz bu yollardan geçtik dependency injectionı da MVC yapısınıda zaten biliyoruz şeklindeki önyargılı ve cesaret kırıcı sözlerinize ki aslında bir frontend developer değilim ve üstüme vazife değil.
ayrıca frontend ve backend developerlar, başarılı bir frontend ve başarılı bir backend istenildiği sürece varlıklarını koruyacak nedeni ise basit teçhizatlar insanlara yardım için vardır işlerini elinden almaz zıpkın ve tüfek tetikle çalıştığı için iyi bir tavşan avcısı iyi bir balık avcısı olmaz daha öğrenmesi gereken bir sürü yeni anlayış, suyun ve balığın davranışları vardır.
sürç-i lisan ım ve noktalama katliamım affola,
niyetinizin kötü olmadığının farkındayım yapıcı bir eleştiriyle birlikte tezinize anti-tez sunmaya çalıştım umarım yanlış anlaşılmam.
Ne yazik ki web tasarimcisi ile frontend programcisi karistirilmis yorumda. User experince denilen seyi web tasarimcilari gelistirir, frontend programcilari koda doker. Bu koda dokme islemi artik iptidai yontemlerle yapilmamali. Backend programciligi ornek alinabilir.
dipnot: UX yalnızca web tasarımdan ibaret değildir, sistemin çalışması, süreçler, adımlar, kullanım kolaylığı gibi backend tarafını da ilgilendiren görevleri kapsar. Aslında dilimizde yanlış algılansa da “tasarım” kelimesi de zaten yalnızca görünümü ifade eden bir kelime değildir. Aslında altyapının kendisi de tasarımdır.
UX sadece bir örnekti ve haklısınız designer lar tarafından daha fazla üstünde durulması gereken bir konu ama hala konsept farklılıkları olduğunu savunuyorum şahsi görüşüm developer, frontend ve backend den anlamalı ama bir projede sadece birine odaklı çalışmalı şeklinde
aşağıdaki fullstack developerın duruma göre frontend ve backend taraflara geçişi örneğinizi okudum ve ne demeye çalıştığınızı daha net anladım bu konuda kesinlikle haklısınız ama bu frontend veya backend developeri yok etmez buna makine, elektrik elektronik, bilgisayar mühendislikleri ile mekatronik mühendisliği arasındaki ilişki örnek gösterilebilir
Bence soylediklerinizin sadece belirli kısımları dogru ancak tamamen backend yazılımcıların frontendin yerini alması soz konusu degil. Bu ayrımlar sadece farklı teknolojik ayrımlardan dolayı degil bir bütünü parcalara ayırarak her parcanın ayrı uzmanlıga sahip kisiler tarafından uygulanmasının zaman ve performans acısından getirdigi avantajlardan dolayıdır. Frontendi nasıl yorumluyorsunuz bilmiyorum ancak hic bir backend yazılımcı veya tek bir bireyin html,css ve javascript ile etkilesimli ui development yapması mumkun olsada zor. Eskiden tek bir yazılımcı her seyi yapardı bu yuzden bu ayrımlar basladı simdi tekrar aynı noktaya sadece teknolojik yeterlilik saglanması gerektigi icin donmek pek mantıklı gorunmuyor bana gore. Frontend daha cok kullanıcı etkilesiminin oldugu noktaları ve bu noktaların backend ile iletisimini saglayan katman. Frontend yazılımcılar backend yazılımcıya donusmuyor tam tersine edindikleri yeni teknolojiler ile backend uzerindeki yuku hafifletiyorlar. Günümüde testide backendciler yapıyor ama dunyada test developer diye bir kavram var bu ayrısmaların nedeni butun isi tek yazılımcının yapmasının dogru olmadıgının tecrube ile belirlenmis olması. Bu nedenle frontendi backendcilerin ustlenmesi gibi bir durum soz konusu degil hala bu katmansal ayrımlar gerekliligini koruyo ve koruyacaktırda. Saygılar.
Ben güncel projemde frontend/backend programcisi ayriminin sikintisini yasadim. Frontend islerini yapan programcimiz 2hafta hastaydi. Bilin bakalim 2 hafta boyunca ne yapmak zorunda kaldik? Javascript uzmani olmadigi icin icimizde, isler yatti. Sadece bu sebepten dolayi bile herseyden anlayan fullstack programcilarin ise alinmasi zaruri.
Frontend programciligi html, css degildir. Bunlar turing complete olmayan programlama dili bile degil. Html, css web tasarimcilarinin isi. Bir programcidan bunlari yapmasini bekleyemezsiniz. Fullstack programcilar yaninda web tasarimcilar ekip icinde varliklarini koruyacaklar.
2 hafta uzun bir süre frontend developerınıza geçmiş olsun dileklerimi iletiniz 2 hafta onun açısından hiç kolay geçmemiş olmalı
Tesekkürler iletelim. Evde bos durmamis 🙂
Bence bu iki rolün birleşmesi (ihtimali) bu yazdıklarınızdan ziyade piyasada iki farklı işi tek kişiye yaptırmak isteyen işverenler neticesinde olabilir ancak bu şekilde geliştirilen projelerde kalite ne seviyede olur orası bilinmez. Web projelerinde geliştirme adına 3 safha var bunlar grafik tasarım, arayüz geliştirme (frontend) ve yazılım geliştirme (backend). Adımlar sırayla bu şekilde olduğundan bazı durumlarda ya ilk iki adım yada son iki adım birleştirilecek şekilde olabiliyor. Siz bu ikinci durumdan bahsetmişsiniz. Elbette ki frontend ve backend ehliyetine beraber sahip olmak bir avantajdır ancak uzmanlık/profesyonellik adına bunların ayrılması da avantaj sağlamakta özellikle orta ve büyük ölçekli projelerde. Bu nedenle “Frontend ve Backend Programcısı Tarihe Karışıyor” fikrinize pek katılmıyorum en azından yakın gelecekte.
“Elbette ki frontend ve backend ehliyetine beraber sahip olmak bir avantajdır ancak uzmanlık/profesyonellik adına bunların ayrılması da avantaj sağlamakta özellikle orta ve büyük ölçekli projelerde. ”
Bir önceki yorumuma bakiniz. Sadece frontend programcisi 2 hafta hastalandi diye, proje durma seviyesine geldi. Yazimda belirtmeye calistim. Frontend ve backend development artik farkli uzmanlik alanlari gerektirmiyor. Burada web tasarimciligi ile web programciligi karistiriliyor. Bir web programcisindan html, css yapmasi beklenmemeli, yani web tasarimi yapmiyor, kod yaziyor frontend developer. Html, css web tasarimcisinin isi. Durum böyle olunca ve frontend kisminda ileri seviye yazilim teknikleri uygulanmasi zaruri hale geldigi icin frontend/backend ayrimi yerine, fullstack devler aranacak. Yeni frontend catilari sayesinde teknolojik ve yazilim metodolojsi olarak iki katman arasinda hicbir farklilik kalmiyor.
Öncelikle elinize sağlık. Yazdıklarınızın bir kısmına katılıyorum ama bazı noktalarda atlanan şeyler olduğunu düşünüyorum.
Katıldıklarımla başlayayım. Bir Front-end (FE) geliştiricisi “ben SOLID bilmem, katmanlardan anlamam, design-patternlar hakkında bilgi sahibi olmak zorunda değilim, temiz kod mu? o da ne, jQuery herşeye yeter” diyor ise dediğiniz gibi yavaş yavaş piyasada istenen elemen olmaktan uzaklaşacaktır ve eğer bunlar da neymiş deyip araştırıp öğrenmezse “Hanımlar jQueryci ayağınıza geldi” diye pencerelerden seslerini duyabiliriz.
İşin şakası bir yana, kesinlikle temel programcılık mantığını ve yazılım mimarisini bilmek ya da hakkında fikir sahibi olmak gerektiğini düşünüyorum. (Hatta ve hatta contiuous delivery/integration, micro servisler, virtualization, containerization gibi konular hakkında da bilgi sahibi olursa tadından yenmez.) Dediğiniz gibi Back-end geliştiriciler tarafından uzun zamandır kullanılan yapılar yeni yeni JS dünyasına gelmese de popülerliğini yeni yeni arttırıyor.
Ancak, JS ile illa ki class inheritance ile geliştirme yapmak zorunda mıyız sorusu tartışılır. JS fonksiyonel programlama yapmak için oldukça uygun bir dil ve hatta class ile yapmaya ne kadar zorlarsanız ve sıkı bağımlılıklar yaratırsanız başınız o kadar belaya girebilir. ES6 (ES 2015) class mantığını getirdi ve birçok yazılımcı bu yeni özellikleri hem node hem de babel ve browsify yardımı ile tarayıcılarda kullanmaya başladılar. Ancak öte taraftan Reactive prgoramlama da popüleritesini yükseltmeye başladı.
Prototypal Inheritance ve Functional programming javascriptin en büyük artılarından biri. Ve functional programlama demek spagetti kod yazmak demek değil. O yüzden belki de class yoksa programlama yapılamaz diye düşünmek belki de pek doğru olmaz. Hatta sıkı bağımlılıklı (tighyly coupled) yazılmış kodlar joe armstrong’un goril/muz problemini doğurur. Siz bir muz istersiniz ama sonunda elinde muz tutan bir goril ve bütün bir ormanı elde edersiniz.
Genel olarak kişinin kendisini mantık ve yöntemler olarak geliştirmesini doğru buluyorum ama tek bir yöntem doğrudur kısmında ayrışıyorum.
İkinci konu ise, atlandığını düşündüğüm HTML ve CSS mevzusu. HTML ve CSS tasarımcının işidir diye değinilmiş ve ben buna kesinlikle katılmıyorum. HTML ve CSS web uygulamalarının eti kemiğidir diye düşünüyorum. Kötü yazılmış CSS ve HTML sizin yazdığını o mükemmel mimariye sahip uygulamanızı yerlerde süründürür. Reflowlar, repaintler havalarda uçar. ‘lerin içerisinde ler kol gezer. Sadece performans ve görsellik anlamında değil. Yukarıdaki programcılık prensiplerini benimseyerek yazılmamış CSS kodları sürdürülebilir olmaz ve kendini tekrar eden ve ezen, tek bir margin ya da padding’i değiştirmeye korktuğunuz bir canavar elde edersiniz. Dolayısıyla programlama bilgisi olmayan bir tasarımcı sizin kabusunuz olabilir. CSS ve semantik HTML konusundaki tartışmalara burada girmeye fırsatımız bile olamaz diye düşünüyorm.
Tasarımcı ve hatta bence UX çalışanı tek satır (markup bile olsa) kod yazmamalıdır. Ya da bu bağlamda eğer HTML ve CSS görevini tasarımcılara yüklemek istiyorsak yakında fullstack tasarımcılar türemesi gerekir.
Merhabalar; hepinize saygılar sevgiler…
Ben yorum olarak biraz enteresan bir yerden giriş yapmak istiyorum. Önce elimize bir çekiç veriyorlar, sonrada gördüğümüz her şeyi çivi zannediyoruz. Sadece çekiçle bütün işleri yapamayacağımızı anlamaya başladığımızda elimizdeki çekiç balyoz olup kafamıza iniveriyor ; iş işten geçiyor.
Seneler evvel işsizlik belası yüzünden .nete bulaştım. Bulaştım diyorum çünkü bilinçle yapılmış bir tercih değildi. Neyse… İlk başta .Net’in 2.0 versiyonuyla tanıştım sonra da dile o geldi bu geldi derken çekiçle uğraşmaktan vazgeçtim. Şimdi java mı .net mi tartışması yapan kardeşlerime gülüyorum. Ya bir süre benim gibi başlayıp ömürlerini yiyecekler ya da gelişen teknolojilerin felsefesini iyi anlayıp baştan neyle uğraştıklarını bilip şikayet etmeyecekler. Halbuki en başta öğrenmemiz ve ayırt etmemiz gereken şey araçlar, araçların sundukları; bunları geliştirenler ve kullananlar. En önemlisi de neyi ne kadar çözebiliyorlar?
.Net dili bir araç, keza java ve diğer diller de aynı… Hepsinin bir amacı var. En nihai amaçları dijital ortamda problem çözmek veya bunlarla çözüm geliştirmek. Birileri bir dil geliştiriyor, ardından ide denen atölyeyi veriyor sonrada çıkıp karşımıza diyor ki : ” Kardeşim sana öyle bir dil geliştirdim ki çözemeyeceğin problem kalmayacak ; ister kişisel takıl ister kurumsal. Özcan hocama bu noktada katılıyorum. Yıllarca frameworkleri öğrenmek için uğraştık, her biri belki geliştirici için ayrı bir yük vs… Ama ihmal ettiğimiz noktalarda olmadı değil. Sonra da tatar ramazan gibi birileri çıkıp : “Ben bu oyunu bozarım arkadaş…” dedi. Front back’e geçti, back te frontu şutladı vs… Gerçekten durum böyle mi? Değil elbette… Bu da bizim her alanda olduğu gibi oturmamış kavramların kargaşasından başka birşey değil…
İster .net olsun ister java isterse başka bir dil, sonuçta üzerinde çalıştığımız platform çözüm geliştirmek için kullandığımız dili başka bir dile çevirmiyor mu? Ama IL kodu, ama baytcode vs… Şimdi birde web tarafına bakalım. HTML var CSS var JS var. Peki bu kodlar nerde çalışıyor? Tarayıcıdaki iki adet motorda, nedir onlar? Render engine ve script engine. Peki sizin tabirinizle back endcinin front endciden ne farkı var? Biz yazılım geliştirme konseptleriyle uğraşırız onlarsa oturup script – markup kodu yazar. Bizim dilimiz derlenir onların ki yorumlanır vs… İki tarafta bir sanal makine kullanır ama farkında bile değildir. Sonra tarayıcıdaki motor birgün sınırlarının dışına çıkar ve sunucu tarafında gezintiye başlar, bizde bunun burda ne işi var diye oturur tartışmasını yaparız vs..
Üzerinde çalıştığımız platform, yazılım geliştirme teknikleri acaba her sıkıntımızı hallediyor mu? Nesne yönelimli programlamada bile hala sıkıntılarımız var. Prototip tabanlı dillerle sınıf tabanlı dilleri birbirine karıştırıyoruz. Ondan dil olmaz bundan bu olmaz vs. Peki neyi ne kadar özümseyebildik? Ben en başta kendime soruyorum bu soruyu… Kaç tane programlama paradigmasından haberim var? OOP nedir? Paradigma mıdır programlama dili mi? Yoksa Object Oriented diye bir dil var da bize C#, Java diye mi yutturuyorlar? Saçmaladığımın farkındayım ama sizi çekmek istediğim nokta şu :” Biz neyin ne amaçla varolduğunu bilmeden uzmanlaşmaya çalışıyoruz.” Sonra da işimizi yüceltmek adına bir sıfat bulma çabasına giriyoruz. Halbuki çekici elimize verenlerin felsefelerine bir bakın, bu değişimlerle ilgileniyorlar mı ilgilenmiyorlar mı? Bizim kullandığımız diller ve araçlar işleri kolaylaştırıyor mu zorlaştırıyor mu?
Teknik dediğimiz, peşinden koştuğumuz şeyler ilahi kurallar mı? Neden aynı problemi farklı metodolojilerle çözemeyelim? Gelen her teknoloji her problemi çözmez. Bizim bakış açımızda sıkıntı var. Biz web’i hala web tarayıcıdan ibaret görelim. MVC konsepti sadece bir tekniktir, solid konsepti bir ilkeler bütünüdür. Aslında farkına varmadığımız şey bunlar ileri seviye kavramlar filan değildir. Sağlam bir programcıda bile bulunması, öğrenilmesi gereken en temel kavramlardır. Fakat çözüm diye kabullendiğimiz yöntemler de ilkeler de, dile veya araçlara yapışık değillerdir. Her araç diğer araçların bazı özelliklerini kendi bünyesinde barındırabilirler. Bunların dogmatic,değişmez olmadıklarını düşünüyorum.