Search Results for: java

Nitelikli Eleman Açığı mı Niteliksiz Yönetici Fazlası mı?

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

Sosyal mekanlarda gezinirken “Yazılım Sektörünün En Önemli Sorunu Nitelikli Eleman Açığı” başlıklı bir yazı gördüm. Aslında sık sık gördüğümüz, ezberlenmiş türden başlıklardan birisi. Nedense bu sefer farklı geldi bana ve bu yazıyı yazmaktan kendimi alıkoyamadım. Bu tür açıklamalarda sık sık BT sektöründeki sivil toplum kuruluşları öne çıkıyor. Bu haberde de Yazılım Sanayicileri Derneği‘nin (Yasad) adı geçiyordu. Bu haberi Yasad’ın sayfasında da görmek mümkün.

Bu ülkedeki yazılım sektöründeki patronların ve yöneticilerin bir araya gelip dernekler oluşturmaları ve sektörü geliştirme amaçlı faaliyetlerde bulunmaları, devleti bu konuda yönlendirmeleri güzel bir şey. Her devlet gibi bizim devletimizin de bu tür danışmanlıklara ihtiyacı var. Ama ya bu yönlendirmeyi yapanların kendilerinin yönlendirme ihtiyaçları varsa? Ya bu tür kuruluşlar, “sektörün yetişmiş nitelikli elemana ihtiyacı var” derken gerçek ihtiyacın nerede olduğunu ciddi bir şekilde atlayıp, yazılımda daha iyi durumda olan yabancıların sektör gazete ve dergilerinde gördükleri haberlerde ifade edilen problemlerinin aynısının bizde de olduğu vehmine kapılıyorlarsa? İşin açıkçası bunları yazarken “yazlılım sanayicisi”nin ne anlama geldiğine ve “eleman” kelimesine takılmamaya çalışıyorum, çünkü bu yazıyı kara mizah yapmak istemiyorum.

Yazılımın içinden birisi olarak ülkemizin en ciddi sorununun nitelikli eleman eksiği olduğuna katılmıyorum. Bu tür haberlerde, konuşmalarda geçen “eleman” kelimesiyle kastedilenin (“eleman” nitelendirmesiyle her ne kadar kelle sayısı hesabı yapan dolayısıyla da itici bir anlayışı yansıtsa da), üniversitelerden sektörümüze sunulan mezunlar olduğu açıktır. Denilen, üniversitelerden yeterince mezun gelmediği ve gelenlerin de ihtiyacı karşılamadığı iddiasıdır. Evet bu bir problem, üniversitelerden hem sayı hem de kalite olarak yeterli mezun çıkmıyor. Ama kendimizi kandırmayalım, problemin büyüğü bu değil, yani bence durum bundan daha vahim. Bakın “eleman açığı”ndan şikayet şu anlama geliyor: “Ülkemizdeki yazılım sektörünün başka problemleri olsa da en büyüğü eleman açığıdır. Yani sektör var olan elemanları düzgün bir şekilde değerlendiriyor, imkanlar elverdiğince iyi işler çıkarıyor ve daha çok yeni elemana ihtiyaç duyuyor. Dolayısıyla en büyük engelimiz eleman açığı, eleman sayımız yetse, siz görün bizi.” Tırnak içinde yazdığım bu düşünceyi ifade eden yine Yasad’ın sayfasındaki şu habere bakılabilir. Haberde sektörün eleman açığının giderilmesiyle uçuşa geçeceğimiz ifade ediliyor.

Bence yine kendimize kendimizin propagandasını yapıyoruz. Çok açık bir şey var, ülkemizdeki yazılım sektörü dişe dokunur bir şey geliştirmekten malesef uzak. Geliştirdiklerimiz kalite olarak son derece düşük, o yüzden dünya yazılım piyasasına sunulabilecek cinsten değil. Çünkü hala kahramanca savaşan yazılımcılara bağlı olarak iş yapıyoruz, süreç tabanlı yazılım geliştirmeden çok uzağız. Daha program ile yazılım arasındaki farkı kavrayabilmiş değiliz. Nasıl futbol oynuyorsak öyle yazılım geliştiriyoruz; ikisinin de en temel dinamiği kaos.

Yazılım sektörünün esas sorununun “eleman açığı” olduğunu söyleyerek, kayıp yüzüğünü, kaybettiği samanlıkta aramayıp, kapının önünde arayan ve neden böyle yaptığı sorulduğunda da “samanlık karanlık ama” diyen Nasrettin hocamızın tiye aldıklarından oluyoruz. Bence bu ülkenin yazılım sektöründeki en temel problem nitelikli eleman açığı değil, niteliksiz yönetici fazlasıdır! Var olan iş gücü potansiyelimizi bile değerlendirmekten uzağız, kaotik bir şekilde iş yapıyoruz, başarımız çoğunlukla şansa bağlı, enerjimizi ve zekamızı yanlış yerlere harcıyoruz. Ve bence bu durumun en başlıca sebebi, yazılım “elemanları” değil, yazılım yöneticileridir, karar vericileridir.

Kifayetsiz yazılım yöneticilerine sahip olmamızın bence iki sebebi vardır. İlki yazılım yöneticilerimizin bizatihi kendileri ile bir şekilde yazılım geliştirme süreçlerini yöneten ya da yön verenler (örneğin daha üst düzey “C” seviyesindeki yöneticiler), daha yazılımın ne olduğundan, tabiatından, süreçlerinden, rollerinden ve yetkinliklerinden vs. habersizler. Bu konuda en temel ayrımları bile bilmediklerine ben defalarca şahit olmuşumdur. Çünkü bu yöneticiler muhtemelen kariyerlerinin başında teknik pozisyonlarda bulunmuşlardır ama daha işlerinde ustalaşmadan yönetici oluvermişlerdir ya da daha doğru ifadeyle yapılıverilmişlerdir. Dolayısıyla henüz öğrenmedikleri bir işi yönetmeye çalışıyorlardır. Yani, tabii olarak gördüklerini uyguluyorlar. Örneğin, projelerdeki en temel problem çözme yöntemleri, fazla mesaidir. Çünkü onlar da fazla mesai ile projeleri kurtarmaya çalıştılar.

Mesleğinde yeterince olgunlaşmadan yönetici olmanın bir başka handikapı da, kendilerini yönetici yapanlara karşı çıkamama şeklinde kendini göstermektedir. Zaten kafasında henüz bir sistem oluşturacak, süreci baştan sona kavrayacak şekilde olgunlaşmamış durumda olduklarından, teknik kaliteyi öne çıkarmaları, iş yapış şekilleriyle ilgili bir yenilik yapmaları ve nihayetinde var olan düzeni değiştirmeleri, üstlerinin kararlarına karşı çıkabilmeleri mümkün değildir. Bundan dolayı bizim sektörümüzde orta düzey yönetici olmak, tokmağı başkasının elinde olan davulu sırtında taşımaktır.

Bu ülkenin, daha mesleğini öğrenmeden o mesleği yönetmeye çalışan yöneticileri var. Bu ülkenin daha 30’una gelmediği halde, hızını almış giderken, teknik olarak ilerlerken, yaptığından zevk alırken, programcılıktan tam işin mimari ve mühendislik kısımlarına atlamaya hazırlanan ya da ekran analistliğinden çıkıp sistem analistliğine doğru ilerleyen civa gibi gençlerini bulunduğu ortamdan aniden koparıp, “sen yöneticisin artık” diyen ve muhteşem mühendis adaylarını berbat yöneticilere dönüştüren bir kültürü var. O kadar çok arkadaşım var ki bu durumda olan. Hepsi çok iyi eğitim almışlar, mesleklerinin ilk 5-6-7, bilemediniz 10 yılında bu eğitimin üzerinde deli gibi bilgi ve tecrübe inşa etmişler. Bu arkadaşlarım ya da tanıdıklarım, tam mesleklerinde çıraklığı atıp, olgunluk çağlarına gelmişler, bundan dolayı da belki daha stratejik konulara ele atacaklar, iş yapış şekillerini düzeltecekler, kaliteyi arttırmaya odaklanacaklar ya da meşreplerine ve ilgilerine göre değişik konularda uzmanlaşacaklar, belki kimileri kitap yazacak, belki çok odaklı, niche, bir konuda bir gelişme sağlayacaklar ve hem ülke hem de insanlık adına bir katkıda bulunacaklar. Ama sektörün böyle insanlar yetiştirmek gibi bir derdi yok ki!  Hemen tüm bu şekilde gelişmeye çalışan arkadaşlarımın önü, daha yüksek maaşla yönetici yapılarak kesilmekte. Daha geçen gün bu şekildeki bir arkadaşım “ben bu ülke için bir kayıpım” dedi bana. Çünkü iyi bir mühendisken, sırf maddi ve sosyal şartlardan dolayı yönetici oluvermişti.

Kifayetsiz yöneticilere sahip olmamızın ikinci sebebi ise, bu yöneticilerin bu makama gelirken hatta geldikten sonra herhangi bir yöneticilik formasyonundan geçmemiş olmalarıdır. Genelde işini iyi yapan, iyi eğitim almış, zeki ve başarılı yazılımcılar, programcı olsun, analist olsun, 3-5 sene içinde bir şekilde yöneticiliğe tabii olarak geçerler. İyi mühendis, iyi programcı, iyi sistemci, iyi bir yönetici olmak için gerek sebep olabilir ama yeter sebep değildir. Yüksek empati yeteneğine sahip olmadan iyi bir sistemci olabilirsiniz, iyi bir organizatör olmadan iyi bir programcı olabilirsiniz, iyi bir arabulucu olmadan iyi bir tasarımcı olabilirsiniz ama bunlar olmadan iyi bir yönetici olamazsınız. Bu durumun benim sıklıkla gözlemlediğim, en açık göstergesi ise yazılım yöneticilerimizin ezici bir kısmının, senelerdir yöneticilik yapığı halde hala doğru detay seviyesinde bulunmayı beceremeleridir. Ya hala çok teknik davranırlar ve bu yüzden altında çalışan teknik insanlara güvenip iş teslim edemezler, bu yüzden de detayda boğulurlar, ya da işin sadece tarihleri ve maliyetiyle ilgilenirler ve üst yönetimin kararlarını altlarına uygulatmak dışında bir insiyatifleri yoktur. Her iki halde de başarılı olamazlar.

Yöneticilik, öğrenilebilir. Ama bir eğitim ve öğrenim sürecinden geçmeden bir şekilde yönetici olanlar ki buna ben de dahilim ve ne olduğunu çok iyi biliyorum, ancak hasbel kader yöneticilik yapabilirler. Yani sektörümüzdeki yöneticiler genel olarak, ne yazılımı ne de yönetimi bilmeyen insanlardır. Yöneticilik algısı ve yeteneği olanlar, uzun vadede başarılı yönetici olabilirler, örneğin hangi detayda kalacaklarını öğrenirler, teknik insanlarla nasıl konusacaklarını belirlemiş olurlar belki ama bu sırada kaç çalışan ve proje telef olur, bilinmez.

Bu ülkenin yazılım sektörünün tek sıkıntısı hakikatten üniversiteden sektöre akan mezunların sayısı olsaydı, örneğin onlara karşı da bu sektör “deneyimin yok ama” sendromunu yaşatmazdı ve bu ülkede çok daha farklı şeyler olurdu.

Ben de yöneticilik yaptım, sıkıntılarını iyi biliyorum. Bu ülkede orta düzey yazılım yöneticisi olmak çoğu zaman yukarıda da söylediğim gibi, tokmağı başkalarının elinde olan davulu taşımaktır. Sektörümüzde yönetici olmak çoğu zaman tetikçiliktir, üstte verilen kararların aşağıya uygulatılmasından sorumlu olmaktır, örneğin bitiş tarihini üstlerinin belirlediği projeyi, alttakilerin ensesinde boza pişirme pahasına bitirmektir. Dolayısıyla bence sektörümüzün sıkıntıları ne teknolojiktir, ne kişi sayısıyla ilgilidir ne de doğrudan maddidir; yoğun olarak kültüreldir. Teknik kaliteye önem vermeyen ve her şeyi insan manipulasyonu ile yapmaya çalışan zihniyetimizi değiştirmedikçe her ilçeye bir üniversite kursak bile, yazılım gibi yüksek soyutlama gerektiren disiplinlerde durum değişmeyecektir.

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

İyi Programcı, Kötü Programcı

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

Ben kendimi nihayetinde programcı olarak görme eğilimindeyim. İşin matematiksel, mühendislik, sanatsal vb. taraflarının hepsinden çok zevk alıyorum. Gerek algoritmik çözümlemeler, gerek üzerine tekrar tekrar düşünerek, daha da etkin hale getirdiğim kod yapısı, çalışma zamanı performansı, bu sırada hissettiğim estetik kaygılar vs. hepsi bana çok zevk veriyor.

Eskiden bu yana, değişik fırsatlarla, kendimi teyzeler, amcalar arasında buluyorum. (Açıkçası, artık çocuklarımın arkadaşları da bana amca diyorlar ama, o tarafa girmeyelim şimdilik 🙂 ) Memleketim Ayvalık’ta olsun, Anadolu’nun farklı yerlerinde olsun, İstanbul’da olsun, aile, eş-dost, akraba vs. ortamları kastediyorum. Eskiden böyle ortamlarda doktor ve avukat olmak problemliymiş, herkes derdini anlatırmış. Uzun zamandır bu mesleklere bizler de eklendik, herkesin bilgisayar vs. ile ilgili bir derdi var. 500-600 km araba sürüp, gittiğim misafirlikte modem-wireless tamiri yaptığımı biliyorum.

Neyse, bu amcalar ya da teyzeler benim yazılımcı ya da amiyane tabirle “programcı” olduğumu öğrendiklerinde, etraflarındaki, örneğin torunları, “programcı”lardan söz açıp, konuyu “o da seninle aynı işi yapıyor”a getirirler. “Eyvallah, çok güzel” diye cevap veririm ben de. Eskiden merak edip, “aaa öyle mi?” diye de saf saf sorardım. Sonra, 5-10 dakika sonra, o torun gelirdi: 17-18 yaşlarında, meraklı, radyoyu parçalayıp ondan bir çamaşır makinesi çıkarma ruhuna sahip, cevval ama eğitimsiz, örneğin orta okuldan terk ya da meslek lisesinde okuyan bir genç örneğin. Tanışırız, konuşuruz, o doğmadan önce benim Fortran ya da C ile uğraşmışlığımın olduğu ortaya çıkar örneğin. Bu işleri yurt dışında öğrenmiş olmam, ne bileyim Netscape tarayıcısının ya da Java’nın yayınlandığı günleri hatırlamam, büyük projelerde, GE gibi yerlerde çalışmış olmam, tecrübelerim, C# ile ilgili soru sorduğunda rahatça “bilmiyorum” demem, vs. vs. sonuçta, tüm bunlar o gençte bana karşı son derece yüksek bir saygı, imrenme vb. duygular oluşmasına sebep olur. Bunu rahatlıkla farkedersiniz.

Size bir sır vereyim mi? Yukarıda saydığım ve o gencin bende görüp de içini çektiği, imrendiği bu şeylerin hiç birisi beni ondan daha iyi bir programcı yapmaz. Yukarıdakilerin hiç birisine kanıp da siz de birisinin iyi programcı olduğuna karar vermeyin. Peki, nedir iyi programcıyla, kötü programcıyı birbirinden ayıran şey? EJBleri çok iyi bilmek mi? Ya da yüzlerce kişiden oluşan bir yazılım projesinin parçası olmak mı? Ya da C, C++, ya da Java’yı sular seller gibi bilmek mi? Örneğin yukarıda bahsettiğim genç ile bana bir algoritmik ödev verin, mesela pi’ye en hızlı şekilde ve en az bellek harcayarak yakınsamak ya da başka bir graf sorusu örneğin, muhtemelen ben daha hızlı ve güzel bir şekilde yaparım o ödevi. Ya da bir proje verin ikimize de, son derece basit, Fahrenheit-Celcius çevirisi yapacak bir web yapısı kurmamızı isteyin örneğin. Muhtemelen ben, o gencinkine göre çok daha sağlıklı bir mimari ve çok daha performanslı ve scalable olacak şekilde bu projeyi tamamlarım. Yani programlama faaliyetinin ister matematiksel ister mühendislik taraflarında muhtemelen ben çok daha iyi performans gösteririm. Ama yine de bunların hiç birisi beni ondan daha iyi programcı yapmaz. Bunların hiç birisi, birisinin diğerinden daha iyi programcı olduğunu göstermez.

Nedir peki iyi programcıyı, kötü programcıdan ayıran en temel şey? Çok basit bir cevabı var bu sorunun. İyi programcılar, yazdığı kodu her yönüyle anlarlar ve başkasının anlayacağı şekilde kod yazarlar. Kötü programcılar ise ne yazdığını her yönüyle anlamazlar, bırakın bir başkası, kendisi bile bir müddet sonra ne yazdığını zor çözer.

Yani kötü programcı şöyle kod yazar:

...
cardInfo.setIdNo(cardInfo.getTcCitizen() ?                               
 (formUtils.isNullOrEmptyString(verifyOtpWSResponse.getTckn()) ? 
  registrationForm.getTckn() : verifyOtpWSResponse.getTckn()):   
(formUtils.isNullOrEmptyString(verifyOtpWSResponse.getCustno())) ? 
  registrationForm.getTckn(): verifyOtpWSResponse.getCustno());
...

İyi programcı ise böyle kod yazar:

// Burada CardInfo’nun Idsi atanır. Id olarak eğer musteri TC vatandasi ise
// ve ya WS’den ya da fromdan gelen tckn atanır. Eğer müşteri TC vatandaşı
// değilse Id olarak customerNo alınır. 
// Burada da yine ya WS’den ya da formdan gelen customer no atanır.

String idNo = null;
Boolean isTcCitizen =  cardInfo.getTcCitizen();
String tcknFromForm = registrationForm.getTckn();
String tcknFromWS = verifyOtpWSResponse.getTckn();
boolean nullOrEmptyTcknFromWS  = formUtils.isNullOrEmptyString(tcknFromWS);
String custNoFromWS = verifyOtpWSResponse.getCustNo();
boolean nullOrEmptyCustNoFromWS  = formUtils.isNullOrEmptyString(custNoFromWS);
  
 if(isTcCitizen){
      if(nullOrEmptyTcknFromWS)
          idNo = tcknFromForm;
      else
          idNo = tcknFromWS;
 }
 else{
       if(nullOrEmptyCustNoFromWS)
          idNo = tcknFromForm;
      else
          idNo = custNoFromWS
 }
 cardInfo.setId(idNo);

Max Kanat-Alexander’ın Code Simplicity isimli kitabında dediği gibi:

İyi programcıyla kötü programcı arasındaki fark anlamadır. Yani kötü programcılar ne yaptıklarını anlamazlar, iyi programcılar ise anlarlar. İster inanın, ister inanmayın ama bu gerçekten bu kadar basittir.

(The difference between a bad programmer and a good programmer is understanding . That is, bad programmers don’t understand what they are doing, and good programmers do. Believe it or not, it really is that simple.)

Ya da Martin Fowler’ın, Refactoring isimli kitabında yazdığı gibi:

Herhangi bir insan bilgisayarın anlayabileceği kod yazabilir. İyi programcılar ise insanların anlayabileceği kod yazarlar.

(Any fool can write code that a computer can understand. Good programmers write code that humans can understand.)

Evet bu fark, hakikatten bu kadar basittir. Yukarıda bahsettiğim genç ile beni sınarken yaptığımız ödevleri bir başka programcıya verin ve ciddi bir değişiklik yapmasını isteyin. yYaptığımzı şey bir algoritma ise, bir kaç adım sıkıştırın araya, ya da bir proje yapmışsak bir süreçte ya da iş kuralında değişiklik yapılmasını isteyin. Hangimizin kodu ya da projesi en kısa sürede bu üçüncü programcı tarafından başarıyla değiştirilebilirse, bilin ki en iyi programcı odur.

Linus Torvalds’ın dediği gibi, “Konuşmak ucuzdur. Bana kodu göster.” (Talk is cheap. Show me the code.)

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

Kararsızlar İçin Mac Klavuzu – Devam

Diğer , , , , ,

3 küsür sene önce Mac kullanmaya başladığımda açıkçası bu kadar memnun kalacağımı düşünmemiştim. Önce 13″, i5 işlemcili MacBook Pro ile başladım sonra 15″ i7 işlemcili Retina ekranlıya geçtim. Yaklaşık 2 sene bunu kullandıktan sonra Aralık ayında aynı makinanın yeni modelini aldım. Şimdi RAM’i 16 GB olan Mac’im oldu yani.

Burada daha önce “Karasızlar İçin Mac Kılavuzu” başlıklı bir yazı yazıp, Mac deneyimim hakkında görüşlerimi paylaşmıştım. Orada da bahsettiğim gibi açıkçası benim için kullanım rahatlığı birinci planda geliyor. Maliyet tabi olarak hemen ardından ikinci faktör. Makinamda çalışırken, herhangi bir pürüz hissetmeden, yapmak istediklerimi bir duraklama, bekleme olmadan yapabilmem benim için çok önemli. Açıkçası danışmanlık ve eğitmenlik yaparken çok da fazla vakit ve enerji kaybına tahammülüm de yok. Dolayısıyla hızlı ve güvenilir çalışan ve benim vaktimi almayan herhangi bir sistem benim için mükemmel. Bu anlamda bir sistem ya da marka takıntım yok.

Pürüzsüz çalışma derken ne kastettiğimi bir örnekle açıklayayım. Geçen ay eski Mac Book Pro makinamı satılığa çıkardım çünkü yeni modelini aldım. Tabi olarak her yeni makina geçişinde eski dosyalar, ayarlar ve programları, yeni makinada aynen tekrardan kurgulamak gibi bazen haftalarca süren bir iş sizi bekler. İki makina arasında dosyaları kopyala, yeni makinaya uygulamaları kur, eski makinadaki ayarları yeni makinaya aktar vs. Örneğin tarayıcı bookmarkları ya da email hesapları, vs. vs.

Ben evimde backup amaçlı 3 TB Apple Airport kullanıyorum. Dolayısıyla makinam sürekli kendini buraya yedekliyor. Hatta bu Airport, yakınımdaki Mac’lerin de yedek yeridir :), bana gelince yedeklenirler. Eve yeni makinamı getirince, eski makinamdaki yapının bu yeni makinaya aktarılmasıyla ilgili yaptığım tek şey, yeni makinanın Airport’u görünce bana buradaki yedekten neyi almak istersin şeklindeki soruya bir-iki tık atarak cevap vermem oldu. Dosyaların aktarılmasını ama uygulamaların aktarılmamasını istedim. Bu aktarma 12 saat kadar sürdü sanırım çünkü akşamdan sabaha kadar zaman aldı. Uygulamaları aktarmak istemedim çünkü seçmece olarak yeni sürümlerini kuracaktım. Ve ben bu dosya aktarımını yaptıktan sonra, yeni makinaya hangi uygulamayı kurduysam, bütün ayarları ve gerekli dosyaları hemen kullanıma hazırdı. Hatta tarayıcıların sakladığı cookieler ve kullanıcı adı ve şifre bilgileri bile, eski makinamda olduğu gibi burada geçerliydi. Yeni kurduğum uygulamaların lisansları zaten hazırdı, uygulamayı kurdum, lisans bilgilerini girecekken, baktım lisansı geçerli. Apple Store’dan indirdiğim uygulamaları da otomatik olarak indirdim makinama. Dolayısıyla aldığımın ertesi günü tüm emaillerim, dosyalarım ve uygulamalarımla makinamdaki ortam aynen eski makinamda olduğu gibi kullanıma hazır bir haldeydi. Profesyonel bir yazılımcı başka ne ister ki?

Bu arada müşterilerimdeki ortamlardan dolayı Windows, Unix ve Linux ile çalışmaya devam ediyorum. Unix ve Linux’de bir problem yok, onlar zaten son derece güvenilir bir şekilde davranmaya devam ediyorlar ama Windows hala problemli. O da açıkçası, alıştırdığı gibi, kör topal çalışmaya devam ediyor. Hatırlıyorum, geçen senenin başında i7 işlemcili 16 GB RAM’li Toshiba marka iyi bir laptop almıştım ve eve gelip de kurulumunu yaptıktan sonra IE’yi ilk açışımda crash olmuştu ve makinayı tekrardan başlatmam gerekmişti. Windows 8.1 çalıştıran bu makinadaki IE’yi çok kullanacağımdan değil, sadece hızlıca Chrome ve Firefox gibi tarayıcıları hemen indirmek isteğimden olmuştu tüm bunlar 🙂 Mac kullanmanın bence Windows kullanmaya göre, gerek günlük kullanımda gerek ise profesyonel kullanımda neresinden baksanız %20 ile %40 civarında üretkenlik farkı sağladığını düşünüyorum ben. Bunu herhangi bir ölçüme ya da analitik modele göre söylemiyorum tabi ki, sadece hissiyatım bu yönde.

Bu yazıyı okuyanlar muhtemelen Apple’ın çok aç gözlü olduğundan dem vuracaklar ve “her şey için para istiyor” şeklinde eleştirecekler. Haksız değiller, çünkü Apple bir kapitalizm kültürünün çocuğu. Bildiğimiz, aklınıza gelen bütün teknoloji şirketleri gibi, Microsoft gibi, Google gibi, Oracle gibi. Tüm bu şirketlerin kapitalizmin kurallarını uyguladıklarında bir şüphe yok, amaç öncelikle kazancı arttırmak. Bu noktada rekabette öne geçmek için farklılığı, kaliteyi ve maliyeti optimum yönetmeleri gerekli. Kimisi iyi yönetiyor kimisi kötü, ya da daha doğru ifadeyle, tamamen insan odaklı bir pazardan bahsettiğimize göre, ihtiyaçlarımızın çok sık değişmesi gerçeğini göz önüne alırsak kimisi bu stratejileri doğru kurguluyor bir t zamanında ama bir başka zamanda yani t1’de bu kurguyu olması gerektiği gibi eviremiyor, dolayısıyla kapitalist döngüde aşağılara kayıyor. Ben Mac kullanımımda 3 OS geçişi yaşadım, ilkine sanırım $10 gibi bir rakam ödemiştim, son ikisine hiç bir şey ödemedim, çünkü bedava geldi yeni OSler. Öte taraftan farklılığı pahalı sunmak bir stratejidir, pahalı arabalar, pahalı giyecekler, pahalı saatler vs. gibi. Her pahalı her zaman farklı ve kaliteli olmayabilir ama her farklı ve kaliteli muhakkak pahalıdır.

Bu noktada ben Apple’ın oluşturmuş olduğu eko sistemden son derece memnunum. Telefon olarak iPhone kullanıcısı olduğum gerçeği de göze alındığında, çocuklarıma ve sevdiklerime de benzer eko sistem kurmam, benim yakın çevremle olan irtibatımı, paylaşımımı ve onların bilişim altyapılarını yönetmemi çok kolaylaştırıyor. Örneğin, dönem arasından faydalanarak Türkiye’ye gelen kızım da bir Apple (iPhone ve Mac Air) kullanıcısı. Dolayısıyla onun sorularına cevap verebilmem, makina vs.sindeki sorunları hızlıca giderebilmem vs. hep aslında bu pahalı eko sistemin bana kazandırdıklarından başka bir şey değil.

Herkesin tercihine saygım sonsuz ama Mac düşünenleri çok rahat bir çalışma ortamı bekliyor.

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

Tasarım Kalıpları – III: Nasıl Öğrenelim?

Java, Tasarım Kalıpları, Yazılım Modelleme, Yazılım Mühendisliği

Tasarım Kalıpları ile ilgili ilk yazıda konuya giriş yapmıştık. Bu yazıda ise tasarım kalıpları nasıl öğrenebileceğimiz konusunu ele almak istiyorum. Çünkü bu konuda çok soruya muhatap oluyorum.

Bir kere peşinen şunu söylemekte fayda var: tasarım kalıpları bir teknoloji değildir. Bu yüzden de tonla farklı konuda kitap okuyan ya da bilgi konusunda abur-cubur beslenip bilgi obezitesi ya da bilgi sindirimi bozukluğu gibi sıkıntılara duçar olmuş pek çok genç arkadaşın, benzer düşünceyle tasarım kalıplarına yaklaşması çok ciddi hazım sorunları oluşturacaktır. Demek istediğim şu: Bir kitabı okumak, bir yaklaşımı öğrenmek ya da bir fikri hazmetmek için belli bir zihni olgunluğa gelmiş olmanız gereklidir. Benzer şey tasarım şablonları için de geçerlidir. Hatta bu gibi soyut yapıları öğrenmek için odaklanmanız da gerekir çünkü kavranmaları zordur. Odaklanmak her başarının ardındaki önemli noktalardan ama tasarım kalıplarını öğrenmek için teknolojinin ötesine odaklanmanız gerekecektir.

Tasarım kalıplarını öğrenmek, en çok soyut düşünme konusunda sizi zorlayacaktır. Soyut düşünme yeteneklerinizi de geliştirecektir aynı zamanda.  Bu durumu kolaylaştırmak için bir miktar UML özellikle de class ve interaction diyagramlarına bakmanızı öneririm.

Önce kitaplardan başlayalım. Tasarım kalıplarını öğrenmekten bahsedildiğinde tabi olarak akla ilk gelen kitap Gang of Four’un Design Patterns isimli kitabıdır. İşin açıkçası bu kitap 1994’de yazılmış olmasına rağmen henüz devrini tamamlamadığı gibi, pek aşılmış da değildir. Konu ile ilgili yazılmış pek çok kitap, bu kitabın tefsiri ya da farklı dillere uygulaması mahiyetindedir. Gerçi bu cins açıklayıcı kitaplar arasında çok başarılar da var elbette ama temelde bu kitapların pek çoğu, Design Patterns kitabına orijinal bir şey katmazlar.

Tecrübeli olmayanlar için zor bir kitaptır Design Patterns. Ciddi bir nesne altyapınız yok ise, nesne-merkezli dillerle uzunca süredir uğraşmıyorsanız, sırf ismi çok sık geçiyor diye bu kitabı okumaya çalışmak çok da faydalı bir hareket değildir, sadece öğrenilmiş çaresizlik üretir. Bu kitabı anlamak için yazılım üzerine çok ciddi soyut düşünce yeteneğine sahip olmak gereklidir. Kitabın örnekleri C++ ile verilmiştir ama Java ve C# gibi dillerde örnekleri olan pek çok açıklama ve uygulama mahiyetinde kitaplar da mevcuttur. Ben egitimlerde bu kitabı kullanıyorum. Hatta  gerek Pdf’inden gerek ise bizzat kendisinden sınıfta bazı kısa okumalar yapıp, eğitime katılanları bu kitaba yaklaştırmaya çalışıyorum.

Bu kitabın ilk iki bölümü nefis bir OO özetidir, hiç okuyamazsanız, bu iki bölümü, altını çizerek ve anlayarak okumanızı tavsiye ederim. Özellikle ilk bölümdeki nesnelerin bulunması, sorumluluklarının atanması, interface ve implementation ayrımı ve ilgili miras yapıları son derece keyifle okunacak konulardır. Yine bu bölümdeki “program to an interface, not an implementation”, “favor object composition over class inheritance” ve “design for change” prensipleri, her daim akılda tutulması gereken en temel yazılım tasarımı prensiplerdendir. Bu kitabı okumaya kesinlikle ilk iki bölümünü atlayarak başlamayın. Bu iki bölümü hazmederek okuyun sonrasında kalıplara geçin. Ben tasarım kalıpları eğitimlerinde, sınıfın durumuna göre bazen 1-1,5 günü bu üçünün yanında “tek sorumluluk” gibi diğer başka prensipleri de örneklerle açıklayarak geçiriyorum, aksi taktirde katalog gibi kalıpların üzerinden gitmenin bir faydasını görmem mümkün değildir.

Peki bu kitabı okuması zorsa ne ile başlayalım? Uzunca bir müddet burun kıvırarak baktığım Head First serisi kitaplarından olan “Head First Design Patterns” kitabı ile son zamanlarda biraz haşır neşir oldum ve bu seri ile ilgili fikrim değişti. Bu kitap GoF’un kalıplarının ciddi bir kısmını son derece eğlenceli tarzda anlatıyor. Ben kitabı “Lise mezunları için Tasarım Kalıpları” olarak niteliyorum zaman zaman 🙂 Temel nesne-merkezli prensipleri bilen, hatta bu konularda kafası karışık olan kişilerin bile sabrederek ilerlediklerinde çok faydalı olacak bir kitaptır. Bu kitapla, gayret ederseniz, muhakkak konuyu anlarsınız. Bu kitap hem anlaşılır, detaylı anlatımı, hem konuyu özetleyen güzel UML çizimleri hem de son derece kolay örnekleri ile tasarım kalıplarının dünyanıza girmesini sağlayacaktır. Kod örneklerini indirip, konularla atbaşı işleyebilirsiniz.

Head First Design Patterns kitabı, kalıplardan önce temel prensipleri açıklayan bir ön bölüme sahip. Aslında pek çok prensibi kalıpları anlatırken yapıyor. Fakat ilk bölümde, yazılımın en temel özelliklerinden olan “değişim”i ele alarak, GoF’un yukarıda bahsettigim üç prensibini açıklıyor. Bu amaçla örnekler üzerine kurgulanan bir problemi önce kalıtım sonra da arayüz ile tasarlıyor. Kitap sonrasında GoF’un kalıplarının yaklaşık yarısını, 11 bölümde ele alıyor. Geriye kalan kalıplara da son bölümde kısaca değiniyor.  Bu kitabın genişçe ele aldığı kalıplar, aslında öğrenilmesi en kolay olanlar. Dolayısıyla kitap okuyarak ve uygulamalarını yaparak kalıpları öğrenmek istiyorsanız, bu kitap tam bu iş için.

Benim tasarım kalıpları konusunda faydalandığım bir başka kaynak da Design Patterns Explained isimli kitaptır. Bu kitap GoF’un açıklaması mahiyetindedir ama bir kalıp kataloğu değildir. Dolayısıyla kitap daha çok kalıp merkezli düşümeyi sağlamak üzere, temel nesne-merkezli yaklaşım problemlerini ele almakta ve kalıplarla bu problemlerin nasıl giderildiğini anlatmaktadır. Kitabın örnekleri Java ile yapılmıştır ve bu örneklere online olarak ulaşabilirsiniz. Kitapta, GoF’un Façade ya da Strategy gibi sadece bazı kalıpları yer almaktadır. Head First kitabi size çok basit geliyorsa, bu kitapla başlayabilirsiniz.

Craig Larman’ın geniş ve güzel “Applying UML and Patterns” kitabından bahsetmeden geçmek olmaz. Bu kitap da aslen bir kalıp kataloğu değildir. Bu kitap hem temel prensipleri hem de bazı kalıpları, UML kullanarak, baştan sona bir tasarım süreci içerisinde ele alır ve detaylıca anlatır. Bu kitap kendi kendinize çalışmak için de nefis bir kaynaktır. Bu kitabın pek çok üniversitede UML ile nesne-merkezli analiz ve tasarım amaçlı derslerde kullanıldığını da biliyorum.

Kaynaklardan bahsedince tabi olarak “Türkçe kitap yok mu” sorusu akla geliyor. Maalesef dilimizde bu konularla ilgili özgün kitap pek yok. Zaten okuyan bir millet olmadığımız için, yazmak hepten bize uzak. Az da olsa bizim sektörümüzde fedakarlık yapıp, zaman ayırıp, güzel kitaplar yazanlar var. Bunlardan birisi de Özcan Acar. Özcan,  “Java Tasarım Şablonları ve Yazılım Mimarileri” isimli 290 sayfalık kitabında GoF’un 22 kalıbı yanında Java EE’nin de en bilinen mimari kalıplarını ele almıştır. Kitabın giriş mahiyetindeki ilk bölümünde soyut sınıflar ve arayüzler ele alınmakta ve altı temel prensipten bahsedilmektedir. Kitabın ikinci bölümü ise tasarım kalıpları kavramını açıklamaktadır. Kitabın 3., 4. ve 5. bölümlerinde GoF’un kalıpları, 6. bölümde ise Java EE kalıpları açıklanmaktadır. 7. bölümü ise tasarım kalıplarının, 3 katmanlı bir yazılım mimarisi içinde nasıl uygulandığı bir örnek uygulama ile ele alınmıştır. Son bölüm ise Spring mimarisi ve bu mimaride Data Access Object (DAO) kalıbının kullanımını ele almaktadır. Kitapta konuların sıklıkla UML sınıf diyagramlarıyla zenginleştirilmiş olması anlaşılmayı kolaylaştırmaktadır.

Özcan, muhtemelen okumama alışkanlığımızı aşmak için kitabını olabildiğince kısa tutmaya çalıştı diye düşünüyorum. Zaten önsözünde de belirttiği gibi anlaşılması için Java örneklerini olabildiğince basit halde vermiştir. Kitap ile birlikte gelen CD’den kitabın örneklerini edinebilirsiniz.

Ayrıca DZone’un konu ile ilgili referans kartlarını da elinizin altında tutmak isteyebilirsiniz.

Zaman zaman konuyla ilgili baktığım bazı web kaynakları da şunlardır:

Konu ile ilgili bazı güzel makaleleri de şöyle verebilirim:

Siz de tasarım kalıpları üzerine faydalandığınız kaynaklardan bahsederseniz buraya eklerim.

Bol tasarım kalıplı çalışmalar dilerim 🙂

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

«< 43 44 45 46 47 >»