(Big Ball of Mud)
“Big Ball of Mud”, belli bir çerçeveye göre tasarlanmamış, iş ihtiyaçlarının baskısı altında ezilmiş, sürekli yamalar ile gelişmiş, sürdürebilirliği maliyetli, kod kalitesinin düşük olduğu ve kötü kokan spagetti kodların olduğu yazılımları tanımlamak için uzun zaman önce yazılım geliştirme literatüründe yerini almış bir kavram. Ne yazık ki kendimizi bu iğrenç çamur topunun içinde bulmak oldukça kolay. İçine düşmenin kötü olduğu gibi, bu çamur topunun oluşmasına katkı sağlamak da ayrı bir kötü durum.
Üzgünüm ama kod yazmaya başladığımız andan itibaren bu büyük çamur topunun oluşması da başlıyor. Bunun farkında olursak, bu topun büyümemesi için farkındalığımız daha yüksek olacaktır. Önemli olan bu çamur yığınının büyümemesi, yönetilebilecek derecede kontrol altında olması. Günümüzde değişimlerin çok hızlı oluyor olması bu çamur topundan kaçınamamamızın en büyük sebebi. Tabi ki insan faktörü de bu sebebin birinci katalizörü.
Yazılım projeleri sonuçta kendi kendilerine ortaya çıkan şeyler değil. Bizler yazıyoruz, geliştiriyoruz. Çamur topunu da biz oluşturuyoruz. Bunu oluştururken de, bir çoğunuza tanıdık gelen belli söylemlerin arkasına sığınıyoruz.
Müşterinin ne istediği net değildi…
Çok sevdiğimiz bir söylem. “Müşterinin ne istediği net değildi”… Bizden istenen ihtiyaç net olmadığı zaman, ister istemez yazdığımız kod da çok net olmaz. Net olmadığını ilk başta fark etmediğimiz için(!!!) ve belli varsayımlara göre ihtiyaçları geliştirdiğimizde ortaya çıkan kod, karmaşıklığın ilk hali olacaktır. Müşterinin istediği bizim tarafımızda net olmadığı sürece, her yeni istek çamur topunu büyütecektir. Kötü bir haberim var; ne yazık ki müşterilerinizin ne istediği %70 net olmayacak… Dolayısıyla müşterinin ne istediğini net olarak anlamaya çalışmak için çaba sarf etmemiz lazım. Değişimlerin sürekli olduğu bir çağda yaşadığımız için de, bu değişimleri yönetebilecek bir yaklaşım içerisinde olmamız gerekiyor. Yazdığımız kodların kolay değiştirilebilir bir alt yapıya sahip olması, kodun içerisindeki bağımlılıkların yönetilebilir olması kod yazarken dikkat edebileceğimiz şeyler olabilir.
(Big Ball of Mud)
Zaman kısıtı vardı…
Nerde yok ki… İnsanoğlunun da ortalama 75 yıllık bir zaman kısıtı var. Yazılım geliştirirken de bir zaman kısıtımızın olması çok normal. Bütçe, kaynak, değişen ihtiyaç gibi zamanı etkileyen parametreler de etkin olunca pek yapacak bir şey yok. Zaman kısıtı değil de, bu zaman kısıtını iyi değerlendiremediğimiz için çamur topumuz oluşuyor ve büyümeye başlıyor. İstenen özellikler ve fonksiyonlara çok odaklanmadan harcadığımız zaman, ya da fonksiyonlar için “over-engineering” yaparak harcadığımız zaman, zaten kısıtlı olan zamanımızı boşa harcamamıza neden oluyor. Zamanımız daraldığı için kodumuzun kalitesi de düşüyor tabi ki. Kısa zamanda geliştirmekle yükümlü olduğumuz fonksiyonlar, test yaklaşımımız da olmadığı için(!) zamanla problem üretmeye başlıyor. Zaman gittikçe azalmaya devam ediyor, yeni ihtiyaçlar ile beraber yeni problemleri de çözmemiz gerekiyor…eyvah eyvah.
Deadlines
Problem vardı…
(Big Ball of Mud)
“Problem vardı, hemen çözmemiz gerekiyordu.” da çamur topunun en sevdiği söylemlerden. Mevcut kodlarımızdaki hataları gidermek için hızlı(?) ürettiğimiz çözümler çamur topunun oluşmasına sebep olan başka bir etken. Problemi çözmek ile problemi ortaya çıkartan durumu çözmek arasında fark var. Genelde olayın aciliyetinden dolayı, problemleri kapsamı dahilinde çözüyoruz ama neden oluştuğunu ve bir daha oluşmamasını sağlamıyoruz. Dolayısıyla her problem oluştuğunda kodumuz farklı şekilde kirlenmeye başlıyor. Her problem oluştuğunda çözüm şeklimiz de farklı olduğu için kirlenme büyüyerek artıyor.
Zaten karışık…Ahmet gitti, Ayşe de yeni geldi…
Ekip içerisindeki kişilerin değişmesi ve ekibin yetkinliği, çamur topunun oluşmasını sağlayan bir diğer etken. Eğer geliştirdiğimiz sistemin belli bir standartı yoksa, bu standart ekip içerisinde uygulanmıyorsa kodun çamur topuna dönmemesi pek mümkün değil. Yazdığımız kodların ekipteki diğer kişiler tarafından okunabilirliği ve anlaşılabilirliği bu açıdan önemli. Unutmuyoruz ki, kod yazarken insanlar okusun, bilgisayarlar çalıştırsın diye yazıyoruz. Herkesin anladığı ve ortak bir noktada buluştuğu kodların, bütünlüğünün bozulması o kadar geç olacaktır. Bunu sağlamak için gerektiği kadar dokümantasyon ve bilgi paylaşımı da ekip içerisinde sağlanıyor olmalı.
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
Martin Fowler, “Refactoring: Improving the Design of Existing Code”
“Programs must be written for people to read, and only incidentally for machines to execute.”
Abelson & Sussman
Özetle…
Geliştirdiğimiz yazılımları, belli prensiplere uyarak ve kodlarımızı sağlıklı besleyerek geliştirirsek, yazılımların uzun ömürlü ve problemsiz olmasını sağlayabiliriz. Yukarda bahsettiğim konular genellikle iş hayatında karşılaştığımız, uygulamalarımızın yıpranmasına sebep olan “soft” etkenler. Yıpranmayı engellemek için teknik olarak neler yapabiliriz ile ilgili ve “Big Ball of Mud”la ilgili biraz daha teknik içerik olması için aşağıdaki kitaplara ve yazılara mutlaka göz atmanızı tavsiye ederim. Şimdilik benden bu kadar, bir sonraki yazıya kadar mutlu kodlamalar. 🙂