Ana içeriğe atla

Spagetti kod nasıl yenir?

Spagetti kod üzerine günü kurtaran if ve else ifadeleri eklenir. Acil olan tüm işlere aynı anda bakılır. Anlaşılmayan hatalar try-catch ile susturulmaya çalışılır. Anlaşılması güç değişken isimleri ve fonksiyon isimleri kullanılır. Tekrarlayan kod parçacıkları yerleştirilir. Kodu açıklayan yorumlar eklenmez, dokümantasyona kesinlikle katkı yapılmaz. Artık spagetti kod servise hazır.

spaghetti code magic
Spagetti kod, okunması ve anlaşılması zor olan, kodun takibinin zor olduğu kodlardır. Yazılımın var olduğu ilk günden itibaren varlığına başlamıştır. Herkes iyi kod yazdığını iddia ederken bu spagetti kod nasıl oluşuyor? Suçu önceki yazılımcıya atmadan önce gelin beraber bakalım işin aslı neymiş. Spagetti kodun varoluş hikayesini birlikte dinleyelim:

Kullanıcıların ihtiyacı tam olarak anlaşılmadan, proje kapsamı belirlenmeden, sektör konusunda bilgi edinilmeden, uygun araçlar kullanılmadan, yazılım mimarisi belirlenmeden ve en önemlisi doğru ekip oluşturulmadan yola çıkılır. Aniden beliren "acil" ihtiyaçlar planlanmadan halledilir. Karşılaşılan hatalar için günü kurtaran çözümler eklenir. Projeye yeni katılan yazılımcılara herhangi bir eğitim verilmeden kod yazdırılır. Yavaşlayan yazılım için ilave işlemci ve bellek kullanılır, SSD'ler eklenir.

Code review yapılmadığı için karmaşık kodlar yavaş yavaş kendini göstermeye başlar. Her yazılımcı kendi kodlama tarzını işine yansıtır ve bununla gurur duyar. Yazılım ekibi tarafından ortak bir kodlama ve isimlendirme standardı olmadığından ekip o günkü ruh haline göre kod yazar. Hele ki yarı zamanlı olarak kodlara katkı sağlayan kişiler varsa bunların kodlarına hiç dokunulmaz.

Plansız işlerde aynı işi yapan tekrar eden kod parçacıkları ortaya çıkmaya başlar. Yazılım ekibi iyi koordine edilmediğinde, dokümantasyon güncel olmadığında, işin teslim zamanının çok kısa olması halinde ihtiyaç duyulan kod parçasının önceden yazıldığı gözden kaçabilir.

Metotlar nesneler tarafından değil de iş akışı tarafından yönetilecek şekilde yazılır. Metot isimleri o metodun yaptığı karmaşık işleri anlatacak biçimde konulur. Metotlar bu şekilde yazıldığı için nesneler arasındaki ilişkiler belirsizdir. Bu tür metotların diğer özellikleri ise ya hiç parametre almamalarıdır ya da çok fazla parametre almalarıdır. Hazır bu kadar parametre almışken bu parametrelerin değerleri ile oynamadan yapamazlar bu metotlar. Bu metotların satır sayıları fazladır. Bu metotlar veri tabanı, dosya ve ağ işlemleri yapmayı da çok severler. Eli değmişken her işi yapan mükemmel metotlardır bunlar. Bu metotları yazarken yapılan ninjalıklar yazılımcının gururunu okşasa da iş daha sonra bu metotların bakımını yapmaya geldiğinde bu metotlar insanı çileden çıkarır, bir hataya bin hata ekler.

Dosya adı, parolalar ve bağlantı adresleri gibi değişebilecek değerler kod içerisine gömülür. Enum kullanımı yerine "Pazartesi", "Şubat", "kırmızı" gibi metinsel ifadeler kullanılır. 

Bir gün işe yarar diye eski kodlar yorum halinde bırakılır ve yorum halindeki kodlara her geçen gün yenileri eklenir.

Nesne yönelimli programlamanın nimetlerinden olan inheritance, encapsulation ve polymorphism kullanılmaz. Yazılımcının zekâsına güven sonsuzdur. Yazılım ekibinin hiç değişmeyeceğine olan inanç tamdır.

Yazılımcılar tek satırda uzunca kod yazarak ne kadar usta bir yazılımcı olduğunu göstermeye çalışırlar. Geçici değişkenler kullanılmaz. Metotların doğru değer göndereceği varsayılır, değişkenlerin alabilecekleri değerlerin hep mantıklı ve düşündüğümüz sınırlar içerisinde olacağı tahmin edilir.

Amaçsız optimizasyonlar yapılarak zaten anlaşılması güç olan kodlara gizem katılır. Optimizasyonun ne kadar hız sağladığı ölçülmez. Optimizasyonun varlık amacı yazılımcının yeteneğini sergileme isteğidir.

Kodların biçimine önem verilmez. Boşluklar, parantezler, boş satırlar düzensiz olarak koda yerleştirilince kodun okunması zorlaşır. Bu bakımı ve hata tespitini zorlaştırır.

Görülen yanlışlıkların ve alınan derslerin ekip içinde paylaşılmaması karşılaşılan bu durumun tekrar tekrar yaşanmasına sebep olur. Her seferinde tekerleği yeniden icat etmek için emek sarf edilir.

Kodların nasıl çalıştığını anlamaya çalışmadan kopyala-yapıştır yapmak karmaşık kodların ana sebeplerindendir. Kısa teslim süresi nedeniyle kodları incelemeye zaman bulamayan yazılımcı hız için kaliteden ödün verir.

Yanlış araç, IDE vb.,  kullanımı ve kullanılan araçları iyi tanımamak yazılımcının basit olabilecek çözümleri görmesine engel olur.

Hata yoksa araçların verdiği uyarıları ve bilgilendirmeleri görmezlikten gelmek hem karmaşayı artırır hem de performansa zarar verir. Derleme başarılı olduğunda kod teslim edilir.

Kodlarda yapılan küçük bir değişiklik öngörülemez hatalara neden olur. Düzeltilen bir hata başka hatalara kapı açar. Ekip yazdığı koddan emin olamaz. Kod testlerden geçse bile canlıda kullanıcı hatalarla karşılaşır.

Kodların anlaşılması zorlaştıkça kodu yeniden kullanılabilir parçalara ayırmak gittikçe zorlaşır. Bu kartopu etkisi yaratarak yazılımcıların karmaşaya karmaşa eklemesine sebep olur.

Kodun bakım maliyeti gittikçe artar. Öyle ki kodun baştan yazılması her tartışmada gündeme gelse bile kimse buna cesaret edemez. Kodun baştan yazılmasının maliyeti sürekli abartılır. Kaçınılmaz sonun geldiği bilinmesine rağmen mevcut kodlarda bulunan anlaşılamayan kod parçalarına, if ve else'lere tecrübe gözüyle bakılıp saygı duyularak konu kapatılır.

Yazılım ekibi yardım istemeden ve internette arama yapmadan sorunu çözmeye çalışır. Soru sormak zayıflık belirtisidir. Tecrübeli yazılımcılar yeni yazılımcılara yardım etmekten kaçınıp kaçamak cevaplar verirler.

Kod versiyonlama sistemlerine olan aşırı güven dikkatsiz kod yazamaya neden olur. Bir şey olursa eski kodlara döneriz mantığı ile özensiz kod parçaları çoğalmaya başlar. Sorunların kaynağını araştırmaktansa önceki kodlara bel bağlama eğilimi artar.

Güvenlik ve performansa yeteri kadar önem verilmez. Önemli olan işlerin yetişmesidir.

Acil işler, verilen sözler spagetti kodun yaşamına katkı sağlar. Yönetimin ürünü ve ekibi yanlış yönetmesi, sadece ürün teslimine odaklanması, emeğe ve personele değer vermemesi kalitesiz kodun ortaya çıkmasına katkı sağlar.

Yazılım ürününün kullanıldığı sektörü bilmeyen yazılım ekibi işi zamanında yetiştirebilmek için karmaşık kod yazma yolunu tercih edebilir. Kullanıcının ihtiyacını tam olarak anlayamayan, ileride değişiklik yapılabilecek alanları kafasında canlandıramayan, kendisine verileri ihtiyaç analinizi yapılacak işler listesi olarak gören yazılımcı aklındaki net olmayan tabloyu kodlara yansıttığında net olmayan kod parçaları ortaya çıkar.

Spagetti kodun oluşmasını engellemenin en iyi yolu spagetti kodun oluştuğu anda yok edilmesidir. Yeni bir özellik eklenirken, hatalar ayıklanırken, koda göz atılırken denk gelen kötü kodlar anında düzeltilmelidir. Bunu yazılım ekibindeki herkes yapmalıdır.

Ortak kodlama ve isimlendirme standardı olmalıdır. Sektör bilgisi olmayan personele önce sektör bilgisi verilmelidir. Yazılım ekibine yeni katılan personele pair programming ve code review yaptırılarak ekibin yoğurt yiyiş tarzı benimsetilmelidir.

Kod temizleme, code cleanup, işlemi periyodik olarak yapılmalıdır. Statik kod analizi araçları kullanılmalıdır. Test süreci ekip tarafından iyi bilinmeli ve uygulanmalıdır. Dokümantasyon güncel tutulmalıdır.

Ürünün performansı ve kullanım istatistikleri sürekli takip edilmelidir. Bakım maliyeti için analizler yapılmalıdır. Bir hatanın ne kadar sürede çözüldüğü, hatalarla ne oranda karşılaşıldığı, hizmet kesintisinin şirkete zararı gibi rakamlar ortaya çıkarılmalıdır.

Plansız iş yapılmamalıdır. Teknik destek ekibinden gelen istekler, üst yönetim ve kullanıcıdan gelen istekler kayıt edilmelidir. Daha sonra bu isteklerin gerekli olup olmadığı değerlendirilmeli, önem sırasına konulmalı, benzer istekler gruplanmalı ve bu isteklerin nasıl geliştirileceği değerlendirilmelidir. Yeni geliştirilecek bir özellik veya hata ayıklanmasında karşılaşılan bir durum için mimari değişim gerekiyorsa bu ekipçe değerlendirilmelidir.

Çalışan mutluluğu önemlidir. Yazılımcıya güven yoksa, biri gider biri gelir gözüyle olaya bakılıyorsa, fazla mesai artık normal bir durumsa, eski donanımlar ve araçlar kullanılıyorsa, çalışma ortamı personeli rahat ettirmiyorsa kodlarda bunun kötü etkilerini görebilirsiniz.

Spagetti kod için birilerini suçlamaktansa daha temiz bir kod nasıl yazılır diye çözümler aranmalı, şirketin iş süreci ve yazılım ekibinin çalışma tarzı gözden geçirilmelidir.


Yorumlar

Bu blogdaki popüler yayınlar

Bir Uluslararası Yazılım Şirketinin Batış Hikayesi

 Güzel başlamıştı hikaye. Yazılımcılar mutlu, kullanıcılar memnundu. Sonra pandemi başladı. Sorun para değildi. Olmayan şey huzurdu… Durdurun hype trenini, inecek var kırık kalpler durağında  — Photo by Kelly Sikkema on  Unsplash Gerçek olamayacak kadar güzeldi çalışma ortamı. Yazılımcılara istedikleri eğitim ve donanım alınıyordu, personel arası hiyerarşik bir yapı yoktu, sorumluluğun yanında yetki de veriliyordu, esnek çalışma saatleri yazılımcılara göre esnekti, izin isteyen hiç kimse geri çevrilmiyordu, pandemiden önce bile uzaktan çalışma vardı. Ne oldu bu şirkete? Nazar mı değdi? Şirketin yazılım ürünü Türkiye’de doğmuştu. Ürün birçok ülkede hem kamu tarafından hem de özel sektör tarafından kullanılıyordu. Yazılım geliştirme ekipleri hem Türkiye’de hem de diğer ülkelerde bulunuyordu. Yazılımın argesi için gelen geri bildirimlerin çoğu Türkiye’den geliyordu. Yazılımın kalbi Türkiye’de atıyordu.  Koronavirüs pandemisi nedeniyle Türkiye’de kamu kuruluşları hizmet alımı ile aldıklar

Türkiye'de Yazılım Şirketi Açmak ve Çıldırmamak

Aklında bir fikir vardı. Piyasada bunu karşılayan yazılımlar vardı ama hepsi eksikti. Hayalindeki yazılım ürününe hiçbiri yaklaşamıyordu. Gördüğü kadarıyla piyasanın böyle bir ürüne ihtiyacı vardı. Kullanıcılar mevcut ürünlerden şikayetçiydi. Kendi ekibini toplayıp hayalindeki şirketi kurmaya niyetlendi. Rüzgarlara dikkat!- Francesco Ungaro -  Pexels İşinden istifa etmeden önce piyasa araştırmasını yaptı, rakip ürünleri inceledi. En önemlisi ekibini kurdu. Ürününün MVP hali için çalışmaları başlattı. Girişim kurmak ile ilgili birçok kitap ve blog okudu, podcastler dinledi. Girişimci birkaç kişinin çayını kahvesini içti. Öngörebildiği her şey için önlemini aldı ve istifa edip kendi yazılım şirketini kurdu. Şirket kurmak için gerekli süreçler düşündüğünden daha kolay geçti. Şirketin adı ve logosu zaten hazırdı. Şirket teknoparkta yerini almıştı. Kendisi etiketlere çok önem vermiyordu ama yine de LinkedIn’deki profiline “Founder of the …” ibaresini ekledi. MVP’nin ortaya çıkması hedefini

Yazılımcılar İçin Yan Proje Oluşturma Rehberi

İster hobi amaçlı olsun ister maddi amaçlı her yazılımcının bir yan projesi olmalıdır. Peki yan proje oluştururken nelere dikkat edilmelidir, nasıl bir yan projemiz olmalıdır? Organize olalım beyler Yan proje (side project) için öncelikle bir fikir bulmak gerekli. Bu projenin amacı ne olacak? Hangi ihtiyacı çözecek? Yeni bir fikir mi olacak yoksa mevcut bir fikrin daha iyi uygulanmış bir hali mi olacak? Sadece yeni bir teknolojiyi öğrenmek için mi? Deneysel mi olacak ya da eğlenceli mi? Yoksa maddi bir getirisi olacak mı? Bu proje ürün olursa kimler kullanacak? Ürünü kullanacak kişilere erişip geri bildirim alabilecek miyim? . . . Bu soruların doğru bir cevabı yok, cevaplar size bağlı. Ama proje bir amaca hizmet edip bir ihtiyacı çözecekse, hele birde maddi getirisi olacaksa motivasyonunuz yükselecektir. Bunun yanında sadece eğlence amaçlı olan deneysel bir proje yapmak stressiz bir öğrenme ortamı sağlayacaktır. Gün içinde proje için aklınıza gelen her şeyi not alın. Not almazsan