Not: Bu yazı bana ait değildir. dev.to sitesinde yayınlanan ve Paul Isaris’e ait olan “The 14 habits of highly effective developers (Part 1)” başlıklı yazının çevirisidir. Çeviri için kendisinden izin alınmıştır.
Giriş
Bir çok kişi, başarılı bir Junior yazılımcıdan mid-level (orta seviye) bir yazılımcıya geçiş yapmanın zaman ve tecrübe işi olduğunu düşünüyor.
Aslında bu iki tip yazılımcıyı birbirinden ayıran çizgi ince bir çizgi ve kişiye göre değişkenlik gösteriyor. Bu yazı, hiç bitmeyen “Orta seviye bir yazılımcıyı tam olarak ne tanımlar?” tartışması üzerine daha fazla şey söylemeyecek.
Dürüst olmak gerekirse birinin düşünce yapısını değiştiren ve Junior seviyeden orta seviyeye geçiren şeyin alışkanlıklar olduğuna sıkı bir şekilde inanıyorum.
Alışkanlıklar, sistematik olarak yaptığımız ve bize garip gelmeyen doğal davranışlardır. Kodla ve işle alakalı alışkanlıklar edinmek profesyonel ve kişisel gelişim için kritik öneme sahiptir.
Uzmanlaştığınızda daha verimli bir şekilde gelişim sağlayacağınız ve bir sonraki seviyeye geçmenize yardım edecek alışkanlıklara bakalım.
1. Küçük metotlar yazın
İdeal olanı 20–30 satırdan daha uzun olmamasıdır. (LoC: Line of code) Bu alışkanlık son derece önemlidir. Sizi yalnızca daha derli toplu kod yazmaya zorlamaz, aynı zamanda kodunuzu modülarize etmeye başladığınızda analitik düşünmenize yardımcı olur. İçinde çok fazla if’in, for döngüsünün olduğu çok girintili büyük bir metotla uğraşmak tam bir kabus gibidir. Böyle bir metodu yazarken çok kolay ve anlaşılır geliyor olabilir ama birkaç gün sonra bile o metodun ne iş yaptığını anlamanız çok zor olacaktır.
Üstüne üstlük büyük metotlar çoğunlukla yeniden kullanılabilir değildir. Yalnızca bir projedeki özel bir ihtiyaca hizmet etmek üzere yazılırlar ve başka yerde kullanılmaları zordur.
2. Anlamlı isimler verin
Hem metotlara, hem de değişkenlere anlamlı isimler verin. Mid-level (orta seviye) bir yazılımcının “x”, “xyz” veya “object” gibi isimlere sahip değişkenler yazması makul değildir. Değişkenlerin İngilizce (veya Türkçe) kelimelerle isimlendirilmesinin amacı anlamlı olmalarıdır.
Kodunuzla iletişim kurmanız dokümanlarla veya comment’lerle iletişim kurmanızdan çok daha önemlidir.
Comment’lerin amacı “nasıl”‘ı değil, “neden”‘i cevaplamaktır.
Anlamlı değişkenlere sahip olmanız kodunuzu okuyan kişiyle daha iyi bir iletişim kurmanıza yardımcı olur ve aynı zamanda haddinden fazla comment yazma ihtiyacınızı azaltmış olursunuz. Bu, hem değişkenler hem de metotlar için geçerlidir. Ayrıca bir metotu isimlendirmek sizi çok uğraştırıyorsa metodu basitleştirmek için kodunuzu refactor etmeyi de düşünün. Çünkü iyi ve temiz yazılmış bir metota isim bulmak, karmaşık bir metota göre daha kolaydır.
İsimlendirmeyle boğuştuğunuzda bir an için durun ve isimlendirmeye çalıştığınız bileşenin çok karmaşık olduğunu ve refactoring’e ihtiyacı olduğunu düşünün.
3. Çok fazla parametre kullanarak metodunuzu karmaşıklaştırmayın
Metodunuzda çok fazla parametre olması refactoring yapmanız gerektiğine bir işarettir. Bu tarz metotlar yazmak çoğunlukla SRP’ye (Single Responsibility Principle / Tek Sorumluluk Prensibi) aykırıdır. Yani metodunuzun çok fazla sorumluluğu olur ve çok fazla iş yapar. Etkili ve temiz bir metot, bir işi iyi bir şekilde yapan metottur. Uncle Bob‘a göre bir metot için en fazla üç parametre makul sayılabilir. Bu görüş bu kadar katı olmasa da bir metot için arzu edilen parametre sayısı konusunda size bir fikir verebilir.
Metodunuzun lokal parametrelerini class field’lara çevirmeyin. Kodunuzu refactor etmeyi veya metodunuzu iki parçaya bölmeyi ve metotlarınıza daha az iş yaptırmayı ihmal etmeyin.
Fonksiyonların çok az parametresi olmalı. Parametresiz olması en iyisi, sonra bir parametreli, iki parametreli ve üç parametreli. Üçten fazlası ise güvensizdir ve peşinen uzak durulmalıdır.
— Robert C. Martin
4. Bir sınıfta çok fazla metot tanımlamaktan kaçının
Parametre sayısının yanısıra bir sınıftaki metot sayısı da önemlidir. Çok fazla metodun olduğu büyük sınıflar genellikle o bileşenin çok fazla şey bildiğine veya çok fazla şey yaptığına işarettir. Bu tarz bileşenlerin yüksek bağlılıklı olarak anti-pattern bir yapıda yazıldığını ifade etmek için God Class (Tanrı sınıf) terimi kullanılır.
Bir sınıfta çok fazla metodunuz varsa kodun akışı esnasında sınıfın davranışını değiştirmek için o sınıfa kaç kere girmek zorunda olduğunuzu düşünün. Bu durum, Açık-Kapalı prensibine (Open-closed principle) -yani gelişime açık, değişime kapalı ilkesi- aykırı olabilir.
5. Üçüncü parti kütüphanelerin LTS/stabil sürümlerini kullanın
Her zaman sizden sonra kodunuzu kullanacak ve projenizi yeniden derleyecek kişiyi düşünün. Kütüphanelerin LTS (Long Term Support / Uzun Süreli Destek) sürümlerini kullanmak yeni özelliklere sahip olma açısından iyi bir tercih olmasa da gelecekte re-build / re-compile ihtiyaçlarını düşününce daha iyidir.
Kullandığınız araçların en yeni ve en güzel sürümlerini kullanma isteğinizi bastırın. Her zaman en güvenli ve en stabil sürüme bağlı olun. Gelecekteki kendiniz ve iş arkadaşlarınız size teşekkür edecek!
6. En yaygın tasarım desenlerini tanımlamayı öğrenin
Çoğu büyük projenin bir veya birden fazla tasarım deseni kullanılarak yapıldığı doğrudur. Tasarım desenleri elemanların açıklamalarını, ilişkilerini ve soyutlama seviyelerini (abstraction level) tanımlar. Hepsini bilmek veya hepsinde iyi olmak zorunda değilsiniz fakat en temel olanları bilmek faydalı olacaktır. Yalnızca düşünme ve tasarlama açısından değil, aynı zamanda code base için tespit etmek açısından da.
Code base içinde tasarım desenlerini tanımlayabilen kişi, belirli sınıf ve objeler için nereye bakması gerektiğini bildiği için kodu sürdürebilir ve ekstra fonksiyonlar ekleyebilir.
İyi uygulanmış bir tasarım deseni, projeye dahil olan herkesin aynı tasarım dilini konuşmasını ve kod içinde daha etkili iletişim kurmasını sağlar.
7. Her zaman kendinizden sonrakini düşünün
Bu kişi siz olabilirsiniz, bir iş arkadaşınız olabilir, yeni bir çalışan olabilir, hatta başka bir şirkette çalışan bir yazılımcı da olabilir, ama birileri sizin kodunuzu sürdürmek veya ekstra fonksiyonlar eklemek zorunda kalacaktır.
Çoğu junior yazılımcı, yalnızca bir kişinin kod yazdığı ve başka kimsenin dahil olmadığı klasik üniversite projesi yaklaşımının olduğu projelerde kullanıldığı için bu maddenin anlaşılması biraz zor.
Profesyonel bir ortamda durum biraz daha farklı; yıllar önce yazılmış bir projede kod yazmanız istenecek ve kodunuzun birkaç yıl içinde gelecek “sonraki kişi” için hazır olması gerekecek. Yani bir şeyin çalışır hale gelmesi için geçici bir kod yazdığınızda, build sürecinde eklediğiniz şeyi dokümante etmekten kaçındığınızda, refactoring etmekten imtina ettiğinizde, ileride sizden sonra uğraşacak kişi için teknik borç (technical debt) çıkarıyorsunuz.
Birkaç saatte bir kodunuzu gözden geçirmek için zaman ayırın. README dosyalarına gerekli dokümantasyonu ekleyin, projeye geçici olarak eklediğiniz dosyaları ve kullanılmayan kodları silin. Mimari veya programlama ile ilgili bir konuda karar almanız gerektiğinde zorlanıyorsanız çalışma ortamınızda sizden daha tecrübeli biriyle iletişim kurun. Yalnızca kodunuzun durumunu iyileştirmiş olmayacaksınız, aynı zamanda gelecekte benzer durumların içinde bulunduğunuzda bununla başa çıkmak konusunda kendinizi geliştirmiş olacaksınız ve gururunuzun incinmesine alışacaksınız. (Bu, Junior aşamasını geçtikten sonra sürekli yaşayayacağınız bir şey :) )
Sonuç
Junior seviyesinden mid-level seviyesine geçmek bir gecede olan bir şey değil. Kariyerinizde ilerlemek ve daha iyi bir profesyonel yazılımcı olmak iyi alışkanlıklar edinme işidir. Bu makalede bu geçişe başlamak isteyenler ve Yazılım Geliştirici olarak etki bırakmak isteyenler için en önemli alışkanlıkları sıraladım.