Kullandığımız uygulama sunucuları ya da yazdığımız kodlar ile ilişki halinde olan araçlar sürekli olarak bir devinim içerisindedirler. Performans iyileştirmeleri, sorun giderilmesi, daha hızlı çalışabilme, sistem kaynaklarını doğru kullanma gibi konularda sürekli kafa patlatırlar. Ya da yeni bir donanım çıkar, eski donanımızdan daha hızlı çalıştığını iddia eder. Bunlar bizim dışımızda gelişen performans ve açık giderilmesi çalışmalarıdır. Bir de bize düşen performans ve kod düzenlemeleri vardır ki, kısa vadede yük getiriyor gibi görünse de uzun vadede işlerin yolunda gitmesini sağlar. İşte uygulanması gereken metodun adı Kodlama Standardıdır. Juan Carlos Herrera The Human Side of Security and Performance yazısında developer'ın bir insan olduğu ve her insan gibi hata yapabileceğinden bahsediyor. Doğru ama aynı zamanda bunlar için önlem alınabileceğinden de bahsediyor. Bunun için de öncelikli olarak kullanılan API'nin iyi bilinmesi gerektiğinden bahsediyor. Yapılabilecek performans hatalarına aşağıdaki örnekleri veriyor.
"About Performance common mistakes are poor algorithm design, wrong use of try/catch, primitive debugging techniques (a lot of "System.out.println"), etc.."
Tabi bütün bu bahsedilenlerden sonra bu tür standardları tek tek takip etmek, veya büyük ölçekli bir projede herkesin bu tür kurallara uyup uymadığını kontrol etmek manuel takip edilecek bir süreç olmuyor. Bunun için piyasada Code Convention araçları mevcut. Findbugs, PMD ve CheckStyle bu ürünlerin başında geliyor. Bu üç ürün birçok yönden benzerlik gösteriyor, IDE plugin desteği, sürüm sistemi ile entegrasyon, kural havuzu gibi... Ama bazı yönlerden birbirlerine karşı avantaj sağlıyorlar. Ama işin güzel yanı, üçü de kod standardına sahip olmanızı sağlıyorlar.
Her proje ekibinin belli kod yazma standardları vardır. Bir kurala dahi sahip olmak ileride size büyük avantajlar getirir, ki bu avantajlar bazen hayat kurtarır.
1 comments:
Selamlar Oğuz Abi;
Yazdığımız uygulamalar eğer bir uygulama sunucusunun yada platformun canına okuyorsa sistemci arkadaşlar kulaklarımızı çınlatırlar. Kulakları çınlatan tarafta olduğun için şanslısın ama öte yandan da sorunla boğuşacak olan tarafta olduğun için şansısız sayılırsın.
Örnek olarak verdiğin uygulamalar gerçekten de Amerika 'yı yeniden keşfetmekten bizleri kurtarıyor. Hatta çoğunda dünya standartı haline gelmiş kurallar pre-defined olarak geliyor. Bunlar kodların revize ihtiyacını minimum'a indiriken hata ayıklama ve revize edilmesi durumunda da okunabilirliği artırdığı için ZAMAN=PARA gibi maliyetlerden kurtarıyor bizleri.
Fakat için içine perfomans girdi mi dediğin gibi üzerinde çalışılan platformun özelliklerinden kullanılan API 'nin tricky noktalarına kadar pek çok şey devreye giriyor. Perfomanslı kod yazımı deneyim ve bilgi paylaşımıyla olacak birşey. sonuçta her projede bir konw-how birikir bunlar diğerlerine aktarılıyorsa,ağzımızın yandığı noktalarda üflemeyi becerebiliyorsak perfomans artışı da ona göre olacaktır.
Bir süre evvel YazılımMüh. Türkiye mail grubunda okunabilirlik vs perfomans gibi bir tartışma olmuştu. Performanslı kod okunabilirlikten uzak kod mudur? Elbette değildir. Okunabilirlliği artırmak adına kullanılanılacak fazladan bir değişken ciddi bir perfomans kaybı getirmeyecektir.
Bu konuyla ilgili geçenlerde okuduğum bir yazıda şöylesine güzel bir söz geçiyordu: Don't document complex code. Write clear code.
Evet compleks kod yazmazsak hem daha perfoamanslı hem de daha okunabilir bir uygulamamız olacaktır.
Post a Comment