Yazılım geliştirme sürecinde K.I.S.S Prensibinin deneyimlenmesi

Bu makalede yazılım geliştirme sürecinde K.I.S.S Prensibinin deneyimlenmesi sürecinde yaşadıklarımı anlatacağım. Öncelikle K.I.S.S nedir bununla başlayalım.

Keep It Simple, Stupid

Yapılan işi basit ve çözüm odaklı bir yol ile sonuçlandırmak. Yazılımcı mevcut bir sorunu çözmek için komplike yollar seçmekten kaçınmalı işin özünü kaçırmadan problemi çözmeye ve işi bitirmeye odaklanmalıdır. Tabi bunu yaparken kurduğu yapıyı elinden geldiğince esnek tutmalıdır. Yazılım geliştirme prensipleri kullanılırken yanlış uygulamalar veya es geçilen durumlar neticesinde teknik borçlanma (Technical Debt) oluşur. Teknik borçlanma başlığı altında biriken iş yoğunluğu sizi bu güzide prensiplerden soğutup çok uzağa götürebilir. Bu nedenle dikkat edilmesi gereken bir durumdur. Tam şuan yazdığım makale için K.I.S.S uyguluyorum ve teknik borçlanma gibi konuların detayına girmiyorum 🙂

K.I.S.S prensibi “çok basit” ve “yetersiz” algısı

Genelde yazılımcılar K.I.S.S prensibinin başlıca getirisini yani “Basitlik” kuralını çoğu zaman es geçerler. Bazı durumlarda problemin çözümü o kadar basittir ki bu durum “çok basit” ve “yetersiz” kelimeleriyle nitelendirilir. Yazılımcı yapacağı işin basitliğinden şikayet eder ve karmaşıklığı göze alarak tatmin olacağı farklı yollar ile çözüme gider. İşte tam olarak bu şekilde yanılgıya düştüğüm bir sürecin nasıl geliştiğini sizlerle paylaşayım.

Birbirine çok benzer geliştirmelerle uğraştığım bir dönemde , Windows servisin belirli bir saate yeniden başlatılması ile ilgili bir iş geldi. İlk aklıma gelen olarak Windows görev zamanlayıcısı (Windows Task Scheduler) üzerinden basit bir işlemle bu işi çözümlemek oldu. Birkaç iş kuralıyla birlikte Log almak istediklerini düşünürsek yine basit bir Console App ile görev zamanlayıcısı üzerinden iş çözümlenebilirdi. “Basit” evet çok basit..

Yazılım geliştirme başlasın

Son dönemler için farklı bir iş olmasının verdiği hevesle güzel bir Scheduler yazmaya karar verdim. Üzerinde biraz düşünüp neler yapacağımı belirledim. Kontrolü yeni bir servis ile sağlamayı planlamıştım. Servis iş kurallarını çalıştıracak parametrik olarak servis adı, çalışma zamanı hatta mail bilgilendirme seçeneği ile epeyce süslü olacaktı. SchedulerService adında bir Windows Service projesi ekledim. Bir servis yazıyorsak kodların direkt olarak servis’in içine yazılması pek tercih edilmez. Kodlar ayrı bir proje üzerinden oluşan dll ile servise içine refere olmalıdır. Bu durum hem servis’i güncellemeyi kolaylaştırır hemde test işlemlerinde kolaylık sağlar.

SchedulerManagement adında bir proje ekleyip kodları yazmaya başladım. ServiceManager adında sealed bir sınıf oluşturdum tek instance yeterli olacağı için  Singleton Pattern’i lazy load ile implement ettim. Sınıf içinde init işlemi , config ve servis iş kuralları, Timer üzerinden schedule işlemini tamamladım.Bu kadarını yapmışken Exception Handling’i de eklemeden olmazdı. İşi biraz daha genişletip servisin çalışma saati ve adını da parametrik yaptım. Scheduler.Common projesi ekleyip içerisine event logları yönetmemi sağlayacak bir sınıf oluşturup sınıfı projeye sunan public bir Helper da yazdım. Epeyce bir proje oldu artık 🙂 Happy case testing kısmını da hatasız geçtik. Problem çıkmadığına göre proje hazır…

Öngörülmeyen durumlar

Yapılacak son iş servis kurulumu. İlgili ortama bağlantı sağladığımda Windows dil ayarlarının farklı olduğunu gördüm.  Bu öngöremediğim bir durumdu. Bize yine geliştirme yolları göründü 🙂 Bir geliştirme de dil ayarları için. Tekrar kodlamaya dönüp Culture-Region desteğini de ekledim.

Test Test Test…

Proje büyüdükçe test’in karmaşıklığı ve hata çıkma olasılığı da o derece artar. Yazılım geliştirme aşaması ve öncesinde not aldığım adımları tekrar test ettim. Problem çıkmadığına göre proje hazır.  Testlerin sonucu başarılı.

Taşlar yerine oturuyor…

Artık elimizde servis altyapısı sağlam, design-pattern ile süslenmiş , farklı dil ayarlarını destekleyen takır takır çalışan bir proje var. Teknik açıdan bakıldığında tatmin edici bir sonuca ulaştım. Ama ulaşılan sonucun somut faydası ne oldu? Problem ile ilk karşılaşıldığında “basit” ve “yetersiz” olarak görülen yöntemden farkı ne oldu? Aynı işi daha fazla efor ve daha fazla kod yazıp bitirmiş oldum. Bir tarafta neredeyse kod yazmadan bitirdiğim istenileni karşılayan bir basitlik, diğer yanda fazladan varsayım ile iş kuralları eklenmiş, sağlam bir altyapı kurulup tatmin edici bir mimari ile bitirilen iş.

İşin özü

Sonuç olarak bu tarz problemleri gördükten ve deneyimledikten sonra doğru olanın işi çözümleyecek şekilde basit olanı yapmak olduğuna karar verdim.Yaklaşık 25 satırlık bir console application yazıp Windows görev zamanlayıcısı üzerinden işlemi tamamladım. En fazla 20 dakikalık bir efor sonucunda Geliştirme + Test + implementasyon süreci tamamlanmış ve iş bitirilmişti. İşte o gün bugündür, iş bitirmenin her zaman Best-Practice ve sağlam bir altyapı gerektirmediği gerçeğiyle bazı başlıklar ile işe başlıyorum.

Done is better then perfect..
Keep it simple, stupid

yada daha basit bir dille şöyle diyelim

Attığın taş ürküttüğün kuş’a değecek mi ?