Herkese selam,
Bu günlüğü daha rahat takip etmek için yandaki sütuna bir abonelik formu koydum. Bu formu doldurup sonra da size gelen emailden teyit yaparak günlükte yayınlanan yazılara emailinizle abone olabilirsiniz. Her yeni yazı yayınaldığında, yazının başlığı ve linki, verdiğiniz emaile otomatik olarak gönderilecektir.
Beni takip ettiğiniz için teşekkür ederim.
Akin
Toplam görüntülenme sayısı: 1177
Akin Java, Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği
Design Pattern üzerine eğitim verdiğim bir grup arkadaştan bir tanesi sağ olsun üşenmeyip eğitim ile ilgili aldığı notları benimle paylaştı. Ben de bu notlar üzerinden giderek sizlerle, hem eğitim hem de tasarım şablonlarını ögrenme üzerine bir şeyler paylaşmak istedim.
Arkadaşımın notlarını, noktasına, virgülüne dokunmadan, kendi izni ile yayınlıyorum:
Eğitimdeki Pozitif Yönleriniz
1. Design patternlar konusunda tam ve donanımlı bilginiz.
2. Design patternlardan once object oriented principlelar ile başlayıp temeli güzelce vermeniz.
3. Ödevler vermeniz, ve bir gun sonra takip etmeniz. bu mutlaka olmalı derse katılımı ve disiplini artırıyor.
4. yazılımcılar arasındaki konuşmaların çözüm tartışmalarının tasarım şablonu ismi vererek soylemenin ne kadar büyük bir soyutlama saglayarak kaliteli bir komuşma oldugu soylediniz. bence bunu mutlaka her egitimde soylemelisiniz, yazılımcıları bu yonde teşvik etmek için.
Olursa daha güzel olabilecekler.
1. her zaman ayakta olmayabilinir ama dinleyenlerin koptuğunu gördüğünüz an ayağa kalkıp anlatabilirsiniz.
2. sunum cihazi ya da kullandıgınız bilgisayardan olabilir, bazı seyler okunabilir degildi sunumda. egitim oncesi bunlar ayarlanabilir.
3. ister istemez bazı kişiler dersde pasif kalabiliyorlar. derse katılım saglamayanlara karsı strateji geliştirebilirsiniz, derse katılıp dersden kopmasın diye.
4. Programınız 5 günlük için bence uygun. Ama bizim gibi 4 ya da 3.5 gün alacaklar için önem derecesine göre bazı patternlara önem verip bazıları ise sona bırakabilir bazılarını ise sadece bahsedip geçebilirsiniz. 3.5 ya da 4 gun için sizin çıkarıp eğitim alacaklara eğitim öncesi vereceğiniz bir program olabilir.
5. Bir tane sunum dosyasında tüm patternlara ile ilgili uml diagramlarni koyabilirsiniz anlatırken kolay erişim olur. Bu sunum dosyasında herbir pattern için sizin örneğinizin,head first ün ve Özcan acar in ayrı ayrı uml diagramlarni konulabilir. “
Ben de değerlendirmeye “Eğitimdeki Pozitif Yönleriniz”deki ilk maddeden başlayayım. Tasarım kalıpları bilgi ve tecrübesi, ne pratik dünyada çalışmakla ne de sırça saraylarda kutucuklar seviyesinde düşünülerek kazanabilecek bir yetkinliktir. Evet tasarım kalıplarını kavramak için soyut düşünce gücüne çok ihtiyaç vardır ama uygulamalar arasında kodlarla boğuşmadan sadece soyutlama gücüyle ancak uygulanamaz düşünceler geliştirilebilir. Benzer şekilde, yapılan işler ve yazılan kodlar üzerine soyut seviyelerde düşünemeyen, tümevarımsal çıkarımlarda bulunamayanlar da ancak kodlarla boğuşmaya devam ederler. Eğer ben bu konuda yetkin isem bilin ki bu duruma, soyut düşünce kabiliyetlerimi destekleyecek şekilde matematiği, felsefeyi sevmem, yazılım tasarımı ve mimarisi üzerine düşünmem ve uygulamalarda bulunmam yanında hala kod yazmam, iyi kötü pek çok kodu review etmem ve eğitim vererek kendimi bu konularda daima zinde tutmaya çalışmamla geldim.
Bu ülkede soyut düşünce kabiliyetleri yüksek çocuklar tabii olarak var ama pek çoğu “bu matematik bizim ne işimize yarayacak” sorusunu aşamıyor, aşmasını sağlayacak bir eğitimden de geçemiyor. Aşabilecek olanları önce ilk, orta ve lise eğitimimiz, hala direniyorsa üniversite eğitimimiz, örneğin İTÜ, hallediyor zaten. Yetmediyse, hala o doğuştan gelen düşünce gücünü kendisinde bulanlar için yazılım endüstrimiz karabasan gibi çöküyor üstüne genç yaşında insanın. Dolayısıyla, satır aralarında, debuggerla boğuşarak seneler geçiyor, sağına gitse ağaç, soluna baksa ağaç görüp de ormanda olduğu sonucunu çıkaramayan, detayda boğulan kişiler oluyoruz.
İkinci maddedeki gerçeklik şu: Sağlıklı bilgilenme, nasıl alttan yukarıya doğru, temellerden başlayıp sistematik olarak ileri konulara doğru gidiyorsa, sağlıklı bir tasarım kalıplarını eğitimi de işe öncelikle, yazılımın en temel özellikleri olan karmaşıklık ve değişimi anlayarak başlamalıdır. Böyle bir eğitim karmaşıklık ve değişim yönetimini nasıl yapabileceğini, birliktelik (cohesion) ve bağımlılık (coupling) kavramlarını son derece pratik örnekler ile ele alarak anlatmalıdır. Ve nihayetinde tek sorumluluk, yerine geçebilirlik, compositonu miras devralmaya tercih etme, değişime kapalı ama genişlemeye açık olma (single responsibility, substitubility, prefer composition over inheritance, closed for modification open for extension) gibi prensipleri yine pratik bir şekilde katılımcıya kazandırmalıdır ki tasarım şablonlarına zihin hazır hale gelsin.
Bu tipten eğitimlerde teoriyle pratiği dengede tutmak çok önemlidir, ikisi de birbirine kurban edilmemeli. Karmaşıklık kavramını ne zamandır düşünüyordum örneğin, eğlenceli bir şekilde nasıl anlatırım diye, sonunda onu da muzikle anlatmaya karar verdim 🙂 Sanırım ilk uygulamam başarılıydı. Sonrası zaten bu prensipler üzerine rahatça bina edildi.
Ödev başarılı oldu çünkü sınıf genel olarak istekliydi, yönetici arkadaşımızın da yönlendirmesiyle, akşam bazı okumalar ya da çalışmalar yapıp ertesi gün derste tartışmak müthiş güzel oldu.
İyi eğitim alan insanlar olmamıza rağmen, genel dili kullanmada, var olan kültürü ister istemez uyuyor ve çok teknik konularda bile çok özensiz ve sanki pazarda karşılaştığımız birisiyle sohbet ediyormuşcasına konuşuyoruz. Tasarım kalıpları, bize sadece bir düşünme yöntemi öğretmekle kalmıyor aynı zamanda dilimizi de dönüştürüyor. Tasarım kalıpları ile artık cohesion, coupling, state, interface, implementation, delegation, strategy, command vb. kavramlar üzerinden düşünüp konuşmak, çok daha kesin ve anlaşılır bir dille derdimizi ifade etmemizde bize çok faydalı oluyor. Tabi ki karşı tarafın da böyle bir kültürü olduğunu kabul ediyoruz.
Yazılım projelerindeki teknik insanların konuşmanalarındaki ifade gücü, sokaktaki insanlarınkinden çok daha yüksek olmalı ki anlaşmamız için illa kod yazmaya gerek olmasın. Analiz, tasarım, kodlama ve test safhaları için geçerli bir durum bu. Ben sadece tasarım şablonları eğitiminde değil, her türlü faaliyetimde buna önem vermeye çalışıyorum. Böyle davranmanın zaman zaman ukela yaftası yeme riski yok değil, farkındayım. Ama sanırım samimiyet bunu da aşıyor.
Gelelim, arkadaşımızın büyük bir nezaketle “olursa daha güzel olabilecekler” diye nitelediği taraflara:
1- Doğru, sınıfa hakim olmak için hareket şart. Bu bazen ayağa kalkmak, bazen ters bir soru sormak, bazen de iyi bir espri yapmakla başarılır. Tüm bunları doğru karışımla harmanlamak önemlidir.
2- Kahretsin!!! Retina display Mac’ime uyumlu bir projektör bulmakta zorluk çekiyorum hep 🙂 Bundan sonra projektörümü de yanım da mı gezdirmeliyi yani 🙂
3- “Derse katılım” meselesi, evet öğrenciler kadar eğitimcilerin de sorumluluğu. Açıkçası bu gibi durumlar için kendime örnek aldığım kişi, Cem Yılmaz. Pek fena da sayılmam sanırım, çünkü çok değişik vesilelerle insanlar bu durumu ifade ediyorlar. Ama her şeye rağmen, derse makinasız gelen, kollarını göğsünde bağlayıp, tavır olarak, “ben derse katılmayacağım” diyen kişiler için henüz, onlara özel espri yapmak dışında bir formül geliştiremedim. Lisede ya da üniversitede hoca olsaydım belki ama yaşı 30’u geçmiş kişilerde bu durumu aşmak için aşırı gayret göstermek riskli ve yorucu geliyor bana.
Katılım durumunun, tamemen o kurumun kültürüyle alakalı olduğunu düşünüyorum. Kurumundan, pozisyonundan, yaptığı işlerden memnun olmayan kişilerin 5 gün eğitim boyunca bir tek soru sormadan ve alaka eseri gostermeden eğitimi tamamladıklarını ve sonunda da değerlendirmelerinde benim konuyu bilmediğimi iddia ettiklerine geçmişte şahit oldum ben. Bu gibi ortamlar konusunda kamu-özel sektör ayırımı da çok geçerli değil bence. Geçerli olan şey, bence liderlik. Özel sektörden ya da kamu kurumlarından, birden çok eğitim verdiğim yerlerde, farklı sınıfların son derece farklı davranışlar gösterdiğini biliyorum. Farklılığın o gruptaki insanlar arasindaki liderlik, muhabbet, güven vb. etkenlerden kaynakladığını çok sık gözlemliyorum.
4- GoF’da 23 pattern var ve bu patternların hepsini ele almak, katılımcıların da ciddi örnekler yapmasını sağlamak ancak 5 gün yani 30 saatlik bir eğitimle mümkün olabiliyor. Aksi taktirde önceliklendirme önemli hale geliyor.
5- Bu doğru. Ben kendi örneklerimin UML class diyagramlarını çizmeye başladım. Her derste tahtaya ayrı ayrı çizmektense standart çizimler üzerinden anlatmak çok daha güzel oluyor.
Evet değerlendirmeleri değerlendirmem bu kadar. Keşke her eğitim sonrası böyle verimli, cesaretlendirici ve yönlendirici değerlendirmeler alabilsem.
Toplam görüntülenme sayısı: 1096
Akin Yazılım Mühendisliği Design, Java, pattern, tasarım, tasarım desenleri
Yazılımın en temel iki özelliği, karmaşıklık ve değişmedir.Yani yazılım ürünleri aşırı karmaşık ve çok sık değişmesi gereken yapıdadırlar. F. Brooks, “No Silver Bullet” isimli makalesinde, yazılımın asli (essential) özelliklerinden bahsederken, diğer iki özelliğinin yanında (görülemezlik (invisibility) ve uyumluluk (conformity)) karmaşıklık ve değişebilirlikten bahseder. Görülemezlik ve uyumluluk özelliklerini, karmaşıklığın ve değişebilirliğin sebeplerinden birer tanesi olarak görürsek, “yazılım asli olarak karmaşık ve değişebilirdir” diyebiliriz.
Yazılım, soyuttur, kavramsaldır, görünmezdir, dolayısıyla anlaşılması ve anlatılması zordur. Yazılımın genelde örneği yoktur; aynı türden yazılım olsa bile farklılıkları çok fazladır, dolayısıyla birinden diğerine geçiş yapmak ya da birinden diğerini türetmek imkansızdır. Çünkü yazılımın bileşenleri kendi başlarına özeldirler, benzerleri yoktur. Bu anlamda yazılımda aynı “şey”den (satır, blok, metot, sınıf, dosya, modul, vs.) iki tane olması istenmeyen bir durumdur. Zaten eğer iki şey benzer ise birleştirilirler. Tekrar kullanılabilirlik bu yüzden son derece zordur. Dolayısıyla yazılımların büyümesi var olan bileşenlerin büyümesiyle değil de yeni ve orijinal bileşenlerin eklenmesiyle gerçekleşir.
Yazılım sistemlerinin bütün durumlarını (state) düşünmek, elde etmek, test etmek, dokümante etmek vs. imkansızdır. Çünkü, soyut kavramların durumlarını belirlemek genel olarak ya çok zordur ya da imkansızdır.
Yazılımların bileşenleri arasındaki ilişkiler de doğrusal (linear) değildir. Fiziksel dünyada, sistemler fiziksel kısıtlarla çevrelendiğinden, alt sistemler ve parçalar arasındaki ilişkileri kontrol altında tutmak mümkündür. Örneğin, bir aracın kasasının, tekerleklerle olan bağlantısı, son derece basit, standart ve akıllıca tanımlanmıştır öyle ki bu standartlara her araç ve jant üreticisi uyar; böylece aracınızı nereden almış olursanız olun, istediğiniz yerden jant ya da lastik alıp, aracınıza takabilirsiniz. Aracınızın tekerleklerini değiştirmek, sileceklerde ya da akaryakıt filtresinde bir etkiye sebep olmaz. Yazılımda durum nasıldır? Yazılım sistemlerindeki karmaşıklık öylesine büyüktür ki aynı karmaşıklığa araçlarda sahip olsaydık muhtemelen bir tekerleğin çalışmasını anlamak için bujiden tutun da sileceklere, kaportadan tutun da antene kadar pek çok şeyi anlamamız gerekecekti.
Benzer durum değişim için de geçerlidir. Son derece karmaşık yapıdaki yarış arabalarının bir yarış esnasında dört tekerleğini değiştirmek 15-20 saniyede yapılabiliyor. Benzer karmaşıklıktaki bir yazılımın, tekerleğe karşı gelen, benzer büyüklükteki bir modülünü bırakın tamamen değiştirmeyi, böyle bir yazılımın en basit bir tarafıni bile değiştirmek günler hatta haftalar sürebilir. Karşılaştırma yapmak zor, farkındayım, ama uğraştığımız alanın kendine has özelliklerini anlamak ancak böyle kıyaslamalı örneklerle mümkün oluyor. Bu anlamda eğitimlerde çok sıklıkla tekrarladığım bir örneğim vardır: “Geçenlerde arabamın lastiklerini değiştirttim. Sonra yolda geri dönerken yağmür yağmaya başladı ve silecekleri çalıştırdım. Ama baktim ki silecekler çalışmıyorlar. Ne olabilir diye düşünürken aklıma lastikleri değiştiren ustayı aramak geldi. Belki orada bir şey olmuştur diye düşündüm. Usta da bana, ‘evet Akin abi, lastikleri değiştirince ilk bir – iki saat silecekler çalışmaz’ dedi.” Böyle bir şey yaşasak herhalde ustam şaka yapıyorsun değil mi deyip karşılıklı gülerdik. Peki böyle bir durum bir yazılım sisteminde olsa, hiç bir yazılımcıyı hiç şaşırtmaz ama. Çünkü, yazılımın parçaları arasındaki bu türden, kontrolsüz bir şekilde kurgulanmış ilişkiler o kadar yaygındır ki, aksini düşünmek zordur.
Fiziksel dünyada değişimi kolaylaştırmak amacıyla, sık değişecek şeyler kolay değişecek şekilde tasarlanmışlardır. Değişmesi zor olan parçalar genelde pek de sık değişmeyecek parçalardır. En sık değişen parçaları, işinin ehli olmayan insanlar bile değiştirebilirler. Ama örneğin trigger kayışı (ya da timing belt), genelde 60.000, 80.000 km gibi aralıklarla değiştiğinden, değişimi zor ve zaman alan bir parçadır.
Karmaşıklık
Robert E. Wood, 1986 yılında yayınladığı bir “Task Complexity: Definition of The Construct” isimli makalesinde, bir işin teorik yapısında üç parça olduğunu ifade eder:
• İşin ürettiği çıktılar (products)
• İşin yapılması sırasında gerekli işler (işlemler) ve davranışlar (required acts)
• İşin yapılması sırasında karar verirken gerekli bilgi parçaları (information cues)
Bu teoriyi yazılım sistemlerine uyguladığımızda, yazılımın karmaşıklığının sırasıyla en temel üç faktörü olarak şunları sayabiliriz:
• Program parçalarının karmaşıklığı: nesneler, metotları ve aralarındaki statik ilişkiler (temelde bilme ilişkisi),
• Program girdileri ve çıktıları arasındaki kamaşıklık: girilen veriler ve eventler ile üretilen hizmetler, GUI yapıları, nesne, veri, rapor, vs. arasındaki yapı, d.nüşüm ve işlemlerle ilgili karmaşıklık (zamansal, prosedürel ilişkiler),
• Veriler ve bilgi karmaşıklığı: işlenen veri yapılarının durumları ile sahip olunması gereken bilginin karmaşıklığı.
Bu üç karmaşıklık faktörünü şu şekilde de ifade edebiliriz:
Bileşen Karmaşıklığı = Program parçalarının karmaşıklığı + Veri/bilgi karmaşıklığı
Koordinasyon Karmaşıklığı = Program girdileri ve çıktıları arasındaki kamaşıklık
Bileşen karmaşıklığı, bileşenin alt parçalarının ne kadar “birlikte” (cohesive) olduğunun bir ölçüsüdür. Yani bir bileşen, ne kadar birlikteliği yüksek ise o kadar az karmaşıktır. Birliktelikten kasıt ise tek bir şeye odaklılıktır. Bir yazılım bileşeni, ister bir satır olsun ister bir blok, ister bir metot isterse de bir sınıf olsun, hatta isterse bir bileşen olsun, tek ama tek bir şeye odaklı olmalıdır. Birliktelik İngilizce’de cohesion olarak ifade edilir ve arzu edilen şey, highly-cohesive yani yüksek birliktelikli yapılardır çünkü karmaşıklıkları düşüktür.
Yüksek birliktelikli yapılar, aynı yerde birden fazla şeyi halletmeye çalışmazlar, sadece bir şeyi ama her yönüyle halletmeye odaklanırlar. Bu anlamda Osmanlıca’da tanımın tanımı olarak verilen “efradını cami ağyarını mani” sağlıklı nesneler için de geçerlidir. Yani nesneleriniz öyle olmalıdır ki bir konuyla ilgili her şeyi hallederken, ilgisiz olan hiç bir şeye de bulaşmamalıdır. Birlikteliği düşük sistemlerin anlaşılması, kodlanması, bakımı, testi, dokümantasyonu vs. hepsi çok daha zordur.
Koordinasyon karmaşıklığı, bir işin ne kadar kendi başına ifade edilebilirliğinin ya da diğerleriyle ne kadar “ilgili” olduğunun ölçüsüdür. İlgililik, diğerleri hakkında bilgidir yani bağımlılıktır (coupling) ve bağımlılığı düşük olan bileşenlerin karmaşıklığı da düşüktür. Bir bileşen oalbildiğince sadece ve sadece kendi hakkında bilmelidir, diğerleriyle ilgili bilgisi ise olabildiğince minimal düzeyde kalmalıdır. Bağımlılık İngilizce’de coupling olarak ifade edilir arzu edilen şey, lowly-coupled yani düşük bağımlılıklı yapılardır çünkü karmaşıklıkları düşüktür. Dolayısıyla, çevresindeki diğer nesnelerle alakası, bilgisi az olan nesnelerın bağımlılıği düşüktür, bu yüzden böyle nesneler daha kolay anlaşılır, aktarılır, kodlanır, test edilir ve dokumante edilirler.
Bu anlamda, gerek karmaşıklığı gerek ise değişimi yönetebilmek için yüksek birliktelikli ve düşük bağımlılıklı (highly-cohesive and lowly-coupled) yapılar kurgulamalıyız.
Toplam görüntülenme sayısı: 1895
Ne hasta bekler sabahı,
Ne taze ölüyü mezar.
Ne de şeytan, bir günahı,
Seni beklediğim kadar.
Necip Fazıl’ın “Beklenen” isimli şiirinin ilk kıtası bu dörtlük. Herhalde beklemeyi bu kadar vurucu bir şekilde anlatan başka bir şiir yoktur. Hasta-sabah, mezar-ölü, şeytan-günah ikililerindeki bekleme nasıl da öne çıkıyor hemen. Hatta ilk ve üçüncü satırlardaki özne ve nesne ilişkisinin ikinci satırda ters yüz edilmesi bile insanı afallatıyor. Bunu ancak bir şair yapabilir diyor insan.
Şiir uzmanı değilim, doğru düzgün bir edebiyat okuru bile sayılmam malesef. Ama tutkulu bir insanım ve beklemenin ne olduğunu iyi biliyorum. Beklemek kadar acı verici, beklemek kadar insanı çıldırtıcı başka çok fazla şey yoktur sanırım. Benim de bir hastanın günün ilk ışıklarını beklemesine benzer beklemelerim oldu. 50sine merdiven dayamış birisi olarak hala mezarın taze ölüyü beklediği heyecanla bekliyorum bazı şeyleri. Ya da şeytanın günahı beklemesindeki şehvetle beklediklerim var, yirmi senedir, otuz senedir beklediklerim var.
Herkes bekliyor, hep bekliyoruz. Beklediklerine ulaşamadan bu dünyadan göçüp gitmek ne kadar zor, acı bir şey, değil mi?
Şiiri ilk okuduğumda, herkes gibi ben de beklenenin sevgili olduğunu düşünmüştüm tabi olarak. Ama şimdi öyle düşünmüyorum. Beklemenin ne zamanı, ne süresi var ne de belirli bir nesnesi. İnsan her zaman bekler, insan her şeyi bekler. Çocukken oyuncak bekler sevdiklerinden mesela. Gençliğinde gönderdiği haberlerin ya da işaretlerin cevabını bekler, girdiği sınavların sonuçlarını bekler. Orta yaşlarda daha fazla mesleki ve ailevi beklentiler öne çıkar. Bekleyeceği bir şey kalmadığında da sonunu bekler insan, o en gerçek olanı, aslında en beklenmesi gerekeni bekler. Herhalde tüm diğer beklemelerimizdeki acı, aslolanı, aslında beklememiz gerekeni beklemediğimizden yaşanıyor.
Geçti istemem gelmeni,
Yokluğunda buldum seni;
Bırak vehmimde gölgeni,
Gelme, artık neye yarar?
Sanırım beklemenin terbiye edici bir yönü de var. Bekleye bekleye sabretmeyi hatta beklememeyi öğrenmek, bekleyerek beklenene olan bağımlılığımızı azaltmak, bu terbiyenin farklı yönlerinden.
Edebiyat aşığı canım kızım da lisede iken bu şiir üzerine burada bir eleştiri yayınlamıştı. Bu sene de üniversitede aldığı bir derste bu şiirle ilgili sınıfında paylaşımda bulunmuş. Bunu da “The Awaited” başlığı altında burada yayımladı. Belli ki benim gibi onu da çok etkilemiş bir şiir. Beni sevindiren şey ise bu şiiri onunla ilk paylaştığım anı bile hayal meyal de olsa hatırlıyor olmam. O benden daha net hatırlıyor gerçi.
Beklemek, beklenen kadar güzeldir…
Toplam görüntülenme sayısı: 1461