Aşırı Mühendislik (Over-engineering)

Bu yazında, yazılım geliştirirken ara sıra yapılan bir gafletten bahsetmek istiyorum. Gaflet de şu ki; bir problemi en efektif-yalın şekilde çözmek yerine, sırf bazı kalıplara uysun ya da daha fazla haz alalım diye daha karmaşık çözümlerin uygulanması gibi bir hastalık her kodşinasın içinde vardır herhalde.

Bu tarz durumlara iki örnek vermek gerekirse:

1) Framework yazma sevdası. İşe konsantre olmak yerine, girişilen framework yazma maceralarında eminim sıkıntıya düşmüş çok proje vardır. Bir framework tabii ki bir proje için hayat kurtarıcı olabilir, hatta ve hatta yokluğu büyük bir kaos yaratabilir; ama özellikle önden büyük bir tasarımla girişilen framework, projenin gelişen ihtiyaçları doğrultusunda yetersiz kalabileceği gibi (yetersizden ziyade, ihtiyaçları doğru karşılamaması daha büyük bir risk) akabinde daha fazla bir iş yükü çıkartmaya başlayabilir.

2) Tasarım desenleri yerinde ve amacına uygun kullanıldığı vakit tadından yenmez. Lakin ve lakin, her şeyi mükemmel bir nesne yönelim anlayışı ile çözmeye çalışırsak; ortaya basit yerine, gereksiz karmaşık bir yapı da çıkabilir. Mesela, basit bir if-else ifadesini ele alalım. En temel refactoring'lerden biri burada strateji deseninin uygulanması olabilir. Fakat 3-4 satırlık kodu, ben desen uygulayacağım sevdası ile daha karmaşık bir yapı ile sonuçlandırabiliriz. Bunun elbette gerekli oldu birçok durum vardır elbette ama bu karmaşıklığın bir geri dönüşünün de olmasını beklemek bana daha mantıklı geliyor.

***

Yazılım camiasında her zaman her yerde geçerli kurallar bulmak zordur. Yukarıda anlattıklarımı lütfen bir genelleme olarak değerlendirmeyin. Her çözüm, kullanıldığı bağlamı dikkate almak zorundadır. Bunun da kantarı akıl, izan ve gereksinimlerdir.  Bu noktada KISS ve YAGNI   presiplerini referans almak akıllıca olacaktır.