Üst %1’lik mühendislerin 7 basit alışkanlığı
(engineercodex.substack.com)- "Elit kod yazarlarının diğerlerinden daha iyi performans göstermesinin yolları"
Kod yazarı değil, mühendis olun (Be an engineer, not a coder)
- Mühendislik, problem çözmektir
- En iyi mühendisler kodu, amaca ulaşmak için bir araç olarak görür
- Kod yazmanın keyfi vardır ama amacı olmayan kod yazmanın bir anlamı yoktur. Bunun yerine kod, kullanıcılar için çözüm tasarlamakta kullanılır
- Kodlama yaratıcılığı teşvik eder! Yaratıcılık çoğu zaman kısıtlar altında ortaya çıkar. Çözülmesi gereken net bir problem gibi bir "kısıt" eklendiğinde, mühendisler kendilerine en uygun gördükleri şekilde çözüm arama ve üretme özgürlüğüne sahip olur
- En iyi mühendisler ürün odaklıdır; her şeyden önce insanlar için problem çözmeyi önceliklendirir ve bu da bir sonraki adıma götürür
Bilgisayar için değil, insan için kod yazın (Code for the human, not the computer)
"Bilgisayarın anlayacağı kodu herhangi bir aptal yazabilir. İyi programcılar insanların anlayacağı kod yazar." - Martin Fowler
- Kod yalnızca bilgisayar için değil, insanlar içindir
- Kod, onu okuyacak, bakımını yapacak ve onun üzerine inşa edecek aynı ekipteki mühendisler içindir
- Kod; telefon kullanan küçük bir çocuk, API çağıran geliştirici ve siz dahil kullanıcılar içindir
- En iyi mühendisler, kodun değerini her zaman tüm kullanıcılar açısından değerlendirmiştir
- Müşterilerinden yalnızca birini bile memnun edemiyorsa, o kod production’a çıkamazdı
Kodun kendisine bağlı kalmayın (Detach from the code itself)
- Üst düzey mühendisler kodun kendisine saplanıp kalmaz
- Genel sonuç daha iyi olacaksa %90 tamamlanmış kodu silip yeniden başlamaktan korkmazlar
- Kod kişisel bir şey olmadığı için geri bildirimi aktif biçimde kabul ederler
- Kod kusursuz değildir. Kimse kusursuz kodla ilgilenmez; insanlar yalnızca fark yaratan kodla ilgilenir
- Koda bağlanmamayı öğrenmenin en iyi yolu, "20 yıl sonra yazdığınız kodun büyük kısmının teknik borç hâline gelmiş, artık kullanılmıyor ya da yeniden yazılmış olacağını fark etmektir"
Tutarlı standartlar kullanın (Use consistent standards)
- Kod yazarken tutarlı standartlara ve kodlama stiline bağlı kalın
- Tutarlılık, gelecekteki sizin ve ekip arkadaşlarınızın kodu daha kolay okuyup anlamasını sağlar
- Tutarlı bir stil rehberi kullanmak hem ekibin hem de codebase’in daha kolay ölçeklenmesini sağlar
- Meta ve Google gibi şirketlerin zaman içinde codebase’lerini okunamaz veya bakımı yapılamaz hâle getirmeden çok miktarda kodu hızla dağıtabilmesinin yolu budur
- Yüksek performans gösteren tüm şirketler stil rehberlerini içselleştirmiş, faydalarını bilmiş ve olabildiğince bunlara uymuştur
- Google bazı stil rehberlerini open source olarak yayımladı
- Meta’nın da bazı open source projelerinde C++ stil rehberi bulunuyor
- İpucu: Ekibiniz için linter ile formatting ayarlarını yapmak, kesinlikle zaman ayırmaya değer
Basit kod yazın (Write simple code)
- Tanıdığım tüm elit mühendisler, üretmesi karmaşık olsa bile sonunda okunması ve anlaşılması kolay kod üretirdi
- Bunu tanımlamak için söyleyebileceğim en iyi şey, kodlarının "estetik olarak tatmin edici" olduğudur
- Kodları temiz, düzenli ve mantıklıdır (clean, organized, and logical)
- Kodda verilen her karar anlamlıydı; öyle değilse kod içinde iyi şekilde dokümante edilmişti
- Temiz kod yazmanın iyi yollarından biri, SOLID ilkeleri gibi prensiplere bağlı kalmaktır. Bunlar başlangıçta OOP (nesne yönelimli programlama) düşünülerek tasarlanmış olsa da genel programlamaya da genişletilebilir
- Single Responsibility: Bir sınıf yalnızca tek bir sorumluluğa sahip olmalıdır
- Open-Closed: Yazılım nesneleri (sınıflar, modüller vb.) genişletmeye açık ama değiştirmeye kapalı olmalıdır; böylece daha öngörülebilir ve bakımı kolay kod ortaya çıkar
- Liskov Substitution: Alt türler, programın doğruluğunu etkilemeden temel türlerin yerine geçebilmelidir
- Interface Segregation: Kod, her şeyi kapsayan dev bir arayüze bağımlı olmamalıdır. Bunun yerine paketlerin daha küçük, belirli arayüzleri içermesine ve import etmesine izin verilmelidir
- Dependency Inversion: Üst seviye modüller alt seviye modüllere bağımlı olmamalı; her ikisi de soyutlamalara bağımlı olarak daha esnek ve ayrık sistem tasarımlarını teşvik etmelidir
- Buna bir örnek naming’dir: iyi isimlerde sihirli değerler olmaz, ayrımlar nettir ve açıklayıcı fonksiyon adları ile anlaşılması kolay değişkenler kullanılır
Sürprizlere izin vermeyin (Don’t allow surprises)
- Kod beklenmedik sonuçlar üretmemelidir. Bu, kod ilkelerine uymak ve uygun testler yazmakla mümkündür
- İyi kod öngörülebilirdir
- Testler kodun açıklığını ve öngörülebilirliğini güçlendirir, güven verir. Güçlü otomatik testler sayesinde ekipler görünmeyen yerleri bozma korkusu olmadan kodu değiştirebilir
- Bazı test türleri
- Tekil bileşenler ve izole fonksiyonlar için unit testler
- Birden fazla bileşen arasındaki etkileşim için integration testler
- Tüm sistemin işlevini kullanıcı bakış açısından değerlendiren end-to-end testler
- Testler basit olmalıdır. Başarısız olan bir testi okuduğunuzda neyin yanlış gittiğini kolayca anlayabilmelisiniz
- Nelerin test edilmemesi gerektiğini bilmek de önemlidir
- Örneğin, end-to-end testlerin maliyeti programın gerçek faydasından büyükse, testler dikkatli dokümantasyon, izleme ve doğru kişilere (ör. kod sahiplerine) bildirim gönderme ile değiştirilebilir
- Ayrıca testler, frontend kodunda belirli bir CSS selector’ını test etmek ya da yalnızca data attribute veya screenshot testleri kullanmak gibi, kod içindeki implementation detail’leri test etmemelidir
Sık iletişim kurun (Communicate often)
- Harika sistemler tek başına inşa edilmez. Harika mühendisler tasarım gözden geçirmelerinden geçer, geri bildirim ister ve kodun ilk tasarımını sürekli yineleyerek geliştirirdi
- Herkesin bilgisinde başkalarının doldurabileceği boşluklar vardır. Yeni bakış açıları çoğu zaman kodu daha net hâle getirmeye veya daha önce düşünülmemiş yeni yaklaşımlar sunmaya yardımcı olur
- En iyi mühendisler, daha iyi bir nihai sonuç için birlikte çalışmaya zaman ayırmaktan korkmaz; iletişim ve iş birliğine önem verir
- Bu, bir ekip arkadaşına dokümanı hızlıca gözden geçirmesi için ping atmak veya önemli bir pull request’e code reviewer eklemek kadar basit olabilir
Hızlı… ve yavaş kod yazın (Code fast… and slow)
- Tanıdığım en iyi mühendisler projeleri hızlı tamamlar ama kodu yavaş yazar
- Kulağa garip geliyor, değil mi?
- Yukarıdaki tüm ilkeler ve alışkanlıklar kodlamanın ilk aşamasına daha fazla zaman ekler. Ama bunlar sayesinde mühendisler proje ilerleyişini adım adım ileri taşıyabilir
- Standart kullanmaya, doğru test etmeye, prensipleri uygulamaya ve sık iletişim kurmaya zaman ayırarak uzun vadede çok daha fazla zaman kazanabilirsiniz
- Bunu stajyer ve junior mühendis olduğum dönemde bizzat yaşadım; birçok mühendis için de aynı durum geçerlidir. Üç adım ileri gitmek için acele ederken bir engele çarpıp beş adım geri düşebilirsiniz
Kuralları körü körüne takip etmeyin (Don’t follow rules blindly)
- Yukarıdaki "kurallar" ve "ilkeler" yalnızca birer rehberdir. Her şey bu rehberlere kusursuz biçimde uymaz
- Bazen yazdığınız kod, dairenin içine sığmayan bir kare olabilir ama bu sorun değildir
- Bu durumda kodun neden belirli bir şekilde yazıldığını dokümante edin
- Aksi hâlde gelecekte siz ya da bir başkası koda bakıp "Vay, o zamanlar ne kadar aptalmışım. Bu neden standartlarımıza uymuyor?" diye düşünebilir
- Sonra da aynı sonuca yeniden varmak için 20 saatini kodu standartlara uydurarak baştan yazmaya harcayabilir
- Yazılım geliştirmenin gerçeği, tüm kodun temiz veya kurallara tamamen uygun olamayacağıdır
- Ama tutarlı, temiz, anlaşılır, test edilebilir ve değerli kod mümkündür
- En iyi mühendislerde gördüğüm diğer bazı kalıplar
- En az bir alanda derin domain bilgisine sahip olmak. Not aldığım tüm mühendisler frontend altyapısı, dağıtık sistemler, temiz UI gibi belirli bir alana odaklanıp uzmanlaştıkları için bugün kendi alanlarında en üst seviyeye ulaştılar
- Kendini sık ve uygun biçimde pazarlamak. Bu mühendisler görünmez yerlerde saklanmadı. Birlikte çalıştıkları herkes onların değerini ve uzmanlığını biliyordu; bu da doğru görünürlük yaratmaları ve etkili projelerde yer almalarının sonucuydu
11 yorum
İyi içgörüler edindim. Teşekkürler :)
Güzel bir yazı!
Teknoloji de önemli ama sonuçta insanlara fayda sağlayan ürünler yapmanın önemli olduğunu bir kez daha düşünmeme neden oluyor!!!
Güzel yazı için teşekkürler!
Meğer 7 alışkanlıkmış ama içerikte 9 tane varmış haha
Ben de saydım ama... En sondakiyle en baştaki galiba sadece başlık gibi duruyor! haha
Vay, büyük ölçüde katıldığım harika bir yazı hehe
Şimdiye kadar gördüğüm bu tür yazılar arasında açık ara en iyi içerik.
Biraz genelleştirince herkesin işine yarayabilecek güzel bir yazı.
Bu, özet değil de neredeyse çeviri gibi olmuş ama... Özet için çok teşekkürler.
Ara sıra dönüp okunabilecek bir yazı gibi görünüyor.
Gerçekten öyleymiş hahaha, ben de bunu dönüp dönüp okumayı düşünüyorum.