Java

İ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ı: 2254

Programcı Olmak ve Anlamak Üzerine

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

Bu blogda sıklıkla programlamanın ve yazılımın tabiatı üzerine bir şeyler yazıyor, üstatlardan alıntılar yapıyorum. Aslen vurguladığım şey, programcı olmak her şeyden önce, anlamaktır. Bunları bir araya toplamak istedim, elime geçtikçe buraya ekleyeceğim. Zevkle okuyun:

Martin Fowler, Refactoring isimli kitabında şöyle der:

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.)

Max Kanat-Alexander, Code Simplicity isimli kitabına şu cümlelerle başlar:

İ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.)

Programlama dünyasının kurucularından Donald Knuth şöyle diyor:

Bir program yazdığınız zaman, onu aslen bir edebiyat eseri olarak düşünün. Çünkü, insanların okuyacağı bir şey yazmaya çalışıyorsunuz. Onu, bilgisayarın uygulayacağı bir şey olarak düşünmeyin. Programınızı okunur kılmakta ne kadar başarılı olursanız, programınız o kadar başarılı olacaktır: Programı, bugün anlayacakınız, önümüzdeki hafta anlayacakınız, ve o program üzerine çalışıp, onu değiştirecek olan, sizden sonra gelenler anlayacaklar.

(When you write a program, think of it primarily as a work of literature. You’re trying to write something that human beings are going to read. Don’t think of it primarily as something a computer is going to follow. The more effective you are at making your program readable, the more effective it’s going to be: You’ll understand it today, you’ll understand it next week, and your successors who are going to maintain and modify it will understand it.)

Devamlı, anladığımız ve etrafımızdakilerin anladığı programlar yazmak umuduyla.

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

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

Statik Metotlu Sınıf mı Yoksa Singleton mı? – I

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

Nesne-merkezli dillerde çok tartışılan konulardan birisi de hiç nesne oluşturmaya gerek bırakmadan kod yazmamızı sağlayan statik özellikler ve metotlar mı yoksa sadece bir tane nesne oluştuğundan emin olup, bu tek nesne üzerinde çağıracağımız nesne özellikleri ve metotları mı? Bu probleme kısaca statik-singleton (static vs. singleton) de denir çünkü tasarım kalıplarında, bir sınıftan sadece bir nesne oluşturmaya “singleton” yani “tekil” denir.

Bence statik kullanımı, tabi özellikle statik metot kullanımı, nesne-merkezli dillerin, yanlış kullanıma en fazla konu olanı ya da bir başka deyişle suistimale uğrayan alanı. Malum, loglama vb. utility metotlarını, üzerinde bulunduğu sınıfın nesnesini oluşturmadan hızlıca kullanmak isteriz. Örneğin aşağıda üzerindeki metotları statik olarak tanımlanmış ve bu yüzden de bu metotları kullanmak için nesnesine ihtiyaç duymayacağımız bir Log sınıfı vardır:

public class Log{
	
	public static void logInfo(String infoString){...}
	
	public static void logError(String errorString){...}

        ...
}

Bu sınıfın kullanım örneği de şöyle olabilir:

public class Client{
	public void doThis(){
                ...
                ...
               if(...)
                  Log.logInfo("...");
               else
                  Log.logError("...");
	}
}

Statik metotlara sahip böyle bir sınıfı kullanmanın kolaylığı çok açıktır: Sınıfın kendisini nesne gibi kullanmak. Dahası o tek nesneyi herhangi bir yere geçmenize bile gerek yok, doğrudan sınıfın üzerinden statik alanlara ve metotlara ulaşabilirsiniz.

Eğer yukarıdaki Log sınıfının metotlarını statik yapmak istemezsek ve bu sınıfın sadece bir tane nesnesinin olacağını planlıyorsak bu durumda Log sınıfını singleton olarak şöyle kodlardık:

public class LogSingleton{
	private static LogSingleton logger = new LogSingleton();
	
	private LogSingleton(){...}
	
	public static LogSingleton getInstance(){
		return logger;
	}
	
	public void logInfo(String infoString){...}
	
	public void logError(String errorString){...}
}

Bu durumda da yukarıdaki Client sınıfı şu şekilde değişirdi:

public class Client{
        private LogSingleton logger;

        public Client(){
                logger = LogSingleton.getInstance();
        }

	public void doThis(){
                ...
                ...
               if(...)
                  logger.logInfo("...");
               else
                  logger.logError("...");
	}
}

Şimdi soru şu: Hangi yöntemi kullanmalıyız?

Bazı diller bu ikilemi baştan çözmüşler ve yapılarına statik özellikler almamışlar. Örneğin Scala’da statik metotlu sınıf tanımlamanız mümkün değil, bunun yerine “object” anahtar kelimesiyle nesne tanımlıyorsunuz. Olan biten şey, Scala size doğrudan bir nesnesi olan sınıf tanımlamanızı sağlıyor. Güzel bir çözüm. Java, C#, C++ gibi dillerde ise statik kullanımı söz konusu olduğundan bu tartışma da geçerlidir. Bu durumda sizce hangi kullanımı tercih etmeliyiz ya da siz hangisini tercih ediyorsunuz? Statik metotlar mı yoksa singleton nesne mi?

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

«< 14 15 16 17 18 >»