Clean Code

Temiz kodun özellikleri:

• Clean code, okuyan herkes tarafından anlaşılır olmalı. Aşağıdakilerin olmasını istemiyoruz:
  • Sadece kendimizin anladığı süper zeki algoritmaları
  • İkinci defa bakıldığında ne olduğu anlaşılmayan isimler
  • Her şey içine tıkılmış olan sınıf ve metodlar
  • Sihirli sayılar
  • Ve kodu dağınık ve anlaşılması güç hale getiren diğer her şey
• Don’t repeat yourself
  • Temiz kod tekrar içermemeli. N kere tekrar edilmiş kod değişitirlme esnasında N+ süreye tekabül eder.
• “Less code generally is good, but better than less code, is more simple”
• Temiz kod, tüm test case’leri geçer
• Temiz kodun bakımı daha kolay ve ucuzdur.

Technical Debt

Teknik borç, daha sonra hallederiz diye karman çorman yazılan koddur.

Bir bankadan borç aldığımızda ana parayla beraber faizini de öderiz. Eğer çok fazla borç alırsak ödediğimiz faiz gelirimizi aşar ve artık borcumuzu hiç kapatamayacak hale geliriz. Aynı şekilde yazdığımız karman çorman kodlar bizlere yarın yol, su elektrik şeklinde dönecektir.

Someone took a shortcut to get something to ship, and now we have to write code to fix the shortcut and “do it the right way.”

“Writing code requires making assumptions, assumptions about code change over time, the delta in assumptions is technical debt”.

Teknik borcun nedenleri

Patron baskısı

Yetiştirilmesi gereken işler varsa özellikle bu işler kısa sürede isteniyorsa el mecbur yazılımcı kimse pardır kürdür kod yazmak zorunda kalmaktadır.

Teknik borcun doğuracağı sonuçları anlamamak

Teknik borcun oluşturacağı yıkıcı etkileri anlamayan yönetici ve/veya yazılım takımının bu durumu önemsememesi.

Birbirine sıkı sıkıya bağlı birleşenleri ayıramamak

Eğer proje modüler değil de tek parça şeklindeyse, projede yapılan bir değişiklik farklı kısımları etkiler. Takım olarak yapılan geliştirmede bu durumu düzeltmek daha da zordur çünkü farklı bireylerin yaptıklarını izole etmek daha zordur.

Test eksikliği

Anlık geri bildirimin olmaması, masum ufak değişikliklerin oluşturduğu kötü değişikliklerden haberdar olmamamızı engeller. Haberdar olduğumuzda her şey çok geç olabilir.

Dökümantasyon eksikliği

Ya da başka bir şekilde ifade etmek gerekirse “bilgiyi saklamak” genelde kendine güveni olmayan bazı çalışanların bilgiyi paylaşmamak istememesi için dökümantasyon oluşturmayıp şirketi kendisine bağlamasıdır. Şirkete yeni gelenlerin tavuk gibi amaçsızca oradan oraya dolaşmasına neden olan bu durum şirketin sürekliliği için zararlıdır.

Takım arası iletişim eksikliği

Farklı mekanlarda, farklı zamanlarda yaşayan takım üyelerinin projenin de farklı aşamalarında olması durumudur. Proje hakkındaki son gelişmelerden herkesin haberdar olmamasıdır.

Farklı branchlarda aynı anda uzun süreli geliştirme

Farklı branchlardaki teknik borç, branch’ı mergelerken üst üste ekleniyor.

Geçikmiş refactoring

Bir noktada projenin bazı kısımlarının tarihi geçmiş olacak. Bu durum kısa süre içinde düzeltimezse geliştirici takımı bu tarihi geçmiş kodları kullanabilir. Bu durum da ilerde daha fazla değişiklik yapmayı gerektirir.

Uyumsuzluk

Herkesin, tek bir biçim yerine kendi biçiminde kod yazması.

Yetersizlik

Geliştiricinin, düzgün kod yazmayı bilmemesi.

Kaynaklar

• https://refactoring.guru/refactoring/technical-debt
• https://www.productplan.com/glossary/technical-debt/#:~:text=Technical%20debt%20(also%20known%20as,speedy%20delivery%20over%20perfect%20code.
• https://www.reddit.com/r/SoftwareEngineering/comments/1235mru/in_your_own_words_what_is_technical_debt/

Ne zaman Refactor yapmalı?

Ne zaman Refactor yapmalı?

• Bir şeyi 3. kez yaptığınızda
• Dirty code’a yeni bir özellik eklemeden önce. Hem kod temizlenir hem de arkaplanda neyin döndüğü anlaşılır.
• Programda çıkan bugları düzeltirken
• code review esnasında

Nasıl refactor yapılmalı?

Birbiri ardına sıralanan küçük adımlarla refactoring yapılır.

• Refactoring yaptıktan sonra kod daha temiz olmalı, eğer değilse vaktinizi boşa harcamış olursunuz. Bu genelde büyük adım atmaktan kaynaklanır bazen de kod gerçekten çok kötü bir haldedir. Böyle durumlarda kodu parça parça yeniden yazmak iyi bir fikir olabilir…
• Refactoring yapılırken yeni feature yazılmaz.
• Var olan testler refactoring yapıldıktan sonra başarıyla geçilebilmeli.