React Native mi yoksa Flutter mı?
Uzun zamandır bir şeyler yazmıyordum. Beni takip edenler neden artık yazmadığımı soruyorlardı ne zamandır. Aktüel konuların sıkıcılığı ve geçiciliğinden daha ziyade genel ve daha kalıcı kavramlar üzerine yazmayı sevdiğimden, doğal olarak aktüel konuları işleyenler kadar yazı çıkaramıyorum. Yazılarıma neden ara verdiğimi merak edenlere buradan bir iki cümle ile cevap vermiş olayım ve gelelim yazımızın esas konusuna. Bu arada küçük bir ipucu vereyim: Bu yazım da önceki yazdıklarımdan çok farklı şekilde ilerlemeyecek.
Bir süredir YouTube kanalım üzerinden canlı yayında kod yazıyor, düşüncelerimi ve tecrübelerimi orada paylaşmaya devam ediyorum. Hemen hemen her canlı yayında bana sorulan sorular arasında React Native mi yoksa Flutter mı kullanmalıyım sorusu oluyor. Genelde cevabım belli aslında. Ama bu sefer daha farklı bir şekilde bu soruya yaklaşmak istiyorum. Açıkcası benzer cevabı tekrar tekrar vermek yerine, bundan sonra bu tür karşılaştırmalı sorular ile alakalı düşüncelerimi merak edenleri bu yazıya yönlendireceğim.
Belki aranızda bu yazıyı bir merakla açıp, yazının başlığında söylediğim teknojiler arasından acaba hangisini seçmeleyim sorusunun cevabını öğrenmek isteyenler olacaktır. O zaman daha fazla vaktinizi çalmadan şunu belirteyim: Hayır, bu konu Flutter yada Reactive Native karşılaştırması olmayacak. Eğer bu itirafım moralinizi bozduysa, o zaman kusura bakmayın ve bu yazı ile zaman harcamayın. Bir teknoloji seçerken olaya sıradan bir programcı gibi yaklaşan ile doğru bir mühendis olarak yaklaşan arasındaki farkı anlamak hakkında olacak bu yazı. Eğer hala merak ediyorsanız, o zaman başlayalım.
Her çıkan teknoloji ile kafası karışan ciddi bir kitle var yazılım dünyasında. Çok da haksız değiller. Karşılarına çıkan her farklı blog yazısı ya da video, farklı bir teknoloji hakkında konuşup, ne kadar süper olduklarından bahsedebiliyor. Çoğu insan ise, İnternette güven duydukları bu yazılımcıların bir teknolojiyi öve öve bitirememelerine karşı ilgisiz kalamıyor ve nedenlerini çok anlamasalar bile o teknolojiye karşı ilgi duymaya başlıyorlar. Tabi güven duyulan bu yazılımcıların hepsi bu şekilde değil. Ama yine de kendi kullandıkları teknolojileri anlatmaları, çoğu insanın kafasını karıştırmaya yetiyor. Ne de olsa, bu adamlar kullanıyorsa, vardır bir hikmeti, değil mi? Olabilir. İnsanların tecrübelerini bir çırpıda silip atacak kadar kendimi kaybetmedim. Bu insanların tecrübelerini bir karşılık beklemeden paylaşmaları da açıkcası tebrik edilecek bir durum. Ama maalesef çoğu insan, bu videolara alternatif düşünceler olarak bakmak yerine, onları bazen fazlasıyla içselleştirebiliyorlar.
Diğer bir sorun ise, insanların kendi ihtiyaçlarını anlamadan, her teknolojiye göz dikmeleri. Teknolojiyi bir çözüm olarak görmek yerine, tüm dertlerine derman olacak, bilirlerse hemen iş bulabilecekleri, her platforma uygun kod yazabilecekleri, vs. kısacası 1 liraya bir çikolata alıp daha kaliteli lezzet almak varken, 10 tane sakız alıp en azından daha uzun zaman tad alırım mantığı ile meseleye yaklaşabiliyorlar. Mesela telefon uygulaması yazmak istiyor. O kadar emek harcayıp, sadece Android ya da iOS için uygulama yazmak yerine; Flutter, Phone Gap, React Native, vs. kullanıp hepsine yazarım düşüncesi ile bir taşla ne kadar kuş vurabileceğinin hesabını yapıyor. Anlaşılır bir durum. Ama kendisine React Native mi yoksa Flutter mı diye sorduran sorunun, aslında sahip olabileceği başka problemlerin bir semptomu olduğunu göremeyebiliyor. Bu sorular içinde boğulan bir yazılımcının problemlerinin altında yatan sorun büyük bir ihtimal hangi teknolojiyi seçeceği değil, kullanacağı teknoloji ile kaliteli bir uygulama çıkaracak yeterli motivasyon ve analitik düşünceye sahip olup olmadığıdır.
Yine benzer sorulardan bir tanesi olan Angular mı yoksa React mı şeklinde ki bir soru, soranın aradığı çözüm hakkında ki bilgisinin yetersizliğini gösterir. Daha doğru soru şekli şu şekilde olabilir: “Var olan websitesi projemde MVVM kullanmak istiyorum. Hangi teknolojiyi kullanabilirim?” .Veya başka bir soru: “Front-end kısmının mimarisi ile çok uğraşmak istemiyorum. Hangisi daha hızlı bir şekilde bu sorunu çözmeye yardımcı olabilir?” Elinizde ki problemi anlamadan, yada neye cevap aradığınızı bilmeden, hangi teknolojiyi kullanacağınızın projenizin başarısı açısından çok bir anlamı kalmayabilir. Problemi anlamayan, kullanacağı teknolojinin çözmeye çalıştığı sorunların ne olduğu ve bunun tam olarak nasıl çözdüğünü anlayabilir mi? Bunun cevabını siz verin.
Bir zaman önce yazdığım bir yazı vardı “Neden Angular Framework?” diye. Orada kendi aradığım özellikleri ve bunun Angular tarafından nasıl çözüldüğünü inceliyordum. Şu mu bu mu sorularının yerine, ne arıyorum ve nasıl olmasını bekliyorum şeklinde daha sofistike sorular ile meseleye yaklaşmak, sıradan bir programcı ile yazılım mühendisi arasında ki farklardan bir tanesi. O yazımı merak edenler, aşağıda ki linke bakabilirler:
Yukarı da ki yazımda sıraladığım bazı özellikler React kütüphanesinde de olabilir. Ama aradığımı, aradığım şekilde çözen Angular olduğundan onu seçtim. Bu React’i basit bir kütüphane yapmadığı gibi Angular’ı da herşeyin çözümü haline getirmiyor. Ama zaten aradığım bu değil. Aradığım benim sorunuma cevap olması.
Aslında şu gerçeğin de farkındayım. Herkes ne aradığını bilecek kadar bu meslekte zaman harcamış değil. Bazen uzman olarak gördüklerimizin fikirlerini genel bazı sorular ile almak istiyoruz. Bu tür karşılaştırma soruları da aslında bunlardan bir tanesi. Bazen de bu dünyadaki zamanımız yarın bitecekmiş gibi bir korkuya kapılıp, en doğru olanı seçmek istiyor ve oradan başlamak istiyoruz. O zaman benden bir abi, bir arkadaş, bir dost, vs. tavsiyesi olsun: Maalesef her zaman en doğru olanı seçemeyeceksiniz. Çoğu zaman en doğru olan ile değil, yeteri kadar doğru olan ile çalışmak zorunda kalacaksınız. Paçalarınız çamura batacak, bazen moraliniz bozulacak, bazen yazdığınız kodları silip en baştan yazacak, bazen gururunuz kırılacak, bazen akşamları gözlerinize uyku girmeyecek, bazen, bazen, bazen… Problemleri doğru anlayacak ve uygun çözümler aramanızı sağlayacak tecrübe işte bu şekilde kazanılacak. Ama bu şimdiden olaya daha sistematik bakmanız için kendinizi yetiştirmenize engel bir durum değil.
Diğer bir mesele ise, şuan kullandığınız teknolojileri kullanırken, nelerini beğenmediğinizi düşünün. Benim mulakat yaptığım insanlara sormaktan en çok zevk aldığım ve genelde kaliteli bir mühendis ile sıradan bir mühendisi en hızlı şekilde ayıran soruların başında gelir kullandıkları teknolojilerde ve geliştirdikleri projelerde beğenmedikleri ve kendilerini en çok zorlayan kısımlar. Hatta bunun da bir adım ötesi, beğenmedikleri o problemlere kendileri nasıl çözümler geliştirirlerdinin cevabını öğrenmeye çalışmak. Bu sorulara o kadar az insan cevap verebiliyor ki, yıllarca bu mesleği yaptığı halde insan hiç mi bu soruları kendine bir kez olsun sormaz diye şaşırmadan edemiyorsunuz. Bu soruları sormak ve kendiniz bazı cevaplar bulmanız için yıllarca bu meslekte çalışmak zorunda değilsiniz. Bu yaklaşım sadece sizi daha kritik düşünen birisi yapmaz aynı zamanda daha kaliteli şekilde öğremenizi sağlar. Çünkü aradığınız çözümleri dışarıda aramak yerine, önce kendi düşünceleriniz ve tecrübelerinizde ararsınız. Dolayısıyla, en etkili öğrenme faktörü olan ihtiyaç duymak ortaya çıkmış olur. Kendi cevaplarınızı aradığınızda, daha farklı çözümlere karşı duyduğunuz ihtiyaç artmış olup, geliştirmek istediğiniz problemi çok daha iyi anlamış olursunuz.
Yukarıda ki meseleye basit bir örnek vereyim: Yeni özellikler eklediğiniz projenizin hiç beklemediğiniz kısımlarının alakalı alakasız bir şekilde bozulmasından bıktınız. Kaliteli bir mühendis olduğunuz için, değerli zamanınızı projeyi baştan sona elle test ederek geçirmek istemiyorsunuz. İşte şimdi kritik düşünmeye başladınız. Çözüm ne olabilir diye düşünürken, bunu automate etmeniz gerektiği sonucuna vardınız. Bu da sizi, kodunuzu bir şekilde test edebilmem gerekiyor düşüncesine götürdü. Parça parça ya da diğer bir tabir ile ünite ünite kodunuzu test etmek istiyorsunuz. Ama kodunuza baktığınızda ünite şeklinde test edilmesinin zor olduğunu gördünüz. Çünkü sınıfınız, bağımlı olduğu diğer sınıfları kendi içinde oluşturuyor. Bu sınıfları bir şekilde mock etmek gerektiği aklınıza geldi. Ama mock olması için bunların dışarıdan interface olarak gelmesi lazım. O zaman bir şekilde bunları inject etmem gerekiyor dediniz. Farkında olmadan kendi IoC Container’ınızı tasarladınız ama acaba buna benzer şekilde başkaları tarafından geliştirilmiş ve yeniden kullanabileceğiniz bir kütüphane var mı diye sormaya başladınız. Derken karşınıza AutoFac, Ninject, vs. isminde bir sürü alternatif çıktı. Projenize baktınız. Mümkün olduğu kadar .dll dosyalarınızın birbirlerinden bağımsız olmasını istiyorsunuz çünkü o şekilde daha scalable olacağına karar verdiniz. O zaman bir şekilde dependency mapping olayını her assembly için kendi içinde yapmak istediğiniz sonucuna vardınız. Böyle bir özelliği hangi IoC Container sunuyor diye baktınız. Sonra başka bir soru aklınıza geldi, derken bu şekilde beklentilerinizi hangi kütüphane karşılamaya başlayacak diye bir fikriniz oluşmaya başladı ve onu seçtiniz…. (Not: Dependency Injection nedir diye merak edenler, aşağıda ki yazıma bir göz atabilirler:)
İşte meseleye bu şekilde yaklaşırsanız, o zaman uzman olduğunu düşündüğünüz insanlara bu şekilde genel geçer sorular sormak yerine, daha net sorular sorabilir ve daha doğru cevaplar alabilirsiniz. Hem de aldığınız cevaplar sizi daha doğru yönlendirir ve o insanların da zamanlarını, cevabı çok zaman alabilecek bu şekilde genel sorular ile almamış olursunuz. Herkes için kazanç.
Bu seferlik benden bu kadar. Bir sonraki yazımda görüşmek üzere.
Bu arada yazılarımı arada bir gözden geçirip bazı kısımlarını düzeltip yeni kısımlar ekleyebiliyorum. Eğer kafanıza takılan kısımlar varsa, arada bir bu yazıyı ziyaret edin. Belki cevabı eklenmiş olabilir.
