Search Results for: iş analizi

Analist ve İş Bilgisi

İş ve İhtiyaç Analizi, Yazılım Mühendisliği , , ,

Giriş

Soru şu: Analist yani bazen iş analisti, bazen ihtiyaç ya da gereksinim analisti bazen de daha klasik bir isimlendirmeyle sistem analisti dediğimiz rol için iş bilgisi ne kadar önemlidir? “Hoppaaa! Böyle de soru mu olur?” demeyin. Ben de farkındayım, iş bilgisinin, analistin varlık sebebi olduğunun. Analistin en temel sorumluluğudur iş bilgisi, tamam da demek istediğim şeyi açıpa çıkarabilmek için şu soruyu da sorayım: Analistin, benzer şekilde iş bilgisine sahip operasyonel bir kullanıcıdan farkı yok mudur? Vardır deriz ama nedir tam olarak bu fark? Daha analitik olması, daha iyi sorular sorabilmesi, ya da iletişiminin daha güçlü olması mıdır sadece?

Analist Yetkinlikleri

Konuyu biraz açayım. Analistin yetkinlikleri 3 boyutta ele alınabilir:

  1. İş alanı bilgi ve yetkinlikleri (business/application domain knowledge and skills): Analistin çalıştığı sektördeki terimlere, süreçlere, rollere ve çıktılara ne kadar hakim olduğu, onun iş bilgisinin ölçüsüdür. Örneğin bankacılık sektöründeki bir analistin çalıştığı alt alanın krediler olduğunu düşünelim. Bu analist, kredilerle ilgili başvuru ve değerlendirme süreçlerini bilmesi, bunlarla alakalı analiz toplantılarında bulunması vb. yetkinlikler, analistin iş alanı ile ilgili yetkinliklerine örnektir.
  2. İş ve yazılım ihtiyaç analizi bilgi ve yetkinlikleri (business and software requirements analysis knowledge and skills): Analistin, formal olarak bir süreci tanımlayabilme, oradaki adımları, iş kurallarını ve aktörleri detaylarıyla belirleyebilme, detaylar arasındaki benzerlik, farklılık, çelişiklik vb. çıkarımları yapabilme, bu bilgileri bir yazılıma dönüştürebilecek şekilde daha formal ve matematiksel formlara örneğin diyagramlara dökebilme, ihtiyaçlarla alakalı önceliklendirme ve risk analizi yapabilme ve tüm bunları dokümana yansıtma yetkinlikleri.
  3. Bireysel yetkinlikler (individual skills): İletişim, ikna, sorgulama, toplantı yönetimi vb. daha yumuşak yetkinlikler (soft skills). Örneğin bir analistin iyi bir dinleyici olması, iyi not alabilmesi, hızlı ve analitik düşünüp çıkarımlarda bulunarak bir analiz toplantısında geri sorularla muhatabını yönlendirebilmesi, çatışan ihtiyaçlara sahip kullanıcılar arasında inisiyatif alabilmesi, onları yönlendirmesi ve karar verilmesini sağlayacak girdileri sunabilmesi vs. bu türden yetkinliklerdendir.

Yukarıdaki 3 farklı yetkinlik alanından hangisi sizce en önemli olandır? İş bilgisi mi, işi çözümleyebilme yetkinlikleri mi yoksa müşteriyle daha iyi iletişim kurabilme yetkinlikleri mi?

Ülkemizde eğitim ve danışmanlık vesilesiyle gittiğim yerlerde bunu devamlı gözlemliyorum. Hatta ben de, tam zamanlı çalışırken ya da sonrasında danışmanlıklarda, uzun seneler analist işe alımıyla uğraştım ve uğraşıyorum. Dolayısıyla analist işe alma ve seçme süreçlerinden haberdarım. Özellikle eğitimlerde ve seminerlerde katılımcılara soruyorum, sizin kurumunuzda hangisi daha çok öne çıkıyor diye. Örneğin, “siz buraya hangi yetkinliklerinizle alındığınızı düşünüyorsunuz?” diye soruyorum. Elde ettiğim kanı şu: Ülkemizde analist denince akla gelen en temel şey, iş bilgisidir. Tabiri caizse, işi bilmek, o sektörde senelerdir bulunmuş olmak, genel olarak bir kişiyi analist olarak tanımlamada kullanılan en temel etmendir. İkinci sırada gelen, bireysel yetkinliklerdir. Yani iletişimi güçlü mü, müşterilerle konuşurken ne kadar düzgün cümleler kurabiliyor vs. Bu iki yetkinliği bir araya getirdiğimizde, işi bilen ve iletişimi güçlü kişi, ülkemizde mükemmel analist adayıdır. Kurumlar kendi kültürlerine göre bu iki faktörden birisine daha fazla önem verebilirler. Yani örneğin bir kurum, özellikle daha az tecrübe seviyelerinde, iletişim becerileri güçlü bir adayın zekasına da güvenerek, iş bilgisini hızlıca elde edebileceğini düşünerek onu analist olarak işe alabilir.

Bu yazıyı yazdığıma göre benim de kendi fikrimi belirtmem gerekir. Bence bir analistin en temel yetkinliği, rolüne adını veren, iş ve yazılım ihtiyaçları analizi bilgi ve yetkinlikleridir. Bir analist, her şeyden önce, bir süreci nasıl ifade edeceğini, o süreçteki tüm adımları, aktiviteleri, aralarındaki ilişkileri, çıktıları, süreçte yer alan rolleri ya da aktörleri, süreçler arasındaki ilişkileri, süreçleri yönlendiren iş kurallarını vs. ortaya koymakla sorumludur. Bu yetkinlikler, tabi olarak farklı sektörlerde edinilen tecrübeyle kazanılır ama nihayetinde sektörden bağımsızdır. Bir örnek vereyim: Bir süreçte, durumu önemli olan ve farklı durumlar arasında gezen temel bir nesne var. Örneğin bir başvuru sürecinde, başvurunun pek çok duruma sahip olması, buna iyi bir örnektir. Başvuru ilk defa alınmış olabilir, ön elemeyi geçmiş, evrakları bekleniyor, son incelemede, vb. durumların birinde olabilir. Tüm bu durumların, sonlu durumlu bir makina (finite-state machine) olarak ortaya konması, yani durumlar ve aralarındaki geçişlerin detaylı olarak ortaya belirlenmesi yetkinliği, ne bir iş bilgisi ne de iletişim yetkinliğidir. Bu yetkinlik, analisti en temelde analist yapan şeydir. Böyle bir modelleme yetkinliğine sahip bir analist, herhangi bir iş alanında sonlu durum makina modellemesi yapabilir, oluşturduğu modelin tasarımda bir durum tasarım kalıbıyla (state design pattern) tasarlanmasını sağlayabilir ve nihayetinde de developerlar dahil herkes kendisine duacı olur. Çünkü böyle çok durumlu nesneler, kodlamada en problemli nesnelerdir, sebebi ise iş bilgisi çok yüksek olsa bile analistin bu durumları formal bir şekile çözümleyip ifade etmemiş ya da edememiş olması, açıkçası, ne tasarıma ne de programlamaya bir katkı sunmaz.

Nasıl her iş alanı, apayrı süreçleri ve iş kuralları olan bir alan (domain) ise, iş ve yazılım ihtiyaçları mühendisliği (business and software requirements engineering) de apayrı bir iş ve uzmanlık alanıdır. Bu alanın da kendine göre süreçleri, iş kuralları, çalışmaları ve çıktıları vardır. Bu alanın çalışanlarının da kendisine has yetkinlikleri, yaptıkları işleri ve ürettikleri çıktıları vardır.

İş bilgisini çözümleme yetkinliklerine sahip olmayan bir analist ancak postacı olur. Ya da analistlerin kafasına kazındığı şekliyle sadece “köprü” olmaya devam eder, tek yaptığı “al-ver”dir, ne çözümleyici olmak söz konusudur ne de bir katma değer ortaya koymak. Böyle ortamlarda zaten iş bilgisi de malumattan öteye gitmez, bilgi seviyesine çıkamaz çünkü. O ortamda senelerce çalışsanız bile hala aklınızdaki iş bilgisini bir başkasına aktarabilir hale getirmekte güçlük çekersiniz. Aktarsanız bile karşı tarafı zorlarsınız çünkü standart ve verimli yöntemleri kullanmazsınız. Çözümleme süreç ve tekniklerinden haberdar olmayan bir analist iğne oyası gibi malumatla uğraşır, onlar arasında kaybolur. Analistten beklenen, bir soru karşısında “hikmet” (wisdom) seviyesinde katkıda bulunmasıdır ama o ekranın şurasındaki bir arayüz elemanın üzerinden konuşur. Ondan beklenen, iki farklı durumu birbiriyle kıyaslayıp, etki analizi vs. yapmaktır ama o bunu sağlıklı bir şekilde yapamaz çünkü kafasında sistemli ilişkiler değil, malumat bulutları vardır. Ama unutmayın, buradaki temel sorun analistten ziyade, kurumdadır. Analiz çalışmalarında “analitik” olmayan bir kurum, analistinin çözümleme süreç ve tekniklerinden haberdar olmasını da isteyemez çünkü bu konuda fikri yoktur.

İş bilgisi, tabi olarak bir analist için önemlidir, sistemli bilgiyi hazmetmek çok daha kolaydır. İş bilgisine sahip bir analist daha hızlı iş yapar, daha rahat ve doğru davranır. Müşterisiyle daha rahat iletişime geçer ve ona güven verir. Ama iş bilgisi, bilgi olursa işe yarar, değilse, bir malumat yığınından ibaretse, vakit kaybettiren bir stres unsuru olur. Ve analistin yeterince teknik çalışmaması, bu malumatı sadece büyütür, bilgiye çevirmez.

İşte, bir analisti, operasyonel kullanıcıdan temelde farklı kılan şey, formal bir çözümlemeci disipline sahip olmasıdır. Analitik düşünebilen, işini gözlemleyen, baştan sonra kavramaya çalışan operasyonel çalışanların analist olmaları iyi bir şeydir, çözümleme ve modelleme tekniklerini öğrenmeleri kaydıyla.

Ülkemizdeki Durum

Ülkemizde sistemli iş bilgisi biriktiren kurumlar maalesef pek azlar. İşini en detayına kadar anlatabilecek bırakın operasyonel kullanıcıyı, iş birimi sorumlusu, müdürü bulmak bile şanstır bu ülkede. Amerika’dan ilk döndüğüm zamanlardı, ilk projelerimin birinde, sürecin sahibi olan birim müdürüyle analiz amaçlı bir araya gelmiştik. Müdür, daha toplantının başında, süreçlerle ilgili olarak analizi BT’deki programcılarla yapmamızı istemişti bizden! Zaten toplantıda bir de tecrübeli programcı vardı. Aynı kurum agile ödülleri almaya devam ediyor, şatafatlı uluslararası danışmanlık şirketleriyle 3-5 senede bir süreç çalışması yapıyor vs. Ama gidin sorun bakalım, müşteri memnuniyeti artıyor mu? Ya da bugların sayısında azalma olmuş mu? Ya da ya da developerlar, kendilerine gelen analiz dokümanlarından memnunlar mı? Örneğin şöyle tipik durumlar olur ülkemizde: Kurumlar agile metodolojilere geçtiklerini söylerler ama hala hantaldırlar, hala çıktılarının kalitesi kötüdür, hala başarı kişilerin özveriyle çalışmalarına bağlıdır, hala her yeni sürümü canlıya almak çok stresli bir iş olmaya devam eder. Neden? Formal çözümleme teknikleri gibi mühendislik disiplinin gerektirdiği işler yerine “dostlar ‘agile’da görsün” şeklinde, görüntü üzerinden iyileştirmelerle yetindiğimiz için.

Ülkemizde bu durumlardan dolayı mesela “iş analizi danışmanlığı” pek görülen bir durum değildir. Halbuki ABD’de böyle çalışan, 6 ay petrol çıkaran bir organizasyonda çalışıp, süreçlerini analiz eden, sonra bir sigorta şirketinde ürün biriminde analiz danışmanlığı yapan, sonra başka bir yerde örneğin ticari olmayan (non-profit) bir kurumda yine analiz sürecinde çalışan profesyoneller var. Çünkü, PM gibi, programcı gibi, analist olmanın en temel yetkinliklerini kendinde barındırıyor ve her ortamda bunları kullanıyor.

Ve Bir Referans

Bu noktada size, iş ve ihtiyac analizi konusunda çok iyi bir otorite olan Karl Wiegers’ın Software Requirements isimli kitabını tavsiye ederim. Kitabın 3. bölümü “Business Analyst” başlığını taşımaktadır ve bir analistin yetkinliklerini ve sorumluluklarını, kimlerle nasıl iletişimde bulunacağını, hangi geçmişe sahip kişilerin nasıl bir geçiş süreciyle analist olabileceklerini ayrıntılı olarak anlatır. Ayrıca bu kitapla beraber gelen malzemeler arsında, Türkçesini bu yazıda paylaştığım iş analisti görev tanımını da var. O tanımda, bir iş analistinin sahip olması gereken bilgiler anlatılırken, “Gerekli Bilgiler” başlığı altındaki son madde şöyledir:

“Kullanıcı temsilcileri nezdinde güvenilirlik sağlaması ve onlarla etkin çalışabilmek için, zorunlu olmamakla birlikte, uygulama alanı bilgisi bir artıdır.”

Ya da orijinal haliyle:

“Application domain knowledge is a plus, to have credibility with user representatives and be able to work effectively with them.”

Bu yazıyı okuyup da bu cümleye katılmayacak pek çok kişi olacaktır. Ama ben şunu her zaman iddia ediyorum: İş süreçlerini çözümleme formal yetkinliklerine sahip, iletişim yetenekleri iyi bir analist, herhangi bir iş alanını en çok bir senede çok iyi bir şekilde öğrenebilir, o alandaki iş sorunlarını çözebilir, çok etkin analiz toplantıları yapabilir. Yeter ki çalıştığı ortamda iş bilgisi, bölük pörçük, insanların kafalarındaki malumatlardan ibaret olmasın, derli toplu, soyuttan somuta gider şekilde, farklı formal modellerle ifade edilmiş olsun. Ama gelin görün ki, senelerdir aynı iş alanında, hatta aynı kurumda çalışan analistlerin sıklıkla bana, iş alanlarıyla ilgili olarak kaotik bir ortamda olmaktan kaynaklanan rahatsızlıklarını ilettiklerini bilirim. Dahası, böyle bir analist, fırsat verilse, sistemli çalışmasıyla, malumat yığını da olsa bu yığını, çözümleyerek, formal iş bilgisine dönüştürebilir. İş süreçleri mühendisliği (business process engineering) adı verilen böyle bir çalışma, bir kurumun en değerli olan iş bilgisini, rahatça anlaşılacak ve tekrar tekrar kullanılacak bir formata döker. Ve bu bilgi, o kurumun en değerli varlığı olur.

Son bir soruyla yazımı bitireyim: Düşme tehlikesi olan bir uçağın pilotu olarak, uçağı kurtarmak için içeride bulunan sadece 2 kişiden, bir analist ve bir developerdan hangisini aşağıya atarsınız? Bu yazıdan sonra tabi ki “developer” diye cevap vereceksiniz muhtemelen. Ben ise daha ağır olanı atmayı tercih ederdim 🙂

Toplam görüntülenme sayısı: 1632

Kod Analizi: Kurucu Kullanımı

Java , , , ,

Danışmanlık verdiğim yerlerde her zaman farklı yaklaşımlarla yazılmış kodlar görüyorum. Bu tür kodların ufkumu açtığında şüphe yok. Ama açıkçası her ufuk açmanın iyiye ve güzele doğru olduğunu söylemek zor.

Aşağıdaki kod da bu şekilde karşılaştığım kodlardan. Tabi ki ciddi miktarda kamufle edilmiş isimler içeriyor. Ama koddaki yaklaşım, arka taraftaki düşünce vs. tamamen korunmuş durumda. Kod şöyle:

public JTUser execute(RegistrationForm form, 
          HttpServletRequest request, Locale locale)    
          throws JTException {

	String uid = Utils.generateUUID();
	String salt = Utils.generateSalt(32);
	String accountId = Utils.generateUUID();

	JTUser user = new JTUser(form.getEmail().trim(), null, true, true, 
                          true, true, AuthorityUtils.NO_AUTHORITIES, uid, 
                          form.getEmail().trim(), salt, 
                          form.getName().trim(), form.getSurname().trim(), null, accountId, true,
		          true, form.getWelcomeMessage().trim(), true, new Date(), null);

	user.setStatus(JTConstants.PENDING);

	String servletPath = request.getServletPath();
	if (executeInner(form, locale, user)) {
	    auditLogDao.insert(new AuditLog(user.getUid(), user.getUsername(), Utils.getRemoteIp(), Utils.getSid(),
		               AuditType.REGISTRATION, AuditSubtype.PENDING, ResponseCode.SUCCESS, 
                               new Date(), null));
	    authenticateFastRegisterUser(form, request);
	}

    return user;
}

Bu metodu analiz etmek istersek, hem nesne-merkezli programlama hem de temiz kod gibi noktalardan inceleyebiliriz. Önce şekilden başlayıp sonra kodu yazanların sahip oldukları, en azından koda yansıttıkları anlayışa doğru gidebiliriz. Bu yüzden önce isimlerden başlayalım.

Mekanı kullanma

Yukarıdaki kodda düzgün olan nedir diye sorsam, olsa olsa “sadece paragraflar” denebilir çünkü isimlendirme bile problemli. Ama açıkçası bir kodun paragraflandırılmış olması, yani bir geliştirme aracının iki-üç tuşa basımlık bir işini meziyet olarak ortaya koymak mümkün değil. Öte taraftan JTUser kurucu ve insert metot çağrılarının, kodda hüküm süren yaklaşımdan dolayı mekanı zorunlu olarak iyi kullanamadıkları da bir gerçek.

İsimlendirme

Çoğu zaman kodu yazanların kafalarındaki karmaşıklığı verdikleri isimlerden çıkarabilirsiniz. Bu kod parçasında da execute ve executeInner metotları, bu metotları yazanların kafalarındaki karmaşıklığa bir örnektir. Biraz empati yapıp, execute metodunun Command tasarım kalıbından esinlendiği düşünülebilir. Bu durumda daha geniş bağlama bakıp hakikatten bu kalıbın kullanıp kullanılmadığına karar verilebilir. Diyelim ki Command kalıbı kullanıldı ve bu metodun bulunduğu sınıf, kalıptaki arayüzü gerçekleştiriyor ve bu yüzden metodun ismi, Command kalıbının geleneğine bağlı kalınarak execute olarak verilmiş olsun. Peki executeInner‘ı ne yapacağız? executeInner metodunun içinden çağrılan metotların isimlerini tahmin edebilir miyiz? executeIpInner, executeDahaDaInner ya da executeInner2 diye gidebilir 🙂  Bu kadar kötü ve ezbere bir isimlendirme olursa, daha fazla düşünce ve tecrübe gerektiren, daha zorlu algoritmik ve modelleme problemlerinde nasıl bir yaklaşım olabilir, tahmin etmek zor değil.

Bir diğer isimlendirme problemi de authenticateFastRegisterUser metodu için söz konusu. Bu metot hali hazırda sisteme kayıtlı olan kullanıcının hızlı olarak sisteme girmesini sağlıyor gibi duruyor. Bu durumda metot isminin authenticateFastRegisteredUser olması gerekirdi.

Yaklaşım

Bu kod parçasında temelde JTUser oluşturulup executeInner‘a geçiliyor ve dönen değer true olduğunda göre  audit bilgisi AuditLog nesnesi olarak oluşturulup, veri tabanına gönderiliyor ve user sisteme dahil ediliyor. Bu işler olurken kodda göze batan iki yer var, iki nesnenin oluşturulması. Bu iki nesne için tabi olarak ikş kurucu çağrısı yapılıyor ve bu çağrılar o kadar kötü kurgulanmış ki insan hayret ediyor. Şu çağrıya bakın örneğin:

	JTUser user = new JTUser(form.getEmail().trim(), null, true, true, 
                          true, true, AuthorityUtils.NO_AUTHORITIES, uid, 
                          form.getEmail().trim(), salt, 
                          form.getName().trim(), form.getSurname().trim(), null, accountId, true,
		          true, form.getWelcomeMessage().trim(), true, new Date(), null);

Bir kurucuya neden nesneyi doğrudan geçmek yerine parçalarını ayrı ayrı geçersiniz ki? Bu kurucuya form nesnesinin email, name, surname ve welcomeMessage alanları ayrı ayrı geçiliyor. Aslen sadece form nesnesinin geçilmesi gerekirdi. Bu durum nesne-merkezli programlamanın pek özümsenmediğini açıkça gösteriyor.

Öte taraftan, bir metoda neden new Date() ile o anki zamanı geçersiniz? İki şeyden dolayı, ya geçilen yerde o anki zamana ulaşamıyorsunuzdur,  yani kurucuda new Date() yazamıyorsunuzdur :), ya da o kadar ince hesaplarla çalışıyorsunuzdur ki, önemli olan execute metodundaki zamandır, bir nano saniye sonra JTUser kurucusundaki an işinize yaramıyordur 🙂 Açık ki burada bu iki durum da söz konusu değildir.

Başka ne gibi problemler var bu kurucu çağrısında? null geçilmesi problemdir. Üç parametre null olarak geçiliyor ve muhtemelen başka yerlerdeki aynı kurucu çağrısında null geçilmiyordur. Bu durumda da kurucuda devamlı null kontrolü yapılmalıdır. Aslen hep null geçiliyorsa bu daha büyük bir problemdir çünkü bu o nesnenin zaten bu kurucuya hiç geçilmemesi gerektiğini gösterir. Yok ilk durum geçerliyse yani bazen null geçiliyor bazen de değer geçiliyorsa bu zaten sıkıntılı bir yapı ortaya koyar çünkü null geçmek ya da null döndürmek hataya sebebiyet verir.

Kurucuya geçilen diğer üç parametre yani uid, salt, accountId, de geçilmemelidir çünkü bu üç değer zaten Utils sınıfından statik metotlarla alınabilir. Ne farkeder ki, ha orada ha burada demeyin, en az parametre geçecek şekilde kod yazmamız gerekli. Aksi taktirde bağımlılıkları gereksiz yere arttırmış oluyoruz.

Geriye bu kurucuya geçilen yedi tane true parametresi kalıyor. Bu parametreler belli ki JTUser nesnesinin belli bir durumda (state) oluşmasını sağlıyorlar. Ama bir nesnenin durumunda yedi tane boolean değişken yer alması biraz garip değil mi? Bu yedi değişken toplamda 2^7 = 128 farklı durumu temsil eder. Bu durumda JTUser nesnesinin en az 128 farklı hali var demektir. Örneğin yeni kayıt olmuş ama henüz teyit edilmemiş kullanıcı, yeni kayıt olmuş ve teyit edilmiş kullanıcı, vs. diye gidebilir. Problem şu: Her ne kadar biz metotları, onlara az parametre geçilecek şekilde tasarlayalım desek de kurucularda böyle yapmak imkansızdır. Yani kurucular nihayetinde oluşturdukları nesnelerin durumlarından sorumlu oldukları için genelde çok sayıda parametre alırlar. Bu türden kuruculara, parametrelerden dolayı uzun olduklarını ifade etmek için “teleskopik” denir. Biz yukarıda saydığımız sıkıntıları giderecek şekilde kodu tekrar yazsak bile kurucular hala çok parametre alır halde kalırlar. Örneğin JTUser kurucusunun 20 olan parametre sayısını 8’e indirmiş oluruz, ve bu hale gelir:

	JTUser user = new JTUser(form, true, true, true, true, true, true, true);

Garip değil mi? Garip olan şey bu kurucu metodun uzunluğu değil, çağrılmasındaki zorluk. Yedi tane arka arkaya gelen boolean parametrenin hangisinin ne olduğunu ve ne işe yaradığını bilmeniz gerekli. Muhtemelen bu kurucu metot şöyle tanımlanmıştır:

...

public JTUser(Form form, boolean verified, boolean authorized, boolean authenticated, ...){
   ...
}

...

Çok fazla sayıda parametre içeren metot yazmanın kaçınılmaz sonuçlarından birisidir bu durum. Normal metotlarda, metotları bölüp parçalayarak, sadece br işe odaklar hale getirip  bu durumdan kaçınabiliriz. Fakat metotların ismi olmasına karşın kurucuların ayırt edici isimleri yoktur. Ve özellikle de karmaşık nesnelerde hem pek çok kurucu vardır ama hangisinin, hem de kurucuların kendileri uzundur. Dolayısıyla hangi kurucunun çağrılacağı ve hangi parametrelerin geçileceği, zaman alan bir kodlama gerektirir ve hataya çok açıktır. Öyleyse kurucularda bu durumdan nasıl kaçınılabilinir?

Aslında bunun bir kaç yöntemi var. Örneğin yaratımsal (creational) kalıpları kullanmak. Ama nasıl bir çözüm önerilirse önerilsin yapılması gereken en temel şey, geçilen boolean parametreleri ortadan kaldırıp ya da en azından azaltıp, parametrenin rolünü metodun isminde ifade edecek şekilde kurgulanmış isimlere sahip, nesne oluşturan, gerekirse uzun isimli ama anlamlı metotlar yazmak. Eğer bu metotları ayrı bir sınıfta yazarsanız üretici metot (factory method) kalıbına varırsınız. Bu durumda bu sınıf şöyle olacaktır:

public class JTUserFactory{
	
	public JTUser produceVerifiedJTUser(...){ ... }

	public JTUser produceVerifiedJTUserUsingForm(Form form, ...){ ... }

	public JTUser produceVerifiedAndAuthorizedJTUserUsingForm(Form form, ...){ ... }

	...
}

(Üretici metot (factory method ) kalıbı için buraya bakabilirsiniz.)

Benzer ama bir başka çözüm, J. Bloch “Effective Java 2nd Ed.” isimli kitabının ilk maddesinde ifade edilmiştir. Burada tekli edilen şey, sınıfta kurucu kullanmak yerine statik factory metotlarının kullanılmasıdır. Yani yukarıdaki metotların statik olarak JTUser sınıfında olduğu durumdur. Ayrıca gerekirse bu metotları kullanmak için JTUser‘ın tüm kurucuları private yapılabilir.

Böyle bir yol izlendiğinde yukarıdaki kodumuz şu hale gelecektir:

public void authenticateUser(RegistrationForm registrationForm, 
                             HttpServletRequest request, 
                             Locale locale) throws JVTException {

   JVTUser user = JVTUser.createUnauthenticatedUser(registrationForm);

   if(authenticateUserUsingForm(registrationForm, locale, user)){
           
      authenticateFastRegisterUser(registrationForm, request);    
      
      mailSender.sendMail(user, locale);

      auditLogDao.insert(
          AuditLog.createAuditLogForUserAuthentication(user));
   }
}

Bu kodda, JTUser ve AuditLog sınıfları statik üretici metotlara sahip olacak şekilde kurgulandıklarından, nesnelerini oluşturmak createUnauthenticatedUser ya da createAuditLogForUserAuthentication gibi metotlarla çok daha rahat hale gelmiştir.

Kodun ilk halinin en berbat tarafı, sadece kötü yazılmış olması değildir. Çoğu zaman bu kodun sadece böyle yazılmış olmasına odaklanır esas problemi gözden kaçırırız. İlk haldeki gibi yazılmış karmaşık kodlar, copy-paste ile her yere dağılır. Her JTUser nesnesine ihtiyacı olan bu ve buna benzer kurucu çağrılarını, çağrıyı yapmak zor olduğundan, haklı olarak copy-paste ile alıp kullanma eğiliminde olur. Bu da bakımı çok zor bir kod yapısına götürür. Eğer bu çağrıyı yapmak için copy-paste’e başvuracak kişi, biraz akıllıca davranıp, yukarıda bahsedilen yollardan birisiyle, cut-paste kullanarak bu kodu iyileştirse (refactoring) idi çok güzel bir şey yapmış olurdu ve bu kod yapısı da iyileşerek büyürdü.

Burada kurucular üzerinden bir kod analizi yaparak nasıl daha temiz, nesne-merkezli ve bakımlanabilecek kod yazılabileceğini ele aldık. Ve yine temiz kod için iyileştirmeye (refactoring) ihtiyacımız oldu.

Rahat bakımlanabilir kodlar yazmak dileğiyle 🙂

Toplam görüntülenme sayısı: 1038

İş Kuralları – Business Rules

İş ve İhtiyaç Analizi , , ,

Bir işi analiz ederken, en önemli iki analiz bilgisi olarak süreçler ve bu süreçleri yönlendiren kurallar öne çıkar. Sürecin ne olduğunu biliyoruz, kabaca, bir işin sonuçlanması için baştan sona yapılması gereken eylemler bütünüdür. İş kuralı ise, bir iş yapılış şeklini etkileyen herhangi bir karardır. İngilizce’de “business rule” olarak geçen bu kavram bir süredir hem iş süreçlerimizi anlamada hem de yazılımı geliştirmede ve programlamada bize çok faydalı bir bakış açısı sunuyor.

Aslında anlamayı kolaylaştırmak istersek, kurallar, örneğin hayatın kuralları, futbolun kuralları gibi, özel bir bağlamda uyulması-uygulanması gereken ilkelerdir. Bu anlamda iş kuralları, bir kurumun iş yapışı ile ilgili ilkeler, yönergeler, prensipler vb.den oluşan soyutlamalardır. İş kuralları, işin parçasıdır, işi yönlendirir, karar mekanizmalarını çalıştırır ya da işi yapış şeklini kısıtlar. İş yapış şekillerindeki hesaplamalarda kullanılan algoritmalar ile katsayılar, oranlar vb. özel anlamı olan sayılar, limitler, sınıflandırmalar hep iş kurallarının farklı görünümleridir.

İş kuralları, en temelde kurum tarafından belirlenir. Kurumlar farklı tanımlar ve sınıflandırmalar yapar, belli standartlar ortaya koyar, bazı değerleri hesaplamak için kendine algoritmalar oluşturur, yetkilendirmeler yapar, örneğin şu roldekiler şunu yapabilir, şu roldekiler şunu yapamaz cinsinden ifadeler belirler. Ayrıca kanuni düzenlemeler, ilgili meslek odaları vb. sektördeki ortak aklı temsil eden kurumların yaptığı düzenlemeler, endüstri standartları, uluslararası kuruluşların koyduğu kurallar vs. hep iş kurallarının kaynaklarındandır.

Literatürde farklı iş kuralı sınıflandırmaları bulunabilir. En temelde, gerçekler, algoritmalar, çıkarımlar ve kısıtlardan bahsedebiliriz. Örneğin ‘Kullanıcılar sistemde TCKN ile temsil edilirler.” sonuçta bir gerçektir ve bir iş kuralıdır. Bir e-alışveriş sisteminde gönderme ücretinin nasıl hesaplanacağı sonuçta algoritmik bir iş kuralıdır. Benzer şekilde vergilendirme de basit de olsa algoritmik yapıdadır. Çıkarımlar ise daha çok bir noktada tetiklenen kurallardır. Örneğin yine bir alışveriş sisteminde bazı mallardan satın alanlar için diğer bazı malların indirimli olarak önerilmesi ya da bazı kredi kartlarıyla ödeme yapacaklar için belli ödeme şartlarının sunulması türünden, iş sürecinde tetiklenen durumlarda kullanılacak iş kuralları mevcuttur. Son tür ise kısıtlardır ve örneğin bir B2B ısmarlama sistemi için “C tipi üye iş yerleri 10.000 TL’den daha fazla cari hesap bulundurmazlar.” şeklindeki bir iş kuralı buna örnektir.

Çoğu zaman iş kuralları bu kadar basit olmaz, içinde pek çok şart cümlesini barındıran, karmaşık cümlelerden oluşur. Bu şekildeki iş kurallarını, atomik alt parçalarına bölmek anlaşılırlık ve yönetilebilirliklerini olumlu yönde etkiler. Örneğin, “Müşteri idsi olarak, eğer müşteri TC vatandaşı ise ya web servisten ya da formdan gelen TCKN atanır. Eğer müşteri TC vatandaşı değilse müşteri idsi olarak olarak müşteri numarası atanır. Burada da yine ya web servisten ya da formdan gelen müşteri numarası kullanılır.” şeklindeki bir iş kuralını şu şekilde, dört ayrı iş kuralı olarak düzenlemek daha faydalı bir sonuç verecektir:

  • TC vatandaşı olan müşterinin idsi, TCKNdir.
  • TC vatandaşı olmayan müşterinin idsi, müşteri numarasıdır.
  • TC vatandaşı olan bir müşterinin TCKNsi, formda gelmiyorsa, web servisten sorgulanır.
  • TC vatandaşı olmayan bir müşterinin numarası, formda gelmiyorsa, web servisten sorgulanır.

İş kurallarını bu şekilde yakalamanın bir kaç faydası vardır. En temel faydası, analiste, analiz malzemesi hakkında analitik düşünme imkanı sağlamasıdır. Süreçleri yakalarken, farklı mahiyette olan iş kurallarını ayrı ihtiyaç tipi olarak yakalamak, üzerinden tartışmak, dokümante edip, doğrulama ve testin konusu olarak kullanmak son derece faydalıdır. Bu anlamda iş kuralları, yazılım ihtiyaçlarını analitik olarak çözümlemenin en temel yollarındandır.

Yazılım projelerinin ihtiyaç analizi sürecinde iş kurallarını ayrı bir şekilde yakalamak için, iş kuralı şablonu oluşturumalı ve bulunan her bir iş kuralı şablon ile belgelenmelidir. Bu amaçla analiz toplantılarında iş kurallarını keşfetmek için ayrı sorular sorulmalı ve kurallar tüm detayıyla, tipleri ve istisnaları dahil olmak üzere, yakalanmalıdır. Analiz ilerledikçe bu şekilde çalışarak bir iş kuralı kataloğu oluşacaktır. Bu katalog, iş süreçleri kadar önemli bir kaynak olacaktır.

Bununla birlikte iş kuralları, yazılım sistemlerinin sıklıkla değişen kısımlarını oluştururlar. Dolayısıyla iş kurallarının analizde yakalanıp tasarımda bunlara özel olarak yaklaşılması önemlidir. Nihayetinde yazılım sistemlerinin değişmesini tetikleyen en temel etmen, iş süreçleri ve kurallarındaki değişikliklerdir. Dolayısıyla iş kurallarının bir analiz konusu olarak yakalanması ve sonrasında tasarımda benzer şekilde özel bir şekilde ele alınması ve bu şekilde kodlanması, sistemin değişebilirliğini olumlu yönde etkileyecektir. Örneğin iş kurallarının rahatça yönetiminin ve değişmesinin sağlanması için bir iş kuralı motoru (rule engine) kullanılması ya da iş kurallarının kod içinde hard-coded olmasının önüne geçilmesi amacıyla örneğin veri tabanında tutulması ve dinamik olarak oradan yüklenmesi ve yönetilmesi, hep iş kuralı merkezli bir yaklaşımın sonucudur.

Aslolan iş kuralları ile ilgili hem iş düzeyinde hem de geliştirme düzeyinde farkındalığa ve bir metodolojiye sahip olmaktır. Yukarıda bahsettiğim sınıflandırmalar ya da isimlendirmeler bu tür yaklaşımlara bir örnektir ama sonuçta yaklaşımlar sadece bunlarla sınırlı değildir.

Tüm dünyada ve ülkemizde, projelerin ezici çoğunluğunda analiz süreci en problemli olan süreçtir. Analiz sürecini, bir malumat biriktiren, yapısallıktan uzak bir çalışma olarak ele almak, çok sık görünen bir yaklaşımdır. İş kuralları merkezli yaklaşım ise bizi daha analitik bir iş ve ihtiyaç analizi sürecine doğru götürecektir.

Toplam görüntülenme sayısı: 2525

Programlama Nedir: Programlamanın Tabiatı ve Programcılık Üzerine – II Bilim mi, Mühendislik mi, Sanat mı Yoksa Zanaat mı?

Bilgisayar Bilimleri, Programlama, Yazılım Mühendisliği ,

Farklı vesilelerle “programlamanın neliği” hakkında konuşuyoruz, okuyup yazıyoruz. Ben de burada daha önce “Programlamanın Tabiatı ve Programcılık Üzerine – I” başlıklı bir yazı yazmıştım. Bu konu üzerine düşünen ve bizzat çalışan farklı kişiler de yazıp çiziyorlar. Örneğin arkadaşım Özcan Acar burada programcılığın sanat mı yoksa zanaat mı olduğunu tartışırken burada da bu konuda bir başka programcının yazdıklarını eleştirmiş.

Sıklıkla programlama ve programcılık, mühendis olup olmamak, okullu-alaylı vb. bağlamlarda tartışılıyor. Ben “üniversiteli mi alaylı mı” konusunu burada ele almıştım. Orada da açık bir şekilde ifade ettiğim gibi aslolan, “bilerek yapmak”tır. Yapmayı sürdürülebilir halde tutan şey bilmektir. Yapamadıkça zaten o şeyi bilmiyoruz demektir. Dolayısıyla her şart altında yapabilen ve başkalarına aktarabilen kişi, yapabilmeyi sürekli bir davranışa dönüştürmüş ve onu herkesin anlayabileceği yapıda ifade etmiş kişi, gerçekten bilendir.

Öte taraftan, gerek akademide gerek ise pratisyenleri arasında, yazılım mühendisliği olsun, onun çok temel ve belirleyici bileşeni olarak programlama olsun, tüm bunların gerçekte ne oldukları üzerine eskiden bu yana tartışmalar yapılmakta. Yani yaptığımız iş, bir bilim midir, yoksa mühendislik midir yoksa sanat mıdır yoksa zanaat mıdır? Ya da hepsi bir arada mıdır?

ABD’de yazılım sektörüne nitelikli insan yetiştiren bölümler ağırlıklı olarak “Computer Science” olarak adlandırılmalarına rağmen, bu bölümlerin yaptığı seyin ne kadar “bilim” olduğuyla ilgili şüpheler çoktur. Belki de bu isimlendirme bir öykünmedir ya da bu bölümlerin tarihi olarak Matematik’ten çıkmış oldukları düşünülerek isimlerine “science” eklenmiştir. Aslında iki kelimeden oluşan bu ismin problemi sadece “science” kelimesinden kaynaklanmıyor, esas problem”computer” kelimesinde. Dijsktra bir zamanlar “astronomy ne kadar teleskoplarla ilgiliyse, computer science da ancak o kadar bilgisayarlarla ilgilidir” (“computer science is no more about computers than astronomy is about telescopes.”) demişti.

“Computer Science” isimlendirmesi ilk defa 1959’da kullanılmasına rağmen yerine zaman zaman farklı kelimeler teklif edildi. “Datalogy” ya da “computics” bu alternatif isimlerden bir kaçı. Bu anlamda sanırım Avrupalılar daha düzgün bir isimlendirme yapmışlar. Bu alan için Avrupa’da genel olarak “automatic information” anlamlarına gelen “informatics”in türevleri kullanılıyor. Aslen yapılan iş de zaten verinin ve bilginin otomatik olarak işlenmesidir. “Computer” ya da “bilgiayar” sadece bir araç. Biz ise bu durumu dilimizde “bilgi” ve “saymak” kelimeleri ile ifade etmişiz. Başlarda, 70li yıllarda yani, bilgisayar yerine “elektronik beyin” dendiğini de hatırlıyorum ben. (Ülkemizde bu alanın “Bilgisayar Mühendisliği” olarak ifade edilmesi, hele benim üniversitemin, İTÜ, “Kontrol ve Bilgisayar Mühendisliği” gibi dahiyane bir isim 🙂 bulması ise başka bir tartışma konusu.) (Bu konudaki isimler için hızlıca Wikipedia‘ya bakabilrisiniz.)

Tanınmış ve tecrübeli bir bilim adamı olan Peter J. Denning, savunma amacıyla yazdığı “Is Computer Science Science?” başlıklı makalesinde, “Computer Science”ın (CS) ne kadar bilim olduğunu tartışıyor. Yazar makalesine alt başlık olarak şunu koymuş: “CS bilim olmanın tüm şartlarını taşıyor fakat kendinden kaynaklanan bir güvenirlik problemi var.” Yazara göre CS’i oluşturan 3 farklı disiplin vardır: Matematik, bilim ve mühendislik. Denning, CS’in, Fizik ve Kimya gibi bir “exact science” (bu terimi dilimizde nasıl ifade ediyoruz bilmiyorum, “kesin bilim” mi, bir kaç yere çevirisine baktım, “pozitif bilim” olarak karşılık verilmiş ki bu durum doğru bir çeviri değil bence) olduğunu savunuyor. Çünkü CS, adında “computer” kelimesini barındırsa da aslen bilgiyi işlemenin bilimidir. Algoritmalar ve hesaplamalı bilim (computational science) CS’i bilim yapan alanlardandır ve sayısal kesinliğe sahip çalışmalardır. Yazılımı tasarlama ve geliştirme ise temelde mühendislik çalışmasıdır. Yazar CS’in ne kadar bilim olduğu konusundaki itirazlara cevap vermeye çalışırken, “Computer Science”daki “science” yani “bilim” kısmının, diğer iki disiplin olan mühendislik ve matematikten daha geride kaldığını kabul ediyor ve ekliyor: Bu durum yakında düzelecektir.

Ben yaptığımız işin bir bilimsel tarafının olduğunu bir gerçek olarak kabul ediyorum. Programlama ve yazılım geliştirmenin son derece matematiksel dolayısıyla da bilimsel bir “hesaplama” alt yapısı var. Zaten bizim “bilgi” ve “saymak” kelimelerini yanyana getirerek ifade ettiğimiz şey İngilizce’de “computer” yani “”hesaplayıcı”dır. Veriyi ve bilgiyi işlemenin yöntemi olan her türlü algoritmik yapı, doğrudan matematiğin de konusudur. Algoritmaların karmaşıklığı, zaman ve bellek açısından ihtiyaçları, daha etkin şekilde ifade edilmeleri, tipik bir uygulamalı matematik ve sayılar teorisi konusudur. Sonuçta yazılan her program bir şekilde bir algoritmadır dolayısıyla da matematiğin ve bilimin konusudur.

Donald Knuth, programlama dünyasının muhtemelen yaşayan en ünlüsü olup, uzun yıllar Stanford’da hocalık yaptı. 1962 yılında tek cilt olarak yazmayı düşündüğü temel programlama kitabı, şu anda 4 cilt olarak yayınlanmış durumda. Hala yayınlamayı planladığı 3 cilt daha var. Knuth, programlamanın en temel kitabı olarak bilinen bu diziye, “The Art of Computer Programming” ismini vermiştir.  Çünkü Knuth’a göre programlama, bir sanattır.

Knuth gibi programlamanın bir sanat olduğunu iddia edenler, ondaki yaratıcılığa (creativity) ve bu yaratıcılığı ortaya çıkaran ilham (inspiration) kavramına vurgu yaparlar. Evet, yazılım geliştirmek de programlamak da zihinsel dolayısıyla da kavramsal, soyut ve son derece karmaşık uğraşlardır. Yazılım geliştirmenin bir sanat olduğunu iddia edenler, onun deterministic olmayan, yani başından, sonunun öngörülemeyeceği gerçeğini öne çıkarırlar. Bence de programlama, bilim ile sanatın iç içe geçtiği alanlardandır.

Mahiyeti itibariyle program yazmak ile bir film senaryosu yazmak ya da ne bileyim beste yapmak çok farklı şeyler değil. Yola çıkarken tüm detayını kestirmiş olamazsınız çünkü, ancak nereye gitmek istediğinizi bilirsiniz, hedefiniz vardır ama arasını ancak yolda anlarsınız çünkü kavramsal bir sentezlemeden bahsediyoruz. Programlama bir sanattır, çünkü doğru yoktur, aynı şeyi herkes tamamen farklı şekillerde yapabilir.

Sanatta da programlamada da çoğu kez ortaya koyduğunuz şey hiç bir zaman bir seferde mükemmel olmaz, muhtemelen pek çok yazarın, bestecinin eserlerine son halini vermeden, üzerinde senelerce çalıştıkları gibi yazdığımız programların da üzerinden tekrar tekrar geçmemiz gerekir. (Biz buna refactoring diyoruz.) Ve her bir üzerinden tekrar geçiş eserimizi daha mükemmel kılar ve bize muthiş bir haz verir. Hangimiz şöyle bir şey yaşamamıştır: Daha önce defalarca baktığınız, gördüğünüz kodunuzun öyle bir yönünü farkedersiniz ki, çok ufak bir değişiklikle örneğin müthiş bir kısaltma, hızlandırma yaparsınız ya da o ana kadar gözünüze çarpmamış bir hatasını giderirsiniz. İşte bu yaratıcılıktır, öngörülemezliktir ve böyle bir tecrübe sizin egonuzu tavan yaptırır. Belki de bu sanat ruhudur programcıları, diğer insanlar gözünde “farklı” kılan. Belki de bizi bilim adamlarından ayıran, “benimkisi daha güzel” düşüncesinin çok yaygın olmasıdır. Belki de başkalarının “ne anlıyorsun bundan” diye sorduğu durumda, o garip ifadelere bakarak sanki bir Mevlevi ayinindeymişcesine haz almaktır programlama.

Ben bu satırları yazarken Knuth’ın The Art of Computer Programming serisinin ilk cildini indirdim Internet’ten ve önsözünü okumaya başladım. Bakın ne diyor üstad:

“The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music.”

Yani

“Dijital bir bilgisayar için program hazırlama süreci çok çekicidir, (bu durum) bunun sadece ekonomik ve bilimsel olarak mükafatlandırıcı/faydalı olmasından dolayı değil, aynı zamanda bir şiir yazmak ya da müzik bestelemek gibi estetik bir tecrübe olmasından dolayıdır.”

(Bu arada bu kitabı okuyanların CVlerini Bill Gates’e gönderebilirler, çünkü kendisi bu kitabı okuyabilenlerin nasıl bir tip olabileceğini biliyor 🙂 Kaynak, Wikipedia.)

Yazılım projesi de programlama da bir sanat eseri gibi yolda nelerin gündeme geleceğini ve nihayetinde detayda neyin ortaya çıkacağını çok da bilmeden girişilen bir çalışmadır. Bilimin prensipleri vardır, halbuki sanat daha çok çalışmayla ortaya çıkar, defalarca denersiniz. Bilim sizi sınırlar, sanat ise ancak serbest kılar. Bilim var olanı açıklar, sanat ise sentezler, yeni şeyler ortaya koyar, bu anlamda bilim bulur ama sanat yaratır.

Yaptığımız işin sanatsal tarafı olduğu kesin, tamamen sanat olmadığının kesin olduğu gibi. Bilimsel tarafı olduğu da kesin, tamamen bilim olmadığı gibi. Ama aslolan, nasıl olması gerektiği. Code Complete’in yazarı Steve McConnell da bu konuyu düşünenlerden. Buradan ulaşabileceğiniz yazısında “Yazılım Mühendisliği ne olmalıdır?” sorusunun daha doğru olduğunu ifade eder ve bu soruya “mühendislik” olarak cevap verir. YMnin örneğin iş analizi son derece subjektif dolayısıyla yaratıcılığa el veren, sanatsal öğeler içerebilir, programlama kısmı gibi. Ama belli ki bu tür pek çok farklı çalışmayı bir süreç halinde ve tekrar edilebilir olarak formüle edebilmek, onu mühendislik disiplini haline getirebilmekle mümkün olabilir. Gittikçe daha hızlandırmak, daha verimli hale getirmek örneğin ve çıktı kalitesini arttırmak, böyle bir mühendislik disiplinin amacı olabilir. Böylelikle bilimsel YM süreçleri ve metotları oluşur ve bunları uygulayanlar iyi yazılım ürünleri üretirler.

Aslında McConnell’in Code Complete isimli kitabının 2. bölümünde de belirttiği gibi, yazılımda da diğer pek çok şeyde olduğu gibi metaforlar kullanırız. Bu metaforlar konuyu anlamamızı kolaylaştıran benzetmelerdir. Ve bu metaforların hiç birisi kendi başına doğru değildir. Örneğin, projelerin sonunda, canlıya geçiş sırasında çalışanların kendilerini “itfaiyeci” gibi hissetmeleri, yaptığımız işin tamamını resmetmez.

Söyle diyor McConnell:

“A confusing abundance of metaphors has grown up around software development. David Gries says writing software is a science (1981). Donald Knuth says it’s an art (1998). Watts Humphrey says it’s a process (1989). P. J. Plauger and Kent Beck say it’s like driving a car, although they draw nearly opposite conclusions (Plauger 1993, Beck 2000). Alistair Cockburn says it’s a game (2002). Eric Raymond says it’s like a bazaar (2000). Andy Hunt and Dave Thomas say it’s like gardening. Paul Heckel says it’s like filming Snow White and the Seven Dwarfs (1994). Fred Brooks says that it’s like farming, hunting werewolves, or drowning with dinosaurs in a tar pit (1995). Which are the best metaphors?”

Yani

“Yazılım geliştirme etrafında şaşırtıcı sayıda metafor türemiştir. David Gries’e göre yazılım yazmak bir bilimdir (1981). Donald Knuth ise o bir sanattır der (1998). Watts Humphrey, o bir süreçtir der (1989). P. J. Plauger ve Kent Beck ise onun bir araba sürmek gibi olduğunu söylerler, ama buna rağmen tamamen zıt sonuçlara ulaşırlar (Plauger 1993, Beck 2000). Alistair Cockburn ise o bir oyundur der (2002). Eric Raymond ise onun bir pazar yeri olduğunu söyler (2000). Andy Hunt ve Dave Thomas ise o bir bahçıvanlıktır der. Paul Heckel ise o bir “Pamuk Prenses ve Yedi Cüceler” (Snow White and the Seven Dwarfs) (1994) filmini çekmek gibidir der. Fred Brooks ise o, kurtları avlayan ya da dinazorları bir tuzakta boğan çiftçilik gibidir der (1995). Sizin en iyi metaforunuz hangisi? ”

İşte size bir kaç tartışma daha: SD Times, Jason Gorman, CodeSqueeze, Research Gate’de iki tane, 1 ve 2 ve Jonah Kagan.

Eskiler “barika-i hakikat müsademe-i efkardan çıkar” demişler, neticede kimsenin aksi fikir belirtmediği yerde hiç kimse zaten düşünmüyor demektir. Neticede düşünmek, yazarak paylaşmak ve eleştirilmek hem cesurca hem de güzel bir şey. 

Toplam görüntülenme sayısı: 1890

1 2 3 4 5 >»