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.

Aşağıda bazı anti-pattern’ler örnek olarak verilmiştir.

God Object

Nesne yönelimli programlamada nesneler, programda yer alan iş bölümü için oldukça yararlıdır. Ancak gereğinden fazla iş yapabilen, çok fazla sayıda değişken ve metot içeren nesneler God Object olarak adlandırılır.

Smoke and Mirrors

Bir ürün oluştururken yanıltıcı araçlar kullanmaktır. Ürünün geleceği açısından büyük sorunlar çıkaracaktır.

Analysis Paralysis

Bir proje üzerinde yapılan analizlere gereğinden fazla zaman ve enerji ayrılmasıyla ortaya çıkar. Temel nedeni bilgi yetersizliği ve tecrübesizliktir. Bir karar vermeden ya da eyleme geçmeden önce aşırıya kaçan analizler, iş sürecinin duraksamasına neden olur.

Overengineering

Mevcut sorunun, olduğundan çok daha büyük olarak algılanmasıdır. Çözüm, daha kolay bir yoldan yapılabilirken daha karmaşık bir yapı ile çözmeye çalışmak olarak belirtilebilir. Bir çok sorunu çözen bir yapı, gerektiği yerde işe yaramıyorsa bir hiçtir.

Golden Hammer

Her problemin farklı bir çözüm yaklaşımına ihtiyacı vardır. Ancak işlevine güvenilen bir çözümü bir çok problemde kullanmaya çalışmak bir anti-pattern’dir.

Hard Coding

Sabit kodlama; uygulamadaki değişkenlerin doğrudan programcı tarafından belirlenmesidir. Bunun yerine değişkenlerin ve konfigurasyon verilerinin veritabanı, ya da .ini uzantılı dosyalarda tutulması daha kullanışlıdır.

Boat Anchor

Kullanılmayan ancak programda yer verilen kod parçalarına verilen addır.

DLL Hell

.dll uzantısı aynı isimden iki dosyanın bulunmasına izin vermez. Aynı isimli farklı bir dosya olşuturulduğunda yeni dosya eskinin üzerine yazılır böylece eski dosya kaybedilmiş olur.

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.

Bu Anti-Pattern’den Kurtulma Yöntemleri

Sonuçta ilk sizin başınıza gelmiyor, dünyada binlerce yazılım firması ve yüzbinlerce yazılımcı varken sadece dünyanın sonunu sizin göreceğini sanıyorsanız gerçekten kafanız çok güzel bir durumda demek. Neyse başta ne dedik, bu bir AP ve her AP’nin olduğu gibi bunun da kaçınma yolları bulunmakta.

Çözümleri ele alırsak;

  • Modellerinizi küçük tutun. Onları birleştirmeyin. Büyük bir model oluşturmak size bilgi katmaz, aksine bilgiyi yokeder!
  • Baştan sona gitmenize gerek yok, fakat test yapılabilecek kadar analiz yapmanıza gerek var. Bu nasıl olacak? Gereksinimleri belirleyerek.
  • Bir “analist” işe almayın. Yazılımcı işe alın. Eğer bir yazılımcı bir gereksinimi nasıl analiz edeceğini bilmiyorsa, yakında öğrenecektir. Eğer bir analist nasıl sistemin inşa edeceğini bilmiyorsa onun “analizi” işe yaramazdır.
  • Eğer yönetimdeyseniz, teknik dokümantasyonu gözden geçirmeyi reddedin. Çalışan işlevselliği gözden geçirin. Eğer her döngüde yeni bir özellik görmüyorsanız, görene kadar milletin başına çökün.
  • Profesyonel yazılım mimarı işe alın – kiralayın. Sadece bir tane sizin işinizi görecektir, bir taneden fazla olmamalı! Mimarın takım lideri olmasına gerek yok – aslında eğer değilse daha güzel. Mimar yazılımın gereksinimlerinin analizini çıkartmakla da sorumlu olmamalı. O sadece kullanılan araçları ayarlamalı, takımı koordine etmeli ve diğer yazılımcıları desteklemeli. Temelin çılartılmasında mimardan başka kimse söz konusu olmamalı – bu sizi de içeriyor. Ve toplantılarda kimse ne toplu olarak ne de öneri olarak yapı hakkında bir şeyi önermemeli – bu Analysis Paralysis için zemin hazırlar.
  • Projenizi başlangıçta bir hedefle ve prototipi hazırlanmış biçinde ortaya çıkartın. Bir aydan fazla kod yazılmasın ve evet kötü algılanabilir ama elinizde kod olduğunda ve çalıştığında kimse size karşı gelemez. Sonrasında değiştirmeye ve güncellemeye başlayabilirsiniz. Prototipi olmayan bir proje ipsiz bir muma benzer ve bu durumda gerçekten Analysis Paralysis ortaya çıkar.