Junior Geliştiricilerin Yaptığı Hatalar
Çalışan kod yayınlamak bir temeldir. Hedef değildir.
Bir keresinde anlaması 45 dakika süren bir pull request incelemiştim. Mantık doğruydu. Testler geçiyordu. Ancak kod, sanki onu sadece yazarı okuyacakmış gibi yazılmıştı.
Geri bildirim verdiğimde geliştirici, "Ama çalışıyor," dedi.
Haklıydı. Çalışıyordu. Sorun tam olarak buydu.
Junior geliştiriciler genellikle teknik becerilere odaklanır. Ancak asıl eksiklikler genellikle alışkanlıklarda ve zihniyette yatar.
İşte sizi yavaşlatan o ince hatalar:
Başkaları yerine kendiniz için yazmak Kod, yazılmasından çok daha sık okunur. Bugün yazdığınız bir fonksiyona iki yıl içinde üç farklı kişi dokunabilir. Eğer bir yabancı kodunuzu 30 saniye içinde anlayamıyorsa, başarısız olmuşsunuz demektir.
Anlamadan kod kopyalamak Stack Overflow kullanmak sorun değil. Nasıl çalıştığını bilmeden bir regex desenini kopyalamak tehlikelidir. Kod tabanınızda bir kara kutu oluşturursunuz. Bozulduğunda hata ayıklayamazsınız.
Gereksiz karmaşıklık eklemek Juniorlar genellikle karmaşıklığı beceriyle eş tutar. Basit görevlere tasarım desenleri (design patterns) uygularlar. Gereksiz soyutlama (abstraction), kodun hata ayıklanmasını ve değiştirilmesini zorlaştırır. Soyutlamanın eksikliğini hissettiğinizde ekleme yapın.
Hata mesajlarını görmezden gelmek Hata mesajları ücretsiz dokümantasyondur. Bir stack trace gördüğünüz anda hemen Google'a koşmayın. Mesajın tamamını okuyun. Genellikle hangi satırın neden hata verdiğini size tam olarak söyler.
Çok erken veya çok geç yardım istemek 10 dakikalık bir problemde takılıp kalarak üç saatinizi harcamayın. Bu verimsizdir. Ancak bir senior'a sadece bir ekran görüntüsü atıp hiçbir bağlam (context) vermeyin. 20 dakika kuralını uygulayın: sorunu çözmek için 20 dakika harcayın. Neleri denediğinizi belgeleyin. Sonra bu belgelerle birlikte yardım isteyin.
Zaten var olanı yeniden inşa etmek Yeni bir yardımcı araç (utility) yazmadan önce kod tabanında arama yapın. Ekibiniz muhtemelen bu sorunu zaten çözmüştür.
Kötü commit mesajları "fix bug" gibi bir commit mesajı ekibinize hiçbir şey anlatmaz. Nelerin değiştiğini ve nedenini açıklayın. Git geçmişini bir dokümantasyon gibi değerlendirin.
Gereksinimleri kanun gibi kabul etmek Gereksinimler genellikle uç durumları (edge cases) gözden kaçırır. Sadece size söyleneni uygulamayın. İşler ters gittiğinde ne olacağını sorun.
"Merged" butonunda durmak Sahiplenme, PR'ınız merge edildiğinde sona ermez. Özelliğinizi QA sürecine kadar takip edin. Production ortamında izleyin. Hata raporlarını okuyun.
En büyük eksiklik sorumluluk bilincidir. Senior geliştiriciler sadece kod yazmazlar. Yeni sorunlar yaratmadan sorunları çözerler.
"Done" (bitti) üzerine optimize etmeyi bırakın. "Good" (iyi) üzerine optimize etmeye başlayın.