Tag Archives: Anti-Pattern

Anti-Pattern: Analysis Paralysis

Gün geçmesin ki bir tane daha anti-pattern öğrenelim, işlerimizi düzene sokalım. Belki de alemlerin en çok dile getirilen fakat buna oranla anlamı tam olarak bilinmeyen anti-patternine de bakalım istiyorum. Bu seferki kalıplaşmış bir AP1, ne olduğu da adından belli. Plaza çalışanlarının ağzında sakız olmuş, bunu bileyeni PM2 yapmıyorlar o derece. Nerede bir sorun varsa bu anti-pattern’i belirtmekte ve aslında hayatın anlamı analysis paralysis, o derece. Peki gerçekten bu terimi doğru kullanabiliyor muyuz. Gerçekten bir anti-pattern olarak görebiliyor muyuz? Bunu irdeleyelim istiyorum.

Anti-Pattern nedir?

Her AP anlattığımda bu kısmı yazmadan geçmek istesem de elimde değil. Kavramı defalarca dile getirerek aşina olabiliriz. AP ya da Anti Pattern dediğimiz şey, toplumsal deneyimlerin birleşimidir. Bir yazılım sürecinde, bir hata ya da yanlış uygulama var ise ve insanlar bu hataya sık sık düşüyorsa kalıplaştırılır ve bir anti-pattern oluşur. Anti pattern dediğimiz aslında yaptığımız ve yapmamamız gereken işleri temsil eder. Yanlışlarımızı gösterir, kurtulmanın yollarını belirtir.

Analysis Paralysis Nedir?

Project Management kategorisinde bulunmakta olan bir AP’dir. Kısa tanımını direk vermek istiyorum bu AP’nin.

Projenin verilmiş olduğu akıllı ve iyi donanımlı analist arkadaşların ya da yazılım takımının analiz sürecine başlaması ve bu analiz sürecinin analizinin başlaması ve bunun da analizinin yapılması ile projenin iptal olmasına kadar giden döngüyü tanımlar.

Detaylı anlatıma gelirsek. Kapıdan içeriye elinde proje talep formu ile müdürünüz içeri girdi ve buyurdu ki bu proje yapıla. Hemen ekibinizin analiz tarafı projeyi analiz etmeye başladı ROI’ler belirlendi, toplantılar ayarlandı ama fark ettiler ki, bu projenin bir de cache sistemi olması lazım, hemen bir cache sistemi analizi planlandı, olası programlar belirlendi fakat proje atıyorum bir finans projesi olduğundan back-up sistemlerinin olması ihtiyacı doğdu, daha cache bitmeden back-up sistemi planlanması yapılmaya başlandı ve onun da analiz dosyası çıktı. Bir gün siz gayet her sabah olduğu gibi analiz yaparken fark ettiniz ki müdürünüze projenin iptal edildiği haberi gelmiş. Fakat siz elinizde 200 sayfalık bir analiz kitabı – ki daha yarısı yazılmış – ile müdürünüze bakıyorsunuz. İşte bu durum analysis paralysis’dir. Yani bir analizin gereğinden fazla detaylandırılıp başka analizler ile birleşerek daha da fazla analize ihtiyaç duyması durumuna denir.

Olası sebeplerini ele alırsak; 3

  • Modulleştirme ve birleştirmenin verdiği dayanılmaz cazibe,
  • Dizayna başlamadan önce tüm analizin tamamlanması gerekliliği,
  • Var olan sistemlerin yeniden yazılması ve planlanması için uygun şansın ortaya çıkması,
  • Bir seferde öğrenilmesi gerekilen çok şeyin olması – yeni yetme analist – yeni şeyler öğrendikçe, sürekli bir önceki işi tekrar ele alma.
  • Ara hedeflerin olmaması,
  • Sürekli artan ara hedeflerin olması – genellikle politikal kararlar,
  • Big Project Syndrome yaşanması; bu seferki istediğimiz her şeyi yapacak, en son toolları kullanıp, en son paradigmaları kullanacak, tüm yeni developerlar bunu yazacak, temiz ve düzenli bir sistem başlatacağız, ilk versiyonda daha önceki programlardan bir ya da iki tanesini içine alacak, vb…
  • Riskten kaçınma, hata yapmaktan korkma.

Bu konuda emin olun her yazılımcı ve analist maalesef bir kere bu hataya düşmekte. Bir sistem inşa ederken her zaman; ya şunu da içine alsa, bak burada double yapıyordum teke düşürürüm bunu yaptıktan sonra, ya şurada yeni bir pattern var onu da koyarsam içine, open source bir tool varmış onu da alayım analize gibi cümleler maalesef biz yazılımcıların içinde var, kanımız kaynıyor böyle şeyleri görünce. Fakat maalesef sonumuz projenin iptali olacak bir sürece giriyor. Sadece projenin iptali olsa ne güzel; analiz ve analiste olan güvenin azalması, kullanılacak yeni teknolojilere olan inancın azalması, yazılım biriminin itibarının zarar görmesi de bunların yanında kolay tamir edilemeyecek şeyler.

Burada kalın harflerle belirtmekte faide var, Analiz kötü değildir, aksine çok güzeldir, süper bir şeydir!

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;3

  • 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.

Bu konuda ilgili detaylı tartışmayı ve çeşitli deneyimleri okumak isterseniz, yazının çoğu kısmının araklandığı http://c2.com/cgi/wiki?AnalysisParalysis adresine girip bakabilirsiniz.

Kişisel Durumlarda Analysis Paralysis

Geçenlerde Scott Hanselman‘ın “Knowing too much code” adında bir makalesini okurken kendisi de Analysis Paralysis’e değindi. Fakat bu konuya değinmesi biraz daha farklıydı. Bir kişinin, gelişen bilgisi neticesinde, yeni projelerde, yeni teknolojileri ve bunların arasında oluşacak yeni sistemleri oturtmaya çalışması üzerine, içine girdiği karmaşayı tanımlarken kullandı. Ve aslında evet, maalesef öyle oluyor. gün geçtikçe şu gelmiş, bu varmış dediğimizde entegre etmeye çalışarak, aslında eskiden 3 günde olan işi 7 günde yapmaya başlıyoruz. İçimiz rahat oluyor ama proje gecikmiş oluyor. Geleceği düşünüp atomik işlemleri hesap etmeye çalışsak da gerçekten çok da gerek var mı? YAGNI You aren’t gonna need it! tam da burada işimize yarıyor. Tabii ki YAGNI hakkında daha detaylı bir makale de gelecek, hepsini yazacağım…

Sonuç

Her koşulda bu konuda tam bir fikriniz olduğunu düşünmekteyim. Artık Analysis Paralysis nedir biliyoruz, ortamlarda birisi dediğinde “hmm, evet haklısın, hmmm” diyebilecek bilgi düzeyine eriştiğimize göre. Bir Anti Pattern’i daha burada kapatmış oluyoruz.


  1. Anti-Pattern’in bu yazıda kısaltılmış hali. 
  2. Project Manager – prone yöneticisi 
  3. Peter Merel’in konuyla ilgili yazısından alınmış ve çevrilmiştir. 

Anti-Pattern: Big Project Syndrome

Uzundur anti-pattern kavramlarından bahsetmeyi planlıyordum ama malumunuz, öyle design-pattern gibi kolayca ele alınabilecek kadar kısa değiller. Bu yüzden seçip seçip yayınlamak gerek. Hatta bunun için not defterimde bir liste bile oluşturudum. Gerçi anlatmak istediğim AP bu değildi; analysis paralysis fakat ona gelmeden önce küçük bir AP’yi size anlatmam gerek.

Unutanlar için Anti-Pattern (AP) tanımı

Anti-Pattern ya da antipattern dediğimiz kalıplar aslında çoğumuzun çalışırken yaptığı, fakat işimizi kolaylaştırmaktan çok işimizi zorlaştıran işlerin kalıplaşmış halidir. Bir nevi toplumsal ortak deneyim denilebilir. Eğer bir AP’yi okuduğunuzda, “aa evet ben de bunu yapıyorum” diyorsanız, siz de muhtemelen yanlış yapıyorsunuz. AP’nin tam bir çözümü yok fakat korunmanın yolları da illa ki var :).

Tanım

Basit bir anti-pattern. Henüz tam olarak resmi bir kategorisi olmasa da ben bunu “Project Management” ile “Project Architecture” arasında bir yerde kategorize ediyorum. Tanımı ise;

Kimi zaman yönetimin baskısı, kimi zaman da kendi kararı – egosu – neticesinde programı dizayn eden kişinin, tüm dünyanın sorunlarını çözecek bir programı inşa etmeye, projelendirilmeye çalışması.

Detaylıca anlatmaya çalışırsak; şirketinizde finans, kalite ve satın alma departmanları var. Bu departmanların hepsinin ayrı ihtiyaçları var tabii ki. Biri muhabsebe programı, diğeri dokümantasyon, bir diğeri ise sipariş takip sistemi istiyor. Şirketinizdekiler de öyle bir sistemden bahsediyorlar ki, bu kudretli program her departmanın ihtiyacını yaptığı gibi ek olarak üç dört departmana daha hizmet veriyormuş. İşte bu program sizde yapılmaya çalışıyorsa ya da en azından planlanıyorsa bu Big Project Syndrome anti-pattern’inin sizde olduğunu göstermektedir.

Önlem

Önlem için önce müdürün ya da sistemi dizayn eden kişinin kafa yapısının değişmesi gerek ama maalesef bu pek ihtimal dahilinde olmadığı için, elimizden azı gelmekte. Muhtemel kurtulma yöntemi ise; Do The Simplest Thing That Could Possibly Work ki bunu bir makalede detaylıca anlatacağım. Şimdilik kısaca özetlemek gerekirse, isminden de anlaşılacağı gibi. Çalışacak en basit şeyi direk yapmak. Yani sizden üç programı da istiyorlarsa, önce hangisi basit ise onun yapılması ve sonrasında diğer işlere geçilmesi.

Maalesef bu karar sizin elinizde değil, siz basit bir yazılımcısınız. Bunun kararı maalesef sistemi dizayn eden kişide – muhtemelen müdür. Bu yüzden projenizin “Death March” adı verilen, hiç bitmeyen ve sürekli over budget olan bir projeye dönüşmesi ise an meselesi.

Her gün bir AP yazsam yine de elimdeki liste bitmez ama yazmadan da olmayacak. Eğer sizin de böyle 007 James Bond tarzı bir programınız şirketinizde yapılıyorsa yorumlarda bana katılmanızı bekleyeceğim. Bir sonraki AP’de görüşmek üzere.

Not: Bu arada ekleyecektim ama unutmuşum, sonradan aklıma geldi. Bu tip seçimler yapan kişilere Occam’ın Usturası1 ile saldırabilirsiniz;

Şeyler gerektirmedikçe çoğaltılmamalıdır! Başka bir deyişle, bir problem var ise her zaman en mantıklı ve basit olan açıklama “esas açıklama” olarak kabul edilmelidir.


  1. Occam’ın Usturası: (http://tr.wikipedia.org/wiki/Ockham’ın_Usturası) 

Anti-Pattern: Smart UI

“Anti-pattern” kavramı hakkında pek fazla bilgiye sahip olmayabilirsiniz. Açıkcası benim için de çok yeni bir kavramdı, sağolsun Nedir TV’nin bir etkinliğinde Burak Selim Şenyurt‘un verdiği bir eğitimde varlığından haberdar olmuştum. Hatta dediğine göre, ülkemizde bazı üniversitelerde ders olarak bile gösteriliyormuş. Bu konu üzerine daha çok araştırma yapınca ben de paylaşım yapmaya özen göstereceğim.

Şimdilik bu konulardan sadece bir tanesi olan Smart UI adındaki anti-pattern’i size anlatmak istiyorum, hem basit bir anti-pattern hem de sık sık yaptığımız bir şey.


Anti-Pattern Nedir?

Çoğumuzun bildiği – ya da bildiğini sandığı – Design Pattern konusu vardır ya hani, yazılım yazmayı kolay hale getiren bazı kalıpları kullanarak hem kolay hem de stabil yazılımlar yazmamız amaçlanır – genelde elimize yüzümüze bulaştırırız. İşte DP1 gibi anti-pattern dediğimiz kavramlar da bize kalıplar sunar, fakat bu kalıplar kod yazarken yaptığımız hataları kapsamaktadır. DP’nin aksine AP2 direk kod içerisinde yapılan saçma hataları ele almaktadır ve tüm yazılımı hedef almaktadır. Öyle ki AP içerisinde proje yönetiminden, user interface’e kadar geniş bir aktegori yelpazesi bulunmaktadır.

O yüzden bir anti-pattern gördüğünüzde, bu direk yapmamanız gereken bir şeyi betimlemektedir! Bu tanım sanırım olabilecek en güzel tanım.

Smart UI

Bir anti-pattern olarak Smart UI, “User Interface”(kullanıcı arabirimi) kategorisine girmektedir. Esasında daha önce bir kaç yerde araştırmama rağmen, resmi AP listelemelerinde karşılaşamadım kendisi ile. Daha çok okuduğum kitaplarda geçen bir AP. Benim gibi Asp.Net üzerine uzmanlaşmış ya da uzmanlaşan birisi iseniz bu Smart UI kesinlikle yazılım hayatınızın bir parçası oluyor, bu yüzden de buna özellikle dikkat etmemiz gerekmekte.

Tanımı

Bir asp.net projesi açtığımızda – hangi tipte olursa olsun – yaptığımız ilk şey genelde UI’ı tasarlamak oluyor. Genelde UI tarafına girmeseniz de fark etmez, sonuçta UI tarafına illa giriyorsunuz ve bu kısımı hemen bitirip diğer işlerinize geçmek istiyorsunuz. Benim gibi işviçre çakısı gibi bir yazılımcı iseniz, sınırlı vakitte maksimum kazanç sağlamak için şirket zaten size dağ kadar iş vermiş ve hemen projenin bitmesini beklemekte sizden. Siz de vakit kaybetmemek için hemen projenin içine sayfayı açıp, gerek sürükle bırak yöntemi, gerek hemen buton altına kod yazma ile fonksiyonları tek sayfanın altında yaratıyorsunuz. Sonuçta proje çalışıyor mu? – Evet çalışıyor. O zaman sorun olmaması gerek. İşte bu Smart UI anti-pattern’i.

  • Proje hızlıca bitsin site tüm fonksiyonların ilgili sayfada toplanması,
  • Fonksiyonları katmanlamak yerine tek bir yerde toplayarak başka yerlerde kullanımlarda aynı fonksiyonların yazılması ya da static değişkeni tanımlayarak projenin bütünlüğünü bozmak

Etkileri

Yukarıdaki işlem bir anti-pattern’i tanımlar. Yani projeniz çalışsa da bir hata yaptığınızı tanımlar. Bu hatanın sonucunda;

  • Kodun bakımı, sistem karmaşıklaştıkça zorlaşır,
  • Geliştirme yapacağınız zaman, unutulan sayfalarda, işe yarar kodlar kalır,
  • Katmanlı mimariye geçilme aşamasınsa vakit kaybı yaratır,

Sonuçta hızla halledeyim dediğinizde, aslında geleceğe yönelik büyük bir hata yaptığınızın farkına varırsınız. Zaten anti-patternler de bu sorunu ortadan kaldırmak için vardır.

Çözüm

Çözüm için belirli bir yol yok. Aslında çözüme geçmeden önce cevap vermeniz gereken bir tane soru bulunmakta. Bu soru;

Bu ekran ya da projenin, ilerleyen zamanlarda geliştirmesi devam edecek mi?

Eğer cevabınız “Evet” ise, çözüm bulmanız gerekmekte. Fakat cevabınız “Hayır” ise, bir çözüm uygulamanıza pek de bir gerek yok. Zira zaten gelişimi devam etmeyecek bir proje ve başka yere de bağlanmayacak, o zaman neden çözesiniz ki, sonuçta amacınız projenin çalışması. Fakat daha sonradan pişman olup da tekrar sayfayı tasarlarken bulursanız kendinizi şaşırmayın.

“Evet” diyenler için çözüm belli, “Separation of concerns3 uygulamasınız, yani “Endişelerin dağıtılması”. Bunun manası da bir design pattern ya da dizayn mimarisi kullanmanızdan geçer. Dizayn mimarileri ile ilgili daha detaylı bir makale anlatacağım, fakat örnek vermek gerekirse MVC ve MVVC birer dizayn patterndir.

İlla ki direk MVC uygulamanıza gerek yok, sonuçta kodunuzun ne kadar gelişeceği burada merak unsuru. Sonuçta sizin projeniz ve istediğiniz şekilde çözümleyebilirsiniz. Bu durumda size tavsiyem, UI katmanı içerisinde fazla fonksiyonlara yer vermemeniz ve Business ile ilgili kodları ayrı sınıflara toplamanızdır. En azından genel bir mantık kurana kadar sizi idare edecektir.

Anti-Pattern konusunda devam yazılarım olacak, şimdiden iyi boş zaman geçirmeler…


  1. Design Patterns’in tarafımdan verilen kısaltması. 
  2. Anti-Pattern’in tarafımdan verilen kısaltması. 
  3. Separation of concerns