Geçen gün kıdemli bir pozisyona başvuran bir JavaScript geliştiricisiyle röportaj yaptım. Röportajda da bulunan bir meslektaşı, adaydan HTTP isteği yapacak ve başarısız olursa birkaç kez yeniden deneyecek bir işlev yazmasını istedi.
Kodu doğrudan tahtaya yazdı, bu yüzden yaklaşık bir şey çizmek yeterli olacaktı. Eğer meselenin ne olduğunu iyi anladığını gösterseydi, oldukça tatmin olurduk. Ancak ne yazık ki başarılı bir çözüm bulamadı. Daha sonra bunu heyecana bağlayarak görevi biraz daha kolaylaştırmaya karar verdik ve ondan geri aramalı bir işlevi vaatler üzerine kurulu bir işleve dönüştürmesini istedik.
Ama ne yazık ki. Evet daha önce böyle bir kodla karşılaştığı belliydi. Genel anlamda orada her şeyin nasıl çalıştığını biliyordu. İhtiyacımız olan tek şey, konseptin anlaşıldığını gösteren bir çözüm taslağıdır. Ancak adayın tahtaya yazdığı kod tamamen saçmalıktı. JavaScript'te vaatlerin ne olduğuna dair çok belirsiz bir fikri vardı ve bunlara neden ihtiyaç duyulduğunu gerçekten açıklayamıyordu. Bir ast için bu affedilebilirdi ama o artık son sınıf pozisyonuna uygun değildi. Bu geliştirici, karmaşık bir vaatler zincirindeki hataları nasıl düzeltebilir ve tam olarak ne yaptığını başkalarına nasıl açıklayabilir?
Geliştiriciler hazır kodun apaçık olduğunu düşünüyor
Geliştirme sürecinde sürekli olarak tekrarlanabilir malzemelerle karşılaşıyoruz. Her seferinde yeniden yazmamıza gerek kalmaması için kod parçalarını aktarıyoruz. Buna göre, tüm dikkatimizi anahtar parçalara odaklayarak, üzerinde çalıştığımız bitmiş koda apaçık bir şey olarak bakarız - her şeyin olması gerektiği gibi çalışacağını varsayarız.
Ve genellikle işe yarar, ancak işler zorlaştığında mekaniği anlamak fazlasıyla işe yarar.
Bu nedenle, kıdemli geliştirici pozisyonu için adayımız vaat edilen nesnelerin apaçık olduğunu düşünüyordu. Muhtemelen başka birinin kodunun bir yerinde ortaya çıktıklarında bunlarla nasıl başa çıkılacağına dair bir fikri vardı, ancak genel prensibi anlamadı ve görüşme sırasında bunu kendisi tekrarlayamadı. Belki parçayı ezbere hatırladı - o kadar da zor değil:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Ben de yaptım ve muhtemelen hepimiz bir noktada bunu yapmışızdır. Daha sonra işlerinde kullanabilmek için bir kod parçasını ezberlediler ve orada her şeyin nasıl çalıştığına dair yalnızca genel bir fikre sahip oldular. Ancak geliştirici kavramı gerçekten anlamış olsaydı, hiçbir şeyi hatırlamasına gerek kalmazdı; yalnızca nasıl yapılacağını bilirdi ve ihtiyaç duyduğu her şeyi kodda kolayca yeniden üretirdi.
Köklere geri dön
2012 yılında henüz front-end frameworklerin hakimiyeti kurulmamışken jQuery dünyaya hükmediyordu ve ben de kitabı okudum. jQuery'nin yaratıcısı John Resig tarafından yazılmıştır.
Kitap, okuyucuya kendi jQuery'sini sıfırdan nasıl yaratacağını öğretiyor ve kütüphanenin yaratılmasına yol açan düşünce sürecine dair benzersiz bir bakış açısı sağlıyor. Son yıllarda jQuery eski popülaritesini kaybetti ama yine de kitabı şiddetle tavsiye ediyorum. Onda beni en çok etkileyen şey, tüm bunları benim düşünebileceğime dair ısrarcı duyguydu. Yazarın anlattığı adımlar o kadar mantıklı, o kadar açık görünüyordu ki, eğer biraz inersem jQuery'yi kolayca yaratabileceğimi ciddi olarak düşünmeye başladım.
Elbette gerçekte böyle bir şey yapamazdım - bunun dayanılmaz derecede zor olduğuna karar verirdim. Benim kendi çözümlerim işe yaramayacak kadar basit ve naif gelirdi ve pes ederdim. Ben jQuery'yi, doğru işleyişine körü körüne inanmanız gereken, apaçık şeyler olarak sınıflandırırdım. Daha sonra, bu kütüphanenin mekaniğini araştırmak için neredeyse hiç zaman kaybetmeyecek, onu bir tür kara kutu olarak kullanacaktım.
Ama bu kitabı okumak beni bambaşka bir insan yaptı. Kaynak kodunu okumaya başladım ve birçok çözümün uygulanmasının aslında çok şeffaf, hatta açık olduğunu keşfettim. Hayır elbette böyle bir şeyi kendi başınıza düşünmek farklı bir hikaye. Ancak kendimize ait bir şey bulmamıza yardımcı olan şey, diğer insanların kodlarını incelemek ve mevcut çözümleri yeniden üretmektir.
Kazandığınız ilham ve fark etmeye başladığınız kalıplar, bir geliştirici olarak sizi değiştirecektir. Sürekli kullandığınız ve sihirli bir eser olarak düşünmeye alıştığınız o harika kütüphanenin, sihir üzerinde hiç işe yaramadığını, sadece bir sorunu özlü ve becerikli bir şekilde çözdüğünü göreceksiniz.
Bazen kodu derinlemesine incelemeniz, onu adım adım analiz etmeniz gerekebilir, ancak bu şekilde küçük, tutarlı adımlarla ilerleyerek yazarın çözüme giden yolunu tekrarlayabilirsiniz. Bu, kodlama sürecine daha derinlemesine dalmanıza olanak tanıyacak ve kendi çözümlerinizi bulma konusunda size daha fazla güven verecektir.
Vaatlerle çalışmaya ilk başladığımda, bu bana saf sihir gibi geldi. Daha sonra bunların aynı geri aramalara dayandığını öğrendim ve programlama dünyam alt üst oldu. Yani amacı bizi geri aramalardan kurtarmak olan modelin kendisi geri aramalar kullanılarak mı uygulanıyor?!
Bu, meseleye farklı gözlerle bakmamı ve bunun, önümdeki, engelleyici karmaşıklığını hayatımda asla anlayamayacağım anlaşılması güç bir kod parçası olmadığını anlamamı sağladı. Bunlar sadece merak ve derinlemesine dalma ile sorunsuzca anlaşılabilecek kalıplardır. İnsanlar kodlamayı bu şekilde öğrenir ve geliştirici olarak büyürler.
Bu tekerleği yeniden icat edin
Öyleyse devam edin ve çarkları yeniden icat edin: kendi veri bağlama kodunuzu yazın, evde yetiştirilen bir vaat oluşturun, hatta kendi durum yönetimi çözümünüzü yaratın.
Hiç kimsenin bunları kullanmayacağı önemli değil - ama artık bunu nasıl yapacağınızı biliyorsunuz. Ve eğer bu tür gelişmeleri daha sonra kendi projelerinizde kullanma fırsatınız varsa, bu genellikle harikadır. Onları geliştirebilecek ve başka bir şeyler öğrenebileceksiniz.
Burada amaç kodunuzu üretime göndermek değil, yeni bir şeyler öğrenmektir. Mevcut bir çözümün kendi uygulamasını yazmak, en iyi programcılardan öğrenmenin ve böylece becerilerinizi geliştirmenin harika bir yoludur.
Kaynak: habr.com