Search Results for: paste

Programlama ve Kariyer

Eğitim ve Seminer, Programlama, Yazılım Mühendisliği

Mayıs ayı başında Malatya, İnönü Üniversitesi’nin düzenlediği Robocofest‘te katıldım ve “Programlama ve Kariyer” isimli bir sunum yaptım. Bu sunumun PDF dosyasına şu yazıdan ulaşabilirsiniz. Şimdi ise bu sunumu biraz daha geniş bir şekilde burada ele almak istiyorum.

Programalama nedir?

Bazı şeyleri, onları yapan, icra edenler üzerinden tanımlamak daha kolaydır. Programlama yapan kişiye programcı (programmer) denir. Peki, programcı kimdir? Programcı tabi ki kafein ve pizzayı yazılıma dönüştüren organizmadır 🙂 Bizim ülkemizde buna sigarayı da eklemek gerekir. Çünkü bekar olan ve muhtemelen bir kaç bekar arkadaşıyla aynı evde yaşayan, kariyerinin başındaki genç programcı arkadaşımızın odasına girdiğinizde hemen göze çarpacak şeylerin başında, izmaritle dolup taşmış küllükler gelir. Aynı odaya gece 2-3 gibi girerseniz dumandan programcıyı seçememe ihtimali de vardır.

 

 

Bir işi yapanı gözlemlemek o işle ilgili size çok şey anlatır. Dolayısıyla programcıları, tabi ortamlarında gözlemlemelisiniz. Programcıların kendilerine has hal ve hareketleri, çoğunlukla başkalarına garip gelir. Çok odaklı çalışırlar mesela, işin karmaşıklığı da zaten bunu gerektirir. O yüzden çalışırken rahatsız edilmek istemezler, açık ofis ortamlarında kulaklık takarak çalışmaları tam da bu yüzdendir. Bu sebepten, onların verimli çalışmalarını isteyen yöneticileri, programcıları zaman zaman aşağıdaki gibi korumaya alabilirler. Tehlikeli kimyasallarla ya da radyoaktif maddelerle uğraşanların da özel, korumalı ortamda çalışmalarından farklı bir şey değildir bu durum. Dolayısıyla bu fotoğraf

 

 

ya da bu fotoğraf,

 

 

programcılar için hiç de anormal değildir.

Peki geyiği bırakıp biraz ciddi olalım ve “hakikatten programlama nedir” diye soralım. Programlama kısaca,
• bilimdir (science),
• sanattır (art),
• mühendisliktir (engineering)
• ve zanaattir (craftmanship).

Programlama, her ne kadar harcıalem yani hemen herkesin yapabileceği, üstesinden kolayca gelebileceği bir şeymiş gibi görünse bile, aslen o kadar da basit değildir. Hayatımıza çok girmiş işleri genel olarak basite alma eğilimindeyizdir, taa ki onun içine girinceye kadar. Aslen “programlama nedir” konusunda daha önce burda bir dizi yazı yayınladım:

Bu yazılarda anlatmaya çalıştığım şey, programlamanın çok disiplinli (interdiciplinary) bir alan olduğu ve hiç bir şekilde harcıalem bir uğraşı olmadığıdır.

Yukarıda programlamanın neliği ile bu kadar uğraşmışken neden şimdi başka bir yazı yazdığımı sorarsanız eğer, burada daha çok programlamayı bir kariyer olarak gören gençlere yönelik bir kaç tavsiyem olacak. Ama bu tavsiyelerin anlam ifade etmesi ve bütünlük için için programlamanın neliğinden kısaca yine bahsetmek gerekecek.

Programlama Bilimdir.

Programlama, bilimdir çünkü programlama, matematiktir. Programlama, temelleri mantık ve cebir olan, aksiyomlara sahip, kendine has notasyonu olan bir uygulamalı matematik disiplinidir. Programlama ile genelde daima bir algoritma yazılır. İster çok karmaşık bir hesap yapın, mesela Newton Raphson yöntemiyle kök hesaplayın, ister bir sigorta poliçesinin fiyatını hesaplayın, isterseniz de KDV hesabı kadar basit bir şey yapın, daima bir algoritma yazarsınız. Grafik kullanıcı arayüzleriyle uğraşıyor olsanız ve bir düğme tıklanınca onun olayını (event) halletseniz de yazacağınız şey bir algoritmadır. Peki nedir algoritma?

Algoritma Nedir?

Tabi ki algoritma, programcıların ne yaptıklarını açıklamak istemediklerinde kullandıkları, mistik bir terimdir!

 

  • Nedir problem?
    • Algoritma abi!
  • Neden gecikti bu iş böyle?
    • Algoritmadan kaynaklanan bir problem var!

Tabi ki abartıyorum, keşke bu topraklarda iş alanı ile ilgili konuşmalarımızda algoritma vb. terimleri kullanarak formal konuşabilsek. Bizim konuşmalarımız daha çok “şu button tıklanınca falan şey gözükmüyor” tipinde, dıdının dıdısı cinsinden, hiç bir şekilde bağlamı içermeyen, detayda boğulan konuşmalardır. Bu problemin ne anlama geldiğini anlamak, başka yerlerde de olup olmayacağını ortaya çıkarmak için 2-3 soru daha sormanız gerekir! Neyse, algoritma, matematiksel bir ifadedir ve “bir işin yapılış şeklinin tarifidir öyle ki içinde iş kurallarının olduğu bir süreci barındırır” denebilir kısaca. Dolayısıyla program yazmak, algoritma yazmaktır, dolayısıyla matematiktir. Algoritmik düşünceyi daima sevmelisiniz iyi bir programcı olmak için. Bu yüzden üniversitelerde programlamayı, tipik olarak farklı türdeki algoritmalar üzerinden anlatırlar. Ama master yaparken saf algoritma dersi alırsınız, herhangi bir programlama dilinden bağımsız, sadece matematiksel, cebirsel bir faaliyet olarak öğrenirsiniz algoritmaları. Hatta güvenlik (security) vb. konularda apayrı yapıda algoritmalara odaklanırsınız.

Geyik de olsa algoritma kelimesine yüklenen “karmaşıklık” algısı aslen, her meslek gibi programcıların da kendilerine has bir dilleri olduğunu ifade etmeye yarar. İngilizce’de “sadece ehlinin bildiği” anlamına gelen “esoteric” terimi kullanılır bu gibi durumlar için. Bu topraklarda her ne kadar henüz örneğin doktorlar kadar formal ve esoterik konuşamazsak da programcılık, tamamen esoterik bir dile sahiptir. Matematiksel tabanlı olan bu esoterik dili ne kadar iyi bilirseniz o kadar iyi programcı olursunuz.

Programlama Sanattır.

Soyut oluşu ve örneğinin olmaması, yaratıcılık gerektirmesi ve yapanın kişisel özelliklerine bağlı olması, programlamayı bir sanat yapar. Programlama matematiktir dedik ama zaten matematikte de sanatsal taraf yok mudur sizce? Hemen hiç bir programlama yapısı bir diğerinin aynısı hatta benzeri bile değildir, her programlama birimi kendi başına tekildir, “unique”dir. Aynı sanat eserleri, tablolar, müzik eserleri, filmler, romanlar gibi. Dolayısıyla ciddi bir kurgu içerirler.

Programlamayı sanat görenlerin başında, bu dünyaya en çok emeği geçmiş, Stanford Üniversitesi’nden emekli, Donald Knuth gelir. Çok özel ilgi duymuyorsanız muhtemelen sadece doktora yaparken karşılaşacağınız kitaplardan olan, Knuth’un en büyük eseri The Art of Computer Programming‘in  ismi de bunu yansıtmaktadır. Knuth bu kitabında programlamadaki estetik tecrübeye de vurgu yapar.

 

 

 

 

 

 

 

 

Programcılar, yaptıkları işi tanımlarken, “aşk”, “tutku”, “bağımlılık” gibi kelimeleri çok kullanırlar. Muhtemelen, zekanın çıktısını, programlama kadar açık ve hızlı görebilen fazla meslek uğraşı yoktur. Bu yüzdendir ki normal insanlar uyanmak, programcılar uyumak için saat kurarlar!

 

Programlama Mühendisliktir.

Programlama bir problem çözme yöntemidir, programlama amaç değil araçtır. Süreçseldir, kodun geliştirilmesi, testlerinin yazılması ve çalıştırılması, dokümantasyonu vb. çalışmalar, programlamanın parçalarıdır. Bu yönüyle programlama bir mühendislik disiplinidir.

Yazılım Geliştirme Nedir?

Yazılım geliştirme, merkezinde programlamanın olduğu bir mühendisliktir. Yazılım Mühendisliği (Software Engineering), programlama yanında, analiz, tasarım, test, yönetim vb. faaliyetlere sahiptir. Fakat programlama, esas çıktıyı üretendir, dolayısıyla koskoca projedeki tüm hata, performans, gecikme vb. şeylerden hatta faturanın kesiminden bile sorumlu olan kısımdır. (Bu sebeple, mesela ülkemizde yazılım mühendisliğini programlamaya indirgeme, ya da programcılığı, yazılım mühendisliği olarak görme eğilimi çok yaygındır.) Bu yüzden programcılık cesaret ister!

 

Programlama Zanaattır.

Usta-çırak ilişkisi ile öğrenilmesi, ciddi el (ve zihin) yatkınlığı gerektirmesi ve yapanın kişisel özelliklerine bağlı olması, programlamayı, bir zanaat (craftmanship) kılmaktadır. Her zanaatta olduğu gibi programlamada da kullanılan araçlar ve iş yapış şekilleri vardır.

 

Diğer Mühendislikler Arasında yazılım Mühendisliği

Programlama da, yazılım geliştirme de çok karmaşıktır, muhtemelen mühendislikler arasında en karmaşık olandır.

 

Ama herşeye rağmen yazılım geliştirme takımının görevi, basitlik illüzyonu yaratmaktır. Belki de tam da bu yüzden programcılık ve yazılım geliştirmek ülkemizde, harcıalem bir uğraşı olarak görülmektedir.

Programcı Olmak İçin

Yukarıda anlattıklarım, belli bir bilgi temelini, zihinsel işleyişi ve nihayetinde çalışma şeklini vurguluyor. Elbette çalışma ile herkes herşeyi yapabilir, başarabilir. Ama mutlu olur mu ya da fark yaratır mı? Sanırım bu sadece çalışma ile ilgili bir durum değil, belki, sevme, tutkuyla bağlanma, uygun olma gibi kavramlar giriyor işin içine.

Bence iyi bir programcı olmak için şu özellikler düşünülmeli:

  • Farklı soyutlama seviyeleri arasında rahatça gezebilen, matematiksel bir zeka,
  • Aynı anda pek çok faktörü yönetebilen detaycı bir zeka,
  • İğne ile kuyu kazabilen bir sabır taşı ve tutkulu bir psikoloji.

Özellikle Türkiye’de, tüm bunların altından kalkabilmek için strese de dayanıklı olmalısınız. Programcılık keyiflidir ama bu ülkede keyifsiz insanlar, programcılığı eziyete dönüştürürler.

Eğer programlama konusunda, kendinizi yukarıdaki özelliklere sahip görüyorsanız, iyi bir programcı olabilirsiniz hatta olun, insanlığa katkıda bulunun. Aksi taktirde bu dünyanın sonu değildir, bilgisayar mühendisliği vb. bir bölümde okuyor olsanız bile, kariyerinizde mutlu olmak için analist, tester, ağ, veri tabanı, vb. sistem yöneticisi vb. pozisyonları tercih etmeyi düşünün.

Programlama-Yazılım Kültürümüz

Açıktır ki, ülkemizdeki programlama kültüründe zanaat tarafı ağır basmaktadır. Zanaatlarda da, ülkemizdeki programlama pratiğinde de, öğrenmede formal eğitim yerine bakıp-görerek öğrenme, problem çözmede de sistematiklik yerine deneme-yanılma ile çözme, iş yapış şekillerinde yaratıcılık yerine araçlara ve teknolojiye bağlı kalma öne çıkmaktadır. Ülkemizdeki programcıların en büyük yardımcısı copy-paste ve Google’dır. Bu anlamda programlama ve yazılım geliştirme kültürümüz, toplumsal kültürümüzün bir yansımasıdır. Bu yüzden sıradan bir programcı olmak yerine fark yaratmayı hedefliyorsanız zanaatkar olmakta ileriye gitmeye çabalamalısınız. Bu yüzden:

  • Formal eğitime muhakkak önem verin. Yani üniversite 2. sınıfta iken “Java’yı ve Android’i öğrendim, şimdi ne öğreneyim” diye sormayın. Matematiğiniz 90 ve üzerinde mi? Algoritmalar ve Veri Yapıları dersinden sınıfın en iyisi misiniz? Bu sorulara hayır diye cevap veriyorsanız sorduğunuz soru zaten yanlış bir sorudur. Hele üniversitede BM’e girdiği ilk sene, binlerce lira para vererek şehrideki bir kursa yazılıp, Windows makinanın TCP/IP ayarlarının nasıl olacağını öğrenmeyi marifet sayanlardan olmayın. İşletim Sistemleri dersinden zor geçip sonra Linux öğreneceğim diye de yırtınmayın. Linux’te komut satırında ihtiyacını giderecek kadar bir şeyler yapmak ya da yasaklarla boğuştuğumuz canım ülkemizde bir kaç IP ayarını hızlıca yapabilmek, işte tüm bunlar zanaatin ta kendisidir! Dolayısıyla Linux öğrenin ama bir Linux de ben nasıl yazarım diye hedefleyin. Algoritmaları ezberlemeyin, şunu şöyle seçseydik nasıl çalışırdı diye akıl yürütmeyi alışkanlık edinin. Temel derslere, işletim sistemleri, algoritmalar, db, network, discrete matematik, vb. çok önem verin. Formal eğitiminizi çalışırken de devam ettirin, master-doktora yapın, sertifika alın örneğin.
  • Sistemli çalışın. Sistemli çalışmak için muhakkak, temelden ileriye doğru gidin ve odaklanın. Kerat cetvelini bilmeden integrali öğrenmeye kalkmayın, öğrenemezsiniz çünkü, sadece ezberlersiniz ve başarısız olursunuz.
  • Odaklanın. Aslında odaklanmak, sistemli çalışmanın bir alt parçası ama önemine binaen ayrı bir başlık altına aldım. Çok sıklıkla görüyorum, ilgisiz pek çok konuyu abur-cubur bir şekilde öğrenmeye çalışanları. Zaten bu şekilde öğrenme de olmuyor, bilgi sahibi olmadan fikir sahibi olunuyor. İyi tanımlanmış ve özelleştirilmiş, spesifik hedeflere sahip olun.  Örneğin 3 senelik BT çalışanı, hem PM sertifikası almış şimdi de SQL eğitimi alıyor, seneye de Cisco kursuna gitmekten bahsediyor! Nedir şimdi bu? Eğer PMP, SQL ve Cisco ile bir şey başarılabiliyorsa, bunları gerekli kılan bir hedef varsa eyvallah ama aksi taktirde zaman, enerji ve zeka kaybı!

Bu türden eleştiri ve tavsiyelere, bizim sektöre katılacak gençlerden çok aslında sektörümüzün ve üniversitelerimizin ihtiyacı var, bunun çok fena şekilde farkındayım. Siz istediğiniz kadar iyi olun sektörümüz iyiyi aramıyor, iş bitiriciliğe prim veriyor. Ya da üniversiteler hatta çok daha öncesinde başlayan eğitim sistemimiz, edep-terbiye adı altında sorgulamamayı, ezberlemeyi kutsamış durumda. Dolayısıyla yurt dışına gitmeyi, gerek eğitim gerek profesyonel olarak çalışmak amacıyla oralarda bir miktar yaşamayı kesinlikle hedef edinin. Yukarıdaki tavsiyelere ne kadar uyarsanız bunu yapmak o kadar kolay olacaktır.

Programlama, keyiftir 🙂

 

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

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

Tasarım Kalıpları: – Builder (Oluşturucu) Kalıbı – I

Java, Tasarım Kalıpları, Yazılım Modelleme

Builder, GoF’un nesne yaratma kalıplarından bir diğeridir. Özellikle karmaşık olan nesnelerin oluşturulması için kullanılır. Dilimize “oluşturucu” (ya da daha yakın bir çeviriyle “binacı” ya da “bina eden”) olarak çevrilebilecek olan bu kalıbın amacıyla ilgili GoF’da şu bilgiler bulunmaktadır:

Intent: Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Amaç: Karmaşık bir nesnenin oluşturulmasını, sunumundan ayırın öyle ki aynı oluşturma süreci farklı sunumlar yaratabilsin.

Bazen bir nesneyi yaratmak, basit bir yapılandırıcı çağrısından ziyade bir süreç içinde olur. Böyle durumlarda hem nesne karmaşıktır hem de nesneyi yaratma süreci karmaşıktır. Bu türden nesneleri oluşturmak için gerekli süreç Builder kalıbı olarak modellenebilir. 

Bir nesnenin karmaşık olduğunun en temel göstergesi, çok parametre alan kurucularıdır (constructor): Telescoping constructor anti-pattern. Kurucuya geçilen parametrelerin de oluşturulması gerektiği düşünüldüğünde bu sürecin soyutlanması gerektiği açık hale gelir. Factory Method ve Abstract Factory bu problemi çözmez.  Çünkü J. Bloch’un da Effective Java kitabında söylediği gibi bu iki kalıp ta kurucular gibi büyüme (scale) probemi olan yapılardır.

Aşağıdaki sınıf diyagramını ele alalım örneğin. Bu örnekteki Computer sınıfı, böyle bir örnek için uygun karmaşıklıkta bir sınıftır. Diyagramdan da görüldüğü gibi bu sınıfın 4 tane kurucusu vardır. Bu tipten karmaşık kuruculara sahip olan sınıfların nesnelerini oluşturmanın bir yolu argüman alan kuruculardan hangisini kullanacağınıza karar verip, sırayla, geçilecek argümanları oluşturup sonrasında ise kurucunun istediği sırayla oluşturulan argümanları geçmektir.

ClassDiagram1

Computer nesnesini bu şekilde oluşturan client kod örneği şöyle olabilir:

package org.javaturk.dp.pattern.gof.creational.builder.problem;

import org.javaturk.dp.pattern.gof.creational.builder.CPU;
import org.javaturk.dp.pattern.gof.creational.builder.Display;
import org.javaturk.dp.pattern.gof.creational.builder.GraphicCard;
import org.javaturk.dp.pattern.gof.creational.builder.HardDrive;
import org.javaturk.dp.pattern.gof.creational.builder.Keyboard;
import org.javaturk.dp.pattern.gof.creational.builder.Mouse;
import org.javaturk.dp.pattern.gof.creational.builder.RAM;

public class Test {

	public static void main(String[] args) {
		Test test = new Test();
		
		CPU cpu1 = test.produceCPU();
		RAM ram1 = test.produceRAM();
		HardDrive hd1 = test.produceHardDrive();
		GraphicCard graphicCard1 = test.produceGraphicCard();
		Computer computerWithoutDisplayKeyboardAndMouse = new Computer("computerWithoutDisplayKeyboardAndMouse", cpu1, ram1, hd1, graphicCard1);
		computerWithoutDisplayKeyboardAndMouse.start();
		
		
		CPU cpu2 = test.produceCPU();
		RAM ram2 = test.produceRAM();
		HardDrive hd2 = test.produceHardDrive();
		GraphicCard graphicCard2 = test.produceGraphicCard();
		Display display2 = test.produceDisplay();
		Keyboard keyboard2 = test.produceKeyboard();
		Mouse mouse2 = test.produceMouse();
		Computer computerFull1 = new Computer("computer full", cpu2, ram2, hd2, graphicCard2, display2, keyboard2, mouse2);
		computerFull1.start();
	}

	public CPU produceCPU(){
		return new CPU();
	}
	
	private RAM produceRAM() {
		return new RAM();
	}
	
	public HardDrive produceHardDrive(){
		return new HardDrive();
	}
	
	public GraphicCard produceGraphicCard(){
		return new GraphicCard();
	}
	
	private Display produceDisplay() {
		return new Display();
	}

	private Keyboard produceKeyboard() {
		return new Keyboard();
	}

	private Mouse produceMouse() {
		return new Mouse();
	}
}

Görüldüğü gibi yukarıdaki koddaki Computer nesnelerinin oluşturulması, pek çok parametre alan ve birbirine benzeyen, dolayısıyla ayırt edilmeleri pek de kolay olmayan kurucu çağrılarıyla yapılmaktadır. Bu tip kurucu çağrılarının hataya elverişli olması bu yaklaşımın bir diğer zorlu tarafını oluşturur.

Yukarıdaki yaklaşıma alternatif olarak J. Bloch, kitabında “JavaBean” yaklaşımından bahsetmektedir. JavaBean nesneleri bildiğimiz gibi, argüman almayan kurucu çağrısı ile bol miktarda “set” metodu çağrısıyla oluşturulur. Yani client kodu şöyledir:

...
		Computer computerFull2 = new Computer();
		computerFull2.setName("computer full2");
		CPU cpu3 = test.produceCPU();
		computerFull2.setCpu(cpu3);
		RAM ram3 = test.produceRAM();
		computerFull2.setRam(ram3);
		HardDrive hd3 = test.produceHardDrive();
		computerFull2.setHd(hd3);
		GraphicCard graphicCard3 = test.produceGraphicCard();
		computerFull2.setGraphicCard(graphicCard3);
		Display display3 = test.produceDisplay();
		computerFull2.setDisplay(display3);
		Keyboard keyboard3 = test.produceKeyboard();
		computerFull2.setKeyboard(keyboard3);
		Mouse mouse3 = test.produceMouse();
		computerFull2.setMouse(mouse3);
		computerFull2.start();
...

Yukarıdaki kod parçası, teleskopik kurucu problemini daha zor bir problemle değiştirmektedir: Çok sayıda set metodunun çağrılmasının zorluğu yanında, bu sırada yapılabilecek olan eksik çağrıların Computer nesnesinde sebep olacağı durum problemlerini çözmek ciddi zaman alacaktır. Bu türden nesne oluşturan kodların copy-paste yoluyla pek çok yere dağılacağı da düşünülürse, nasıl bir problemle karşı karşıya kalındığı ortaya çıkar. JavaBean yaklaşımı ayrıca nesnenin durumunu devamlı değiştirilebilir kılmaktadır.

Görüldüğü gibi karmaşık nesnelerin tekrar kullanılabilir şekilde oluşturulmasını sağlayacak bir yaklaşım, yukarıdaki problemleri ortadan kaldıracaktır. Böyle bir yaklaşım Builder kalıbıyla mümkün olabilir. Builder kalıbıyla böyle bir problemin nasıl çözülebileceğini bir sonraki yazıda ele alalım.

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

Temiz Kod Nasıl Yazılır? – Basitlik İlkesi – II

Java, Yazılım Mühendisliği , ,

Bir önceki yazıda ele aldığımız basit kodun özelliklerine devam edelim.

Basit kodun en temel özelliği odaklı olmasıdır. Ancak sadece bir kavramı, bir işi, bir ihtiyacı halletmeye odaklanan kodlar anlaşılır olur. Bir kod ne kadar fazla şeyi bir arada halletmeye kalkıyorsa o derece anlaşılmaz olacaktır. Odaklanmak hem anlaşılır hem de kısa kodun dolayısıyla da basit kodun en temel özelliklerindendir. Odaklanmanın kendisi de odaklanılacak bir kavram olduğundan, örneğin “bir satırda neye odaklanılır”, “bir sınıfta neye odaklanılır” gibi soruları etraflıca ele almak gerektiğinden, odaklanmanın detayları sonraki yazılarda ele alınacaktır.

Basit yazılan kodun diğer özelliği olan kısa olmasıdır. Kısa kod için şu iki şeye dikkat etmek gereklidir: Odaklanmak ve budamak.

Öncelikle kısa kod, ancak içeriğinden dolayı kısadır. Yani kod ancak küçük bir şeyi ya da bir seferde sadece bir şeyi hedefliyorsa kısa olur. Kısa kod ancak hem yapılan işin küçük olması hem de bu küçük işin kısa bir şekilde yapılmasıyla mümkün olur. Yapılacak işi ne kadar küçük seviyede tutulabilirse, yazılacak kod da o kadar kısa olacaktır. Yapılacak iş ne kadar büyük ve geniş tutulursa, kodda o kadar çok şey yapılır, bu da odaklanma prensibine terstir. Burada bahsedilen “şey” ve “iş” kavramları ise nihayetinde sorumluluklardır ve odaklanmaktan kasıt da “tek sorumluluk” (single responsibility) prensibidir.

Odaklanma olmadan kısa ve anlaşılır kod yazılamaz, uzun kod yazılır, çok kod yazılır, iç-içe geçmiş, çorba kod yazılır, dolayısıyla karmaşık kod yazılır, basit kod yazılamaz.

Örneğin aşağıdaki arayüzü odaklı olarak nasıl gerçekleştirelim?

public void login(String tckn, String password) throws 
   NoSuchCustomerException,CustomerAlreadyLoggedException, 
   WrongCustomerCredentialsException, 
   MaxNumberOfFailedLoggingAttemptExceededException, 
   CustomerLockedException;

Yukarıdaki metodun arayüzündeki sıra dışı durumlardan da anlaşıldığı gibi, aslında bu metotta bir kaç farklı şey kontrol edilmekte ve bu kontrollerin hepsi olumlu sonuçlanırsa, hiç sıra dışı durum nesnesi fırlatılmayacağından, metot başarılı bir şekilde sonlanacaktır. Dolayısıyla bu metot aşağıdaki gibi yazılabilir:

public void login(String tckn, String password) throws NoSuchCustomerException, 
                  CustomerLockedException, CustomerAlreadyLoggedException,  
                  WrongCustomerCredentialsException,   
                  MaxNumberOfFailedLoggingAttemptExceededException {
    Customer customer = customerDao.retrieveCustomer(tckn);
 
    // If passwords match, customer hasn't already been locked nor logged in
    // Customer loggs in and it is now currentCustomer
    if (customer.getPassword().equals(password) & 
                           !customer.isLocked() & !customer.isLoggedIn()) {
        // Database is updated when a customer logs in.
        customer.setLoggedIn(true);
        if (customerDao.updateCustomer(customer))
        currentCustomer = customer;
        loginAttemptCount = 0;
    } else if (customer.isLoggedIn()) {
        throw new CustomerAlreadyLoggedException("Customer is already logged in. 
                                                  Please first log out.");
    } else if (customer.isLocked()) {
        throw new CustomerLockedException("Customer is locked. 
                                           Please consult your admin.");
    } else if (!customer.getPassword().equals(password)) {
        loginAttemptCount++;
        if (loginAttemptCount == Integer.parseInt(ATMProperties.getProperty(
                                                  "customer.maxFailedLoginAttempt"))) {
            customer.setLocked(true);
            customerDao.updateCustomer(customer);
            throw new MaxNumberOfFailedLoggingAttemptExceededException("Max number of 
                                                              login attempt reached: "
                                                              + loginAttemptCount);
        }
        throw new WrongCustomerCredentialsException("TCKN/password is wrong.");
    }
}

Peki sizce bu kod odaklı mıdır? Yani “login” metodu, sadece bir şeyi mi hallediyor? Aslında bakarsanız bir şeyi hallediyor, müşterinin login olmasını. Ama belli ki bu üst seviye bir sorumluluk ve alt seviyede müşterinin bulunup getirilmesi, kilitli (locked) veya zaten sistemde (logged in) olup olmadığının belirlenmesi, passwordünün uygunluğunun kontrol edilmesi ve eğer yanlış password girilmiş ve bu şekilde yanlış password girme sayısı, belirli bir değeri aşmışsa, müşterinin kilitlenmesi (locked) sorumluluklarını içermektedir. Bu durumda aslolan şey, tüm bu alt sorumlulukların ayrı metotlarda ifade edilmesidir. Çünkü, bu alt sorumlulukların her birisi, sistemde farklı yerlerde tekrar tekrar ihtiyaç duyulabilecek ve bu yüzden metotları çağrılabilecektir. Dolayısıyla bu haliyle “login” metodunun yukarıdaki gerçekleştirilmesi, odaklı değildir, “tek sorumluluk” prensibine uygun değildir.

Yukarıdaki kodun bir diğer problemi ise, ayrık olması gereken sorumlulukları bir araya getirdiği için, copy-paste yardımıyla, tekrarlı kod yazmayı teşvik ediyor olmasıdır. Örneğin, sisteme bir başka yerde ihtiyaç duyulacak ve örneğin müşterinin kilitli olup-olmadığını kontrol eden kod, buradan copy-paste ile alınarak çoğaltılacaktır.

Bakın aşağıdaki kod ise, aynı metodun farklı sorumlulukları, farklı metotlarla halleden şeklidir ve bu yüzden herşey daha odaklıdır ve sorumluluk sahibidir.

public void checkIfCustomerAlreadyLoggedIn(Customer customer) throws CustomerAlreadyLoggedException {
    if (customer.isLoggedIn()) {
        throw new CustomerAlreadyLoggedException("Customer is already logged in. 
                                                  Please first log out.");
    }
}
public void checkIfCustomerLocked(Customer customer) throws CustomerLockedException {
    if (customer.isLocked()) {
        throw new CustomerLockedException("Customer is locked. Please consult your admin.");
    }
}
public void checkCustomerPassword(Customer customer, String password) throws 
        MaxNumberOfFailedLoggingAttemptExceededException, WrongCustomerCredentialsException {
    if (!customer.getPassword().equals(password)) {
        loginAttemptCount++;
        checkLoginAttempCount(customer);
        throw new WrongCustomerCredentialsException("Wrong password!");
    }
}
public void checkLoginAttempCount(Customer customer) throws 
                                            MaxNumberOfFailedLoggingAttemptExceededException{
    if (loginAttemptCount == Integer.parseInt(ATMProperties.getProperty(
                                                           "customer.maxFailedLoginAttempt"))) {
        lockCustomer(customer);
    }
}
public void lockCustomer(Customer customer) throws MaxNumberOfFailedLoggingAttemptExceededException{
    customer.setLocked(true);
    throw new MaxNumberOfFailedLoggingAttemptExceededException("Max number of login 
                                                                attempt reached: "
                                                                + loginAttemptCount);
}
private void loginCustomer(Customer customer, String password) throws  
   CustomerAlreadyLoggedException, 
   WrongCustomerCredentialsException, 
   MaxNumberOfFailedLoggingAttemptExceededException, 
   CustomerLockedException{
		
      boolean login = false;
      checkIfCustomerAlreadyLoggedIn(customer);
      checkIfCustomerLocked(customer);
      checkCustomerPassword(customer, password);
      customerDao.updateCustomer(customer);
}

Bu şekilde sorumluluklar, ayrı metotlarda ifade edildikten sonra gerçekleştirdiğimiz metot, sadece bu alt sorumlulukları çağırır:

public void login(String tckn, String password) throws 
   NoSuchCustomerException, CustomerAlreadyLoggedException, 
   WrongCustomerCredentialsException, 
   MaxNumberOfFailedLoggingAttemptExceededException, 
   CustomerLockedException{

      Customer customer = customerDao.retrieveCustomer(tckn);
      loginCustomer(customer, password);
}

Odaklı kod yazmak, tek sorumluluk prensibine uymaktır demiştir. Bu da sorumlulukları önce bulmak sonra da ayırmakla olur. Bu anlamda, metot seviyesini düşündüğümüzde, daha alt parçalara bölünemeyecek ve sistemde tekrar tekrar kullanılacak her sorumluluk bir metotta halledilmelidir.

Yukarıdaki örnekten de açıkça görüldüğü gibi, kısa kod ancak ve ancak odaklanmakla yazılır. Bu anlamda esas amaç kısa kod değildir, odaklı koddur. Odaklı kod her halukarda kısa olma eğilimindedir. Odaklanmadan kısa kod yazmaya çalışmak, kodu okunmaz ve anlaşılmaz hale getirir. Kod, sorumluluklar tabanında bölünmeli ve yazılmalıdır.

Sınıf seviyesindeki sorumlulukların en temel olanları ise örneğin GOF’un tasarım kalıpları ile belirlenmiştir. Örneğin bu yazıda bu sorumluluklardan bazıları kısaca ifade edilmiştir. Dolayısıyla tasarım kalıplarını bilmeden sorumlulukları bulup dağıtmaya çalışmak, hem zordur hem de tekerleği tekrardan keşfetmeye çalışmaktır.

Bir sonraki yazıda budamayı ele alalım.

Son derece odaklı kodlar dilerim 🙂

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

1 2 3