Serimizin önceki iki bölümünde mesleğe ilk adımlar ve kariyerin başında gerçekten neyin öğrenilmesinin faydalı olduğundan bahsetmiştik.
Şimdi neredeyse her Junior'ın çekindiği ana noktaya geliyoruz.
İlk Code Review. İlk kod yorumları. İlk düzeltmeler.
Ve ilk düşünce: "Acaba gerçekten bu kadar kötü mü yazdım bu kodu?"
Sakın panik yapma.
Hepimiz bir zamanlar bunun içinden geçtik.
Code Review bir sınav değildir
Bu, başlangıç seviyesindeki geliştiriciler arasında en büyük yanlış anlaşılmalardan biri olmalı.
Birçok Junior, koduna yapılan yorumları çok kişisel algılıyor. Stres ortaya çıkıyor. Güvensizlik. Bazen hayal kırıklığı.
Oysa Code Review'un amacı birine hata yaptığını kanıtlamak değildir. Tam tersine. Bu, iyi yazılım üretme sürecinin en önemli parçalarından biridir.
Code Review sayesinde:
- hata riskini azaltırız,
- kodun okunabilirliğini artırırız,
- birbirimizden öğreniriz,
- tüm projenin tutarlılığına özen gösteririz,
- takım üyeleri arasında bilgi aktarırız.
En iyi ekipler Code Review'u kontrol gibi görmez. Onu günlük bir tecrübe paylaşımı olarak görürler.
"37 yorumun var"
Korkutucu mu geliyor? Başta evet.
İlk Pull Request genellikle şöyle görünür:
- Yorum.
- Düzeltme.
- Bir yorum daha.
- Bir düzeltme daha.
Bir saat sonra tüm kodun çöpe gitmesi gerektiği hissine kapılırsın. Bu normaldir.
Sadece bir şeyi unutma: Senior, kodu düzeltmiyor çünkü üstünlüğünü göstermek istiyor. Bunu yapıyor çünkü birkaç ay sonra çok daha iyi kod yazıyor olacaksın.
Ve amaç tam olarak budur.
İyi bir Senior sadece "kötü" demez
Çalıştığımız en iyi geliştiriciler her zaman şöyle açıklardı:
- neden bir şeyi farklı yapmanın daha iyi olduğunu,
- mevcut çözümün ne tür sonuçlar doğuracağını,
- hangi alternatiflerin olduğunu,
- hangi çözümün bir veya iki yıl sonra daha kolay sürdürüleceğini.
Bu büyük bir farktır.
Çünkü şöyle denebilir: "Bu yanlış."
Ya da şöyle denebilir: "Bu çalışır, ama yarım yıl sonra bu modülü geliştireceksek bu yapıyla sürdürmek çok daha kolay olur."
İkinci durumda, sadece düzeltmeyi değil, çok daha değerli bir şeyi öğreniyorsun. Düşünme biçimini öğreniyorsun.
Clean Code güzel kod demek değildir
Bu, çok sık yanlış anlaşılan bir başka kavram.
Clean Code gösterişli görünen kod demek değildir. Boş satır sayısı değildir. Fonksiyon uzunluğu değildir. Hatta belli kalıpların kullanımı da değildir.
Daha basit bir şeyle ilgilidir - kod okunabilir olmalıdır.
Eğer yarım yıl sonra kendi projenizi açıp ne düşündüğünüzü hatırlamıyorsanız...
...muhtemelen kod yeterince okunabilir değildi.
Böyle bir söz vardır: Kod insanlar için yazılır. Derleyici sadece sözdizimini kontrol eder.
Ve bunda çok fazla gerçeklik var.
Kendi koduna aşık olma
Bu en önemli derslerden biridir.
Kod bir sanat eseri değildir. Bir tablo değil. Bir heykel değil.
Çözülecek belirli bir probleme yönelik bir araçtır.
Birisi daha iyi bir çözüm öneriyorsa...
...onu değerlendirmeye almak gerekir.
Bunun sebebi o kişinin daha büyük bir otoriteye sahip olması değil; belki gerçekten daha iyi olduğu içindir.
En çok öğrenen geliştiriciler, şöyle diyebilenlerdir: "Haklısın. Bunu farklı yapalım."
"Bende çalışıyor"
Tamam. Sonunda bu ünlü cümleye geldik. Her yazılım şirketinin bu şakanın bir versiyonu vardır...
Durumu bir düşünün.
Testçi bir hata bildiriyor.
Geliştirici cevap veriyor: "Bende çalışıyor."
Testçi tekrar kontrol ediyor. - Çalışmıyor.
Proje Müdürü bakıyor. - Çalışmıyor.
Müşteri de kontrol ediyor. - Çalışmıyor.
Ama... kodun yazarı için hala çalışıyor.
Tanıdık geliyor mu?
Sorun çoğunlukla kodun kendisinde değildir.
Nedenleri çok çeşitli olabilir:
- farklı veri versiyonu,
- farklı ortam,
- cache (önbellek),
- konfigurasyon,
- izinler,
- tarayıcı,
- işletim sistemi,
- daha önce kimsenin tahmin etmediği bir vaka.
Bu yüzden profesyonel bir geliştirici analizi "Bende çalışıyor." cümlesiyle bitirmez.
Bir sonraki soruyu sorar.
Neden bende çalışıyor ama başka yerde çalışmıyor?
Ve işte gerçek hata ayıklama (debugging) o zaman başlar.
"Bu sadece küçük bir değişiklik"
Bu, çoğu yazılım şirketinde hafif bir gülümseme uyandıran başka bir ifadedir.
Müşteri der ki: "Bu sadece küçük bir düzeltme."
Geliştirici ise muhtemelen altı yıldır kimsenin dokunmadığı bir dosyayı açacağını biliyordur.
O "küçük düzeltme" beş modülde, üç entegrasyonda ve iki veritabanında değişiklik anlamına çıkabilir.
Bu yüzden deneyimli geliştiriciler "sadece" kelimesine çok temkinli yaklaşır.
Sektörün en bilinen lafları
Her mesleğin kendi deyimleri vardır. Geliştiricilerinkiler de öyle.
Bunların birkaçı sanırım herkesin bildiği türden:
- "Bende çalışıyor."
- "Sadece beş dakika."
- "Bu bug değil. Bu özellik."
- "Zaten hiçbir şey değiştirmemiştim."
- "Prodüksiyonda patladı."
- "Sadece bir deploy kaldı."
- "Kesinlikle cache'dir."
- "Hafta sonu öncesi hızlı bir düzeltme."
- "Bu çalışmalı."
Ve muhtemelen en tehlikelisi: "Bunu cuma 16:00'dan sonra prod'a atalım."
Eğer IT'de çalışıyorsan...
...muhtemelen şimdi gülümsedin.
Geliştirici tek başına çalışmaz
Bu sıkça atlanan bir konu. Aslında çoğu proje ekip çalışmasıdır.
Geliştirici şu kişilerle çalışır:
- UX tasarımcıları,
- UI tasarımcıları,
- Proje Yöneticileri,
- Testçiler,
- DevOps mühendisleri,
- Yöneticiler/Administratorler,
- Analistler,
- Müşteriler.
Bu yüzden teknoloji bilgisi kadar önemli olanlar şunlardır:
- iletişim,
- dinleme becerisi,
- bilgi aktarma,
- sorumluluk,
- karşılıklı saygı.
En iyi kod, ekip birlikte çalışamıyorsa projeyi kurtaramaz.
Terimler sözlüğü
Code Review
Kodun yayına alınmadan önce diğer geliştiriciler tarafından incelenme süreci. Amacı kod kalitesini artırmak, hataları yakalamak ve bilgi paylaşmaktır.
Pull Request (PR)
Projeye değişiklik önerisidir. Code Review genellikle bu aşamada yapılır.
Clean Code
Okunabilirlik, sadelik ve sürdürülebilirlik hedefleyen kod yazma yaklaşımı; kullanılan tasarım kalıplarının sayısı değil, kodun anlaşılabilirliği önemlidir.
Debugging (Hata ayıklama)
Uygulamadaki hataların nedenlerini bulma ve düzeltme süreci.
Cache (Önbellek)
Uygulamanın hızını artırmak için verileri geçici saklama mekanizması. Test sırasında birçok tuhaf sorunun kaynağı olabilir.
Özet
Ne kadar uzun süre geliştirici olarak çalışırsak, bir sonuca daha çok yaklaşırız: En iyi geliştiriciler en az hata yapanlar değildir.
En iyi geliştiriciler şunları yapabilir:
- sorunun kaynağını daha hızlı bulmak,
- çıkarımlar yapmak,
- başkalarından öğrenmek,
- yapıcı eleştiriyi kabul etmek,
- ve yeteneklerini sürekli geliştirmek.
Yani Code Review bir engel değildir. Kariyerin başında alınabilecek en değerli derslerden biridir.
Serimizin son bölümünde Junior'dan Senior'a giden yolu konuşacağız. Neden Senior Developer'ın on yıllık deneyime sahip bir kişi değil de projeden sorumluluk alabilen, iş odaklı düşünebilen ve ekipteki diğer üyelerin gelişmesine yardımcı olabilen biri olduğunu açıklayacağız.
