5. AntiPatternler

Antipattern kullanışsız ve çoğunlukla hatalı sonuçlar ortaya çıkaran, yanlış çözümlere denir. Anti-pattern’lerin en büyük sıkıntısı, davranışın ya da çözümün ilk başta doğru gibi düşünülmesidir, bu durum sorunların uzun vadede ortaya çıkmasına neden olur.

Kötü çözümleri belirlemek, iyi çözümleri belirlemek kadar yararlı olabilir.

Yazılım geliştirmede bir problemin birden fazla çözüm yolu vardır. Ancak önemli olan bu çözüm yollarının hangisi doğru bir çözümdür, hangisi uzun vadede başınıza sorunlar açar ya da hangisi geliştirilmeye açık çözümdür bunu tespit edebilmektir. AntiPattern’ler, çok sık karşılaşılan ortak sorunlarda sıklıkla uygulanan kötü çözümleri size sunar. Antipatternler yazılımcıların bu kötü çözüm kalıplarını bilmesini ve tanımasını sağlar. Bu çözümler ile kendi çözümlerinizi karşılaştırırsınız ve çözümünüzün kalitesi hakkında fikir sahibi olursunuz. Size hangi çözümü uygulamamanız gerektiğini gösterirler. Dünün en popüler çözümü bugünün AntiPattern’ i olabilir.

Bir Pattern çözdüğünden daha fazla problem oluşturuyorsa AntiPattern’dir.

Sıkça Uygulanan AntiPatternler

Overengineering

Mevcut sorunun, olduğundan çok daha büyük ve compleks olarak düşünülmesidir. Çö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ç bir şey ifade etmez. Yazılımcılar genellikle bilgilerinin tümünü(design patterns, tools vb) bir problem üzerinde kullanmaya heveslidir ancak problem ufak bir dokunuşla istenilen şekilde çözülebiliyor ise overengineering yapmak yersiz olacaktır.

Copy-Paste Programming

Bir programcının çözüme gitmek için, kodu bir fonksiyondan diğerine kopyalayıp yapıştırarak aynı kodu sıklıkla kullanması bir antipattern örneğidir. Yazılım geliştirici, yazdığı kodun ne iş yaptığını bilmeli, arka planını bilmediği kodları çözüm amaçlı copy-paste kullanmaktan kaçınmalıdır. Bunun yanında copy-paste programlama yazılımcıyı kod tekrarına düşüreceğinden uzun vadede, tekrar eden kodlarda bir bug bulunması veya kodun geliştirilmesi gereken durumlarda, bir çok yere dokunmak gerekecektir ve copy-paste programming uzun vadede projeyi zora sokacaktır. Bunun yerine karşılaşılan problemlere daha jenerik çözümler üretmek tercih edilmelidir.

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.

God Object -Blob

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. God Object, tasarımın tek bir parçasının-ki burada kastedilen bir sınıftır- çok fazla sayıda fonksiyona konsantre olmasıdır.

Lava Flow (Dead Code) Antipattern

Lava flow kod, önceden yazılmış , yazılma sebebi developerın bir probleme geçici çözüm arayışı veya kodla ilgili herhangi bir denemesi olabilir. Ancak geriye dönüp bakıldığında bu kodların ne işe yaradığı kimse tarafından bilinemez öyle ki bu kodları yazan  developer işten ayrılmış bile olabilir. Bu tarz kodların ne amaçla yazıldığı kimse tarafından bilinmediğinden çıkarılması yahut üzerinde değişiklik yapılmasının maliyeti yüksek olur ve  bu sebeple bu tarz kodların uzun vadede götürüsü fazla olur.

• Bazı işlevselliklerin uygulanmasına yönelik çeşitli deneme yaklaşımlarının uygulanması.
• Tek geliştirici (yalnız kurt) tarafından yazılan.
• Konfigürasyon yönetimi veya süreç yönetimi politikalarına uyum eksikliği.

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. Geliştiriciler ve yöneticiler mevcut bir yaklaşımla rahatlar ve daha uygun olanı öğrenmek ve uygulamak istemezler. Bu, özellikle dünya bankacılığı topluluğunda yaygın olan ortak “bizim veri tabanımız mimarimizdir” zihniyetiyle belirlenir.

Hard Coding

Sabit kodlama; uygulamadaki configlerin ve değişkenlerin doğrudan programcı tarafından kodun içinde belirlenmesidir. Bu gibi durumlarda config ve değişkenlerde yapılmak istenen her değişiklik için kod üzerinde bir değişiklik ve deployment süreci gerekecektir ve hard codingin miktarı arttıkça bunun maliyeti daha da artacaktır. Bunun yerine değişkenlerin ve konfigurasyon verilerinin veritabanı, ya da .ini config dosyalarda tutulması daha kullanışlıdır.

Boat Anchor

Kullanılmayan ancak programda yer verilen kod parçalarına verilen addır. “Bu metoda/kütüphaneye ilerleyen zamanlarda ihtiyacımız olabilir” denilerek yazılan fakat yazıldığı yerde unutulan kod parçalarının ortaya çıkarttığı durumdur.

Cargo Cult Programlama

Niye kullanıldığını bilmeden, arka planında yatan prensipleri anlamadan bir takım pattern’leri sırf kullanmış olmak için kullanıp kod yazmaya verilen isimdir.

Error Hiding (Hata Gizleme) 

Çalışma zamanında oluşan hataları exception handling mekanizmasıyla yakalamak ancak hata mesajlarını log’lamayarak gizlemek, adeta hatanın üstünü örtmek anlamına gelir. Bu özellikle uygulamaya destek veren kişileri zora sokacak bir antipatterndir. Bu tip bir anti-patternden kurtulmak için hataları olabildiğince gidermek , hata mesajlarını loglamak ve son kullanıcıya anlamlı hata mesajları dönmek gerekir.

Reinventing the Square Wheel

Var olan bir çözüm yerine ondan daha kötü olan özel bir çözüm üretme hatasına düşmek. Bazı yazılım problemlerinin çözümünde kullanılacak olan yollar zaten standart ve bellidir. Üstelik bu çözümler için standart hale gelmiş mimari yaklaşımlar, ürünler ve alt yapılar(Frameworks) mevcuttur. (Hatta tasarım kalıpları) Problemin bu tip yardımcılar ile çözülemeyeceğini düşünüp sıfırdan bir çözüm üretilmeye başlandığı hal tekerleğin yeniden keşfi olarak düşünülür ve bu AntiPattern’ in oluşmasına neden olur. Nitekim ekip söz konusu problemin çok özel olduğuna ve var olan pratikler ile ele alınamayacağına inanır.

Vendor Lock-In — Organizational 

Bir sistemin dışarıdan sağlanan bir bileşene aşırı bağımlı tasarlanması/geliştirilmesi/yürütülmesi.

Müşteri olarak bir üreticinin ürünü veya hizmetine sıkı sıkıya bağlı olunan hallerde ortaya çıkar. Öyleki farklı bir üreticinin ürününe geçiş yapmak için ekstra maliyet altına girmek gerekebilir. Sıklıkla verilen örneklerden birisi müzik sistemi içeriye gömülü olan otomobillerdir. Bunlarda müzik sistemini değiştirmek epeyce külfetli bir iştir.

Functional Decomposition

Bu AntiPattern, nesne yönelimli bir dilde bir uygulama tasarlayan ve uygulayan, ancak tasarımı nesne yönelimli olmaktan ziyade prosedürel olan kodlar için geçerlidir. Functional Decompositionda  class isimleri genellikle fonksiyon isimlerine benzer olup classlar tek bir fonksiyon veya tek bir processle kısıtlanır.Ayrıca tüm sınıf propertyleri özeldir ve yalnızca sınıfın içinde kullanılır.  Geliştiriciler, çok sayıda alt rutin çağrısı yapan bir “ana” rutin üzerinden, sınıf hiyerarşisini tamamen yok sayarak bir sınıf haline getirme eğiliminde olurlar.

Aşağıda müşteri borç sisteminin functional decomposition antipatterni ile tasarlanışı ve olması gereken tasarım verilmiştir.

* Functional Decomposition antipatterni ile müşteri borç sistemi

Aşağıdaki tasarımda tüm süreçler nesnel bir yaklaşım yerine fonkisyonel olarak ayrılarak functional decompositon antipatternine örnek teşkil etmiştir.

1. Yeni bir müşteri eklemek.
2. Bir müşteri adresini güncellemek.
3. Bir müşteriye verilen kredinin hesaplanması.
4. Bir krediye olan ilginin hesaplanması.
5. Bir müşteri kredisi için ödeme planının hesaplanması.
6. Ödeme takvimini değiştirmek

functional decomposition ile ilgili görsel sonucu

 * Nesne Yönelimli Tasarım ile müşteri borç sistemi

Aşağıda , yukarıda örneklenen functional decomposition nesne yönelimli bir yaklaşım izlenerek çözülmüştür. Birbiriyle ilişkili processler Customer, Loan, Payment gibi uygun classta toplanarak her biri bir varlığa karşılık oluşturmuştur.

İlgili resim