Albatros

Bilişim Kooperatifi Girişimi

Clean Coding (Temiz kodlama), yazılım dünyasında son dönemlerin popüler konuları arasına giren önemli
pratiklerden biri. Girmeyi de sonuna kadar hakediyor. Yazılımcılardan şuna benzer sözleri(şikâyetleri) sık sık
duyarız:
– Enkaz devraldım
– Çok karmaşık bir kod
– Burada neden bunu yapmış
– Ellersem patlayabilir

Öncelikle şunu itiraf edelim: Çalışan koda gecikmeli de olsa bir şekilde ulaşılabilir. Benzer işi yapan kodları
kopyalayarak, Google’da aramalar yaparak, birilerinden yardım alarak, hiç olmadı deneme-yanılma yöntemleri ile
bir bakmışsınız uygulamanız çalışıyor ve mutlu oluyorsunuz. Ancak sorunlar bundan sonra başlıyor:

  • Kodlar ne kadar basit ve anlaşılır?
  • Exception’lar yeterince handle edildi mi?
  • Performansa dikkat edildi mi?
  • Duplicate kodlar ne durumda?
  • Ortam bağımlılıkları var mı?
  • Memory etkili kullanıldı mı?

Bunlardan bir veya birkaçına verilecek olumsuz cevap, çoğu zaman kodun kısa ömürlü olmasına yetiyor. Ya
emeklilik ya da refactoring konuşulmaya başlanır. Bunlar da bildiğimiz gibi maliyetli işlerdir. Temiz kodun(clean
code) önemi burada devreye giriyor.

Clean Code, bir teknoloji problemi değildir. Bir mimari problemdir ve işini iyi yapmak ile ilgilidir. Tarifi zordur ancak
kabaca basit, anlaşılabilir, etkin, bir düzene bir pattern’a sahip olması diyebiliriz. Kullanılan programlama dilinden
bağımsızdır.

Peki bir kodun yeterince temiz olmadığına, refactoring’e ihtiyacı olduğunu nasıl anlarız?

Refactoring işlemine genelde söz konusu kod bloğuna değişiklik için dokunulduğunda, bir performans problemi yaşandığında veya bir defect ortaya çıktığında ihtiyaç duyulur. Çünkü bu durumlarda test ihtiyacı doğması zaten kabul edilebilir bir durumdur ve kontağı buna hazırlıklıdır. Ancak durup dururken yapmak istediğinizde regresyon testleri ihtiyacı doğar ve bir analist/testçi kontağı bulmak zorundasınız. Bu da özellikle kurumsal firmaların pek de sıcak bakmadığı bir maliyet doğurur. 

Dokunduğunuz kodun bir refactor’e ihtiyacı olduğunu gösteren bazı işaretler vardır. Bunlar tecrübeli yazılımcılar tarafından kolayca göze çarpabilir. Bunlardan bazıları:

  • İç içe çok fazla döngüler veya kondisyonlar
  • Anlamsız değişken, method veya sınıf isimleri
  • Çok parametreli metotlar veya fonksiyonlar
  • Çok büyük metotlar, sınıflar, kod bloklar
  • Tekrarlanmış(duplicate) copy-paste kodlar
  • Gereksiz commentler
  • Yetersiz Exception handling

Bunlardan birkaçı görüldüğünde ekibinize(veya squad) bir technical debt(teknik borç)’ten bahsedebilir ve planlama(veya backloga ekleme) talep edebilirsiniz.

Refactoring öncesi ve sonrası nelere dikkat edilmeli?

Küçük veya büyük her refactoring işleminde bir risk vardır. Bu riski minimize etmek için dikkat etmeniz gereken bazı önemli noktalar:

  • Birim testlerini(unit test) ihmal etmeyin. Temiz kodun da en önemli prensiplerinden biridir. Hem kodun patlama ihtimalini azaltır hem de sizden sonraki geliştirmecilere(developer) büyük bir kolaylık sağlar.
  • Regresyon testleri için bir analist/test kontağı atanmış olmalı. Ona değiştirdiğiniz ve şüphelendiğiniz noktaları mutlaka belirtin.
  • Birine code review yaptırın. İkinci göz her zaman çok faydalıdır.
  • Mümkün olduğunca küçük parçalar halinde ilerleyin. Çok geniş bir refactoring hem riski hem de test maliyetini artırır.
  • İmkan varsa test ortamlarında bir süre yaşadıktan sonra proda alınsın. O esnada çok farklı case’ler test edilmiş olur. Yeni bir fonksiyonun çalışmaması kabul edilebilirken, var olan bir fonksiyonun bozulması krize neden olabilir. 
  • Bir geriye dönüş planınız olsun. 
  • Bol bol okuyun ve pratikler yapın. 

Cover of Clean Code book
Clean Code(Temiz Kod) Pratikleri

 Refactoring, patlama veya kod emekliliği durumlarını sık sık yaşamak istemiyorsanız temiz kod pratiklerini öğrenmek ve uygulamak önemli bir gerekliliktir. Çalışan kod, temiz kod, refactoring, teknik borç… konularında bir giriş yaptıktan sonra artık clean coding pratiklerine değinebiliriz. Çok kapsamlı bir konu olduğundan bunu bir yazı serisine dönüştürmek daha güzel olur. İlk pratiğimiz olan Naming Conventions(İsimlendirtme Standartları)’ı içerecek bir sonraki yazımızda görüşmek dileğiyle.