Acı Çekmeden Üstad Olunmaz

Her sektörün kendi guru, üstad, pir olarak görülen zatları var. Yazılım sektöründe de durum farklı değil. Şöyle başımızı kaldırıp devleşmiş bir üstada baktığımızda, bu adam nasıl bu kadar yetenek, kabiliyet, bilgi ve beceri sahibi olabildi diye bir soru aklımıza gelir. Aynı zamanda kendimizin bu devin yanında ne kadar küçük kaldığımızı görür, saklanacak bir yer aramamıza bile gerek kalmadan onun yanında kaybolup gideriz. Örnek mi ver diyorsunuz: Robert C. Martin, Kent Beck, Peter Norvig. Ne milletten oldukları önemli değil. Bu listede birgün mutlaka Türk yazılımcılarının da ismi yer alacak. Önemli olan nasıl üstadlaşabildikleri.

Bir yazılımcı üstad olarak mı doğdular? Yoksa ultra zekiler mi? Yaratan onlara daha mı özen gösterdi? Eğer öyle ise, neden ben ya da siz değil de, onlar? Bu soruların cevabı düşündüğümüzden daha kolay. Sizden ve benden bir farkları yok. Aynı fizyolojik özelliklere sahibiz. Onları farklı kılan bir sey var: üstad olmanın bedelini ödediler. Bu bedeli nasıl ödediklerini inceleyelim.

Noel Tichy’nin kişisel gelişim için tanımladığı üçlü çemberi tanıyor musunuz?

Noel Tichy’ye göre kişisel gelişimin sağlandığı saha Learning Zone olarak isimlendirdiği ikinci çember. Bu çember bireyin yetenek, bilge ve becerilerinin yetmediği alanı tanımlıyor. Birey bu sahaya geldiğinde, daha önce tanımadığı şeylerle karşılaştığı için bunları öğrenmek zorunda kalıyor. Comfort zone olarak tanımlanan en içteki cember bireyin kendisini geliştirmesinin mümkün olmadığı saha, çünkü birey bu sahada hakim olduğu aktiviteleri tekrarlıyor. Bildiği şeyleri tekrarlaması ona bir şey katmıyor. En dışta bulunan çember, bireyin olup bitene anlam veremediği, gidişatı kavrayamadığı, kısaca karşılaştığı durumun onu panik ettiği sahayı tanımlıyor.

Kendimizi geliştirebilmemiz için Comfort Zone’dan çıkıp, Learning Zone’a girmemiz gerekiyor. Bu ne yazık ki o kadar da kolay bir şey değil. Birincisi Comfort Zone’dan çıkmak demek, bilinmeyene doğru gitmek demek. Buna birey içgüdüsel olarak karşı koyabilir, çünkü bu geçiş bireyin içinde huzursuzluk ve tedirginlik yaratabilir. Ayrıca bu geçis bireyi akli ve ruhi açıdan çok zorlayabilir. İkincisi Learning Zone’un yeri devamlı değişiyor. Ne zaman Learning Zone’da, ne zaman Panic Zone’da olunduğunu kestirmek kolay olmayabiliyor.

Bireyin kendisini devamlı zorlayarak Learning Zone içinde kalmaya çalışması kısaca acı çekmesi anlamına gelmektedir. Kendi kişisel gelişimi için icat ettiği tüm aktiviteleri Learning Zone’da kalacak şekilde şekillendirmesi gerekmektedir. Bu bireyi zihinsel ve ruhsal olarak çok yorar. Devamlı sınırları zorlamak kolay değildir. Ama sınırları devamlı zorlamadan kişisel gelişimde yol kat etmek mümkün değildir.

Beşer ile üstad arasındaki fark burada yatmaktadır. Müstakbel üstat emin adımlarla her daim Learning Zone ve Panic Zone’da cirit atarken ve bunu yıllar boyunca hiç yılmadan yaparken, beşer yer, içer, yatar ve üstadlara hayran olur, ama kendisinin bu yüksekliklere ulaşmasının imkansız olduğunu düşünür, çünkü ya Learning Zone’un varlığından bihardir ya da sınırları devamlı zorlayacak cesareti yoktur. Beşer olarak hayatını sürdürür, üstad gibi ölümsüzleşmenin sadece rüyasını görebilir. Ama bir üstad olmak düşündüğü kadar zor değildir.

Bir örnek üzerinde bir programcının Learning Zone’a nasıl geçip, orada kalabileceğine değinmek istiyorum. Yazılımda usta ya da üstad olmanın bir yolu da iş haricinde pratik yapmaktan geçer. Bunun en iyi örneğini kod kataları teşkil eder. Programcı bir katayı ilk defa uyguladığında hemen Learning Zone’a geçer. Katayı her tekrarlayışında tekrar tekrar Learning Zone’a geçtiğine şahit olur, çünkü her tekrar ona yeni bir şeyler öğretir. Belli bir zaman sonra programcı öğrenebileceği birçok şeyi öğrenir ve içinde bulundugu Learning Zone onun için Comfort Zone haline gelir. Artık Learning Zone’un yeri değişmiştir. Programcının katayı harfiyen tekrar tekrar uygulaması ona yeni bir şeyler katmaz. Artık tekrar katayı değiştirerek yeniden Learning Zone’a geçmesi gerekmektedir, aksi taktirde olduğu yerde saymaya başlayacaktır. Programcı örneğin katayı başka bir programlama paradigması ile yeniden şekillendirebilir. Bu programcıyı tekrar Learning Zone’a katapult eder. Programcı yepyeni bir dünyayı keşfetmeye ve kişisel sınırlarını zorlayıp, aşmaya başlar.

Kendimden bir örnek vereyim isterseniz. Bu satırları yazarken Learning Zone içindeyim, çünkü düşüncelerimi ifade edebilmek için muazzam zorlanıyorum. Bunu hissediyorum. İçimde devamlı bir güç yazıyı yarım bırakarak yazmamı engellemeye çalışıyor, çünkü gidişattan hoşnut değil. Tanımadığı bir şeyler olup bittiği için zorlanıyor ve beni yazmaktan alıkoymaya çalışıyor. Bu güç benim Comfort Zone’da geride bıraktığım yazı yazma yetilerim. Onları geliştirmek için bu ve bunun gibi bir milyon yetmiş altı bin sekiz yüz doksan yedi yazı daha yazmam gerekiyor. İşte bu güç bunun bilincinde olduğu için, neden acı çekip Learning Zone ya da Panic Zone’da kalmak istiyorsun diyor ve beni devamlı Comfort Zona’a geri çekmeye çalışıyor.

Üstad olarak gördüğümüz her şahıs bu hale gelebilmek için yeterince acı çekip, bedelini ödedi. Bu acılar sadece bir iki gün, bir iki hafta, bir iki ay ya da bir iki yıl değil, onlarca yıl çekildi. Peter Norvig “Kendine on senede programlamayı öğret başlıklı yazısında her hangi bir dalda ustalaşmanın on sene gerektirdiğini söylüyor. Altını çizdiği ve bu yazının konusu olan bir şey daha söylüyor:

“The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again.”

Kabaca tercüme edecek olursak: “Tartarak pratık yapmak işin sırrı: sadece tekrarlamak değil, mevcut sınırları zorlayacak bir aktivite seçip denemek, analiz etmek ve hataları düzeltmek ve akabinde tekrar etmek ve tekrar etmek.”

Üstat olmak imkansız değil. Bunun için yüksek IQ ya da yetenek gerekli değil. Ama acı çekip bedelini ödemeden kimse olamaz.

EOF (End Of Fun)
Özcan Acar

Detayları Görebilmek Ya Da Görememek

Robert Martin Transformation Priority Premise – Transformasyon Öncelik Teorisi başlıklı yazısında yeniden yapılandırmaya (refactoring) karşı yöntem olan kod transformasyonuna değiniyor. Refactoring uygulamanın dışa gösterdiği davranış biçimini değiştirmeden kodun yeniden yapılandırılması anlamına gelirken, kod transformasyonu uygulamanın davranış biçimini yeniden şekillendirmek için kullanılan bir yöntemdir.

Benim kod transformasyonlarını bilinçli bir şekilde algılamam kod kataları yapmaya başladığım zamana denk gelir. Daha önce de test güdümlü yazılım yaparken kod transformasyonlarına şahit olmuştum, lakin kod kataları ve Robert Martin’in yazısı aracılığı ile transformasyon sürecinin nasıl işlediğini daha iyi algılama fırsatı buldum.

Bu konuda lafı fazla uzatmadan kod transformasyonunun ne olduğunu bir örnek üzerinden sizlerle paylaşmak istiyorum. Aşağıda yer alan kod prime factor katasından alıntıdır. Bu kata bünyesinde herhangi bir rakamın asal sayı (prime number) olan faktörleri hesaplanmaktadır. Bir asal sayı sadece bire ve kendisine bölünebilir. 2,3,5,7,11,13 asal sayılardır. Örneğin 10 rakamı 2 ve 5 asal sayı faktörlerinden oluşur. 6 rakamının asal sayı faktörleri 2 ve 3’dür. Kata bünyesinde oluşturulan generate() metoduna kod transformasyonları aracılığı ile herhangi bir rakamı oluşturan asal sayı faktör listesini oluşturabilecek kabiliyet kazandırılır. Kata için oluşturduğum birim testi aşağıda yer almaktadır:

[source language=’java’]
package com.kodkata.kata.primefactor.kata;

import static com.kodkata.kata.primefactor.kata.PrimeFactorz.generate;
import static java.util.Arrays.asList;
import static org.junit.Assert.assertEquals;

import java.util.Arrays;
import java.util.Collection;
import java.util.List;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

@RunWith(Parameterized.class)
public class PrimeFactorTest {

private List list;
private int expected;

public PrimeFactorTest(List list, int expected) {
this.list = list;
this.expected = expected;
}

private static List list(Integer… integers) {
return Arrays.asList(integers);
}

@Test
public void generate_as_expected() throws Exception {
assertEquals(list, generate(expected));
}

@Parameters
public static Collection testData() throws Exception {

return asList(new Object[][] { { list(), 1 }, { list(2), 2 },
{ list(3), 3 }, { list(2, 2), 4 }, { list(5), 5 },
{ list(2, 3), 6 }, { list(7), 7 }, { list(2, 2, 2), 8 },
{ list(3, 3), 9 }, { list(2, 5), 10 }, });
}
}

[/source]

Bu parametrik JUnit test sınıfı testData() bünyesinde yer alan veri listesini kullanarak, generate_as_expected() test metodunu koşturmaktadır.

İlk birim testi { list(), 1 } veri kümesi ile 1 rakamı için yapılmaktadır. 1 rakamının asal sayı faktörü yoktur, yani generate() metodu boş bir listesi geri döndürmelidir. Bu testi oluşturduktan sonra aşağıdaki şekilde generate metodunu oluşturuyorum.

[source language=’java’]
public static List generate(int i) {
return null;
}
[/source]

Burada ilk kod transformasyonunu görmek mümkün. Ortada hiçbir kod yokken, bir metot oluşturdum ve metodu null değerini geri döndürecek şekilde yapılandırdım. Robert Martin atılan bu ilk adımı ( {}–>nil ) şeklinde tanımlıyor.

Testin geçebilmesi için kodu aşağıdaki şekilde dönüştürmem (transform) gerekiyor:

[source language=’java’]
public static List generate(int i) {
return Collections.EMPTY_LIST;
}
[/source]

Bu dönüşüm ( nil->constant ) şeklinde ifade edilebilir. Birinci testin geçebilmesi için yapmamız gereken sadece boş bir listeyi (constant) geri döndürmektir.

İkinci test için { list(2), 2 } veri kümesini kullanıyorum. generate() metodu 2 rakamını parametre olarak aldığında, bünyesinde 2 rakamı olan bir listeyi geri döndürmeli. Bu testin geçebilmesi için kodu aşagıdaki şekilde dönüştürmem gerekiyor.

[source language=’java’]
public static List generate(int i) {
List primes = new ArrayList();
if (i > 1)
primes.add(2);
return primes;
}
[/source]

Bu dönüşüm ( unconditional->if ) şeklinde ifade edilebilir. Testin geçebilmesi için en basit olan çözümü seçtim. Bu durumda en basit çözüm if kullanarak 2 rakamını listeye eklemek. Tetiklediğim iki kod transformasyonu iki testin geçebilecek seviyeye gelmesini sağladı.

Üçüncü test için { list(3), 3 } veri kümesini kullanıyorum. generate() metodu 3 rakamını parametre olarak aldığında, bünyesinde 3 rakamı olan bir listeyi geri döndürmeli. Bu testin geçebilmesi için kodu aşağıdaki şekilde dönüştürmem gerekiyor.

[source language=’java’]
public static List generate(int i) {
List primes = new ArrayList();
if (i > 1)
primes.add(i);
return primes;
}
[/source]

Bu dönüşüm ( constant->scalar ) şeklinde ifade edilebilir. Testin geçebilmesi için bir constant olan 2 rakamını i (scalar) parametresi ile değiştirdim.

Dördüncü test için { list(2,2), 4 } veri kümesini kullaniyorum. generate() metodu 4 rakamını parametre olarak aldığında, bünyesinde 2,2 rakamları olan bir listeyi geri döndürmeli. Bu testin geçebilmesi için kodu aşağıdaki şekilde dönüştürmem gerekiyor.

[source language=’java’]
public static List generate(int i) {
List primes = new ArrayList();
if (i > 1) {
if (i % 2 == 0) {
primes.add(2);
i /= 2;
}
if (i > 1)
primes.add(i);
}
return primes;
}
[/source]

Bu dönüşüm ( unconditional->if ) şeklinde ifade edilebilir. Testin geçebilmesi için yeni bir if bloğu içinde ikinin katlarını bulan modülo işlemini gerçekleştirdim. i/=2 ile i’nin değerini ikiye bölmüş oldum. Bunun yanısıra ikinci bir if bloğu içinde arta kalan değeri birden büyük ise listeye ekledim.

5,6 ve 7 rakamları için generate() metodunda değişiklik yapmaya gerek yok. generate() metodu bu rakamlar için geçerli listeleri geri döndürüyor.

8 rakamının asal sayı faktörlerini bulmak için { list(2,2,2), 8} veri kümesini kullanıyorum. Bu testin geçebilmesi için kodu aşağıdaki şekilde dönüştürmem gerekiyor.

[source language=’java’]
public static List generate(int i) {
List primes = new ArrayList();
if (i > 1) {
while (i % 2 == 0) {
primes.add(2);
i /= 2;
}
if (i > 1)
primes.add(i);
}
return primes;
}
[/source]

Bu dönüşüm ( if->while ) şeklinde ifade edilebilir. Testin geçebilmesi için ikinci if bloğunu while döngüsüne dönüştürmem yeterli oldu.

9 rakamının asal sayı faktörlerini bulmak için { list(3,3), 9} veri kümesini kullanıyorum. Bu testin geçebilmesi için kodu aşağıdaki şekilde dönüştürmem gerekiyor.

[source language=’java’]
public static List generate(int i) {
List primes = new ArrayList();
int divisor = 2;
while (i > 1) {
while (i % divisor == 0) {
primes.add(divisor);
i /= divisor;
}
divisor++;
}
return primes;
}
[/source]

Bu dönüşüm ( if->while ) ve ( constant->scalar ) şeklinde ifade edilebilir. Divisör (bölen) olarak kullandığım 2 rakamını bir değişkene ( constant->scalar ), ilk if bloğunu bir while döngüsüne dönüştürdüm.

generate() metodu bu son transformasyon ile herhangi bir rakamın asal sayı faktörlerini hesaplayacak duruma gelmiş oldu. Yapabileceğim iki transformasyon kaldı. Bu transformasyonlar ile satır sayısını azaltabilirim. Bu iki tranformasyonu ( while->for ) olarak tanımlayabiliriz.

[source language=’java’]
public static List generate(int i) {
List primes = new ArrayList();
for (int divisor = 2; i > 1; divisor++) {
for (; i % divisor == 0; i /= divisor)
primes.add(divisor);
}
return primes;
}
[/source]

Görüldüğü gibi testler geçtikten sonra metodun davranış biçimini kod transformasyonları uygulayarak yeniden yapılandırmamız mümkün. Uyguladığımız her transformasyon ile oluşturduğumuz çözüm spesifik olmaktan çıkıp umumi olmaya doğru gidiyor.

Test güdümlü çalışmayan bir programcı doğrudan generate() metodunu yukarda gördüğünüz şekilde kodlayacak ve mevcut kod transformasyonlarından bihaber olacaktır. Bu transformasyonları görmek bana ne fayda sağlar diye bir soru aklınıza gelebilir. Bilmiyorum! Belki bir faydası yok. Ama ben artık işin daha derinlerinde başka şeylerin varlığını hissetmeye başladım. Bu bana programcılıkta başka bir boyuta geçmek ya da olup bitenleri daha iyi algılamak için kullanabileceğim bir kapı olabilir gibi geliyor. Bazı şeyler detaylarda gizli. Onları görebilmek lazım.

EOF (End Of Fun)
Özcan Acar

Yazılımda Çeviklik İflas mı Etti?

Çevikliğin Böylesi başlıklı yazımı okudunuz mu? O yazımda çevik kelimesinin yerli yersiz her şey için kullanıldığını ve bu yüzden anlam erozyonuna ugradığından bahsetmiştim. Bu yazımda çevikliğin tanımını yapmaya çalışacağım.

Martin Fowler bu link üzerinden ulaşabileceğiniz yazısında şöyle diyor:

… lack of rigorousness is part of the defining nature of agile methods, part of its core philosophy. … Any attempt to define a rigorous process that can be tested for conformance runs contrary to [the agile] philosophy.

Martin Fowler yazılımda çevikliğin belli bir çerceveye sokulmuş bir süreç (process) olarak tanımlanmasının mümkün olmadığını, bunun çeviklik filozofi ve düşüncesine ters düştüğünü söylüyor.

Bazı kesimler Martin Fowler’in sözlerini çevikliğin iflası olarak yorumlayabilirler. Onların mutlaka katıksız bir tanımlamaya ihtiyacı var, çünkü ipe sapa gelmeyen bir şeyin pazarlamasını yapmak mümkün değil. Bu yüzden çeviklik filozofisinin sadece bir kısmını ihtiva eden yarım yamalak çevik süreçler tanımlamaya ve satmaya çalışıyorlar. Onlar için önemli olan elle tutulur, gözle görülür ve ölçülebilir bir süreç tanımlaması yapmak. Eğer A, B, C adımlarını uygularsan, X, Y neticesini elde edersin diyebilmek istiyorlar. Keşke müşteri gereksinimleri odaklı yazılım bu kadar basite indirgenebilseydi!

Bu sebeptendir ki birçok sözde çevik süreç ile istenilen neticeler elde edilemiyor, çünkü sürecin ihtiva ettiği adımları birebir uygulamak her projede mümkün olmuyor. Doğal olarak bu durumda sürecin yeniden tanımlanıp, ihtiyaçlar doğrultusunda yeniden yapılandırılması gerekiyor. Sözde çevik süreçler bu değişime izin vermedikleri için yazılımda çeviklik yarı yolda kalıyor.

Benim Çeviklik Tanımım

Ben yazılımda çevikliği bir soğanın kabukları gibi iç içe geçmiş, değişik katmanlardan oluşmuş bir yapı olarak görüyorum. En üst katmanda değişikliklere karşı koymadan, onlarla beraber yaşayabilmek için gerekli olan cesaret yer alıyor. Yazılımda çeviklik cesaret ile başlar ve en içteki katmana kadar varlığını sürdürür. Değişiklikle yaşamak ve yeni yollar, yöntemler keşfetmek için birey ve ekip bazında casaret gereklidir. Bunun olmadığı yerde sadece sözde çeviklik olabilir.

Sözde çevik süreçlerde cesaretin yerini sabit süreç tanımlamarı alır. Bunlar tek tek ve sırayla atılması gereken adımlardır, bir nevi yemek tarifidir. Değişikliğe bu şekilde bilinçaltı karşı konulmaya ve her şey daha kontrol edilir hale getirilmeye çalışılır. Yazılım projelerinde değişmeyen tek parametrenin değişikliğin kendisi olduğunu düşünecek olursak, sabit süreç tanımlamaları ile buna karşı koymanın imkansız olduğu ortadadır. Sabitlik isminden de anlaşıldığı gibi dinamizmin karşıtıdır ve ani değişikliklere cevap verebilecek nitelikte ya da değişikliklere adapte olacak yapıda değildir. Değişikliğe karşı koymanın tek yolu, ona karşı koymamak ve onunla beraber yaşamayı ögrenmekten, bunun yolu da cesaret ve cesaretli olmaktan geçer.

Casaret aynı zamanda müşteriye devamlı ne istediğini sorabilmektir. Bu amaçla yazılımda çeviklik çok kısa döngülerin doğurduğu geribildirimlerden beslenir. Bu döngülerin başında proje gidişatını yönlendirmek için kullanılan iterasyon bazlı planlama yer alır. Değişikliğin her an damdan düşer gibi projeyi alt üst edebilecegini varsaydığımızda, buna karşı koymanın en kolay yolu, projeyi kısa ve tanımlanmış zaman dilimlerinde müşterinin gereksinimlerini tatmin edecek seviyeye getirmektir. Bu örneğin bir ya da iki haftalık bir zaman dilimini ihtiva eder. Bu zaman diliminde müşteri kendisi için önemli olduğunu düşündüğü gereksinimlerini tespit edip, gerçekleştirilmek üzere yazılım ekibiyle paylaşır. Yazılım ekibi müşterinin seçmiş olduğu gerekli gereksinimleri hayata geçirir. Ekip seçilen gereksinimlerin öngörülen zaman diliminde tamamlanır tarzda olmasına dikkat eder. Öngörülen zaman dilimi tamamlandığında müşteriye çalışır bir prototip sunulur ve kendisinden geribildirim sağlanır. Bu noktatan itibaren müşteri gidişati kontrol edebilir bir araca sahiptir: çalışan bir prototip. Çoğu zaman müşteri bu prototipe bakarak sahip olduğu gereksinimleri doğru olarak tanımlamadığının farkına varır. Bu kendisi ve yazılım ekibi için bir geribildirimdir ve değişikliğin habercisidir. Bir sonraki çalışma safhasında (iterasyon) ekip bu geribildirimden beslenerek, müşterinin gereksinimlerini tam anlamıyla tatmin edecek değişikliklere gider.

Geribildirim alma çevikliğin ana temellerinden birisini teşkil etmektedir. Müşteriye ne istediğini sorarak, iterasyon bazlı çalışıp prototipler oluşturarak, sürekli entegre edip, entegrasyon seviyesinin ne durumda olduğunu sorgulayarak, birim testleri yazıp, uygulamanın test edilbilirliğini ölçerek birçok katmanda geribildirim ediniyoruz. Bu bizim yazılımcılar olarak müşteri gereksinimlerinin ifade edilmesi ile yazılımcılar tarafından tatmin edilmesi arasında nerede durduğumuzu anlayayıp, tartabilmemiz için çok önemli bir veri olma özelliği taşımaktadır.

Teknik olarak yazılımda çevikliği incelediğimizde çevik olmanın çekirdeğinde çok önemli bir metodun yer aldığını görmekteyiz: uygulamayı yeniden yapılandırma. İngilizce refactoring olarak isimlendirilen bu yöntem, biz yazılımcılara yeni müşteri gereksinimleri ile uygulamayı hamur gibi yogurma yetisi kazandırmaktadır.

Birçok sözde çevik süreci ya da çevik süreçlerin uygulandığı projeleri yakından incelediğimizde, başarısızlıklarının sebebinin uygulamayı hamur gibi yoğurma kabiliyetlerinin olmadığından kaynaklandığını söylemek mümkündür. Bazı sözde süreçler uygulamanın yeniden yapılandırılabilme özelliğine oluşturdukları gidişat planında yer bile vermemektedirler. Bir uygulamanın müşteri gereksinimlerine cevap verebilmesi için yeniden yapılandırılabilmesi gerekmektedir. Bunun ne olduğunu bile bilmeyen ya da tanımlayamayan bir çevik süreç nasıl çeviklik ibaresi olma savına sahip olabilir? Bunu anlamak güç!

Belki çevikliği tanımlamak kolay değil. Belki bu sebepten dolayı herkes her şeye çevik ismini takabiliyor. Ama bildiğim bir şey var, o da birim testi yazmadan ve sürekli refactoring yapmadan çevik olunamayacağıdır. Bu ikisinin nasıl yapılması gerektiğine dair birçok kaynak bulmak mümkündür. Martin Fowler’in Refactoring isimli kitabı yazılımcılara bu konuda ilham kaynağı olacaktır. Refactoring’i mümkün kılmak için birim testleri yazılması gerekmektedir. Bunu isteyen test güdümlü (Test Driven Development), isteyen klasik tarzda uygulamayı kodladıktan sonra yapabilir. Test güdümlü yazılımı şiddetle tavsiye etmekle beraber, klasik birim test yazılımını da hor görmüyorum. Uygulamayı hamur gibi yoğurabilmek için otomatik çalışan her türlü birim testi mübahtır. Bu birim testleri yeniden yapılandırma sürecinde oluşan hataları yazılımcıya gösterirler. Bunun yanısıra yazılımcının özgüvenini artırarak, daha cesaretli bir şekilde yeniden yapılandırma sürecine dahil olmasını sağlarlar. Birim testleri olmadan mantıklı çercevede uygulamanın yeniden yapılandırılması mümkün değildir.

Müşteri gereksinimlerini tatmin etmek için oluşturulan bir uygulama, üç katlı bir apartman gibi sabit bir yapı değildir. Uygulama devamlı değişiklige maruz kalır, çünkü müşteri kendi çalışma sahasında değişikliğe maruz kalmaktadır. Bunun doğal olarak uygulamaya yansıması gerekmektedir. Aksi taktirde uygulama müşterinin güncel gereksinimlerini tatmin edemez. Müşterinin gereksinimlerini tatmin edemeyen bir uygulama, işe yaramayan bir uygulamadır.

Demek oluyor ki “Birim testi yoksa refactoring yok. Refactoring yoksa çeviklik yok. Çeviklik yoksa, müşteri yok (olur)”. Benim çeviklik konusundaki formülüm bu.

EOF (End Of Fun)
Özcan Acar

Gezen Defterin Hikayesini Biliyor musunuz?

2009 yılında Enrique Comba‘nın aklına bir not defteri alıp, yazılım zanaatı akımında (Software Craftsmanship Movement) yer alan programcılara posta yoluyla gönderme fikri gelir. Her programcı deftere bu konudaki kendi düşünce ve tecrübelerini ekledikten sonra, defteri listede yer alan bir sonraki programcıya posta yoluyla gönderir. Bugün SocRaTes 2012 konferansında tanıştığım bir programcı 2010 senesinde bu defterin kendisine ulaştığını, defteri belli bir zaman sonra listede yer alan bir sonraki programcıya gönderdiğini, ama defterin 2011 senesinden beri kayıp olduğunu söyledi. Herhalde birisi defteri kitaplığına koyup, unuttu :)

Fikir çok orijinal. Programcı zanaati hareketinde bu işe gönül vermiş ve yaptığı işle gurur duymak isteyen programcılar yer alıyor. Bu programcılar kendilerine her gün aynı soruyu soruyorlar: “nasıl daha iyi bir programcı olabilirim?”. Bu sorunun cevabını ararken günlük işlerinde, bu bilince sahip olmayan programcılardan daha değişik yöntemler deniyorlar. Kendilerini bir çırak ya da kalfa olarak gördükleri için, ustaların peline düşüp, daha iyi bir programcı olabilmek için öğrenebilecekleri her şeyi kapmaya çalışıyorlar. Bu programcıların edindikleri tecrübeleri gezen deftere not etmiş olmaları, gezen defteri çok kıymetli bir hazine haline getiriyor. Umarım gezen defter bir gün ortaya çıkar.

EOF (End Of Fun)
Özcan Acar

Kataların Eşli Programlanması

Yaptığım kataları KodKata.com‘da sizinle paylaştım. Her gün düzenli olarak kod katalarımı yapıyorum. Her gün değişik bir kata yapmaya gayret ediyorum. Kataları tekrarladıkça katanın öngürdüğü birçok işlem benim için rutinleşiyor. Zaman zaman katanın öngördüğü yoldan saparak, başka şeyler deniyorum. Bu yeni bir tasarım kararı olabiliyor ya da yeni bir refactoring metotunun kullanımı. Okumaya devam et →

Yazılımcı Anketi 2012

Bu anket 31.13.2012 tarihinde sona erdi. Bu anketteki verileri ihtiva eden rapora bu link üzerinden erisebilirsiniz.

Bu anketi hazırlayarak, yazılım ve yazılımcılık hakkındaki düşüncelerinizi öğrenmek istedim. Yeterli veri elde ettikten sonra Yazılımcı 2012 Raporu’nu sizinle paylaşacağım.

Kişisel Gelişim

Bir programcının tipik bir haftasının kırk saati patronu için çalışmakla geçer. Daha önceki bir yazımda bir programcının mesai saatlerinde kendisini geliştirmesinin mümkün olmadığını, ama mesai haricinde pratik yaparak programcılık yeteneğini geliştirmesi gerektiğinden bahsetmiştim. Gel gelelim günde sekiz saat çalıştıktan sonra eve gelip, pratik yapmak ya da kitap okumak kolay bir şey olmayabilir. Yemek yedikten ve biraz televizyon seyrettikten sonra kişisel gelişim için gerekli motivasyon tabana vurabilir. Bu çok doğal bir şey. Bu sebepten dolayı kimse kendisine kızmamalıdır. Daha ziyade insan kendisine bu kısır döngüyü nasıl kırabilirim sorusunu sormalıdır.

Kişisel gelişim için hiç zaman yokmuş gibi görünse de, bu doğru değildir. Mesai saatlerini çıkardığımızda geriye 128 saat kalmaktadır, yani tam tamına 5.3 gün. Bu zaman dilimine kocaman bir dünyayı sığdırabiliriz, yeterki zaman yönetimini iyi yapabilelim.

Öncelikle kişisel anlamda bize bir fayda sağlamadan geçip, giden zaman dilimlerine bir göz atalım. Bu zaman dilimlerini kişisel gelişim için nasıl kullanabiliriz, onu da akabinde inceleyelim.

Eğer programcı binek otosuyla ile işe gidiyorsa, her gün ortamala 1-3 saatini anlamsız bir şekilde israf etmektedir. Programcı eğer mümkünse toplu taşıma araçlarını kullanarak işe gidip, gelmelidir. Bu şekilde yolculuk esnasında bir kitap okuyabilir ya da akıllı telefonu ya da tableti ile ilgilendiği konuda bir sunum seyredebilir. Bu şekilde her hafta bir kitabı bitirmek mümkündür.

Gelelim öğle aralarına. Kimin akıllı bir telefonu yok, el kaldırsın! Evet, herkesin varmış. O zaman akıllı telefonumuzu kişisel gelişim aracına çevirelim. Öğle aralarında bir programcı akıllı telefonu üzerinden ilginç bulup, takip ettiği blogları okuyabilir ya da sektörün önderliğini yapan kişilerin sunumlarını seyredebilir. Mesai arkadaşları ile lak lak yapmak yerine, her gün bir saatlik bir zaman dilimi kişisel gelişim için kullanılabilir. Yemek yerken bir blog okumak ya da sunum seyretmek düşünüldüğünden daha kolaydır.

Gelelim işin zor kısmına. Mesaiden eve döndükten sonra, motivasyon sorunumu nasıl çözerim? Yapılacak işi gözde büyütmeyerek ve küçük parçalara bölerek. Eğer yeni bir kitabı okumaya başladıysam, büyük bir ihtimalle motivasyonum ilk yirmi sayfa için yeter. Kitabın geri kalan beş yüz sayfasını okuyabilmek için motivasyonumu geri getirici bir taktik geliştirmem gerekir. Bunu sağlamak için Promodoro tekniğinden (http://www.pomodorotechnique.com/) faydalanılabilir. Ne yazık ki insanlar en fazla yarım saat, bilemediniz bir saat tam konsantre çalışabilir. Bu zaman dilimi dolduktan sonra beyin ara vermek için bahaneler uydurmaya başlar. Bu bize motivasyon eksikliği gibi yansır, ama sorunu ufak bir ara vererek çözebiliriz. Promodoro tekniğinde planlanan aktiviteler yirmi beş ya da otuz dakikalık birimlere bölünür. Örneğin iki saat ara vermeden kitap okumak yerine, okuma süreci otuz dakika uzunluğunda dört seansa bölünür. Her seans başında bir çalar saat otuz dakika sonra çalacak şekilde ayarlanır ve yapılmak istenen aktiviteye konsantre olunur. Seans süresince sadece seçilen aktiviteye konsantre olunması gereklidir. Eğer konsantreyi bozan yan etkiler tespit edilirse, bunların seans esnasında bir kenara not edilerek, daha sonra analiz edilmelerinde fayda vardır. Örneğin Promodoro seansında telefon çalıyorsa, bir sonraki seansta telefon kapatılmalıdır.

Her Promodoro seansından sonra beş dakikalık ara verilerek, beyin dinlendirilmelidir. Bu tarz aktivite yapılandırması kişisel gelişim için atılması gereken adımların daha kolay hazmedilmesini sağlar. Kişi her Promodoro seansından sonra verimli bir şeyler yaptığı hissine sahip olarak kişisel gelişimine katkıda bulunacaktır.

Kişisel gelişimi daha verimli ve istikrarlı bir hale getirmek için kisisel gelişim projeleri hazırlanabilir ve uygulanabilir. Bunun Promodoro ve Scrum kombine edilerek nasıl yapılabileceğini değinmek istiyorum.

Scrum çevik projeleri yönetmek için kullanılan bir metotdur. Proje bünyesindeki aktiviteler bir ya da iki haftalık Sprint ismi verilen zaman birimlerine bölünür. Sprint öncesi, o Sprint bünyesinde yapılmak istenen aktiviteler tespit edilir. Seçilen aktivitelerin Sprint bünyesinde tamamlanacak nitelikte olması gereklidir. Programcılar tahminlerde bulunarak, Sprint bünyesinde yer alacak aktivitelerin seçilmesine katkıda bulunurlar. Programcılar ayrıca seçilen aktivitelerin Sprint bünyesinde tamamlanmalarından sorumludurlar.

Kişisel gelişimimizi de bir proje olarak el alırsak, bu projeyi organize etmek için kişisel Scrum’dan (personal Scrum) faydalanabiliriz. Scrum bünyesinde gerçekleştirmek istediğimiz aktiviteler, kişisel gelişim aktivitelerimiz olacaktır. Bu aktiviteleri not ederek, bir aktivite listesi oluşturmakta fayda vardır. Bu aktivite listesinde örneğin okunacak kitaplar ve bloglar, yapılacak kod kataları, izlenecek eğitim videoları ve diğer kişisel gelişim için gerekli olduğunu düşündüğümüz aktiviteler yer alabilir.

Aktivite listesini oluşturduktan sonra Sprint planlamasına geçilebilir. Her Sprint belirli bir zaman dilimini kapsar. Bu zaman diliminde üzerinde çalışılacak aktiviteler seçilir ve Sprint başlatılır. Örneğin bir Sprint süresini bir hafta olarak seçti isem, o zaman bu Sprint bünyesinde bu bir haftalık zaman diliminde üstesinden gelebileceğim kadar aktivite tanımlaması ve seçimi yapmam gerekir. Bir haftalık Sprint süresi benim bu bir hafta içinde kişisel gelişimim için ayırmak istediğim zaman dilimini kapsayacaktır. Örneğin her gün iki saat kişisel gelişimim için ayırmayı düşünüyorsam, bir haftalık Sprint toplamda 10 saatlik çalışma planlamasını ihtiva eder (on saat, çünkü beş iş günü).

Seçilen aktivitelerin yarım saat ile en fazla üç saat içinde tamamlanabilecek türde olmasına dikkat edilmelidir. Örneğin üç saat süren bir aktiviteyi bir çırpıda tamamlamak mümkün olamayacağı için, bu tür aktiviteleri yarım saatlik Promodoro seanslarına bölmekte fayda vardır. Söz konusu bir kitabı okunamak olduğunda aktivite planlaması nasıl yapılmalıdır? Bir aktivitenin en fazla üç saat içinde tamamlanabilir yapıda olması gerektiğini yazmıştım. Bir kitap büyük bir ihtimalle üç saat içinde okunamayacağı için, kitabı okuma işleminin alt aktivitelere bölünmesinde fayda vardır. Örneğin kitabın her bir bölümü için ayrı bir aktivite tanımlanabilir. Böylece en fazla aktivite uzunluğu olan üç saat aşılmamış olur.

Sprint ve aktivite yönetimi için bir Kanban panosu kullanılabilir. Benim kullandığın Kanban panosu aşağıdaki şekildedir:


(Bakınız: leankitkanban.com)

Kişisel gelişim için gerekli gördüğümüz aktivitelerin gözümüzün önünde olması ve kaydettiğimiz gelişimi ölçebilir durumda olmamız büyük önem taşımaktadır. Ben örneğin bir Kanban panosu kullanmadan önce kişisel gelişimim için gerekli aktiviteleri aklımda tutmaya ve uygulamaya çalışıyordum. Kısa bir zaman sonra kafamdaki bu listenin aslında bir LIFO (Last In First Out – Son giren ilk çıkar) yapısı olduğunu gördüm. Karşıma devamlı ilgimi çeken yeni kitaplar ve bloglar, uygulamak istediğim yeni teknolojiler ve ilgimi çeken diğer konular çıkıyor. Durum böyle olunca karşılaştığım her şey tepeden aklımda yer alan LIFO listesine yerleşiyor ve listede yer alan diğer konuları aşağıya doğru itiyor. Zaman içinde listenin tepesinde olan aktivitelerin aşağıya doğru kaybolup gittiğini fark ettim. Bu şekilde kişisel gelişimi organize etmek verimli değil. Bunun için bir Kanban panosu kullanmaya başladım. Bu pano bana neyi ne zaman yapmam gerektiğini hatırlatıyor. Kafamdaki LIFO’yu silip, attım.

Kafamdaki LIFO’yu silip atmanın bana sağladığı bir avantajı daha olduğunu gördüm. Kafamdaki aktivite LIFO’su ile yaşadığım sürece devamlı tedirgin olduğumun farkına vardım. Her aktiviteyi akılda tutmak, ne zaman neyi yapmam gerektiğini organize etmeye çalışmak beyin için çok yorucu bir işlem. Beynim devamlı böyle yarım kalmış aktivitelerle haşır neşır ve onların nasıl üstesinden geleceğinin planını yapıyor. Bu yükten kurtulmak için Kanban panosu gibi bir yapıdan istifade edilebilir. Bu web tabanlı bir Kanban panosu olmak zorunda değil. Kağıt üzerinde buna benzer bir planlama yapılabilir. Önemli olan kafadaki LIFO’nun boşaltılması ve aktivitelerin Kanban panosuna eklenmesi. Kafadaki LIFO silindikten sonra beyin kişisel gelişim için daha zinde olacak ve daha verimli çalışacaktır. Bunu hayatın diğer alanlarına da yaymak mümkün. Aklımızda ne kadar LIFO varsa, tüm içeriklerini kağıda ya da Kanban panosuna dökün ve LIFO’ları silin. Ne kadar rahat ettiğinizi göreceksiniz. Ben yorulacağıma kağıt yorulsun :)

Buraya kadar kişisel gelişimimizi nasıl organize edebileceğimizden bahsettim. Şimdi birazda kişisel gelişim için gerekli pratiğin nasıl yapılabileceğine değinmek istiyorum.

Daha önce Kod Kata ve Pratik Yapmanın Önemi isimli bir blog yazdım. Biz programcılar ne yazık ki pratik nedir tam olarak bilmiyoruz. Sabah ofise geliyoruz ve direk kod yazmaya başlıyoruz. Aynı şey müzisyenler ya da sporcular için söylenemez. Bu iki meslek gurubu pratik ve performansı birbirinden ayırt ediyorlar. Sahnede olmak onlar için performans. Sahne aktiviteleri haricinde devamlı pratik yaparak, performansları için hazırlık yapıyorlar. Biz programcılar sadece performansı tanıyoruz ve pratik yapma yetimiz gelişmiyor.

Bu durumu aşmak için kod kataları yapmamız gerekiyor. Bu amaçla KodKata.com isminde bir web sayfası hazırladım. Kod kataları on beş ila bir saat arası süren kod yazma pratikleridir. Kod kataları hakkında detaylı bilgi için yukarda linkini verdiğim yazımı okumanızı ve KodKata.com’a bakmanızı tavsiye ederim.

Kişisel gelişim için kod katası yapmak çok önemli. Bu sebepten dolayı her sabah işe başlamadan önce bir kata yapmayı alışkanlık haline getirilmesini tavsiye ediyorum. Bu amaçla KodKata.com’dan bir kata seçin ve yapın. Yaptığınız kataları ve adetlerini bir yere not edin. Zaman içinde sağladığınız gelişmeler gözle görülür hale gelecektir. Bir programcının ustalaşmasının sırrı kod katalarında gizlidir.

Çok yazdım, kafanızı şişirdim, kusuruma bakmayın. Kişisel gelişim benim için çok önemli bir konu. Burada yer alan öneriler kendi kişisel gelişimimde kullandığım ve faydasını gördüğüm yöntemleri ihtiva etmektedir, laf olsun diye işkembeden salladığım şeyler değildir. Verimli olduklarını düşünmesem sizinle paylaşmazdım. Umarım faydasını görürsünüz. Kullandığınız kişisel gelişim metotlarını benimle paylaşırsanız sevinirim.

Güncelleme:
Bu yazımı 07.07.2014 tarihinde tekrar okudum ve bir süredir LIFO sistemine geri döndüğümün farkına vardım. Yapılacak işleri beyinde tutmaya ve organize etmeye çalışmak gerçekten çok zor bir iş. Beyin devamlı yapılması gereken şeyleri organize etmekle meşgul ve yapılacak işler listesinde tatmin edici bir ilerleme sağlamak mümkün değil, çünkü insan beyni bir mikro işlemci ve işletim sistemi gibi preemtif çalışmıyor. Multitasking insan beyni için mümkün değil. Bu yüzden beyinden yapılacak işlerin organiyasyon yükünün alınması gerekiyor ki beyin yapılması gereken asıl işlere
konstantre olabilsin. İş organizasyonu beyne bırakıldığı sürece kişisel gelişim konusunda elle tutulur bir gelişme elde etmek mümkün olmayacaktır.

EOF (End Of Fun)
Özcan Acar

Bilgisayar Mühendisi mi, Yazılım Mühendisi mi?

İsmini açıklamadan bir üniversite ögrencisinin bana göndermiş olduğu e-posta iletisini sizinle paylaşmak istiyorum.

Bana gelen e-postanın içeriği şöyle:

Özcan Bey Merhabalar
Ben XXX Üni. Teknoloji Fak. Yazılım Müh. okuyorum.Yatay geçişle YYY Üni.Müh Fak. Bilg. Müh. geçmek istiyorum ama kararsızım. Sizce hangisini seçmeliyim? Gelecekte hangisinde işsiz kalma ihtimalim daha az? YYY Üni. eğitimi daha iyi olur diye düşünüyorum ama bilg. müh. geleceğin meslekleri arasında yer alamıyor artık. Yazılım müh. adı geçiyor. Sizce ne yapmalıyım? Hangisini tercih ederek kariyerime devam etmeliyim? Şimdiden sağolun …
Not: Acil cevaplayabilirseniz sevinirim.

Benim cevap:

Merhaba, eğer ilerde sadece yazılım yapacağım diyorsan, XXX Üni’den bir yere kımıldama. “YYY’nin serin sularında yüzerim, keyfime bakarım ve bunun yanında bir de bilgisayar mühendisi çıkarsam iyi olur” diyorsan o zaman YYY’e bir otobüs bileti al. Devir artık belli bir konuda uzmanlaşma devri. Bilgisyar mühendisliği çok geniş, her şeyden ufak defek bir şeyler öğretilen, ama yazılımın pek fazla ciddiye alınmadığı, matematiğe fazlasıyla kıymet ve ağırlık verildiği, diplomayı alınca müstakbel bilgisayar mühendisinin hiçbir şeyi doğru dürüst bilmediği, ama dünyayı ben yarattım ve her şeyi ben bilirim edasıyla piyasada iş bulmaya çalışıp, ama absürd ve gercekçi olmayan maaş hayalleri ile duvara toslayıp, beklentilerini aşağıya çekmek zorunda kaldığı bir eğitim dalı haline geldi ya da her zaman öyleydi. Gelecekte işsiz kalmayacak tek takım varsa, onlarda programcılar. Sen benim dediklerime çok fazla kulak verme. İçindeki sesi dinle. Eğer gönlünde gerçekten yazılım varsa, zaten o yöne doğru gideceksin, ha XXX, ha YYY, fark etmez. Üniversiteyi bitirdiğinde, hangi üniversitede olursa olsun, beni bul, bu konuyu tekrar birlikte değerlendirelim.

Başarılar dilerim.

Not: YYY benim memlekettir, kızları güzeldir :)

Bu arkadaşımız sizce nasıl karar verecek? Yatay geçer mi yoksa yazılımda kalır mı? Verdiğim cevap benim bu konudaki düşüncelerimi yansıtıyor. Bu konuda diyecek daha fazla bir şeyim de yok. Bilgisayar mühendisliği okumak zaman kaybından başka bir şey değil!

Ekleme:
Bu yazıyı yazdıktan sonra gelen yorumlar beni biraz düşündürdü. Amacım şu an bilgisayar mühendisliği okuyan arkadaşların kafasını karştırmak değildi. Eğer buna sebebiyet verdiysem, özür dilerim. Yazılım mühendisliği Türkiye’de ne yazık ki çok yeni bir öğrenim dalı. Bunun haricinde geriye bilgisayar mühendisliğinden başka bir seçim kalmıyor. Doğal olarak birçok öğrenci arkadaşımız da bilgisayar mühendisliği dalını seçmiş ve öğrenimlerini sürdürüyorlar.

Bilgsiayar mühendisliği okuyup, gidişattan memnun olmayan arkadaşlardan ricam motivasyonlarını yitirmemeleri. Nihayi amaç üniversiteyi bitirmek olmalı. Akabinde insan kendi istediği şekilde kariyerine yön verebilir. Bilgisayar mühendisinin programcı olması zor bir şey değil. İstek ve motivasyonun olduğu yerde mutlaka izlenebilecek bir yol vardır.

EOF (End Of Fun)
Özcan Acar

Kod A.Ş. – Kod Anonim Şirketi

Programcılar tarafından yazılan metotların ve kullanılan değişken isimlerinin çoğu anonim, yani adı sanı belirsiz. Kullanılan isimler ilk bakışta kod bünyesinde olup bitenleri ifade gücünden aciz. Bu kodun okunabilirliğini düşüren bir faktör. Zamanımızın büyük bir kısmını kod okuyarak geçirdiğimizi düşündüğümüzde, seçilen isimlerin ne kadar önemli olduğunu ortaya çıkmakta.

Anonim kod sadece metot ve değişken isimleri ile sınırlı değil. Dün katıldığım bir kod inceleme oturumunda (peer code review) kodun büyük bir kısmını oluşturan koşullu mantık yapılarının (if/else) da anonimlikten nasiplerini aldıklarına tekrar şahit oldum. Oturum esnasında aşağidaki tarzda bir if yapısa denk gelince, burada ne tür bir işlemin yapıldığını sormadan edemedim, çünkü birkaç sefer okumama rağmen, kodun ne yaptığını anlayamadım.

[source language=’java’]
// bla bla bla bla
if(pos.length() > 0 && indexAccess.isLucene() && blabla && blabla …..){
}
[/source]

Sağolsun çalışma arkadaşım kodun ne yaptığını bana açıkladı. Ben ne zaman bu kod parçasını okumak istesem, yanımda tercüman olarak çalışma arkadaşımı da bulundurmam gerekiyor. Ne kadar pratik degil mi!

Bu kod parçasında gözüme çarpan iki sorun var. Birincisi if bünyesinde olup bitenleri anlamak hemen hemen imkansız. İkincisi kodun ne yaptığını açıklamak için //bla bla seklinde koda yorum eklenmiş. Bu kadar zaman harcayip, koda yorum eklemek yerine, if bünyesindeki kodu bir metoda dünüştürüp, bu metoda anlamlı bir isim versek nasıl olurdu?

[source language=’java’]
if(searchable()){
}

private boolean searchable(){
return pos.length() > 0 && indexAccess.isLucene() && blabla && blabla …..
}
[/source]

Şimdi if bünyesin olup bitenleri anlamak benim için daha kolaylaştı. Anonim olan if içindeki kodu bir metoda dönüştürerek, ona bir kişilik kazandırdım. Bu metot ismini gören programcı metot bünyesinde olup bitenleri aşağı yukarı kestirebilir. Bunun için kodu yazan programcıyı tercüman olarak kullanmak zorunda değil.

Eğer anonim kodu nasıl anlarım derseniz, kod içinde bırakılan açıklayıcı yorumların izini sürün derim. Eğer bir değişken ismini ya da if bünyesinde olup bitenleri açıklayıcı bir yorum bırakılmışsa, o zaman o kod anonim koddur.

Buraya kadar olan kodun teknik olarak nasıl daha okunabilir hale getirilebilir olması ile ilgiliydi. Şimdi gelelim programcının neden anonim yapıları tercih ettiğine. Bunu öğrenmek için programcıya şu soruyu sordum: “Bana if bünyesinde olup bitenleri ifade edebilecek güçte bir metot ismi söyleyebilir misin?“. 10 saniye… 20 saniye… 30 saniye geçti ve programcı hiç te fena olmayan bir öneride bulundu. Ama akabinde yorumu şu oldu: “Bu ismi düşünene kadar ben if için gerekli kodu yazmıştım bile!”. Ama marifet kod yazmak değil ki canım kardeşim. Marifet okunabilen kod yazmaktır.

Programcılar bu tarz kod yazmaya alışmışlar ve farkında olmadan her gün anonim, yani okunması zor kod üretiyorlar. Bunu değiştirmek için tavsiyem programcının kod kataları yapmasıdır. Kod Kata ve Pratik Yapmanın Önemi başlıklı yazımda pratik yapmanın programcı için ne kadar önemli olduğunun altını çizmiştim. Yaptığım kataları programcılarla paylaşmak için KodKata.com isminde bir websayfa hazırladım. Vakit bulduğunuzda bir göz atmanızı tavsiye ederim. Bu konudaki geri bildirimleriniz beni sevindirecektir.

Kod A.Ş. iflasa mahkum. Bu batan gemiden ayrilmanın zamanıdır.

EOF (End Of Fun)
Özcan Acar

Java’da Bilinmeyenler

Bu yazımda Java programclarının bilmediği, doğru olarak kabul edip kullandığı ya da yanlış bildiği konulardan bahsetmek istiyorum.

Hafıza Alanı Ayarları
Genelde JVM için hazıfa alanı -Xmx -Xms parametreleri ile oluşturulur. -X ile başlayan parametreler standart JVM parametreleri değildirler, yani bu parametreleri JVM implemente etmek zorunda değildir. Durum böyle olunca -Xmx1024m şeklindeki bir parametre, eğer JVM -Xmx parametresini implemente etmedi ise JVM için kullanılan hafıza alanının 1GB olarak ayarlanmasını sağlayamayacaktır. -Xmx ve -Xms yerine standart olan -mx ve -ms parametreleri kullanılmalıdır.

finally Bloğu
try/catch/finally yapısında metot son bulmadan önce finally bloğunda yer alan kodun mutlaka koşturulduğu düşünülür. Ama bu tam doğru değildir. İki durumda finally içinde yer alan kod koşturulmaz. Bu iki durum: Eğer try içinde System.exit(0); komutu kullanıldı ise (bu durumda program hemen son bulur) ya da bir Thread try içindeki kodları koştururken bilgisayarın elektriği kesilirse ;-)

Call By Reference
Java tamamen call by value mantığı ile çalışır. Java’da call by reference mantığı olduğu bir yanılgıdır. Primitif veri tipleri (int, long vs) nasıl metotlara parametre olarak gönderildiklerinde değerleri kopyalanıyorsa, nesne referansları da metot için oluşturulan stack’e kopyalanır. Referans bir göstergeştir (pointer). Bir metoda parametre olarak gönderildiğinde, çoğaltılarak aynı nesneye işaret eden ikinci bir göstergeç oluşturulur. İkinci göstergeç te aynı nesneye işaret ettiği için, metot içinde işaret ettiği nesne üzerinde işlem yaparak nesnenin durumunu değiştirebilir. Bu değişikliklere metot dışındaki göstergeç üzerinden de erişmek mümkündür, çünkü iki göstergeç aynı nesneye işaret etmektedir. Metot içinde oluşturulan ikinci göstergece null değeri atandığında, metot dışındaki göstergeç bu durumdan etkilenmez. Bu nesne referanslarının metotlara parametre olarak gönderildiklerinde kopyalandıkları yani call by value mantığı ile çalıştıkları anlamına gelmektedir.

Java’da sadece call by value mantığının kullanıldığının kanıtı Java spesifikasyonunda yer alan şu cümledir :

When the method or constructor is invoked (15.12), the values of the actual argument expressions initialize newly created parameter variables, each of the declared Type, before execution of the body of the method or constructor. The Identifier that appears in the DeclaratorId may be used as a simple name in the body of the method or constructor to refer to the formal parameter.

String ve StringBuilder

“a”+”b” ile StringBuilder.append(“a”).append(“b”) arasında bytecode seviyesinde bir farklılık yoktur. “a”+”b” kullanıldığı taktirde bu bytecode seviyesinde StringBuilder.append(“a”).append(“b”) şekline dönüştürülür.

[source language=’java’]
public class Test
{

public static void main(String[] args)
{
StringBuilder temp = new StringBuilder();
temp.append(“a”);
temp.append(“b”);

String a =”a”;
String b = “b”;
System.out.println(a+b);
}

}
[/source]

[source language=’java’]
C:\Temp>javap -c Test
Compiled from “Test.java”
public class Test extends java.lang.Object{
public Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object.”“:()V
4: return

public static void main(java.lang.String[]);
Code:
0: new #2; //class java/lang/StringBuilder
3: dup
4: invokespecial #3; //Method java/lang/StringBuilder.”“:()V
7: astore_1
8: aload_1
9: ldc #4; //String a
11: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
14: pop
15: aload_1
16: ldc #6; //String b
18: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
21: pop
22: ldc #4; //String a
24: astore_2
25: ldc #6; //String b
27: astore_3
28: getstatic #7; //Field java/lang/System.out:Ljava/io/PrintStream;
31: new #2; //class java/lang/StringBuilder
34: dup
35: invokespecial #3; //Method java/lang/StringBuilder.”“:()V
38: aload_2
39: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
42: aload_3
43: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
46: invokevirtual #8; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
49: invokevirtual #9; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
52: return

}
[/source]

Bu yazım devam edecek!!! Sizde bildiklerinizi lütfen yorum olarak bu yazıya ekleyin.

Bugün Neler Ögrendim?

Bugünkü günüm bir tweet göndererek başladı. Saat sekiz gibi Frankfurt’ta yapılan Code Retreat etkinliğine katıldım. Code Retreat 15-20 arası programcının bir araya geldiğı ve birlikte gün boyunca kod geliştirdikleri bir etkinlik.

Etkinliğin formatı kısaca şöyle: Etkinlik 45 dakikalık, iki programcının bir araya gelerek eşli programlama (pair programming) yaptıkları altı oturumdan ve her oturum sonunda beş ya da on dakika retrospective ismi verilen, oturum esnasında olup bitenlerin analiz edildiği bölümden oluşuyor. Bir oturum esnasında iki programcı test güdümlü yazılım metodunu kullanarak Game Of Life ismi verilen programı geliştiriyorlar. İlk oturumdan sonra aslında oturum için öngörülen 45 dakikanın böyle bir program yazmak için yeterli olmadığını, ama asıl amacın zaten programı sonlandırmak değil, her oturumda yeni fikirler geliştirerek, başka bir bakış açısından kod yazmaya çalışmak olduğu anlaşılıyor.

İlk oturumda daha önce böyle bir etkinliğe katılmış ve Game Of Life programını tanıyan bir programcı ile eşleştim. Game Of Life hakkında ön bilgim olmadığı için başlangıçta zorlandım. Bunun yanısıra eşimin kodlama esnasında oluşabilecek hataları daha önceden bilerek, beni belli bir yöne doğru itmeye çalışması, oturumu benim için daha zor bir hale getirdi. Ben kafamda Game of Life dünyasını nesnelerle modellemeye çalışırken, birden kendimi eşimin etkisiyle prosedürel bir dünyada buldum. İçgüdüsel olarak bir şeylerin doğru gitmediğini sessiz ve sesli düşünmeye başladım. Oluşan prosedürel bir yapıda benim fikirlerimi nesnelere dökmem imkansız hale geldi. Bu durum beni bloke etti. Ben böyle bocalarken ilk 45 dakika doldu ve ilk retrospective seansına geçtik. Retrospective seansında bunu dile getirdim.

İkinci seansta başka bir programcı ile bir araya gelerek, seansın başlangıcından itibaren Game Of Life oyununu Java sınıfları kullanarak tasarladık. Yazdığımız testler yavaş yavaş sınıflar için gerekli davranış biçimlerini (metot) şekillendirmeye başladı. O test senin, bu kod benim derken ikinci seansında sonuna geldik. Kısa bir retrospektive seansı ardından üçüncü ve diğer seansları tamamladık. Her seansın sonunda yazdığım kodun daha okunur, daha iyi tasarlanmış hale geldiğine sahit oldum.

Her seans sonunda kodları silerek yeniden başlamamız istendi. Bu şekilde yazılan koda ne kadar sahip çıktığımı ve kod silmenin benim için ne kadar zor olduğunu gördüm. Yeni bir perspektif kazanmak için kodun silinmesi gerektiğini anladım. Mevcut bir kodu yeniden yapılandırmak mümkün, lakin çok daha değişik bir bakış açısı ile kod yazmak için kodun silinmesi gerekiyor.

Toplamda bu etkinlik benim için çok verimli geçti. Diğer programcılardan yeni teknikler öğrenme fırsatı buldum. Özellikle eşleştiğim bazı programcıların kullandıkları implementasyon şablonları benim için öğrentici nitelikteydi. Hemen aklıma Kent Beck’in yazdığı Implementation Patterns isimli kitap geldi. Bu kitaba daha önce göz atmış olmama rağmen, şimdi daha başka bir motivasyonla bu kitabı okuyacağım.

Biz programcıların pratik yapması gerekliliğine daha önceki bir yazımda değinmiştim. Bunun ne kadar gerekligi oldugunu bugün daha iyi anlama fırsatı yakaladım. Müzisyenler gibi pratik ve performans arasında ayrım yapmamız ve bu ikisini karıştırmamız gerekli. Ne kadar çok bilinçli pratik yapma fırsati yakalarsak, o oranda programcı olarak daha ileriye gidebileceğimizi düşünüyorum.

Pazartesi Brutal Refactoring Game için Nürnberg’te olacağım. Şimdiden bu etkinliği iple çekiyorum.

EOF (End Of Fun)
Özcan Acar

Kataların Anası

Java ve diğer dillerde kullanılan switch komutu OCP tasarım şablonuna ters düşmekle beraber, kodun bakımı ve geliştirilmesini zorlaştırmaktadır. Martin Fowler Refactoring isimli kitabında yer alan Video Store örneğinde “Replace Conditional with Polymorphism” refactoring metodu ile switch komutunun nasıl yok edilebileceğini göstermektedir. Robert C. Martin’in CleanCoders.com sayfasında Video Store örneğini daha geniş çaplı yeniden yapılandıran bir ekran gösterimi (screencast) mevcuttur. Bu iki örnekten esinlenerek, sizler için aşağıdaki ekran gösterimini oluşturdum. Bana soracak olursanız bu tüm kataların anasıdır, çünkü içinde günlük iş hayatında bir programcının kullanalabileceği bilumum yeniden yapılandırma metotları kullanılmaktadır. Bu kata benim şahsen her gün ya da gün aşırı yaptığım favori katalardandır.

Video Store sınıflarını buradan edinebilirsiniz.

Herkesi böyle kata ekran gösterimleri hazırlamaya davet ediyorum. Bu şekilde hem birbirimizden öğrenmiş oluruz, hem de kolektif kata hafızamızı geliştiririz.

EOF (End Of Fun)
Özcan Acar

Ultra Lüks

Biliyorsunuz yazılim sektörü sadece biz yazılımcılardan oluşmuyor. Bu sektörün proje yöneticisi, satış elemanı, testcisi gibi emekçileri de var. Bu meslek gurupları içinde teknik anlamda yazılımın nasıl yapılması gerektiğini bilen ya da bilmesi gereken biz yazılımcılarız. Bu sektördeki diğer meslek guruplarından bu konuda bir ümit beklemeyin.

Durum böyle olmasına rağmen, bir yazılım projesinin nasıl yürütülmesi gerektiği konusunda en az söz sahibi olan biz programcılarız. Bize gelene kadar birçok insan köklü bilgi sahibi olmadan yazılım projelerine yön veriyor, vermeye çalışıyor. Biz programcılar için yazılım kalitesi ön planda iken, ön planda olmalıyken, bu kişiler çok daha değişik parametrelerin gravitasyonuna kapılıp, açıkçası işi berbat ediyorlar. Bu şahısları motive eden en önemli faktör: “ürünü bir an önce satmak”.

Bir ürünü çabucak satmanın önündeki en büyük engel nedir? Cevap: zaman kaybı olarak algılanan aktiviteler. Hangi aktiviteler örneğin? Cevap: birim testleri yazmak, birlikte kod inceleme seansları yapmak (peer code review), sürekli entegrasyon vs. İnanmıyorum dercesine kafanızı sağa, sola salladığınızı görür gibiyim. Benim gibi bunların yazılım kalitesi açısında önemli aktiviteler olduğunu düşünüyorsunuz değil mi? Ama programcılar haricindeki diğer yazılımla ilgili meslek guruplarında böyle bir algılama ne yazık ki mevcut değil. Onlar için bu saydıklarım lüks, biz programcılar ise büyümeyi becerememiş ve istekleri bitmeyen şımarık çocuklarız.

Ellerinden gelse bizi hemen kapıya koyacaklar ama göbekten bize bağlı olduklarını bildiklerinden sesleri çıkmıyor. Bizim de sesimiz çıkmıyor. Arkadaş, yukarda saydığım aktivitelerin gerekliliğine inanmış, ama uygulanmadıkları yerde masaya yumruğunu vurup, “savulun ulan, biz bu aktiviteleri yapacağız, işinize gelirse“ diyen cesur bir programcı görmedim. Ağlamayan bebeğe kim emzik verir ki? Bize bu şekilde davranmaları ve anormal şartlarda çalıştırmaları normal!

Yukarda saymış olduğum aktiviteler modern yazılım pratiklerinden bazılarıdır. Nasıl bir duvar ustasının spatula, fırça gibi alet, edevatı olmadan çalışması zorsa, biz programcıların da bu pratikleri uygulamadan anlamlı sonuç üretmesi zordur. Ha, bu söylediklerim zaten günü kurtarmaya çalışanlara değil! Ben yazılım yapmayı bir bilim ve mühendislik dalı olarak görenler adına konuşuyorum.

Saydığım aktivitelerin lüks olarak görülmesini engelleyememişken, test güdümlü yazılım gibi aktiviteler nasıl algılanıyor sizce? Cevap: ultra lüks! Adam kafadan “iki programcı neden aynı işi yapsın ki, boşuna kaynak harcamam” diyor. Bak! Bak! Arkadaşım sana iki çift sözüm var: Birincisi biz kaynak değiliz, insan evladıyız, ikincisi şimdi sana test güdümlü yazılımın faydalarını anlatırdım, ama anlama kapasiten var mı bilmiyorum.

Zor! Gerçekten bu şartlarda, bu köhnemiş kafalarla beraber çalışmak çok zor. Bir dünya hayal ediyorum, içinde profesyonel programcıların mutlu, mesut oldukları, test güdümlü yazılım gibi pratiklerin ultra lüks değil de, gerekli oldukları düşünülen, proje gidişatını yetkin yazılımcıların tayin ettiği bir dünya. Ne yazik ki böyle bir dünya yok. Elimizdeki ile yetinmek zorundayız. Ama bu ara sıra masaya yumruğumuzla vuramayız anlamına gelmiyor.

EOF (End Of Fun)
Özcan Acar

Neden Her Programcının Bir Blog Sayfası Olmalı?

Blog kelimesi Web Log kelimelerinin kısaltılmış halidir. Bir blogu dijital ortamda tutulan bir günlük olarak düşünebiliriz. Aşağıda sıraladığım sebeplerden dolayı her programcının bir blog sayfası olmalı:

  • Blog bir programcının özgürce kendini ifade etmesini sağlar. Söyleyecek bir şeyi olan bir programcı blogu aracılığı ile okurları ile buluşur. Programcı okurlarından geribildirim niteliğinde yorumlar alır. Bu kendi düşüncelerini yapıcı yönde sorgulamasını sağlar.
  • Bir blog tutmanın en olumlu yanı bilgi paylaşımını teşvik etmesidir. Blog programcıyı daha paylaşımcı olmaya iter, yıldız programcı olma tehlikesine önler.
  • Sahip olduğu bilgi ve tecrübeyi blogu aracılığı ile paylaşan programcı diğer programcılara bilgi eksilerini gidermelerinde yardımcı olur. Ne kadar çok programcı bilgi paylaşımında bulunursa, o kadar çok okur bundan faydalanır.
  • Verimli olmanın önündeki en büyük engellerden birisi dahil olmak zorunda olunan e-posta trafiğidir. Birçok kişiye aynı konularda tekrar tekrar aynı cevaplar verilir. Sayfalar dolusu e-posta iletisi yazmak yerine, programcı bunu bir defaya mahsus kendi blog sayfasında ya da çalıştığı firmanın wiki sayfasında yaparak, ondan bilgi isteyenlere bu blog ya da wiki sayfasının linkini gönderebilir. Bu şekilde hem aynı cevapları yazarak zaman kaybetmez, hem de sahip olduğu bilgilerin merkezi bir yerde toplanmasını sağlar.
  • Blog yazılar zaman içinde programcı için kaynak referans haline gelir ve kendi çözümlerini tekrar gözden geçirme firsatı verir.
  • Blog yazmak günlük tutmak gibidir. Zamanla blog kişisel gelişimin aynası haline gelir.
  • İşverenler mülakat öncesi programcının internetteki izlerini araştırırlar. Güncel içeriğe sahip bir blog sahibi bir programcı mülakata 1-0 önde girer. Bloğu aracılığı ile bir programcı piyasa değerini artırmış olur.
  • Blog yazan programcının ana dilini kullanma kabiliyeti genişler. Bu günlük işlerine olumlu olarak yansır. Blog yazan programcı daha iyi kod ve doküman yazar ve ana dilini daha iyi kullanır.
  • Blog yazıları ile belli bir kesime hitap eden programcı bir zaman sonra güvenilir ve sektörde tanınan bir referans haline gelir.
  • Blog yazan programcı kendisi ile aynı fikirdeki diğer programcılarla tanışma ve bir araya gelme firsatı yakalar. Böylece programcının çevresi genişler, sosyal aktiviteleri artar, kendisi ile aynı fikirdeki diğer programcılarla fikir alışverisinde bulunur.

Bir blog sayfanız yoksa, hemen bir blog sayfası oluşturun. Blog yazı yazmayı zaman kaybı olarak görmeyin ya da yazdıklarımı kim okur demeyin. Bunu ilk etapta kendi kişisel gelişiminiz için yapıyorsunuz. Eğer kaliteli içerik oluşturabilirseniz ki zaman içinde bu şüphesiz gerçekleşecektir, o zaman okuyucu kitlenizin çok hızlı büyüdüğüne şahit olacaksınız.

Blog yazmanın size kattığı artı değeri çok kısa bir zamanda hissetmeye başlayacaksınız. Blog yazmadan bulu bilemessiniz :)

EOF (End Of Fun)
Özcan Acar

Benlik Güden Programcılar

Geçenlerde bir okuyucumdan bir e-posta aldım. İletisinin bir bölümünde şöyle yazmış:

“Mağrur programcı ustalar sizin gibi mi? Burnundan kıl aldırmaz. Onlara da şöyle diyorum: Mağrur olma padişahım senden büyük Google var“. Bunu okuyunca aklıma bu yazıyı yazmak geldi.

Ninem bize ufakken “benlik gütmeyin yavrularım, güzel bir şey değil” derdi. Yıllar sonra ne demek istediğini anladım. Allah rahmet eylesin, çok dayağını yedim ufakken :) Bir keresinde… neyse bunları başka bir yazımda anlatırım.

Benlik gütmek demek, her şeyi ben merkezli görmek demektir. Benlik güden bir şahıs yakaladığı her fırsatta “ben yaptım, ben başardım, en iyisini ben bilirim, bu konuda benden daha iyisi olamaz“ şeklinde kendini ifade eder ya da düşünür. Kendisini mükemmel ve kusursuz görerek, benlik güder ve kibirlenir.

Programcılık mesleği de ne yazık ki benlik gütmek için ideal bir ortam sunar. Programcılığın temelinde bilgi sahibi olmak yatar. Bu bilgiye sahip olan haklı bir gururla işini yapmaya çalışır. Bazı şahıslarda ne yazık ki bu gurur kibire dönüşür. Bilgi bu tür şahısları ne oldum delisi yapar. Bilgiye sıkı sıkı sarılırlar. Kimseyle paylaşmazlar. Gizli gizli yeni bilgi edinip, bilgilerine bilgi, kibirlerine kibir katarlar.

Bu tip programcılarla mutlaka siz de karşılaşmışsınızdır. Her projede bir örneğini bulmak mümkündür. Ben bu tür programcılara yıldız programcı (star developer) diyorum. Yıldız programcının hemen göze batan birkaç özelliği vardır. Toplantılarda en sesli onlar konuşurlar. Söyleyecek mutlaka bir şeyleri vardır. Genelde ortaya atılan görüşe ters pozisyon alarak, kendilerini dolu dolu ifade etme fırsatı yaratırlar. Siz bir şey söylemek istediğinizde “evet, ama…” şeklinde bölüp, kendi düşüncelerinin ne kadar daha doğru olduğunun altını çizerler. Karmaşık çözümleri yeğlerler. Bu onlara iki türlü avantaj sağlar: kimsenin kodu anlamaması yıldız programcının uzun vadede çalışma yerini korumasını sağlar (job protection); kodu anlamayan diğer programcılar devamlı yıldıza danışmak zorunda kalırlar. Bu da ona vazgeçilmez olduğu hissini verir. Yıldızlar blog ya da kitap yazmazlar. Kitap yazdılarsa bile referans olsun, namım yürüsün düşüncesiyle yazmışlardır. Bilgiyi güç olarak görürler ve bilgi paylaşmayı güç paylaşma olarak algılarlar. Böyle bir tip ile çocukluğuna geri dönüp, nelerin yanlış gittiğini gerçekten görmek isterdim. Mutlaka bir yerlerde bir şey olmuş olmalı. Ya annesinden yeterinde ilgi görmedi ya da okulda çok dayak yeyip, ezik büyüdü. Bu çünkü normal bir davranış biçimi değil!

Sektörümüzde benlik güden, kendini beğenmiş, sözde programcılara ihtiyacımız yok. İhtiyacımız olan, bilgisini karşılık beklemeden paylaşan, her konuda mütevazi, gençlerimize örnek olabilen programcılardır. Alın size birkaç örnek: Cem Ikta, Murat Yener, Gökalp Kuşcu, Mehmet Çeliksoy ve daha niceleri. Hepsinin blog sayfası var, devamlı bilgiyi paylaşma derdindeler. Neden? Bilginin paylaşarak çogaldığının bilincindeler. Yeni yetişen gençlere yardım etmeyi seviyorlar. Kendilerinin de bir zamanlar o konumda olduğunu unutmamışlar. Saygı ve hürmeti hak ediyorlar.

Okuyucumun dediği gibi “Mağrur olma padişahım senden büyük Google var“.

EOF (End Of Fun)
Özcan Acar

Melek Programcılar ve Şeytan Yatırımcılar

Melek yatırımcıları (business angels) bilirsiniz; hani şu yeni kurulmuş firmalara (startup) yatırım yapan şahıslar. Melek programcıları bilir misiniz? Bunlara gelmeden önce şeytan yatırımcıları açıklamam gerekiyor. Melek yatırımcıların yanında bir de şeytan yatırımcılar (business devils) vardır. Bunlar da melek yatırımcılar gibi yatırım yaparlar, ama niyetleri iyi değildir. Maksatları bellidir; kısa zamanda firmayı satıp (exit), para yapmak. Bu uğurda yapmayacakları yoktur. Genelde dünyadan ve ticaretten haberi olmayan, belki üniversiteyi yeni bitirmiş, İnternet üzerinden uygulanabilecek iyi bir ticari fikre sahip bir veya birden fazla programcının kurduğu firmalardır kendilerine seçtikleri kurbanlar. Ben bu programcılara melek programcılar diyorum. Okumaya devam et →

JVM Nasıl Çalışır Yazı Serisi – Old Generation Parallel Garbage Collector Hatası

Eğer özellikle bir Garbage Collector türü seçimi yapılmadı ise, 2 GB ve üzeri ve Windows işletim sistemi ile çalışmayan sunucularda JVM otomatik olarak paralel çalışan Garbage Collector’ü kullanıyor (-XX:UseParallelGC). Bu Garbage Collector sadece Young Generation üzerinde paralel, Old Generation için kullanılan Garbage Collector ise dizisel (serial) çalışıyor. Her iki heap alanında da paralel çalışan Garbage Collector’ü aktif hale getirmek için -XX=+UseParallelOldGC JVM parametresinin kullanılmasi gerekiyor. Bunu BizimAlem.com için çalışan uygulama sunucularından birinde denemek istedim. BizimAlem için JDK 1.5 kullanımda.

İkinci resimde görüldüğü gibi -XX:+UseParallelOldGC kullanıldığında JVM bir zaman sonra takılıp kalıyor ve çalışmaz hale geliyor. İlk denememde NewSize, SurvivorRatio gibi diğer parametrelerin hepsini deaktive edip, sadece -XX=+UseParallelOldGC parametresini kullanmıştım. Sonuç ikinci resimdeki gibi oldu. İlk önce yeni JVM ayarlarının sorun yarattığını düşündüm ve resim 1’de yer alan ayarlara geri döndüm. İkinci denememde de tekrar -XX=+UseParallelOldGC parametresini kullandım. Lakin ikinci denememde de JVM takılı kalıp, çalışmaz hale geldi. Buradan çıkardığımız sonuç: JDK 1.5 Update 12’de parallel Garbage Collector’ün bir bugı olsa gerek ;-)

EOF (End Of Fun)
Özcan Acar