Ticker

6/random/ticker-posts

Kodumdan Kötü Kokular Geldiğini Nasıl Anlarım? - 1

Clean Code Notları
Clean Code Notları


Kötü kokuya burnumuz alışınca artık kokuyu farketmez oluruz. Kodlamada da durum farklı değil. Kötü kokan koda o kadar aşina olmuşuzdur ki, onun yanlış olduğunu bile fark edemeyebiliriz.
Clean Code notlarımıza devam ediyoruz. İşte kötü kokan kodu farketmemize yarayacak bazı ipuçları:

Yorumlar

  • Yersiz Bilgilendirme:
    • Kodun değişiklik geçmişi, en son kimin değiştirdiği gibi bilgiler versiyon takip sistemlerinde tutulmalıdır. Bu bilgileri kodda tutmak gereksiz yorum kirliliğine neden olmaktadır.
  • Eskimiş yorum:
    • Kod değiştirildikçe taşıdığı anlam değişir ve buna bağlı olarak yorumların da güncellenmesi gerekebilmektedir. Mevcut yorum artık yeni kod için anlamsızdır. Yanlış eskimiş yorumlar derleme hatasına yol açmadığı için çoğu yazılımcı yorumları güncellemeyi ihmal eder. 
  • Lüzumsuz Yorum:
    • Koddan apaçık şekilde anlaşılabilecek konuları yorum olarak eklememek gerekir. Yorumlar kodun söyleyemediği şeyleri söylemek için yazılmalıdır.
  • Yoruma alınmış kod bloğu:
    • Gereksiz kodları silmekten korkmayın. Tekrar yazabileceğinize güvenin. Aksi takdirde yoruma alınmış kod, birgün birinin işine yarayabileceği düşüncesiyle kimsenin silmeye cesaret edemeyeceği kirlilik olarak kaynak kodda bulunmaya devam eder.

Geliştirme Ortamı

  • Derlemenin birden fazla adımda gerçekleştirilebilmesi: 
    • Projeyi derlemeden önce yaptığınız adımları gözünüzün önüne getirin. properties dosyasında bir düzenleme, kullanılan üçüncü parti kütüphanelerde ekleme/çıkarma yapma, xml, java dosyalarında değişiklik yapma... Derleme işlemini basit bir kaç adımda gerçekleştiremiyorsanız geliştirme ortamınızı elden geçirme ihtiyacı var demektir. Kaynak kodu çektikten sonra basit bir derleme komutuyla proje derlenebilmelidir.
  • Testleri koşmanın birden fazla adımda gerçekleştirilebilmesi:
    • Testler de basit bir "run" komutuyla çalıştırılabilmelidir. Testleri çalıştırmanın basit, hızlı ve kolay olması gerekir. Aksi takdirde geliştiriciler test yazmaya ve koşmaya soğuyabilirler.

Fonksiyonlar

  • Çok fazla argüman alan fonksiyon:
    • Hiç argüman almayan fonksiyon en iyisidir. Sırasıyla bir, iki ve üç argüman alan fonksiyonlar gelir. Üçten fazla argüman alan fonksiyonlar tercih edilmemeli, gerekli refactoring yapılarak, argüman sınıfları oluşturularak bu kötü koku giderilebilir.
  • Output argümanı kullanmak:
    • Fonksiyon argümanları genelde input olarak anlaşılır. Output argüman kullanmak okuyucuyu yanlış yönlendirebilir. 
  • Flag argümanı kullanmak:
    • Boolean flag argüman alan fonksiyon kuvvetle muhtemel iki iş yapıyor demektir. Fonksiyonlar tek işten sorumlu olmalıdır.
  • Atıl fonksiyon barındırmak:
    • Hiç çağrılmamış, kullanılmayan fonksiyonlar silinmelidir. İhtiyaç duyulması halinde versiyon kontrol sistemindeki geçmişe bakarak tekrar yazılabilir.
Devam edecek...

Yorum Gönder

0 Yorumlar