Kod Okumak
Giriş
İlk bölümde, yapay zekâ çağında kod yazmayı öğrenmenin hâlâ mantıklı olup olmadığını sorgulamıştık. Şimdi çoğu zaman göz ardı edilen ama en az kod yazmak kadar önemli bir konuyu daha ele alıyoruz: Kod okumak.
Kod okumak nedir? Neden önemlidir? Ve neden birçok yazılımcı bu konuda sandığından daha kötüdür?
Bu sorulara cevap vermeden önce, basit ama kritik bir noktayı netleştirelim.
Kod Kimin İçin Yazılır?
Tabii ki yaygın inanış, kodun bilgisayar için yazıldığı yönündedir. Fakat kod kesinlikle bilgisayar için yazılmaz. Kod, insanlar için yazılır.
Bilgisayar zaten ne yazdığınızı anlamak zorunda değildir; derleyici veya interpreter bunu çözer. Asıl mesele, kodu daha sonra okuyacak olan kişinin ne kadar rahat anlayabildiğidir.
Peki bu kişi kim olabilir?
- Altı ay sonraki siz
- Siz tatildeyken çıkan bir bug’ı düzeltmek zorunda kalan ekip arkadaşınız
- Ya da projeye sonradan dâhil olan tamamen yabancı bir koder
İşte burada devreye çok tanıdık bir kavram girer: “Önceki yazılımcı.”
“Önceki Yazılımcı” Kimdir?
Önceki yazılımcı, çoğu zaman sandığımız gibi başkası değildir. Çok büyük ihtimalle sizsiniz. Üç ay önce yazdığınız koda baktığınızda şunu dediğiniz oldu mu? “Ben bu if’i neden yazmışım?”
İşte bu aşamada kodu okumaya başlarsınız. Eğer kod, insanlar için belirlenmiş bazı temel kurallara uymuyorsa — bilgisayar için nasıl yazıldığının hiç önemi yoktur — okunması giderek zorlaşır. Zorlaştıkça da yeni özellik eklemek ya da hata düzeltmek neredeyse imkânsız hâle gelir.
Ve bir gün bir ekip arkadaşınız şu cümleyi kurar: “Bu kodu baştan yazmak daha mantıklı.” Yazılım dünyasında bu, neredeyse evrensel bir klişedir. Her projede yaşanan bu durumu ne kadar iyi kavrarsak o kadar iyi yazılımcı oluruz.
Kodu baştan yazmak her zaman kötü demek de değildir. Okunabilirligin projelerimize saglayacagi büyük faydalari vurgulamaya calisiyorum. Bu baglmada gelistirilen stanandartlar bize yol gösterirler.
Kod Okuma ve Standartlar
Kod yazma standartlarının amacı: Kodu okuyan kişinin işini kolaylaştırmak.
Bu kişi siz olsanız bile.
- Clean Code prensipleri
- İsimlendirme kuralları
- Kodlama teammülleri (conventions)
Bunların hiçbiri iş olsun diye yapılan şeyler değildir. Hepsi, kodu okuyan kişinin zihinsel yükünü azaltmak için vardır.
“Ben kendi yazdığım kodu okurum” düşüncesi kulağa hoş gelir ama pratikte pek işlemez. İnsan unutur. Çünkü kod yazarken bir problemi çözeriz; okurken ise o problemin hangi zihinsel bağlamda çözüldüğünü hatırlamaya çalışırız. Okumak ile yazmak arasındaki bu derin fark, projelerin kaderini oluşturur. Acelemiz varsa, konuya tam hâkim değilsek ya da sadece yorgunsak; yazdığımız kodun okunabilirliği doğrudan düşer.
Tasarım Kalıpları ve Anti-Pattern’ler
Kendi adıma, sırf bir tasarım kalıbı kullanacağım diye kodu gereksiz yere karmaşıklaştırdığım olmuştur. Çok eskiden, yazılan kod ne kadar soyutlama içerirse o kadar iyi olacağı gibi yanlış bir inancım vardı. Ama sadece basit bir if ya da metot çağrımı kodun okunabilirliğini artırıyorsa, neden ne işe yaradığını anlamak için ekstra emek isteyen bir soyutlama yapalım ki?
Bu, tasarım kalıplarının önemsiz olduğu anlamına gelmez. Ancak kullanacağız diye ekstra uğraşmanın koda zarar verdiğini de unutmayalım. Denge burada çok önemlidir ve kod yazdıkça bu dengeyi oturtmamız, okudukça geliştirmemiz mümkündür. Bu yüzden açık kaynak projelerde yazılan kodlara bakarak, başka mühendisler ne yapmış, ne gibi tasarım desenleri (design pattern) kullanmışlar gibi soruların cevaplarını aramak bizi çok geliştirir.
Peki tasarım kalıpları (Design Patterns) nedir?
Yaygın yazılımsal problemlere, herkes tarafından kabul görmüş, tekrar kullanılabilir çözümlerin genel adıdır.
Fakat burada kritik bir nokta var: Tasarım kalıpları çözüm değil, iletişim aracıdır. Yanlış yerde, yanlış dozda kullanıldığında kodu daha “profesyonel” değil, daha okunmaz hâle getirir.
Burada dengeyi gözetmemiz gerekir. Binlerce satır kod yazmak, sekreter gibi her metoda paragraflarca açıklama yazmak düşünüldüğü gibi iyi değildir. Karmaşıklığı artırır. Bu anlamda “çalışkan” yazılımcının kendine çok zararı vardır. “Tembel” olanın aslında daha avantajlı olduğu söylenebilir. Buradaki tembellikten kastın pratiklik olduğunu açıklamama gerek yok.
Anti-Pattern’ler
Design pattern’ler gibi bu anti-pattern kavramı da çok önemli olmaya başladı. Artık kodun kalitesini bu tarz anti-pattern’ler ile daha iyi anlayabiliyoruz. Mesela en yaygın anti-pattern, kodun mantık akışındaki bir olumsuzluğun exception fırlatılarak çözülmesidir. Örneğin, kullanıcı veritabanında bir ürün aradığında o ürün yoksa, kodumuz exception fırlatıyorsa bu bir anti-pattern olur.
Buradaki design pattern, Result design pattern olmalıdır. Yani biz kodu yazarken öyle kurgulamalıyız ki, her zaman olumlu değil, olumsuz sonucu da içerebilecek şekilde bir sonuç dönmelidir.
İsimlendirme, Dil ve Yazılı Olmayan Kurallar
Bizim dünyamızda neredeyse evrensel kabul görmüş bazı kurallar vardır. Bunlardan en bilinenlerinden biri şudur:
Değişken isimleri, metotlar, sınıflar İngilizce yazılır.
“Nasıl olsa Türkçe bilen biri okur” düşüncesi yanlıştır. Yazılım, yerel değil küresel bir disiplindir. Her programlama dilinin kendine özgü isimlendirme teammülleri vardır:
- C# → PascalCase
- JavaScript → camelCase
- Python → snake_case
Bu kurallar sayesinde, dili bilen biri projeye baktığında neyle karşı karşıya olduğunu daha çabuk anlar.
Küçük ama önemli bir not:
Yazılımla ciddi şekilde uğraşacaksanız, en az orta seviye İngilizce bir zorunluluktur.
Kod Yazmak Edebiyat Değildir
Şu gerçeği unutmamak gerekir: Kod yazarken edebiyat yapmıyoruz. Bir problemi en sade, en anlaşılır ve en sürdürülebilir şekilde çözmeye çalışıyoruz.
Yazdığımız yazılım:
- Bir web sitesi olabilir
- Bir mobil uygulama olabilir
- Ya da arka planda çalışan basit bir servis olabilir
Ama hepsinin ortak noktası şudur: İnsanlara bir fayda sağlamak, bir problemlerini çözmek için vardırlar.
Bu yüzden okunabilirlik, performans ve sadelik bir lüks değil; zorunluluktur. Fakat dengeyi gözetmek adına çok iyi tasarlanmış kod yazacağız diye projeyi bitirmemek de olmaz. Var olmayan bir projenin kodunun iyi olmasının da bir önemi yoktur.
Yapay Zekâ Çağında Kod Okumak
Günümüzde kodu sadece insanlar yazmıyor. Büyük dil modelleri de yazıyor. Bu da “önceki yazılımcı” kavramını genişletiyor. Artık önceki yazılımcı:
- Bir insan olabilir
- Ya da bir yapay zekâ modeli
Ancak kurallar değişmiyor. Yapay zekâya kod yazdırırken bile:
- Hangi stilin kullanılacağını
- Hangi isimlendirme kurallarının geçerli olduğunu
- Kodun nasıl yapılandırılacağını
net şekilde belirtmemiz gerekiyor.
Aksi hâlde, yapay zekânın ürettiği kodu okumadan ve değerlendirmeden doğrudan kullanmak, orta vadede ciddi sorunlara yol açar. Tabii, eğer ilk deploy’da patlamazsa.
Kodlama asistanlarının hepsi, kural (rule) setlerini tanıtabileceğiniz araçlara sahiptir. Bu yüzden mutlaka yapacağımız proje için kullanacağımız teknolojilere göre bu kural setlerini ve kodlama standartlarını tanımlamamız gerekir. Böylece modelin çıktısını okurken zorlanmayız. Hata yapma olasılığı çok yüksek olan bu arka plan kodlama asistanlarının ne yaptığına bakmadan ilerlemek, başarısızlığın garantisi olur.
Görüldüğü gibi, yapay zekâ çağında kod yazmayı bilmek — kodu o yazsa bile — çok önemlidir.
Kapanış
Kod yazmak işin başlangıcıdır. Ama kod okuyamıyorsanız, yazdığınız kodun da pek bir değeri kalmaz.
Okuyamadığınız kod:
- Size ait değildir
- Güvenilir değildir
- Sürdürülebilir değildir
Yapay zekâ çağında fark yaratan beceri, daha fazla kod yazmak değil; daha az ama daha okunabilir kod yazabilmektir."