Gizli Tehlike: AntiPatterns
Yazılım geliştirirken benimsediğimiz en önemli prensiplerden birisi uyguladığımız çözümlerin denenmiş, benimsenmiş ve doğru yöntemler olmasıdır. Bu yöntemler kimi zaman oluşturacağımız basit bir kontrol-karar yapısının nasıl olacağına yol gösterirken, kimi zaman da bir uygulamanın nasıl şekillenmesi gerektiğine yani mimarisine yön verebilir. Neden bahsettiğimi tahmin ettiğinizi sanıyorum: Design patterns yani Türkçe ifadeyle tasarım kalıpları.
Tasarım kalıpları yazılım geliştirirken bir problemin çözümü için bize en doğru yolu göstermeyi amaçlar. Yazılı kuralların yanında kendi edindiğimiz, birlikte çalıştığımız arkadaşlarımızdan veya çevremizdeki yazılımcılardan edindiğimiz bazı kalıpları da günlük hayatımızda sıklıkla kullanabiliyoruz.
Kullanılan bir yöntem olumlu yönlerinin yanında bazen hesaba katamadığımız sorunlara da yol açabilir. Bir başka deyişle doğru diye bildiğimiz yöntemler aslında hatalı kalıplar olabilirler. İşte bu noktada yazılım geliştiricilerin tıpkı design patterns gibi bir de AntiPatterns kuralları da bulunmaktadır. AntiPatterns’in yazılım geliştirirken uyguladığınız bazı çözümlerin size doğru gibi görünse de aslında olumsuz yan etkileri olduğunu ve bu tip kullanımların hata olduğunu söyleyen kurallar olduğunu söyleyebiliriz.
AntiPatterns konusunu daha iyi kavrayabilmek adına kendinize şu soruları sorabilirsiniz.
- Hiç bir tasarım kalıbını veya kod parçasını nasıl çalıştığını anlamadan kullandınız mı?
- Ne kadar iş kuralı varsa hepsini arayüzdeki kontroller arkasına gömdünüz mü?
- Küresel olarak sunulmuş bir çözümü kullanmak yerine onun özel vakaları olduğunu düşünüp tekrardan yazma yoluna gittiniz mi?
- Mükemmel olması için en ince detayına kadar incelenen bir ihtiyaca ait ürünü geliştirmek için analizin çıkmasını beklediniz mi?
- Bir zamanlar deneme amaçlı olarak geliştirdiğiniz kütüphaneleri bir ürünün geliştirilmesinde doğrudan kullandınız mı?
- Kernel gibi isimlendirdiğiniz ve önemli olduğunu düşündüğünüz tüm fonksiyonellikleri içerisine kattığınız devasa bir sınıf geliştirdiniz mi?
- Daha önce başarılı bir şekilde kullandığınız çözüm mimarisini sonraki ürünlerde terk etmeyi hiç düşündünüz mü?
- Yıllar sonra geliştirdiğiniz kütüphane içerisinde var olan ama artık atıl olmuş bir sınıfa/metoda rastladınız mı?
- Ürün içerisinde bir başkasının uyguladığı kod parçasının aynen yapıştırıp içeriğinde biraz değişiklik yaparak kullandınız mı?
- Kaynak kodları açık olan ve şirket içerisindeki ürünlerde kullanılan 3. parti bir bileşende özelleştirme yaptınız mı?
- Bir servisten aldığınız hata mesajını son kullanıcıdan gizlediğiniz oldu mu?
Vereceğiniz cevaplar ne olursa olsun, oluşan hal genellikle bir AntiPattern oluşumunu işaret edecektir.
AntiPatterns terimi 1995’ de Andrew Koenig’ in Journal of Object Oriented Programming(ki doğrulatamadığım bilgilere göre bunun yerini Journal of Object Technology almıştır)’ de yayınlanan C++ köşesindeki Patterns and AntiPatterns makalesinde şu şekilde tanımlanmıştır;
AntiPattern is just like pattern, except that instead of solution it gives something that looks superficially like a solution, but isn’t one. (Koenig, 1995)
Şöyle yorumlayabiliriz : AntiPattern görünüşte(yüzeysel anlamda) çözüm zannedilen bir Pattern gibidir, ama aslında değildir.
AntiPattern’ ler yazılım geliştirme de kötü çözüm yaklaşımları ve pratikleri olarak da bilinirler. Söz gelimi tasarım desenleri, belli başlı problemlerin çözümünde standart pratikleri önerirken, AntiPattern’lar tam tersine arzu edilmeyen ve sonrasında daha büyük problemlerin kapısını açan pratiklerin uygulanması olarak düşünülebilir. Aslında AntiPattern’lerin tehlikeli tarafı ürün geliştirme süreçlerinde ve vakalarda en uygun çözüm yolu olarak düşünülmeleridir.
Dünün en popüler çözümü bugünün AntiPattern’ i olabilir.
AntiPattern’lar aslında Design Pattern’lerin doğal bir uzantısı olarak yazılım geliştirme sürecinde tekrar eden bazı yanlışları ifade etmektedir ve özünde bu yanlışları engellemek, anlamak ve onlardan korunmak için gerekli bir takım tanımlamaları da içermektedir.
AntiPatterns kavramlarını bilmek, yazılım geliştirme sürecinde karşılaşılabilecek ciddi problemleri önceden tahmin edebilmeyi ve tedbir almayı kolaylaştırır.
Diğer yandan mimari kavramlar ile gerçek dünya uyarlamaları arasındaki boşluğu dolduran bir köprü olarak da vurgulanmışlardır. Nitekim mimari kavramların doğru uygulanamadığı veya seçilemediği noktalarda, gerçek dünya ihtiyaçlarını karşılamak için ele alınan ve ideal gibi görünen çözümler, iki dünya arasındaki boşluğu dolduran AntiPattern’lar haline gelebilirler.
Bir Pattern çözdüğünden daha fazla problem oluşturuyorsa AntiPattern’dir.
Çok sık verilen ve bilinen AntiPattern örnekleri vardır. Spaghetti code, Copy-Paste programming, God Object(BLOB AntiPattern olarak da bilinir) vb. Yazılım dünyasının genişlemesi, platformlar arası iletişimin artması ve Enterprise olarak kabul edilen çözümlerin yaygınlaşması ile birlikte, AntiPattern konusu daha da önem kazanmıştır. Sayısız AntiPattern vardır ve bunlar ana ve çeşitli alt kategoriler halinde sınıflandırılmaktadır.
Gün içerisinde vakit ayırıp en azından bir AntiPattern vakası okumak, bununla ilişkili semptomları kavramak, çözüm yollarını incelemek ve olası istisnai durumları tanımak her yazılımcı için önemlidir.