Clean Code Semineri
8 Ekim 2014 Carşamba saat 14:00 – 16:00 arasında İTÜ ARI-3 binasındaki konferans salonunda Clean Code konuşmak için toplanacağız. İlgilenen arkadaşlar davetlimdir.
Toplam görüntülenme sayısı: 776
8 Ekim 2014 Carşamba saat 14:00 – 16:00 arasında İTÜ ARI-3 binasındaki konferans salonunda Clean Code konuşmak için toplanacağız. İlgilenen arkadaşlar davetlimdir.
Toplam görüntülenme sayısı: 776
Akin İş ve İhtiyaç Analizi, Yazılım Mühendisliği
Daha önce bu konuya bu yazıyla giriş yapmış ve ihtiyaç ile istek arasındaki ilişkiden bahsetmiştik. Bu yazıda bu konuyu sonlandıralım.
Karl Wiegers, “More About Software Requirements” isimli kitabının ikinci bölümünde, kozmik doğrulardan bahsederken “The customer is not always right, but the customer always has a point.” der. Yani “müşteri her zaman haklı değildir fakat müşteri her zaman bir noktaya işaret ediyordur.” Bu sözü, bir önceki yazının ışığında ele alırsak demek istenen şey, müşterinin ihtiyacı olarak size aksettirdiği sey her zaman bir ihtiyaç olmayabilir, bir istektir örneğin, ama bu isteğin ardında müşteriyi bunu ifade etmeye iten bir sebep muhakkak vardır.
“Müşteri her zaman haklı değildir fakat müşteri her zaman bir noktaya işaret ediyordur.” sözünün en doğru olduğu zaman, müşterinin ihtiyacını değil de ihtiyacına çözüm olduğunu düşündüğü şeyi ifade ettiği zamandır. Sıklıkla karşılaşırız, analiz toplantısında müşteri açmıştır kullandığı yazılımın bir tarafını ve ilgili kullanıcı ekranları üzerinden, “şuraya bir kombo istiyorum”, “şurada şöyle bir liste olsun” vb. bir dille konuşmaya başlamıştır. Bu durumda, müşterinin, ihtiyacından değil, isteğinden de değil ama çözümden bahsettiği aşikardır. Tecrübeli analistler, müşteriyi bu durumda, “siz ihtiyacınızdan değil de çözümden bahsediyorsunuz” diye hemen kesmezler, müşteriyi dinlerler, çünkü müşterinin bir sıkıntısı vardır ama bu sıkıntıyı, onu halledeceğini düşündüğü çözüm olarak anlatıyordur.
Zaten iş süreçlerini soyut bir şekilde anlamak ve anlatmak müşterinin çok nadiren yapabildiği bir şeydir. Müşteri çoğu zaman, ihtiyacını değil, nasıl bir çözümün onu tatmin edeceğini ifade etme eğilimindedir ve bunu da çoğu zaman kullanıcı arayüzleri üzerinden yapmayı kolay bulur. Bu durumda müşterinin bahsettiği bu çözümü doğuran esas ihtiyaca, hatta ihtiyaçtan da bu ihtiyacın arkasındaki kök probleme (root cause) gitmeliyiz. Tecrübesiz analistler, müşterinin çizdiği çözümü aynen aktarırlar, Analistlerin olmayıp, kullanıcıların doğrudan programcılarla iletişimde oldukları durumlarda, pek çok programcı, kullanıcının istediği çözümü aynen geliştirme yönünde davranır. Bu durum ise nihayetinde tuttarsız, aynı şeyin bir kaç yerde yapıldığı, sürecin ıskalanıp yerine bir sürü “ekran”ın yanyana yığıldığı yazılımlara sebebiyet verir.
Müşteri ne kadar süreç odaklı düşünebiliyorsa ihtiyacını da o kadar soyut ve süreç cinsinden anlatır. Bu durumda gerçek sebebe, yani ihtiyacı doğuran gerçek probleme daha yakınız demektir. Fakat çoğu zaman kullanıcı ekranları seviyesinde konuşan bir kullanıcı ile karşı karşıya olabileceğimizi unutmayalım.
Bu durumlarda yapılacak şey bellidir, “neden/niçin” sorularını sormaya devam edip, katman katman giderek esas, kök probleme varmak. Karşı tarafı rahatsız etmeden, soracağınız 3-5 tane “neden” sorusuyla asıl ihtiyaca, oradan da ihtiyacı doğuran nedene ulaşabilirsiniz. Örneğin müşterinin “şuraya bir radyo buton koyalım ve kullanıcı, evet cevabı verise de şuraya koyacağımız listeden şunu şeçsin” şeklinde bir cümle sarfettiğini düşünelim. Burada yapılacak ilk şey, “neden bu iki arayüz elemanına ihtiyacınız var?” ya da daha açık olarak “buradan girilen bilgiyi ne yapacaksınız?” şeklinde sorular sormaktır. Muhtemelen kullanıcı şöyle cevap verecektir: “biz bu bilgileri şu raporda, şunu hesaplamada vs. kullanmak istiyoruz.” Bu durumda tecrübeli bir analist, o raporun ya da hesaplamanın ne iş yaptığını, kullanıcı için neden önemli olduğunu anlamalıdır. Çünkü belki o bilgi o raporda olmamalıdır, belki o bilgi farklı bir yerde farklı bir şekilde alınmalıdır, belki o bilgi zaten sistemin bir başka yerinde alınıyordur da o kullanıcının haberi yoktur, ya da o hesaplama aslında o bilgiye ihtiyaç duymuyordur, vs. vs. gibi pek çok durum söz konusu olabilir. Bu şekilde dibe doğru inen sorulardan sonra örneğin bu bilgilerin alınmasının devlet tarafından istenen bir durum olduğu ya da pazarlama biriminin yapacağı promosyonları yönlendirmek üzere kullanılacağı gibi sonuçlara varılabilir. İşte bu sonuçlar, gerçek problemi ortaya koyar.
Kullanıcı, işinin başı ile sonunu bir anda görme yetisine her zaman sahip değildir. O çoğu zaman, “şuraya koyalım şunları, sonra kullanırız” gibi de düşünüyor olabilir. Kullanıcın kafasındaki gerçek nedene ulaşamazsanız, cicili-bicili arayüzleriniz olur ama hala müşteri memnun değildir. Çünkü siz, müşterinin problemini çözmemiş, onun çözüm olduğunu düşündüğü şeyi yapmışsınızdır. Bu durumda analist “analitik olmak” yerine postacı olmayı seçmiş demektir. Analistlerin postacılık yapıp, herhangi bir analitik süreç işletmemeleri ise kullanılması zor, işe yaramayan bir sürü kullanıcı ekranına sahip, tutarlılığı düşük yazılımlar demektir. Bu yüzden müşteri her zaman haklı değildir ama onu bu şekilde konuşmaya ve davranmaya iten sebepler vardır.
Tecrübeli ve iyi niyet ve sistematik yaklaşıma sahip analistler, belli bir müddet çalıştıkları kullanıcıları eğitirler. Bu tür kullanıcılar bir süre sonra zaten kulanıcı arayüzleri yerine ihtiyaçlarına, hatta onları doğuran gerçek problemlere inmeyi, toplantılarda bunlar üzerinden konuşmayı öğrenirler. Bu durum ise analistin ve nihayetinde tüm takımın işini kolaylaştırdığı gibi, tekrarların önüne geçer, daha doğru ve kullanılabilen sistemler tasarlanmasını sağlar.
Analitik analistler ve sistematik kullanıcılarla yazılım projesinde bulunmak büyük bir keyiftir.
Toplam görüntülenme sayısı: 1213
Akin Yazılım Modelleme, Yazılım Mühendisliği
Bugünlerde UML’den bahsediyorken nasıl öğrenileceğinden bahsetmezsem ayıp olur diye düşündüm ve bu yazıya başladım.
En iyi UML kitaplarından birisi, Martin Fowler’ın UML Distilled‘dir. 2003 yılında 3. sürümünü yapmış bu kitap dilimize de “Rafine UML” olarak çevrildi ve ben de zamanında satın aldım çeviriyi. Malesef pek çok çeviri kitap gibi ne İngilizce ne de yazılım modellemesi konusunda yetkin birisi tarafından çevrilmiş. Bu konuda bu yazıya da bakabilirsiniz. Dolayısıyla bu kitaptan yararlanmak isteyenler için öncelikle Ingilizce aslını tavsiye ederim.
UML Distilled, 200’den az sayfada UML 1.x’in her diyagramını, o diyagramları oluşturmak için gerekli çalışmalarla birlikte son derece anlaşılır bir şekilde sunmakta. Kitap, UML’in 2.x sürümlerini kapsamasa da hala bence UML ögrenmek için, bildiklerim arasında, bir numaraları kaynaktır. Bu kitap yazılım geliştirme sırasında modelleme amacıyla UML’in nasıl uygulanacağını çok güzel ve kısa bir şekilde anlatır.
Giriş seviyesinde UML 2.0’i ele alan “Learning UML 2.0” ise O’Reilly’nin hem anlaşılır hem de pratik kitaplarından bir diğeri.
UML konusundaki bir başka güzel kitap da Meilir Page-Jones‘ın “Fundamentals of Object-Oriented Design in UML“dir. 2000 yılında piyasaya çıkmış olan bu kitap nesne-merkezli tasarımı nefis bir şekilde anlatırken UML’i de okuyucusuna öğretmektedir. Zaten Page-Jones eskiden bu yana çok teknik ve derin tasarım kitapları yazmaktadır. Bu kitap da nesne-merkezli paradigmanın en temel kavramalrından olan encapsulation, cohesion ve coupling kavramlarını akademik ve pratik olarak açıklamaktadır.
UML kullanarak yazılım geliştirme konusunda bir başka güzel yazar ise ABD’den benim de hocam olan Hasan Gomaa‘dır. Kendisinin “Designing Concurrent, Distributed, and Real-Time Applications with UML” isimli kitabını ben yıllarca elimden düşürmedim. Zaten kitabı da GMU’da verdiği “Software Modeling and Architectural Design” isimli ders sayesinde almıştım. Hasan hoca bu kitabın yeni sürümünü “Software Modeling and Design: UML, Use Cases, Patterns, and Software Architectures” ismiyle 2011 yılında çıkardı. Bu kitabını okuttuğu dersinin ikinci kaynağı da yukarıda bahsettiğim UML Distilled’dir. Hasan hoca bir akademisyen olmasına rağmen kitapları son derece pratik ve uygulanabilir bir şekilde yazılmıştır.
Scott Ambler’ın “Elements of UML 2.0 Style” kitabı da küçük ama hoş bir kitaptır. Daha etkin UML kullanımmak amacıyla okuyabilirsiniz.
Türkçe olarak UML üzerine yazılmış tek bir kitap biliyorum: UML ile Nesne Tabanlı Çözümleme ve Tasarım. Yazarı Bora Güngören olan bu kitap, dilimizdeki nadir güzel yazılım kitaplarından birisi. Kitap adından da anlaşılacağı gibi aslen UML üzerine değil; nesne tabanlı çözüleme (analiz) ve tasarımı ele alırken tabi olarak UML’i kullanıyor. Kitap da zaten temelde kullanım şekli (use case) tabanlı analiz, yazılım mimarisi tasarımı ve fonksiyonel tasarıma odaklanmış durumda. Kitap 2009 yılında basılmış ama yazarının yeni baskısı üzerine çalıştığını biliyorum.
Bahsettiğim kitapların içeriğinden de anlayacağınız gibi, UML’i tek başına notasyon olarak öğrenmeye çalışmak çok da anlamlı değildir. UML ancak yazılım geliştirme sürecinin farklı noktalarında anlam kazanır. Bu yüzden her ne kadar “The Unified Modeling Language Reference Manual” ya da “The Unified Modeling Language User Guide” vb. isimli kitaplar olsa da kitapların ciddi bir kısmı bir UML referans kitabından öte analiz ve tasarım kitaplarıdır.
Bu kitapların büyük çoğunluğunu internette online olarak da bulabilirsiniz.
Bol modelli ve UML’li projeler dilerim.
Toplam görüntülenme sayısı: 2889
Akin Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği
Bir önceki yazıya, kaldığımız yerden devam edelim ve “yazılımcı/programcı olmak için bilgisayar mühendisliği okumak gerekli midir?” sorusunun cevabını araştıralım.
Bence üniversite kişiyi, kendini eğitebilir, kendi yolunu bulabilir bir noktaya getirmesi açısından önemlidir. Bir konuda yoğun bilgi ve metot aktarımı dışında ve sistemli çalışma, araştırma disiplini kazandırması, analitik düşünme becerilerini geliştirmesi, belli konuları etraflıca düşünebilme ve tartışabilme yeteneği kazandırması vb. açılardan üniversite okumak önemlidir. Bu konuda “hangi üniversite” sorusu malesef bu ülke için hala çok önemli. Üniversitelerimizin durumunu ve akademisyenlerimizin halini düşününce tabi olarak bu soru öne çıkıyor. Malesef gözlemim o ki ülkemizdeki akademik kurumlar ve akademisyenler, sınıflarındaki insanları heyecanlandırmaktan, onlara liderlik yapmaktan, bilgi kazandırırken beceri ve vizyon da kazandırmaktan uzaklar. Bu durum da en iyi okullarda bile gençleri dersten uzaklaştırıyor. Bunun çok iyi farkındayım. Şimdi bu konuyu kenara koyup “hangi bölüm” konusuna gelelim.
Bence herkes sevdiği ve yetenekli olduğu, adını duyunca heyecanlandığı bölümü okusun. Ama Cem Yılmaz’ın dediği gibi filmlerdekileri görüp itfaiyeci olmaya karar verenler gibi de olmayalım, tercihlerimizin gerçekliğini, bize ne kadar uyduğunu değerlendirelim. Bu konuda yazılımcı/programcı olmanın en temel yolu tabi olarak Bilgisayar Mühendiliği okumaktır. Bunu çok da tartışılacak bir tarafı olduğunu düşünmüyorum. Yani doktor olmak istiyorsan tıp, dişçi olmak istiyorsan diş hekimliği, hariciyeci olmak istiyorsan uluslararası ilişkiler okumak ne kadar anlamlıysa, yazılımcı olmak için BM okumak da o kadar normal bence.
Lakin BM okumak yazılımcı olmanın tek yolu degil. Bunun için bence pek çok farklı yol var. Açıkçası, BM ile ilgili etrafta pek çok yalan-yanlış malumat dolaşıyor. Bunu tartışmak bu yazının konusu değil ama burada örneğin konu ile ilgili güzel bir yazı var.
Ayrıca geç de olsa detayına girmeden yazılımcı olmaktan kastın büyük çoğunlukla yazılım geliştirici yani developer ya da programcı olmak manasına geldiğini düşündüğümü ifade edeyim. Bunun yanında analist, tester, network veya database yöneticiliğini de bu kapsamda ele alıyorum.
Bence matematik-fizik gibi bölümlerde okuyanlar, okul sırasında alacakları ek derslerle kendilerini yazılımcı olarak konumlandırabilirler. Benzer şey Elektrik-Elektronik, Endüstri gibi mühendislikler için de geçerli. Özellikle de günümüzde farklı bölümlerden ders almak, çift anadal ya da minor yapmak kolaylaştığı için, gayretli, disiplinli kişilerin BM bölümlerine giremeseler bile bu yolu tutmaları halinde başarılı yazılımcı adayı olabileceklerini düşünüyorum. Özellikle Endüstri M. mezunlarının yazılım projelerinin iş-business tarafında bulunmamaları için hiç bir sebep görmedigim gibi BM dahil diğer pek çok bölüme göre bu pozisyonlarda daha başarılı olacaklarını düşünüyorum. Bu bölümlerin ortak tarafı son derce yoğun matematiksel soyutlamalarla eğitim görüyor olmaları ve zaten ders programlarında belli bir miktar bilişim derslerine sahip olmaları. Matematiksel yoğunluk açısından düşünüldüğünde makine ya da inşaat gibi bölümlerde okuyanlar da benzer imkanlara sahipler bence fakat sanırım ders programları daha uzak. Bu şekilde yazılımcı olarak çalışan bir sürü isnan bir bu ülkede ve dünyada.
Bu gibi bölümlerden mezun olup, BM ve benzer bölümlerde master yapmak da bence iyi bir fikir. Temel matematiksel bilgi ve düşünme yeteneklerine sahip bir kişi yaklaşık 8-10 ders ile BM formasyonunu rahatlıkla kazanabilir. Bu da bir mastera karşılık gelir zaten. Operating Systems, Algorithms and Data Strutures, Database Managament Systems, Programming Languages, Networking, Compilers vb. dersleri master seviyesinde almak, bu sırada pratik olarak bazı programlama dillerinde kendini geliştirmek bence iyi bir plan olur. Tabi masteri, askerliği geciktirmek için yapılan bir masraf olarak görmememiz lazım.
Örneğin ben İTÜ’de Elektronik ve Haberleşme Mühendisliği okudum. Bu bölümde aldığım sağlam matematik dersleri, yüksek matematik olsun, lineer cebir, olasılık vb. dersler olsun hatta nümerik analiz vb. dersler bana matematiksel soyutlamaları öğretti. Bölümüm gereği, elektronik bağlamında aldığım devre analizi ve sentezi, logic tasarım vb. dersler ya da bir diyotun ya da transistörün fiziksel çalışması ve bunlarla ilgili farklı matematiksel modellerin anlatıldığı dersler, matematiğin gerçek dünyada nasıl kullanılabileceği konusunda bana sayısız örnekler sundu. (Tabi İTÜ’nün, anlaşılmasına- özümsenmesine önem vermeden bilgi yığma odaklı sisteminden çok müzdarip oldum. Liseden gelmiş bir genten daha 3. döneminde Maxwell denklemlerini anlamasını beklemek ki sonuçta bu geçmiş senelerde çıkan soruların cevaplarını ezberlemeye dönüşüyor, sanırım bu ülkedeki üniversitelere has bir şey. Nihayetinde iyi ya da kötü, dünya için değil ama bu ülke için iyi bir eğitim aldığımı düşünüyorum. Zaten bu ülkede çok az kimse neyi ne kadar bildiğinle ilgileniyor.)
Sonrasında gittiğim ABD’de masterda BMde algoritmalardan programlama dillerine, veri tabanından dağıtık sistemlere kadar temel dersleri aldım. Sonrasında da çalışırken devam ettiğim Yazılım Mühndisliğinde ihtiyaç analizinden nesne-merkezli tasarıma, proje yönetimine kadar süreç odaklı dersler aldım ve bilgi ve beceri olarak gelişmeme müthiş katkıda bulundu.
Ciddi kaliteli yazılımcı iş gücü açığının olduğu ülkemizde ve dünyada master yaparak yazılımcı olmak bence iyi bir fikir ve değerlendirilmeli.
İki senelik meslek yüksek okullarından mezun olanların mezuniyet sonrası geçişle BM diploması almaları hem bilgi ve yetkinlikleri hem de piyasada bulunmaları açısından bence önemli. Çünkü bu ülkede, özellikle de bizim sektörde bir “dört senelik bölüm” fetişizmi hüküm sürüyor. Bu bölümlerden mezun arkadaşların pek çok yere yaptıkları başvurular daha IK’dan geri dönüyor. Meslek yüksek okullarından mezun, kendini yetiştirmiş ve meraklı gençlerin yazılım sektöründe, İngilizcelerinin olması durumunda, yapamayacakları bir iş olduğunu düşünmüyorum. Ama yukarıda bahsettiğim takıntımızdan dolayı mühendislik derecesini almaları yerinde olacaktır.
Üniversitelerde değişik adlar altında olup da bilişim dünyasına yönelik farklı ağırlıkta eğitim veren bölümler de bence yazılımcı olmak isteyenler için fırsattır. Örneğin Bilkent’deki “Bilgisayar ve Bilişim Sistemleri Teknolojisi” son derece pratik bir eğitim sistemine sahip. “Yönetim Bilişim Sistemleri” (MIS) adı altındaki bölümler, BMe göre daha hafif bir bilişim eğitimi veriyorlar ama buradaki arkadaşların yazılımcılık taraflarını geliştirmek için avantajları çok bence. Nitekim bu bölümlerden mezun olup developer-programcı olarak çalışan olduğu gibi, analist, tester vb. sorumluluklarla çalışanlar muhtemelen daha fazladır. Bu tip bölümler mezunlarının daha iş odaklı ortamlarda bulunmalarına imkan tanıyor. Bu yüzden örneğin BI (business intelligence) ya da veri analizi (data analysis) gibi konularda çalışmaları, bir BM mezununa göre çok daha rahat oluyor. Benzer şekilde ilgili öğretmenlikler de ilgili ve tutkulu ama hasbel kader bu bölümlere puanı yetmiş arkadaşlarımız için fırsattır. BMde master yapma, konu ile ilgili daha yetkin olmak içın yine bir alternatiftir diye düşünüyorum.
Ülkemizde Yazılım Mühendisliği bölümleri de var. Ama malesef gerek yazılım mühendisliği pratiklerinin bu ülkede uygulanmaması gerek ise bu ülkede verilen YM eğitiminin gerçeklikten uzaklıği gibi sebeplerden dolayı, bu bölümlerden mezun olanların işe girmede BMden mezun olanlardan bir farkı olacağını düşünmüyorum. Yani kimse YM mezunlarını bu ülkede use case yazsın, ya da modelleme yapsın diye işe almayacaktır. Ben YM danışmanlığı ve eğitmenliğinden para kazanan birisi olarak bu bölümleri önemsiyorum ama malesef faydaları konusunda çok da umutlu değilim. Hatta YM eğitiminin, MBA gibi yüksek lisans seviyesinde verilmesinin daha doğru olacağını düşünüyorum. Piyasada ciddi bir tecrübe edinmiş kişilerin, yazılım geliştirme süreçleriyle ilgili bir formasyona sahip olmaları bu bölümü liseden hemen sonra okumaktan çok daha faydalı olacaktır.
Nihayetinde, ülkemizin iyi yetişmiş, teorik bilgisi sağlam, piyasada doğru tecrübelerle bezenmiş, yetkin yazılımcılara ihtiyacı var. Bu gibi kişilerin hem ülkemizde hem de yabancı ülkelerde önleri çok açık.
Toplam görüntülenme sayısı: 16253