Yazılım geliştirme süreçlerinde kod yazmak işin sadece ilk adımıdır. Asıl zorluk, yazdığınız kodun yıllar sonra bile anlaşılabilir, geliştirilebilir ve hatasız çalışabilir olmasını sağlamaktır. Yazılım projeleri büyüdükçe, kod tabanının karmaşıklığı da doğru orantılı olarak artar. Eğer bu büyüme kontrollü bir şekilde yönetilmezse, projeler bir süre sonra geliştirilemez hale gelir ve teknik borç dediğimiz kavram ortaya çıkar. Teknik borç, kısa vadede işleri hızlandırmak için yapılan kalitesiz veya aceleye getirilmiş kodlamaların uzun vadede getirdiği yüksek maliyetli bir faizdir.
Temiz kod yaklaşımı, bu maliyetin önüne geçmek için geliştirilmiş bir dizi disiplin ve felsefedir. Kodun sadece bilgisayar tarafından anlaşılması değil, aynı zamanda başka bir insan tarafından da kolayca okunabilmesi ve üzerinde çalışılabilmesi temel amaçtır. Yazılımcılar mesai sürelerinin çok büyük bir kısmını yeni kod yazmaktan ziyade mevcut kodu okumaya ve anlamaya harcarlar. Dolayısıyla okunabilirliği artırmak, doğrudan ekip verimliliğini ve ürün kalitesini artıran en kritik yatırımdır.
Anlaşılır İsimlendirme ve Değişken Yönetimi
Kodun okunabilirliğini artırmanın en temel yolu doğru isimlendirmeden geçer. Değişkenler, fonksiyonlar, sınıflar ve modüller seçildikleri isimlerle ne yaptıklarını, neden var olduklarını ve nasıl kullanıl aclarını net bir şekilde anlatmalıdır. Kısaltmalar, tek harfli değişkenler veya anlamı belirsiz terimler sadece yazan kişinin o anki zihnindeki bağlamı yansıtır ve zamanla unutulur. Bir değişkenin adı, o değişkenin ne sakladığını açıklamak için yorum satırına ihtiyaç duymamalıdır.
İsimlendirme yaparken iş alanının (domain) terminolojisine sadık kalmak ve bağlamı korumak gerekir. Örneğin, bir kullanıcı listesini tutan değişkene sadece veri anlamına gelen genel bir isim vermek yerine, verinin türünü ve işlevini belirten açıklayıcı bir kelime grubu seçmek okuma hızını dramatik ölçüde artırır. Benzer şekilde, fonksiyon isimleri mutlaka bir eylem bildirmeli ve yaptığı işin dışına çıkmamalıdır. Eğer bir fonksiyon hem veritabanından veri okuyor hem de ekrana log basıyorsa, ismi bu iki sorumluluğu da yansıtmak zorunda kalır ki bu da kötü tasarımın ilk işaretidir.
Tek Sorumluluk ve Fonksiyon Tasarımı
Yazılım mimarisinde modülerliğin ve sürdürülebilirliğin kalbi fonksiyon tasarımıdır. Bir fonksiyonun veya metodun ideal olarak sadece tek bir sorumluluğu olmalı ve o sorumluluğu eksiksiz yerine getirmelidir. Buna Tek Sorumluluk Prensibi denir. Fonksiyonlar mümkün olduğunca kısa tutulmalı, iç içe geçmiş döngüler ve karmaşık koşul bloklarından arındırılmalıdır. Bir fonksiyon içinde çok fazla seviyede indentasyon varsa, o fonksiyonun alt görevlere bölünmesi gerektiğinin açık bir göstergesidir.
Fonksiyonların parametre sayıları da tasarım kalitesini doğrudan etkiler. İdeal bir fonksiyonun sıfır, bir veya en fazla iki parametre alması beklenir. Üç veya daha fazla parametre, fonksiyonun çok fazla şey yapmaya çalıştığını ya da parametrelerin bir nesne altında gruplanması gerektiğini gösterir. Küçük ve odaklanmış fonksiyonlar, hem birim testlerin yazılmasını kolaylaştırır hem de kodun farklı yerlerinde tekrar kullanılabilirliğini artırır.
DRY Prensibi ve Kod Tekrarının Önlenmesi
Yazılım mühendisliğinin en temel kurallarından biri olan Kendini Tekrarlama, yani DRY prensibi, sistem içindeki her bilginin veya mantığın tek ve yetkili bir temsile sahip olması gerektiğini savunur. Aynı kod bloğunu veya mantığı projenin farklı yerlerinde kopyalayıp yapıştırmak, ileride yapılacak bir değişiklikte büyük riskler doğurur. Mantıksal bir hata düzeltildiğinde veya yeni bir kural eklendiğinde, kopyalanan tüm yerlerin tek tek bulunması ve güncellenmesi gerekir. Bu süreç insan hatasına son derece açıktır ve unutulan tek bir nokta bile sistemin tutarsız çalışmasına yol açar.
Kod tekrarını önlemek için ortak mantığı soyutlayarak yeniden kullanılabilir bileşenler, yardımcı fonksiyonlar veya servisler haline getirmek gerekir. Ancak burada dikkat edilmesi gereken hassas bir denge vardır. Tamamen farklı iki iş kuralı tesadüfen aynı kodu paylaşıyorsa, bunları premature bir şekilde (erken soyutlama ile) birleştirmek ileride bu kurallar ayrıştığında büyük bir bağımlılık sorununa yol açabilir. Soyutlama yapılırken gerçek iş mantığının bağlamı göz önünde bulundurulmalıdır.
Hata Yönetimi ve İstisnai Durumlar
Güvenilir bir yazılım sistemi, sadece mutlu yollarda (happy path) düzgün çalışmakla kalmaz, aynı zamanda beklenmeyen hatalarla karşılaştığında da zarif bir şekilde tepki verebilmelidir. Hata yönetimi, temiz kodun vazgeçilmez bir parçasıdır. Kodun içine sürekli hata kodları döndüren yapılar serpiştirmek yerine, modern programlama dillerinin sunduğu istisna (exception) mekanizmalarını etkili bir şekilde kullanmak gerekir.
Hataları yakalarken çok geniş kapsamlı yakalama bloklarından kaçınılmalıdır. Hangi hatanın nerede ve neden fırlatılabileceği öngörülebilmeli ve hata mesajları hata ayıklama sürecini kolaylaştıracak düzeyde anlamlı olmalıdır. Ayrıca, hata yönetimini iş mantığından mümkün olduğunca ayırmak, kodun ana akışının okunmasını kolaylaştırır ve bakım maliyetlerini düşürür.
Otomatik Testler ile Kalite Güvencesi
Temiz kod yazmanın en büyük pratik getirisi, otomatik testlerin kolayca yazılabilmesidir. Sıkı sıkıya bağlı (tightly coupled), global durumlara bağımlı ve karmaşık kodların test edilmesi zor, hatta imkansızdır. Buna karşın, tek sorumluluk prensibine uyan, bağımlılıkları dışarıdan alan (dependency injection) ve küçük parçalara bölünmüş kodlar için birim testler yazmak son derece kolaydır.
Test edilebilirlik, kodun mimari kalitesini ölçmek için harika bir metrik olarak kullanılabilir. Eğer bir kod parçasını test etmekta zorlanıyorsanız, büyük ihtimalle o kodun tasarımı yeterince temiz ve esnek değildir. Yazılan otomatik testler, kod üzerinde gelecekte yapılacak değişikliklerin mevcut işlevselliği bozmadığından emin olmanızı sağlar ve geliştiricilere güvenli bir refaktör alanı sunar.
Yorumlar
0 onaylı yorum · Görüşlerinizi paylaşınHenüz yorum yok. İlk görüşü siz paylaşabilirsiniz.