Data Vinci 4 : Spaghetti code

Birkaç yazıdır sürekli vurgu yaptığım “Spaghetti Code” kavramına değinmemek olmaz. Bu yazıyı da komple “Spaghetti code” a ayırdım. Afiyet olsun.

Yazılım geliştirme serüveni çok keyiflidir. Tamamen soyut olan düşünceleri bir cihaza input olarak verip bir çıktı üretmek, yazılımcılık işini cazip kılıyor. Tatmini yüksek bir iş. Bir şeyler ortaya çıkarıyorsunuz belki tek başınıza, belki bir grupla ve ürettiğiniz bu aracı belki de binlerce insan kullanıyor. Daha ne olsun?

Yazılımcılık distopyasında “bug free” uygulamalar vardır. Yani sıfır hata ile çalışan programcıklar, programlar… Bunun için bir sürü disiplin tanımlanmış ve uygulanması önerilmiştir. Çıktı ne olursa olsun. Arkasında yatan güzide kodlarımızın “clean” olması gerekir. Zira süreç yaşamakta, beklentiler değişmekte bir süre sonra programlar bu isteklere cevap verememekte, genişleme, akım kaçınılmaz olmaktadır. Hâl böyle olunca “yazdım bitti gitti” daha da bir satır kod eklemem, değiştirmem gibi bir lüks bulunmamaktadır. Vakti gelip fütursuzca yazılmış bir kod yığını içerisine bir yama, bir ek özellik katılmak istendiğinde “deadline” baskısı ile sabunlanmış, karma karışık kötü bir “code base” var ise yazanın kulakları da çınlayacaktır. İşte bu tarz kodlara camiada “spaghetti code” deniliyor.

Yine bir anti-pattern olan spaghetti code temel olarak kötü yazılmış(yazan kör oldu), anlaşılması zor(okumaya çalışan kanser), bakımı zor(linkedin profilimi güncelliyim ben abi) kodlara işaret eder. Ancak parantez açılması gereken bir nokta var ki bir uygulama esnasında uygulanan yazılım disiplinleri, uygulanmaya devam edildiği sürece “clean code” kavramından bahsetmek mümkün.

Fakat iş dünyasına baktığımızda yazılımcı profilleri, iş yapış şekilleri, gözetilen kurallar çok geniş bir yelpazede karşımıza çıkıyor. Şöyle ki bir projeye başlanmış ve bir takım manifestolar yayınlanmış, neleri nasıl yapmak gerekiyor bunlar ile ilgili farkındalıklar yüksek, ufukta “deadline” yok, arayan soran yok, ancak ekip içerisinden birisi çıkıyor, yerine yeni birisi geliyor, o ara proje yöneticisi değişiyor, hatta belki tamamen üst yönetim değişiyor, yazılımcılara maaş az gelmeye başlıyor, deneyimli yazılımcının yerine alınan yeni mezun, bir an önce kendini ispatlamak adına bazı kuralları es geçiyor. “Çalışan yazılım” üretme derdine düşüyor. “Code Review” es geçiliyor, ya da üstün körü yapılıyor. Teknik borçlar kapatılmıyor. Kötülüşen kod kalitesinin üstüne yarı kaliteli, yarı özensiz kodlar ekleniyor. Refactoring yapılmak isteniyor ama proje sonu yaklaşıyor. “İşte bunlar hep spaghetti”.

Herkesin prensipte istediği(kime sorsam Martin Fowler :=) ), gerçekleşmesi ise ciddi olarak “ciddiyet ve uzmanlık, disiplin” gerektiren kavram. Özenle yazmış olduğunuz, yazın naftalinlediğiniz, kışın kalorifere yakın tuttuğunuz kısaca “kirlenmesini, bozulmasını, çirkinleşmesini” istemediğiniz kodlarınız, gerek zaman kısıtlarından, gerek dikkatsizlikten, gerek fazla kişinin “mıncık”lamasından bir de bakmışsınız ki iyice karmaşıklaşmış. “Penne Arabia” olmuş. Eh hasbelkader hepimiz bu süreçleri yaşadık. Yaşadık ki anlatılıyor, isimlendiriliyor. Yapılmaması gerekenler, yapılması gerekenler diye listeler sunuluyor. Bu kadar çuvaldızı kendimize sapladığımıza göre, ufak bir istatistiki bilgi ile zülfü yâre dokunayım.

 İş birimlerinden veya müşterilerden talep edilen isteklerin “%80″i hiç kullanılmıyor. 

Oran inanılmaz. Bu istatistik neye göre verildi tam bilemiyorum fakat kendi bilgisayar kullanım alışkanlıklarıma baktığımda birçok uygulamanın çok az özelliğini kullanıyorum diyebilirim. Bazen tesadüfen rastladığım özellikler bile olabiliyor o derece. Çok sallamış istatistiği veren diyemedim. Umarım aklımda bu sayı yanlış kalmamıştır. Çünkü bu tarz bir argüman sununca kaynağı da belirtiyim istedim fakat bulamadım.

Zaten çok önemli değil değinmek istediğim konu için 80 olmasın da 60 olsun. O da yeter. Yazılımcı olarak tüm bu isteklere, -ki bazıları acilen oluşur ve hemen aksiyon alınması istenir- Dexter Morgan soğukkanlılığı ile çıktı üretmek zor olabilir. Tüm önem verilen ritueller, kodlama alışkanlıkları bir kenara bırakılmak zorunda kalabilir. O anı kurtarmak için tasvip edilmeyen kod parçaları hasıl olabilir. İşte bu ahval ve şeriat içinde dahi geriye dönüp daha iyi bir çözümü uygulamaz isek. “İşte bunlar hep spaghetti”.

Spaghetti kodu niteleyen, “Code Smells” denilen bir kavram, bir anti-pattern daha var. Yani koda bakıldığında az çok anlaşılabiliyor ve burnunuza “kötü kokular” geliyor. Yazılım geliştirme sürecinde yazılımcılar olarak, bir özelliğe efor verirken, o özelliği hangi sisteme ekleyeceğimize dikkat etmemiz gerekir. Yani kodu görmeden efor vermek -bazen dışardan bakıldığında “çok kolay” görünen özellikleri geliştirmenin maliyeti tahmin edilenden çok yüksek olabilir- proje sahipleri karşısında bizi zor duruma düşürebilir. Beyaz yaka camiasında efor verirken “şişirme” işlemine “buffer” deniliyor. Buffer denildiğinde daha havalı oluyor:) Aslında buffer demek hele ben eşeği sağlam kazığa bağlıyım da başım ağrımasın demek gibi bir şey:) Oysa buffer vereceğimize, tüm proje boyunca titiz bir şekilde geliştirme süreçlerini işletmek gerekir.

İşte biz fularsız yazılımcıları böyle “work-around”lar uygulamaya götüren şey. Yazılım geliştirme süreçlerinin yeterince doğru uygulanmaması, ana kaygının ortaya bir an önce ürün çıkarılması olması. Proje biter dertler biter sananlar yanılıyor. Proje biter, gelir Acil!!!! (ünlemler önemli, ne kadar ünlem varsa o kadar önemlidir, ben 5 ünlemden aşağına acil bile demem, basın ünlemleri güzel insanlar) kodlu mailler. Evet proje bitmiş ve başarıyla kapatılmıştır. Fakat arka tarafta yapılan teknik borçlanmalardan ötürü ızdırap devam etmektedir. İşte bunlar hep spaghetti yüzünden.

keep_calm

Leave a Reply

Your email address will not be published. Required fields are marked *