Java Kitapları Üzerinde – İngilizce Kaynaklar

Java

Sıklıkla Java kitapları hakkında sorular geliyor bana. Bu konuyu bilgim dahilinde biraz yazmak istiyorum ama önce bir şeyi hatırlatayım. Eskiden kitapları daha yakından takip ederdim çünkü o zaman bu kadar çok Java kitabı yoktu. (Geçen gün bir vesileyle yaptığım ufak bir araştırmada Amazon’da Java için 22,710, C++ için 7,322, Python için 3,975, C# için ise 5,016 kitap sonucu geldi. İngilzice dünyasında yayınlanmış bu kadar Java kitabını takip etmek için Oracle’da kütüphaneci falan olmak lazım.) Ama yine de Java’ya yeni başlayanlar içın bildiğim kadarıyla bir kaç şey söylemek isterim.

Burada bahsedeceğim kaynaklar, temel Java yani Java SE ile ilgili ve İngilizce olanlar, bunu baştan belirteyim. Türkçe kaynaklarla ilgili daha sonra yazacağım.

Java’ya baştan başlayacaklar için bence en iyi kaynak hala Java Tutorial‘dır. Malum bunun hakkında daha önce de bir şeyler yazmıştım. Tutorial olduğundan kendi kendine ögrenecekler için de nefis bir kaynaktır. İngilizcesi son derece basittir, örneklerini Netbeans projesi olarak çalıştırabilirsiniz. Java Tutorial sık sık güncellenmektedir, ara sıra ziyaret edip son halini indirebilirsiniz.

Java’yla bir süredir haşır- neşir olup da daha ciddi olarak, “nasıl”dan ziyade “neden”le ilgilenenler için Bruce Eckels’in “Thinking in Java“sı var aklımda. Bu kitap ilk çıktığında hem elektronik versiyonu erişilebilir durumdaydı hem de ciltli hali satıştaydı. Ve ben gidip satın alıp satır-satır çizerek okuduğumu hatırlıyorum. Muhtemelen Java ile ilgili beni en fazla doyuran kitap bu olmuştur. 4. ve son baskısı 2006 tarihli olan bu kitabı okumak zaman alır ama çok şey kazandırır. Bu kitabın 3. baskısı hala burada erişilebilir durumda. 4. baskısının ise bazı kısımlarına buradan erişebilirsiniz.

Malum, Eckels’in “Thinking C++” kitabı da klasikler arasındadır. Hatta kendisinin hem C++ hem de Java üzerine seminerleri var ve CD ile bu seminerleri satıyor. (Hatta ben zamanında $200’a bu CDleri satın almıştım. Henüz ABD’den yeni dönmüştüm ve bu ülkeyi daha pek tanımıyordum 🙂 Eminönü’ndeki alt geçitte baktım birileri bir sürü program vs. CDsi satıyor. Üzerinde Java yazanı sanırım 500 bin TLye satın aldım ve bilin bakalım içınden ne çıktı? Bruce abinin $200’a sattığı seminerleri 🙂 ) Dolayısıyla hem seminerleri hem de kitapları Internet’te elektronik formatta çok hızlı bir şekilde bulunabilir durumda. Sağlam Javacı olmak isteyenler, iyi bir nesne-merkezli anlayış geliştirmek isteyenler için bence düşünülmesi gereken bir kaynak.

Joshua Bloch’un “Effective Java” kitabı da vazgeçilmezler arasındadır bence. Etkin, temiz ve kaliteli Java kodu için kaçırılmamalı. Ama unutmayın bu kitap Java’yı bir kaç sene kullandıktan sonra okunmalıdır.

“Head First Java“yı ben okumadım ama çok methini duydum. Ben “Head First” terimini dilimize “lise öğrencileri için” diye çevirmeyi tercih ediyorum 🙂 Dolayısıyla kendi kendine öğrenim için çok uygun duruyor.

“Core Java” da taa Java’nın ilk günlerinden bu yana yayınlanan kitaplardan. Uzun süredir de 2 cilt olarak basılıyor ve şu anda 9. baskısını yapmış durumda. İki ciltte pek çok konuyu ayrıntılı olarak ele alıyor. Baştan sona okunacak bir kitap değil ama başvuru kaynağı olarak elinizin altında bulunabilir.

Java’da ilerleyen arkadaşlar, Java speclerini okumayı, en azından elinin altında bulundurup zaman zaman bakmayı düşünmeliler. Java SE’nin speclerine buradan ulaşabilirsiniz. Specleri okumak zordur ama en sağlıklı bilgiler de oradadır.

“The Elements of Java Style“,  küçük bir cep kitabıdır ama elinizden düşüremezsiniz okumaya başlayınca. Clean Code yazmak için birebirdir. Araç kullanmıyorsanız, işe gidip gelirken serviste mesela bir kaç günde okuyup bitirirsiniz, sonraki 1-2 yılda da öğrendiklerinizi uygulamaya çalışırsınız.

Bir de Bilgisayar Mühendisliği (ABD’de Computer Science) bölümlerinde programlamaya giriş derslerinde Java ele alındığında kullanılan, daha akademik kitaplar var. Örneğin kitap fabrikası olan Deitel ailesinin “How To Program” serisinden olan “How To Program Java” kitapları. Hemen iki senede bir yeni versiyonu çıkan, ticari başarı için yarışan, gereksiz detaylı ve aşırı hacimli olmasından dolayı insanda “bitmez bu kitap” şeklinde bir his oluşturan bu tür kitapları açıkçası sevmiyorum da tavsiye etmiyorum da. Malesef ülkemizde, ABD’de de, bu kitabı kullanan bayağı bir okul var. Deitel’lerin kitabı aslen nesne kavramını son derece geciktiren bir yapıdaydı, bundan dolayı yenilerde “early objects” versiyonunu da çıkardılar. Bence bu tür sanırım sadece ders için okunur.

Java öğrenmeye daha sıkı giriş yapmak isteyenler sertifika sınavlarına yönelik yazılmış kitapları tercih edebilirler. Bu tip kitapların bol sorulu yapısının, programlama yapmayı öğretmekten ziyade sertifika sınavına hazırlamak amaçlı olduğunu unutmamak gereklidir.

Java’yı ya da bir başka programlama dilini öğrenmek için, konuşma ya da yazma seviyesinde olmasa da okuma seviyesinde bir İngilizceye ihtiyacınız vardır. (İşin açıkçası, Türkiye’deki imkanlarla, çok özel dil ve yazma yeteneğine sahip değilseniz ne yaparsanız yapın, akıcı şekilde konuşmanız çok zor, zaten gerek te yok bence.) İngilizce, öğrenmeyi ertelediğiniz her an size Java vb. teknolojileri öğrenme konusunda ayağınıza bağ olmaya devam edecektir. Halbuki teknik kitapları okuyacak derecede İngilizce öğrenmek çok zor değil. Bu yüzden, yaşınız ne olursa olsun, İngilizceye 1-2 senede biraz vakit ayırarak, bir şekilde halledin derim.

Okumak, okuyarak gelişmeye devam etmek malesef toplum olarak çok benimsediğimiz bir davranış değil. Habuki Java ve benzeri teknik konularda düzenli kitap okuyan kişi, bir topluluk içinde çok cabuk farkediliyor. Bol okuyan yazılımcılara ihtiyacımız var.

 

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

İstek mi İhtiyaç mı Yoksa Problem mi? – II – Müşteri Her Zaman Haklı mıdır?

İş 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ı: 1220

UML’i Nasıl Öğrenebiliriz?

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ı: 2919

«< 33 34 35 36 37 >»