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

Uluslararası Yazılım Firmasında Çalışmak

Türkiye merkezli 5 ülkede ofisi olan 50’den fazla mühendisi bulunan ve müşterileri hariç 8 farklı milliyetten kişiler bulunan bir yazılım firmasında yaklaşık 11 aydır çalışmaktayım. Bu süreç boyunca hem çalıştığım şirkette hem de iletişimde bulunduğum diğer uluslararası şirketlerde gözlemlediğim noktaları paylaşmak istedim. Buradaki görüşlerim tamamen kişiseldir ve firmadan firmaya değişebilir. Eleştiriyi önce en günahsız olanınız yapsın! Photo by Kyle Glenn on Unsplash İşe giriş ve mülakat süreçleri zor. İş ilanlarını mantıklı ve açıklayıcı olarak açılıyorlar. Öyle her şeyden anlayan süper yazılımcı aramıyorlar. Şirketin ihtiyacını göz önüne alarak ve her yazılımcının şirkette kullanılan teknolojileri bilemeyeceğini göz önüne alınarak iş ilanını açılıyor. Özgeçmişimde yazan her kelime ile ilgili sorguya çekildim. Başvurduğum pozisyon için gereken yeteneklerle ilgili zor sorular soruldu. Nasıl yaptılar bilmiyorum ama şirket kültürüne uyumumu ve iletişim yeteneğimi de ölçmüşler. Açık

Kamuda Yazılımcı Ol(ma)mak

Yazılımcı olarak 8 yıl kamuda, 2 yıl özel sektörde çalıştım. Bir yandan da freelance olarak çalıştım. Yurtdışındaki firmalarla da güzel yurdumun esnafıyla da çalıştım. En garip manzara bence kamudaki yazılım manzarası. Şu anda bir kamu kurumu için geliştirilen yazılım projesini yönetiyorum. Girdiğim toplantılarda, aldığım e-postalarda, yaptığım telefon konuşmalarında eski kamu anılarım depreşti. Kağıtların arasında hayalleri yıkılmış bir yazılımcı bulabilirsiniz Kamuda çalışırken hem benim hem de arkadaşlarımın başına gelen olaylardan ve şu anda kamuda çalışmaya devam eden tanıdıklarımdan aldığım bilgilerle, kamudaki yazılım dünyasını size sanayi diliyle aktarmaya çalışacağım. Bu yazı şahsi görüşlerimi içerir. Yine de kamuda 8 yılın yeterince objektif bir bakış açısı sunacağını düşünüyorum. Kamuya yazılım projesi geliştirirken karşılaşabileceğiniz durumlar: Bir kamu kurumu ile görüşmeye başlamak için bağlantı gerekir. Kamu kurumuna “sizin şöyle bir ihtiyacınız var ben bunu çözen yazılı