Overengineering AntiPattern ve Kaçınma Yolları

Merhaba arkadaşlar, bir önceki yazımda genel olarak anti-patternlerden bahsetmeye çalışmıştım. Şimdi bunların sırayla detaylarına inmeye çalışacağımız bir seriye başlıyoruz. İlk yazımız Overengineering anti-pattern ve kaçınma yolları olacak.

Overengineering kavramını, bir sorunun olduğundan çok daha fazla kompleks hale getirerek, basit bir çözüm yerine karmaşık bir çözüm uygulamaya çalışmak olarak tanımlayabiliriz.

“Code or design that solves problems you don’t have.” Paweł Głogowski

envylabs-over-engineering

Peki Overengineeringe sebep olan durumlar nelerdir?

• Problemi / isteri doğru anlamamak.
• İster hakkında varsayımda bulunmak.
• Kendini ispatlama çabası ya da kontrol edilemeyen kişisel ego
• Hype olan teknolojiyi -analiz etmeden, ihtiyaç var mı sormadan- kullanmaya çalışmak
• Optimum çözümler yerine en havalı çözümleri uygulamaya çalışmak
• Çözümün maliyetlerini göz ardı etmek
• Sürekli tek başına karar almak
• Çözümü planlama ve geliştirme sürecinde düşünmeden, soru sormadan ilerlemek.

Yukarıda toparlamaya çalıştığım maddeler haricinde farklı maddeler de tabi ki olabilir, ben burada genele yayabileceğimiz konu başlıklarını belirtmeye çalıştım.

Peki bu Overengineering kavramından nasıl kaçınabiliriz?

İlk olarak iş birimi ile iletişimimizi kuvvetlendirerek bize gelen isterler hakkında daha fazla detay öğrenebilir, anlamadığımız konuları sorabiliriz. Netleşmeyen durumlar varsa çözümü belirlemeyi geciktirebiliriz. Burada net olmayan konuların netleşme maliyeti yanlış belirlenen bir çözüm maliyetinden çok daha düşük olacaktır. İsterleri olabildiğince yalın değerlendirerek kendi başımıza varsayımlarda bulunmamalıyız. “Yarın burada kesin buna ihtiyaç duyulur” gibi varsayımlar yerine isteri gerçekleştiren ve gelişime açık çözümler bulmalıyız. Unutmayalım ki “maliyeti en düşük kod, yazılmayan koddur”.

mindtheproduct-overengineering

Sürekli kendimizi ispatlama çabasından dolayı ya da kişisel egomuzu tatmin etmek için, problemleri olması gerekenden daha maliyetli çözmekten uzak durmaya çalışmalıyız. Bu konuda kendi kişisel gelişimimizi sağlamakla sorumluyuz, bununla beraber çalıştığımız iş ortamının da sürekli bizi buna itmediğinden emin olmalıyız. Sonuçta bir takımın içindeyiz ve burada beraber sonuçlar alıyoruz bunun bilincinde olmalıyız.

engineer-types

Hype olan teknolojileri ya da denemek istediğimiz teknolojileri uygulamadan önce bu teknolojileri doğru anlamaya çalışmak, avantaj-dezavantajlarını öğrenmeye çalışmalıyız. Her şeyden önce “Buna ihtiyacımız var mı?” sorusunu sormalıyız. Bu tarz denemek istediğimizi teknolojileri kişisel projelerimizde, poc projelerde denemeliyiz. Her istediğimiz teknoloji, her çözüm için doğru teknoloji olmayabilir, bunun bilincinde olmalıyız.

Çözümleri düşünürken “en az eforla en çok verimi nasıl alabiliriz?” üzerine düşünmeli en havalı çözümler yerine olabildiğince karmaşıklıktan uzak, verimli çözümlere odaklanmalıyız.

mindtheproduct-code-complexity

Yazdığımız her kodun, uyguladığımız her tasarımın bir maliyeti vardır, bu maliyet sadece uygulama / entegre etme maliyeti değildir. Uygulanan çözümün daha sonrasında bakım ve sürdürülebilirlik maliyeti vardır.
Aslında uyguladığımız her çözümde teknik borç için yeni bir alan, test için cover edilmesi gereken yeni bir yapı oluşturuyoruz.

Sürekli tek başına ilerlemek yerine pair programming, ekip içi tasarım değerlendirmeleri, arkadaşlarımızla fikir tartışmaları yaparak Overengineering yapmaktan uzaklaşabiliriz. Sonuçta Overengineering yapan bir kişi aslında bu çözümün doğru olduğunu düşünebilir fakat farklı gözlerle bunu anlamak daha kolay olacaktır.

Bireysel ve ekip olarak KISS (Keep It Simple Stupid), YAGNI (You Ain’t Gonna Need It), LSD (Lean Software Development) gibi kavramları okuyarak, tartışmak, bunları anlamaya, uygulamaya çalışmak Overengineering yapmaktan bizi uzaklaştıracaktır.

Çözümü planlarken ve bulduğumuz çözümü uygularken gözü kapatıp ilerlemeye çalışmak yerine arada bir kendimize “Bu çözüme gerek var mı?”, “Bulduğum bu çözüm ürüne değer katıyor mu?”, “Bu çözümü ben hangi fayda/yarar için uyguluyordum?” gibi sorular sorarak ilerlemeliyiz.

Bugün Overengineering anti-pattern ve kaçınma yollarını incelemeye çalıştım, umarım faydalı olmuştur. Kalın sağlıcakla … 🙂

Kaynakça

https://www.mindtheproduct.com/overengineering-can-kill-your-product/
https://www.buraksenyurt.com/post/AntiPatterns-Ders-Notlarc4b1m
https://medium.com/devopsturkiye/yazılım-mühendisliğinde-over-engineering-ve-lean-thinking-üzerine-922550693d9b