Monthly Archives: Nisan 2014

Doğru bil(me)diklerimiz neler?

Dediğim gibi bir sürü boş vaktim olmasa da bir sürü boş işe harcadığım vaktim olduğu için bir çok gereksiz konuda yazı yazabiliyorum. Aynen bir sürü gereksiz yazılım yazmak gibi ama biraz daha farklı. Bus efer ki konu, esasta doğru bildiğimiz yanlışlar ile alakalı. Bildiğiniz gibi, yazılım üzerine çalışınca, yazılım hakkında bir çok diyaloğun da içerisinde oluyorsunuz. Bu yazının ortaya çıkmasında sebep aynı böyle bir tartışmaydı; **“Object Oriented Programming kullanmıyorsunuz!” lafından çıktı hepsi, beni suçlamayın onu suçlayın.

Ne Bil(mi)iyoruz?

Pek tabii ki yazılımcılar olarak biz her şeyi biliyoruz! Aksi ispat edilemez, edilecekse gelsin çıksın karşıma. Biz bu meslekte dirsek çürüttük, her şeyini biliyoruz tabii ki. Ne biliyoruz peki? OOP biliyoruz, Pattern biliyoruz, Nesne biliyoruz, Polimorfizm biliyoruz, her bir şeyi biliyoruz. Açıkcası bir kaç güne kadar ben de böyle diyordum ki, piyasadan bir üstadımız beni yerin yedi kat dibine sokuncaya kadar. Sonrasında kendime geldim, nefes aldım bir oh çektim falan.

Peki gerçekten bu terimlere hakim miyiz?

Konuşmanın biraz daha heyecanlandığı noktada, benim otomatikman muhalefete geçme gibi bir özelliğim olduğundan, konu genelde farklı boyutlara taşınır. Konuşmada arkadaşın yukarıda belirttiği OOP kullanmıyorsunuz, bir nefi bilmiyorsunuz lafı sonrasında, sinirler arttı benim. “OOP Nedir?” dedim arkadaşa, basitçe bana OOP tasarım kalıplarıdır dedi o da. Bir kere öyle değil bu işler. OOP dediğimiz, nesne tabanlı programlamadır. Yani nedir? Nesne olması gerekir, yani senin nesneler yaratman, basitçe bu nesneleri yönetecek katmanları yazman ve buna bağlı programlama yapmanı anlatır. Peki ben hiç tasarım kalıbı ya da güzel adıyla Design Pattern kullanmamışsam? O zaman ben hiç OOP kullanmamış mı olurum? Ekmeğe, şeklini verirken franzile şekil vermediysem ortaya çıkan ürün ekmek değil midir? Aynı mantıkta yanıtlanabilecek bir cümle.

Eğer sen nesnelerini oluşturup, katmanlarını koyduysan, SOLID mantığını biraz da olsun yakaladıysan o zaman zaten OOP yapmışsın ne mutlu sana. Pattern kullanmadıysan OOP yapmadın diye bir algı yok, olmamalıdırda. Pattern kullanmadım diyorsunuz da peki o konuda da emin misiniz?

Pattern olayı

Ya şimdi bir gerçek var, Design Patterns popüler olduğundan beri, herkes bu terimi kullanır oldu hayatında. Adı üzerinde, tasarım kalıbı bu, yani kalıplaşmış kod yapısı. Hiç kullanamadan adam akıllı kod yazmanız için çömez olmanız lazım, kullanıp adını bilmezseniz normal developersınızdır. Fakat insanlar sizden ismini ve cismini bilmenizi bekler. Yeni dünya diye bir meyva var, ismini tam olarak bilmem. Alırım, yerim. Tutup da sen bana bunu yerken, “hiç yeni dünya yememişsin, çok süper meyva” dersen, yemiş olsam bile yemedim psikolojisi oluşur üzerimde.

Kod açısından örnek verirsek, yıllarca data fonksiyonlarını yazdıktan sonra, datayı ele alan DAL yani Data Access Layer’ı yazarken nesnelere uygun tekil sınıflar yazdım. Yani bir tablo varsa, o tabloya data girişini sağlayan. DataTablosuBase.Save() ya da DataTablosuBase.Insert(DataTablosu _dataTablosu) kodlarını içeren sınıfı yazdım ve datalarımı öyle kaydettim. Şimdi yıllar sonra öğreniyorum ki bu yöntem Repository Pattern olarak ele alınıyormuş. Şimdi aynı konuşmada, arkadaş bana onu da dedi “Hiç pattern kullanmadan OOP yazılmaz”. Bu arkadaşı ilk arayan 20 kişiye postayla göndermeye karar verdim. Bildiğin bas baya kullanmışım işte.

Bu pattern’in üç temel prensibi var; Data erişiminde tek noktanın olması, Tablolarınızla alakalı tek bir sorumlu yer olması, Olası altyapı değişimlerinde sistemin minimum değişimle işlemesi. E ben bunu gayet yerine getirmişim, sadece “DataTablosuBase” yerine “DataTablosuRepository” dememişim. Ha bir de EF kullanmamışım ama o kontaya girersem çok olaylar çıkar.

Sonuç

Demem odur ki, asla bir insanla beraber adam akıllı kod yazmadan ona şunu yapmamışsın, bunu yapmamışsın demeyin. Yapmıştır, illa yapmıştır da bilmiyordur. Yapmıştırsın da bilmiyorsundur diyin. Bu sayede siz de o insandan biraz kod öğrenebilir, o insanla aranızı bozmazsınız. Dünya daha güzel bir yere gelir. Fakat konunun başında da dediğim gibi biz yazılımcılar her şeyi bildiğimiz için bu konuda burnu havada insanlarız. Arada bir kendinizden daha iyi olan insanlar tarafından alaşağı edilin de, kendinize gelin vallaha.

Composite Application Architecture ve Service Oriented Architecture

Bu sefer de biraz servis tabanlı mimariler üzerine bir yazı yazayım istedim. Belki bildiğiniz üzere, son zamanlarda her insan SOA demeye başladı yazılım firmalarında, fakat bu terime aşina mıyız? SOA diye bahsettiğiniz şey CAA Composite Application Architecure olmasın ya da SaaS Software as a service de olabilir. Bu terimler üzerine biraz düşmek ve aklımızda bazı şeyleri netleştimek istiyorum.

Bu yazının sonrasında detaylı olarak açıklancak şeyleri burada listeleyeyim ki sonradan açıklanmamış şeyler kalmasın;

  • CAA – Composite Application Architecture (Bileşik Yazılım Mimarisi) Nedir?
  • SOA – Service Oriented Architecture (Servis Tabanlı Mimari) Nedir?
  • SaaS – Software as a Service (Bir Servis Olarak Yazılım) Nedir?

Yukarıda belirtiğim konulara özgü detaylı makaleleri sonradan anlatacağım pek tabii ki. Şimdilik ben SOA ve CAA üzerinde durmak ve aklınızda oluşan sorulardan kurtulmak istiyorum.

CAA Nedir?

CAA dediğimiz olay bileşik yazılım mimarisini temsil etmektedir. Adından da anlaşılacağı gibi bazı temel faktörlerin, yazılım mimarisini oluştururken birleştirilmesi temeline yatar. Oluşturulan sistemin bel kemiğine Composite Solution Platform (Bileşik Çözüm Altyapısı) diyebiliriz, diğer programlar ya da programcıklar buraya bağlanır ve yönetilirler. Şöyle detaylıca anlatmaya çalışayım. Programlama temelleri üzerinden gidersek, bir programın illa birleşim yapması için service olmasına gerek yok. Her hangi bir dille yazılmış, dışarıya data verirken belirli limitasyonlar ve standartlar altında alınmış programlara Composite Application diyebiliriz. Bu programlar ister servis olsun – SOA üzerinden – ister dll olsun – CBD component based development üzerinden – bir şekilde projeye entegre olabilmelidirler.

Belirtilen entegrasyonu sağlayan bir Governance (Yönetim) altyapısı çıkar. Bu yönetim altyapısı, bileşik altyapıların entegrasyonu ve yönetimini sağlamakta ayrıca diğer programlar ile data alışverişi, mesaj alışverişi gibi kontrolleri sağlamalıdır. İstenilen dilde ve istenilen altyapıda buna uygun bir yöntem bulabilirsiniz.

Bu programlama modeli, yazılım mimarisinde üç temel noktayı ele almaktadır;

  • İşin ya da çalışmanın dizaynından tam yarar alabilmek,
  • İşin ya da çalışmanın, olabildiğince efektif evrim geçirmesine destek olmak,
  • Var olan sistemlerin yerine yenilerini yapmak yerine, onlara destek vererek tekrar kullanmak (reusability).

Kısaca bu programlama modelinde amaç; esnek, adapte edilebilir ve iş ile IT arasında yüksek oranda verim sağlayacak şekilde mimariler oluşturmak.

SOA Nedir?

Bu geyiği burada yapmazsam tabii ki kafayı yerim; One person successfully described SOA completely, and immediately died. Tabii ki böyle bir olay yok, SOA aslında anlatılabilir ve anlaşılabilir bir yapıda. SOA’nın açılımı Service Oriented Architecture, yani servis tabanlı mimari. Buradan da anlayabileceğimiz gibi, program altyapımız servisler (.net için WCF, Web Service, Web API).

Bu mimariyi kısaca özetlersek; Bir Enterprise Application geliştirdiğimizi düşünelim, CMS olur, ERP olur, HRP olur. Bu tip sistemler için daha önceden yazılmış, başka sistemlerde de kullandığınız küçük programlar olsun, SMS gönderimi, Mail SMTP sunucusu, acil durumlarda gerekli kişilere haber verecek Code Red altyapısı ya da bir Report programı. Bu programların büyük seviye programlar ile iletişime geçmesi için önce hepsini servis olarak yani entegre edilebilir, bağımsız programcıklar olarak kodlayıp, gerekli kısımlara entegre etmemiz işleminin planlanmasına SOA denir.

Daha detaylı örnek olarak ele alalım; Report servisi, düzenli olarak her hafta sonunda ilgili haftanın ilgili datalarını almak için ERP’ye HRP’e gidebilir. ERP’de HRP’de bu programın çalışması ya da çalışmaması bağımsız olacak şekilde datalarını ona verirler. Bu Report servisine bir de önemli bir rapor çıktığı için Code Red servisi bağlayabilirsiniz ki bu datanın gelmemesi durumlarını kontrol eder, eğer data gelmiyorsa Code Red sistemine bağlı SMS gönderim servisi – ki bu servis daha önceden ERP ve HRP sistemlerine bağlanmıştır – acil durum çağrısını ilgili birimlere gönderir.

Tekrar tekrar kod yazmadan ne kadar çok işlemi yapabildiğimizi görebildiniz mi? ERP ve HRP genel arayüzü oluştururken, SMS gönderim gerekli bildirimi, Reporting ise gerekli raporlamaları sağlamaktadır. Code Red ise datanın bütünlüğünü ve acil durumların kontrolünü sağlamaktadır. Bu arada yaptığımız Seperation of Concerns olayına da dikkatinizi çekmek isterim.

Lafı uzatmadan, SOA’nın dört ana maddesini de ele alalım istiyorum;

  • Sınırlarınız kesin olmalıdır.
  • Servisler özerk yapılarda, kendini idare edebilir olmalıdır.
  • Servisler schema ve contract paylaşır, class paylaşmaz.
  • Servis uyumluluğu belirli politikalarla belirlenir.

Bu dört kurala bağlı şekilde yazdığınız servisleri, birbirleri ile entegre hale getirebilir, projelerinizi genişletebilirsiniz. Daha detaylı olarak SOA kısmından daha sonra bahsedeceğim.

SaaS Nedir?

Aslında SaaS’ın konu ile hiç bir alakası yok, fakat tartışmalar sırasında insanların aklına alakalıymış gibi gelmesin diye burada bahsediyorum. SaaS yani Software as a Service olayı, bir yazılımın servis olarak sunulmasıdır. Yukarıda bahsettiğimiz SOA olayı değil, bildiğiniz ücretli ya da ücretsiz bir işlem yapan kapalı kutulardan bahsediyoruz. Online Task Yönetimi ya da Online Project Management araçları bunlara örnek verilebilir. Kendi API’leri ile diğer programlarla konuşabilirler ama bu demek değildir ki bizim SOA altyapımıza uygun olacaklar. SaaS olayını kendi içinizde geliştirirseniz bir servis olur, parayla satılan servis olmaz. Burada Türkçe karmaşası yaşıyoruz, ilk servis dediğim nokta bir iş yapan programı analtırken, diğer servis kelimesi hizmet veren programı kast etmektedir.

Sonuç

Bu yazıda biraz tanımları size aşina olması için ele almak istedim. Halen aklınızda sorular olabilir ki bu soruları Yorum kısmında yazarsanız, elimden geldiğince yanıt vermek isterim. CAA ile SOA aslında bağlantılı sistemler olmasına rağmen SOA daha kalıplaşmış bir tanıma sahiptir, CAA ise daha genel ve daha eski bir teridir. Neticesinde günümüz programlama mantığı SOA’yı bile eskitmiş olmasına rağmen, geleneksel yazılım mimarilerinden yeni kurtulan Türk Yazılım Piyasası anca SOA terimini yeni kabul etmeye başladı. Belki yıllardır kullanıyorsunuz fakat emin olabilirsiniz ki çoğu firma daha terimi ilk defa duyuyor.

SOA ve CAA konusunda daha detaylı analiz makalelerini daha sonra yazacağım, şimdilik iyi kodlamalar…

Mobili yakalamak / IsMobileDevice / 51 Degrees

Daha önce bahsettiğim mobil uygulama çilesini bilenler bilir (bilmeyenler için; Android Üzerine). Bu uygulama tabii ki her ne kadar küfretmek istesem de edemediğim bir sorunla karşı karşıya kaldı geçenlerde. Güvenli kontrol ve download istatistiği sağladığımız için belirli bir download sayfasından verilen izinli dosyaların, mobil cihazlarda indirilememesi. Ben de yeter artık diyerek, mobil gelen cihazlara direk dosyayı link olarak atamaya karar verdim ve bu sorunun daha üstesinden gelecektim ki – ayrıca bu karara 6 saatlik iş gücü sonrasında ulaştım – bir sorunla karşılaştım. .Net Bowser Request.Browser.IsMobileDevice özelliği, tabletleri yakalamıyor!!!

Sorun

Sorun belli, sisteme talepte bulunan bir cihazın mobil olup olmadığını anlamak için eklenen eklenti tabletleri yakalamıyor. Ayrıca bunun güncel olduğunu da pek sanmıyorum. Cihazın tabletde olsa neden mobil olarak algılanmasını istememin sebebi de, üzerinde o harika Android işletim sisteminin olması. Bu arada belirtmem gerekir ki; iOS aletlere hiç bir sorun yok, Android’in en güncel sürümlerinde de hiç bir sorun yok yani download yönlendirme sayfamızdan indirme yapabiliyorlar. Fakat Andorid’in eski sürümünü kullanan %35’lik bir kesim olunca ve bu arkadaşlar sürekli Play Store’a “dosyalar açılmıyor, ne kötü program” diye yazınca insan görmezden gelemiyor işte.

Çözüm 1

Baştan diyeyim bu sorunu çözmedi :D. (http://detectmobilebrowsers.com)’a girip oradan browser agent ile yakalarım ben ne olacak ki yaa dedim ben de. Demez olaydım, sonuçta Chrome tarayıcısı tablet ve desktop arayüzünde benzer agent info bilgisini kullandığı için bu ihtimal de bir çırpıda son buldu. Dedim ki media query koysam falan, gizlesem göstersem linkleri. O kadar da düşmedin sen dedim kendi kendime. Bunun üzerine araştırma yapınca bu tip dataların en güncel halinin (WURFL)[http://wurfl.sourceforge.net] denen açık kaynaklı bir DB’den geldiğini öğrendim. Fakat bunu nasıl implemente edebilirdim ki, ayrıca tek istediğim sadece IsMobileDevice yazıp, if koyup link göstermek yani gerek var mı bu karada eziyete? (YAGNI) 1

Esas Çözüm

İşte tam bu düşüncelerin arasında bir çözüm buldum 51degrees (http://51degrees.codeplex.com). Başta open source yazılan ve daha sonra paralı versiyonu da çıkan bir library. Ayrıca sadece .net için değil diğer diller için de çözümleri bulunmakta. Kurulumunu da NuGet üzerinden yapabildiğimiz için direk atladım diyebilirim. Bu arada yükleyeceğim sistem de kıçıkırık bir sistem değil, anlık responce timeların istatistiğini tuttuğumuz büyük bir ERP çözümü. Yine de seçenekleri bitince insan her yolu denemeye başlıyor.

NuGet üzerinden yükledikten sonra kendi configurasyon ayarı ve dll dosyası ile sisteme dahil olan bu çözüm üzerinde bir ayar yapmadım. Açıkcası Login yönlendirmesi ve gereksiz iki üç dosya vardı, bunları kaldırmaya ayar denemez bile. Sonuçta sistemi çalıştırdığımda her şey istediğim gibiydi. Tablette test edince yine Mobile olarak algılıyor ve her şey mükemmel çalışıyordu. Size tavsiyem bu ürünü eğer sitenizin mobil kısmını yapacaksanız kullanmanız. Zira açık lisanslı hali ile gayet güzel kullanılabiliyor.

Sadece bu özelliğe yaramayan 51degrees’in diğer özelliklerini ele alırsak;

  • ScreenWidth ve ScreenHeight değerlerini alabilmek.
  • Request.Browser.IsMobileDevice özelliğini genişlettiği için ekstra bir kod yazmamak.
  • Paralı versiyonunda IsTablet gibi bir değişkene sahip olmak,
  • Free hali ile haftada bir güncelleme geçirdiği ve bu da standart mobil cihazlar için yeterli bir güncelleme olduğundan pek de bir sorun teşkil etmemek,
  • Paralı versiyonu ile tarayıcınızın bir çok özelliğine erişmek; renkler, falan filan,
  • Paralı versiyonunda gelen kullanıcının Celluar mı yoksa Wi-Fi üzerinden geldiğini bulmak.

Açıkcası bana free versiyonu yettiği için pek de diğer özelliklerini araştırmadım. Eğer gerçekten hızlı ve sürekli güncellenen – bu arada WURFL DB’sine bağlayabiliyor ve oradan güncellenmesi sağlanabiliyor – bir sistem istiyorsanız ve Request.Browser.IsMobileDevice kodu sizi deli ediyorsa, bu tam da sizin aradığınız çözüm.

Size kafayı sıyırmadan iyi mobil kodlamalar…


  1. You aren’t gonna need it! prensibi. 

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. 

Facilitation / Kolaylaştırma

Geçen gün takip ettiğim Project Management bloglarından bir tanesinde bir yazıyı yıldıza aldığımı fark ettim. Bu yazıyı burada çevirip sizinle de paylaşmam lazım, bugün yarın ihtiyacınız olabilir. Benim gibi boş vakti bol olanların bir görevi de bu tabii ki.1

Zayıf PM’ler2 takımlarını ve kullandıkları yöntemleri kontrol etmeye çalışır. Fakat bunu yaparken işleyişin doğal düzenine müdahale edip daha kaotik bir ortamın ortaya çıkmasını sağlarla. Ekibin işleyişi kendi kendine evrimleşip olgunlık kazanmalıdır. Eğer PM sürece müdahale eder ya da onu kontrol etmeye çalışırlarsa, proje genelde başarısız olacaktır.

Erdemli PM, proje takımı içinde ne olduğuna güvenmeyi öğrenir. Eğer bir suskunlık var ise onun büyümesini ve ortaya çıkmasını sağlar. Eğer bir fırtına var ise, onun köpürmesini ve böylece kendi kendine sönmesini sağlar. Eğer takım bir şeylerden mutsuzluk duyuyorsa bunun çözümünü bulur. Erdemli PM, dağılan iş sürecini rahatlatır, kolaylaştırır. O, olaylar derinlemesine etki bırakmadan nasıl işlerin düzeltileceğini bilir.

Maalesef erdemli PM, Türkiye şartları içerisinde pırlanta değerinde ve bir o kadar da bulunması zor bir nesne. Yetişmesi için bulunması gereken ortam da maalesef burada yok. Belki öncesinde bir kaç defa fail olması lazım ki öyle Erdemli PM olabilsinler.


  1. Kaynak (http://thetaoofpm.blogspot.com.tr/2014/03/58-facilitation.html) 
  2. Project Manager (Proje Yöneticisi) 

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ı) 

Layer Supertype Pattern

Süperli müperli şeyler görünce heyecanlanmıyor değilim.

Nedir?

Martin Fowler’ın1 kim olduğunu bilmiyor olabilirsiniz, fakat ismini kesin bir yerlerde duymuşsunuzdur. Kendisi, şu an için pek hakim olamadığımız “Patterns of Enterprise Application Architecture”(İleri Seviye Yazılım Mimarisi Kalıpları) kitabının yazarı, bir nevi ortamların ağalarından bir tanesidir. Kendisini araştırın derim.

Martin Fowler’ın PoEAA2 kitabında bahsettiği kalıplardan bir tanesi olan Layer Supertype’a bakalım istedim bugün. Güzel bir kalıp ve çok da işe yarıyor, şahsen büyük bir programda kullanma fırsatım olmadı ama sizin imkanınız olabilir, ben de ekleyeceğim ilk fırsatta kendi programlarıma.

Fowler der ki; Kendi katmanında bulunan tüm tipler için bir süpertip oluşturan tip.

Kısaca açıklama çalışırsam; Bir katmanda birden fazla tip – diğer adıyla Entity – kullanıyorsanız ve bu entitylerde ortak olan noktalar var ise, tüm bu entitylerin türeyeceği bir tip yaratın ve bu ortak noktaları oraya yerleştirin.

Bir daha yazayım; Kendi katmanında! Ayrıca bir katmanda birden fazla Supertype olması gayet doğal, rahat olun agalar.

Hangi Durumlarda Kullanılır?

Yukarıda açıklamaya çalıştığım gibi birden çok Entity içerisinde kontrol etmeniz gereken bir durum var ise bunun için bir BaseEntity oluşturup, tüm Enity’leri buradan oluşturursanız, kontrol fonksiyonlarını tek bir süpertip’e vermiş olursunuz.

Örnek verecek olursa; ID alanının boş geçilmemesi her Entity için olabilecek bir şeydir. Genelde de zaten bu örneği verirler ya kıl olurum. Neyse, ID’nin boş geçmemesi için bir ID kontrol’ü yapan Supertype oluşturabilirsiniz.

Aslında anlatılmak istenen durum, bu ID alanının boş olmaması için gerekli küçük Framework’ün yaratılması için gerekli altyapının hazırlanmasıdır. Filozof gibi adam bu Fowler, zira PoEAA’da bu konuda pek bir şey de yazmamış, “kolay ya, ben hep yabıyom” demiş.

Uygulama

Hiç bir zaman şu kod örneklerini, diğer insanlar gibi vermemek gibi bir huyum olduğu için ben ID değil de, kendi kullandığım, Datanın Silinmemesi3 ilkesine göre bir örnek kod oluşturacağım. Bu arada bu kod kopyala yapıştır ile çalışmayabilir, zira direk düz metin olarak yazıyorum pseudo gibi algılayabilirsiniz.

Diyelim ki bir proje geliştiriyoruz, bu proje ne olursa olsun ben her Entity objem için DB’de IsActive, CreatedBy, CreationDate alanlarını tutarım. Bu alanlarım her Entity için var ise, neden bir Supertype yapmayayım ki?

namespace MyProject.Model
{
    public abstract class SuperEntity
    {
        private DateTime _createdDate; // Kontrol edilecek alan
        private IList<string> _errors = new List<string>(); // Hata içerikleri
        private bool _dateEntered = false; // Data girildi mi ki?

        public SuperEntity()
        { }

        public DateTime CreatedDate
        {
            get { return _createdDate; }
            set {
                if (_dateEntered)
                    BanaTarihHatasiVer();

                _createdDate = value;
                _dateEntered = true;
        }

        private void BanaTarihHatasiVer()
        {
            throw new ApplicationException("Yaratılma tarihi bir kere atandıktan sonra değiştirilemez!");
        }

        public bool IsValid()
        {
            ClearBusinessErrors();
            CheckErrors();
            return _errors.Count() == 0;
        }

        private void ClearBusinessErrors()
        {
            _errors.Clear();
        }

        protected abstract void CheckErrors();

        public IEnumerable<string> GetBusinessErrors()
        {
            return _errors;
        }

        protected void AddError(string error)
        {
            _errors.Add(error);
        }
    }
}

Buradan bir SuperEntity oluşturduk, şidmi diğer Entitylerde uygulamasına bakalım bunun;

namespace MyProject.Model
{
    public class News : SuperEntity
    {
        public News() { }

        public string Yazar { get; set; }

        protected override void CheckErrors()
        {
            if(String.IsNullOrEmpty(Yazar))
                base.AddError("Yazar olmadan haber mi olur?");
        }
    }
}

Kullanımını yapabilirsiniz.

Şimdi biz ne yaptık?

1- news.CreatedDate alanı için bir kere değer girildi mi, bir defa daha girilmesini elgelledik.
2- Hata kontrol sistemi entegre ettik. Yani news.Yazar alanı eğer boş geçilmişse, news.IsValid()bize o entity için boş geçilmiş, doldurulması zorunlu alanları verdi.
3- Ayrıca ortak olan fieldleri de bir supertype içine koyarak, mapping işlemleri için kolaylık sağladık.
4- Entity objemiz böyle sade bir entity oldu, içinde tekrar eden fieldler ve bunlar için kod olmadı, okunabilir oldu.

Aynı işlemi daha da genişletebiliriz, IsActive ve CretedBy alanlarını ekleyebilir. Tüm üç alanı, Error kontrolüne sokabilirdik.

İşte bu da bir yazılım kalıbı arkadaşlar, kullanıp kullanmamak tabii ki elinizde, fakat ben ilk gördüğümde gözlerim fal taşı gibi açılmadı diyemem. Darısı sizin başınıza.


  1. Martin Fowler Wikipedia 
  2. Patterns of Enterprise Application Architecture 
  3. Daha sonra detaylıca anlatacağım!