Kötü Kod Nedir?

Canan Gümrükçüoğlu —  3 Haziran 2015 — Yorum bırakın

Her yazılımcı temiz kod yazmak ister. Projenin kapsamına bağlı olarak, bireysel ya da bir ekiple, proje için planlar yapsın, analizler oluşturup sayfalarca doküman yazsın, sonrasında kodlasın, daha sonra kodlar üzerinde test süreçlerini işletebilsin ve nihayetinde projeyi tamamlasın ister. Ama sadece ister 🙂 Gerçek hayatta işler her zaman böyle yürümez maalesef. Başlangıçta her şey düzgün gider. İşler planlar dahilinde yürür. Analizler yapılır, dokümanlar yazılır, hararetli toplantılar ardı ardına gelir. Sonra bir şeyler değişir. Kodlarımız kötü olur…

idoitagain

Peki bir kodun kötü olduğunu nasıl anlarız?

  • ›Bir kod parçasının ne yaptığı üzerine kafa yormaya başlıyorsak,
  • ›Kodumuza yeni bir geliştirme eklemek bizim için eziyete dönüşüyorsa,
  • ›Bir yerde yaptığımız basit değişiklik çok farklı bir modülde hata olarak bize dönüyorsa,
  • ›Yaptığımız geliştirmeyi bir çok yere kopyalamamız gerekiyorsa,
  • ›Kodlarımız if-else’lerin içinde uzayıp  gidiyorsa…

yazdığımız kod maalesef artık kötü bir koddur.

Hepimiz iyi kod yazmak isteriz de neden kodlarımız kötü olur?

Türkiye’ de analist-yazılımcı diye bir kavram var. Yani bir yazılımcı yapacağı geliştirmenin önce analizini yapar – en azından böyle bir durumda biz öyle umuyoruz – sonra da kodlamasını yapar. Aslında yazılımcı bir kişiyken iki kişi birden oluverir. Aynı maaş ve aynı geliştirme süresi içerisinde. Analiz ayrı bir iştir ve uzmanlık gerektirir. Bir yazılımcı daha önceden analist olarak çalışıp sonrasında kodlama tarafına geçmemişse tam manasıyla bir analiz yapamaz. Bir geliştirme için analistin 5 birim, yazılımcının 3 birim zamanı ayrı ayrı harcaması gerekirken, analist-yazılımcıdan toplam 3 birimlik sürede hem analiz hem de yazılımı yapması beklenir. Ya da başka bir durum: Yazılımcıya analiz için süre verilir, ama sonra “kodlarken bir yandan da analizini yazarsın, sen en iyisi kodlamaya başla” denilerek yine analiz süreci göz ardı edilir.

Müşterinin her zaman acelesi vardır. Yapılması gereken her iş onun için acildir. Bir butonun yazı tipi bile bazen “ACİL” olarak işaretlenmiş bir maille hata olarak gelebilir. Diğer yandan uygulamanın akışında kritik bir sorun çıkarmayan, hata statüsünde olmayan bir geliştirmeyi “X tarihine kadar tamamlanmasını istiyorum” diyerek mail atabilir. Bir yere kadar bu sorunlara karşı ayak direriz, iş planı var, scrum yapıyoruz vs. vs. deriz… Ama sonra ya “Hızlıca yapayım da kurtulayım” diyerek ya da yöneticimizin baskısına dayanamayarak hızlıca kodlar geçeriz.

Bizden önce yazılan kodların temiz olduğunu düşünmek belki de bizlerin en büyük yanılgısıdır. Hani bir nevi Pollyanna olmak isteriz kodlara karşı. Bizden önce yazılan kodlar her zaman kötüdür, biz en iyisini yazarız diye bir iddiamız tabi ki olamaz. Her geçen gün kod yazma yeteneğimiz gelişirken aylar önce kendi yazdığımız kodlar bile tekrardan baktığımızda kötü kodlar olarak görünebilir gözümüze. Tabi bu arada, iyi olduğunu umduğumuz kodların üstüne geliştirme yapmaya başladığımızda bir anda karşımıza kötü kodlar çıkabilir ve bizim bunları düzeltmeye zamanımız olmadığı için, bir de bakmışız içimiz kan ağlayaraktan, biz de kötü kodlara yenilerini eklemeye başlamışız. Böylece iyi kod yazmayı hep erteleriz. “Hiç çalışmamasındansa kötü çalışması iyidir” diye kendimizi avuturuz. Hep bir gün geri dönüp bu kodları düzelteceğimizi söyleriz. Ama LeBlanc kuralını unuturuz: “Sonra, eşittir asla”.

Değişen gereksinimler ve kanunlar da bizi kötü kod yazmaya iten faktörlerdendir. Bir İnsan Kaynakları uygulaması geliştiriyorsak yeni çıkan bir kanunu uygulamada devreye almak için kanun dahilinde bir tarih kısıtı olabilir. Bu durumda daha önce planımızda olmayan, iş listemizde zaman ayırmadığımız ama ayırmamız gereken bir zorunlu geliştirme çıkar karşımıza. Verilen tarihe kısa bir süre varsa “Kervan yolda düzülür” deyip, iyi ve detaylı bir analiz yapılmadan girişiriz kodlamaya.

Bu kadar kötü kodun tabi ki de bize bir maliyeti vardır… 

Bu maliyeti de bir sonraki yazımızda inceleyeceğiz.

“Her kod güzel yazılmayı hakeder.”

Kaynak : Clean Code – Robert C. Martin

Bu yazının orjinali buradadır.

Canan Gümrükçüoğlu

Posts Twitter

KTÜ İstatistik ve Bilgisayar Bilimleri mezunuyum. C# ile başlayan yazılım serüvenimde cebimde artık Java da var. Şimdilerin çaylak scrum master'ı olmaya çalışıyorum bir yandan da. Yeni teknolojileri ve teknoloji etkinliklerini takip etmeyi seviyorum. Ailem ve yazılım olmadan geçmez bu hayat diyorum...

No Comments

Be the first to start the conversation.

Yorum yapmak için