Garbage Collector’dan bahsediyorum. Çoğu Java programcısının varlığından bile haberdar olmadığı, bazılarının çekindiği, bazılarının ne yaptığını tam olarak anlamdığı, bazılarının ise yaptığı işe hayran olup, ince ince hayranlık duyduğu Garbage Collector… Java’yı Java yapan özelliklerinden bir tanesi bir Garbage Collector’e sahip olmasıdır. Şimdi yakından tanıyalım bu kahramanı.

Java dilinde herhangi bir sınıftan bir nesne oluşturmak için new operatörü, Class.forName().newInstance(), clone() veya readObject() metodu kullanılır. Örneğin new operatörü sınıfın konstrüktörünü kullanarak JVM bünyesinde yeni bir nesne oluşturur. Nesne inşa edildikten sonra Java Heap içinde konuşlandırılır. Nesnelerin hepsi kullanıldıkları sürece heap icinde mutlu, mesut hayatlarını sürdürürler. Ama her canlı gibi onlar da birgün ölürler. Öldüklerinde onları toplayıp, ebediyete intikal ettiren Garbage Collector’dür.

İngilizce’de garbage çöp anlamına gelmektedir. Garbage Collector JVM bünyesinde hem yeni nesnelerin doğmasına yardımcı olan, hem de ölen nesneleri ortadan kaldıran modüldür. new operatörü ile doğan yeni nesneler için Garbage Collector hafıza alanını temin eder. Ölen ve çöp olarak isimlendirilen nesnelerin işgal ettikleri hafıza alanını Garbage Collector boşaltır ve yeni nesnelere tayin eder. Garbage Collector kısaca Java’da otomatik hafıza yönetiminden sorumludur. Onsuz Java’nın C/C++ dilinden bir farkı kalmazdı.

Garbage Collector’ün nasıl çalıştığını görebilmek için aşağıda yer alan videoyu hazırladım. Collector’ü kızdırmak için bolca çöp (garbage) üreten minik bir Java programını şu şekilde oluşturmak yeterli:

package com.kurumsaljava.jvm.garbage;

import java.util.ArrayList;
import java.util.List;

public class Heap {

	public static void main(String[] args) throws Exception {
		List<String> temp = new ArrayList<String>();

		Thread.sleep(10000);
		while (true) {

			temp.add("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx");
			//System.out.println(temp.size());

			if(temp.size() > 3000000) {
				temp = null;
				temp = new ArrayList<String>();

			}
		}
	}
}

Heap ismini taşıyan sınıf bünyesinde x’lerden oluşan uzunca bir String nesnesini sonsuz bir döngü içinde temp ismindeki bir listeye yerleştiriyoruz. Liste bünyesinde yer alan String nesne adedi 300.000′e ulaştığında listeye null değerini atayarak siliyor ve yeniden bir liste oluşturuyoruz. Döngü içinde tekrar String nesneleri yeni listeye ekleniyor. Buradaki amacım hafızanın tükenmesi ile java.lang.OutOfMemoryError oluşmasını engellemek ve Garbage Collector’ün değişik heap alanları üzerinde nasıl çalıştığını gösterebilmekti. Java’da herhangi bir nesneye null degeri atandığında Garbage Collector’e “bu nesne ölmüştür, yok edilebilir” mesajı verilmektedir. Eğer bu nesneye herhangi başka bir nesneden referans yoksa, Garbage Collector bu nesneyi öldü kabul edip, temizleyecektir. Şimdi beraber videoyu izleyelim.

Videoda yer alan program için 64 MB büyüklüğünde bir heap alanını -Xms64m -Xmx64m JVM parametreleri kullanarak tahsis ettim. Eğer heap alanı 10 MB olursa OutOfMemoryError hatası oluşmaktadır. Aynı şekilde liste içindeki String nesne adedini 600.000′e çıkardığımda hafıza yetersizliğinden dolayı OutOfMemoryError hatası oluşmaktadır.

Video ve oluşan Garbage Collection aktiviteleri hakkında detaya girmeden önce, değişik Garbage Collector mekanizmalarını ve algoritmalarını gözden geçirelim.

Generational Garbage Collection

Tipik bir Java uygulaması gözlemlendiğinde, uygulamanın hayatı süresince oluşan birçok nesnenin kısa ömürlü oldukları görülmektedir. Oluşturulan nesnelerin çogu bir metot son bulduktan sonra, sadece metot bünyesinde kullanıldıkları için hayata gözlerini yumarlar. Bunun yanısra bir Java uygulaması bünyesinde nesneler yaşlanarak belli bir yaşa erişebilirler. Bir nesnenin yaşlanma süreci uygulama bünyesinde kullanılma derecesini yansıtmaktadır.

Resim 1

Java uygulamarında oluşturulan nesnelerin hayat döngülerini yönetmek icin Sun firması tarafından JDK 1.3 versiyonu ile Generational Garbage Collection geliştirilmiştir. Resim 1’de görüldüğü gibi Generation Garbage Collection ile Java uygulamasının kullandığı hazıfa iki jenerasyona bölünmektedir. Yeni doğan nesneler genç jenerasyon (young generation), orta ve ileri yaşlı nesneler yaşlı jenerasyon (old generation) bölümünde konuşlandırılırlar.

Nesnelerin ait oldukları yaş gurubuna gore ihtiyaç duyulan hafıza yönetim mekanizmaları farklılık gösterir. Yeni jenerasyon bünyesinde nesne doğum ve ölümleri çok hızlı gerçekleşir. Bu bölümde kullanılan Garbage Collection algoritmasının yeni doğan nesnelere hızlı bir şekilde hazıfa alanı tahsis etmesi, ölen nesneleri ortadan kaldırması gerekmektedir. Bu jenerasyon için kullanılan Garbage Collection algoritması bu ihtiyaca cevap verecek şekilde geliştirilmiştir. Yaşlı jenerasyonda durum farklıdır. Bu bölümde Formel 1’de olduğu gibi hızlı haraket etme gerekliliği yoktur. Bu jenerasyonda nesneler daha yavaş bir hayat temposuna sahiptir. Bu jenerasyonda kullanılan Garbage Collection algoritması buna uygun şekilde geliştirilmistir.

Young Generation Garbage Collection

Young generation üç hafıza alanından oluşmaktadır. Bunlar Eden, Survivor 1 ve Survivor 2 hafıza alanlarıdır. Bir Java uygulamasında nesnelerin hepsi gözlerini Eden hafıza alanında dünyaya açarlar. Survivor 1 ve Survivor 2 alanları geçici ara hafıza alanı olarak kullanılır. Eden hafıza alanı dolduğunda, Garbage Collector hayatta kalan nesneleri önce boş olan Survivor alanlarından birisine kopyalar. Bu işlemin ardından Garbage Collector Eden ve kullanımda olan Survivor alanını boşaltır. Eden hafıza alanı tekrar dolduğunda, hayatta kalan nesneler ve dolu olan Survivor alanındaki nesnelerin hepsi tekrar boş olan Survivor alanına kopyalanır. Her zaman bir Survivor alanı boştur ve bir sonraki Garbage Collection işlemi sonunda hayatta kalan nesneleri bünyesine alacak şekilde pasif olarak bekler. Videoda da Eden ve Survivor hafıza alanlarının Garbage Collector tarafından doldurulma ve boşaltılma işlemleri görülmektedir. Young generation bünyesinde çalışan Garbage Collection mark & copy (işaretle ve kopyala) algoritmasını kullanmaktadır. Şimdi bu algoritmanın nasıl çalıştığını yakından inceleyelim.

Mark & Copy Algoritması

JVM bünyesinde kullanılan tüm Garbage Collection mekanizmaları hayattaki nesneleri işaretleme (mark) işlemi ile işe başlarlar. Garbage Collector hangi nesnelerin hayatta olduğunu anlamak için kök setini (root set) oluşturan nesnelerden yola çıkıp, diğer nesnelere olan bağlantıları takip eder. Bu işlemi bir ağacın kökünden yola çıkarak, dallarına kadar erişme olarak düşünebiliriz. Garbage Collector bu şekilde hayatta olan tüm nesneleri işaretler. Erişemediği diğer nesnelerin hepsini ölü kabul eder ve bir sonraki Garbage Collection ile ortadan kaldırılmalarını sağlar. Kök setinde kendisine doğru nesne referansı olmayan, ama kendisinden başka nesnelere referans giden nesneler yer alır. Bu tip nesneler genelde metot parametreleridir ya da global geçerliliği olan statik olarak tanımlanmış nesnelerdir.

Resim 2

Resim 2’de kök setin A ve E nesneslerinden oluştuğu görülmektedir. Garbage Collector işaretleme işine önce A nesnesinden yola çıkarak başlar. B, C ve dolaylı olarak D nesnelerine erişir ve bu nesne kümesini (A,B,C,D) hayatta olan nesneler olarak işaretler. İşaretleme işine E nesnesi ile devam eder. E nesnesi kök setinde yer alan bir nesnedir, lakin E’den yola çıkarak başka bir nesneye erişmek mümkün değildir. Ayrıca başka bir nesne de E nesnesine işaret etmemektedir. Bu yüzden E nesnesi artık ölmüş bir nesnedir ve bir sonraki Garbage Collection ile E nesnesinin işgal ettiği hafıza alanı temizlenir.

Garbage Collector işaretleme (mark) işlemini tamamladıktan sonra hayatta kalan nesneleri aktif olan Survivor alanına kopyalama işlemine başlar. Garbage Collector resim 2’de görüldüğü gibi hayatta kalan nesne kümesini (ABCD) aktif olan Survivor 1 alanına kopyalar. Nesneler, işgal ettikleri adres alanları arka arkaya gelecek şekilde Survivor 1’de konuşlandırılır. Garbage Collection işlemi sonunda hayatta kalan nesnelerin birbirlerine olan referansları ve sahip oldukları adres alanları değişeceği için Garbage Collector işaretleme ve kopyalama işlemi öncesinde uygulama bünyesinde çalışan tüm threadleri durdurmak zorundadır. Bu işlem JVM terminolojisinde dünyayı durdurma (stop the world) olarak adlandırılır. Belli bir süre boyunca uygulama durur ve uygulama bünyesinde aktif olan sadece Garbage Collector’dür. Eğer Garbage Collector işine başlamadan önce dünyayı durdurmamış olsa, aktif olan uygulama threadleri nesne referansları üzerinde değişiklik yaparak, Garbage Collector’ün yanlış nesneler üzerinde işlem yapmasına sebep olabilirler. Bu sebepten dolayı Garbage Collection öncesi dünyanın durması gerekmektedir.

Resim 3

Resim 3’de Garbage Collection sonrasınra Eden bünyesinde yeni nesnelerin oluştuğu görülmektedir. Kök set içinde X ve W nesnesi yer almaktadır. Garbage Collector X,Y,Z ve Survivor 1’de yer alan ABCD nesnelerini Survivor 2’ye kopyalar. Garbage Collection işlemi sonunda young generation hafıza alanındaki son durum resim 4’de yer almaktadır.

Resim 4

Görüldüğü gibi her Garbage Collection sonunda Survivor alanları rolleri değiştirmektedir. Survivor alanlarının her Garbage Collection sonrası yer degiştirmeleri resim 5’de de görülmektedir.

Resim 5

Resim 5’de yer alan birinci kolon Survivor 1’in, ikinci kolon Survivor 2’nin, üçüncü kolon Eden’in, dördüncü kolon Old hafıza alanının doluluk oranını göstermektedir. Görüldüğü gibi Garbage Collector düzenli olarak hayatta kalan nesneleri kopyalamak için pasif olan Survivor alanını kullanmaktadır.

Resim 6

Bir Java uygulaması -XX:+PrintHeapAtGC JVM parametresi ile çalıştırıldığv zaman, resim 6’da yer alan Garbage Collection log kayıtları oluşmaktadır. İlk kırmızı işaretli alan içinde Survivor 1 from, Survivor 2 ise to olarak isimlendirilmiştir. Survivor 1’in hafıza başlangıç adresi 0x30e40000, Survivor 2’nin hafıza başlangıç adresi 0x30c20000’dir. İkinci kırmızı işaretli alana baktığımızda from ve to’nun adres alanlarının değiştiğini görmekteyiz. Garbage Collection işlemi oluşmuş ve Survivor alanları yer degiştirmiştir. Garbage Collector tarafından hep bir Survivor alanı reserve durumunda bir sonraki Garbage Collection içinde kullanılmak üzere beklemede tutulur. Bu dogal olarak belirli bir hafıza alanının kullanılmayarak israf edildiği anlamına gelir. Ne yazık ki bu Mark & Copy algoritmasının bir dejavantajıdır. Bunun haricinde bu algoritma hızlı bir şekilde Eden bünyesinde olup bitenlere cevap verebilecek yetenekte ve kapasitededir.

Minor & Major Garbage Collection

Garbage Collection minor (küçük) ve major (büyük) olmak üzere ikiye ayrılır. Minor Garbage Collection’ı kendi odamızı, Major Garbage Collection’ı evimizi temizleme gibi düşünebiliriz. Young Generation bünyesinde yapılan Garbage Collection işlemine minor Garbage Collection, JVM kontrolündeki tüm hafıza alanlarının temizlenme işlemine major Garbage Collection ismi verilir.

Resim 7

Resim 7’de Garbage Collector tarafından yapılan minor ve major Garbage Collection işlemleri yer almaktadır. GC ile başlayan satırlar minor, Full GC ile başlayan satırlar major Garbage Collection yapıldığınin ibaresidir. Major Garbage Collection işlemi için ayrıca Full Garbage Collection ismi de kullanılmaktadır.

İlk satırda young generation tarafından işgal edilen hafıza alanı toplamda 11994 kilobytetır (~ 12 MB). Minor Garbage Collection işlemi sonunda ölen nesneler temizlenmiş ve hayatta kalan nesnelerin kapladığı alan 4048 (~ 4 MB) kilobyte olarak değişmiştir. Garbage Collector minor Garbage Collection işlemi ile 8 MB civarında ölü nesneyi hafıza alanından kaldırmıştır. Bu minor Garbage Collection işlemi 0.02 saniye sürmüştür. Bu zaman diliminde JVM bünyesinde sadece Garbage Collection işlemi yapılmıştır. Parantez içinde yer alan 63360K (~ 64 MB) JVM tarafından kullanılan tüm hafıza alanlarının toplamını yansıtmaktadır. JVM parametreleri olarak -Xms64m -Xmx64m kullandığımız için, programın işgal ettiği toplam hafıza alanı 64 MB’dir.

Eden hafıza alanı, Old hafıza alanına göre daha küçük olduğu için bu alanda minor Garbage Collection işlemleri Old generation bünyesinde olan major Garbage Collection işlemlerinden sayıca çok daha fazladır. Resim 7’de Garbage Collector 20 minor Garbage Collection, buna karşılık sadece 4 major Garbage Collection gerçekleştirmiştir.

Resim 8

Yedinci satırda major Garbage Collection yapıldığını görmekteyiz. Tüm JVM bünyesinde 56241 kilobyte (~56 MB) hafıza alanı kullanımdadır (young + s0 + s1 + old). Görüldüğü gibi bu değer JVM hafıza büyüklüğü olan 64 MB’ye yakın bir değerdir. Resim 8’de young ve old generation hafıza alanlarının dağılım oranları yer almaktadır. JVM Eden için 17 MB, S0 için 2 MB, S1 için 2 MB ve Old icin 42 MB alan ayırmıştır. JVM parametreleri ile hafıza alanlarının büyüklüklerini değiştirmek mümkündür. Buna yönelik bir ayarlama yapılmadığında JVM otomatik olarak hafıza alanlarının büyüklüğünü ayarlar. Full GC ardından hayatta kalan nesnelerin kapladığı alan 6011 kilobyte (~6MB) olarak değişmiştir. Bu major garbage collection işlemi ile 50 MB büyüklüğünde nesneler Garbage Collector tarafından ebediyete uğurlanmıştır.

Durdurun Dünyayı

“Durdurun dünyayı başım dönüyor” diyor Ferdi Tayfur şarkısında. JVM mucitleri Ferdi Tayfur’un bu şarkısından esinlenerek dünyayı durduran Garbage Collector algoritmaları geliştirmişlerdir. Arabesk müziğin Java üzerindeki etkilerini başka bir yazımda detaylı olarak ele alacağım. Arabeskin programcılık üzerinde etkileri düşünüldüğünden çok daha fazladır. (:)

Garbage Collector minor Garbage Collection için tek bir thread (Reaper Thread) kullanmaktadır. Garbage Collection işlemi esnasında Garbage Collector JVM bünyesinde çalışan tüm threadleri durdurur. Uygulama için dünya durmuş olur. Dünya ne kadar uzun durursa, uygulamanın kullanıcıya verdiği cevaplar o oranda gecikir. Buradan Garbage Collection işlemi esnasında verilen araların mümkün olduğunca kısa olması gerektiği sonucu çıkmaktadır. JVM mucitleri bunu göz önünde bulundurarak paralel çalışan minor Garbage Collection algoritması geliştirmişlerdir.

Paralel çalışan minor Garbage Collection algoritması, tekil threadle işini gören minor Garbage Collection ile teoride aynı yapıdadır. Aralarındaki tek fark, parelel minor Garbage Collection için birden fazla threadin çalışmasıdır. Bu şekilde stop the world duraklamaları daha kısaltılmış olur. Bu uygulamanın kullanıcıya karşı cevapkanlık oranını artırmaktadır.

Paralel minor Garbage Collection nasıl çalışmaktadır? Garbage Collector’ün temizleme işlemine hayatta kalan nesneleri işaretleyerek (mark) başladığını yazmıştım. Garbage Collector bu amaçla kök setinde yer alan nesneleri tarar ve bu nesnelerden yola çıkarak işaretleme işlemini yapar. Akabinde hayatta kalan tüm nesneleri aktif olan Survivor alanına kopyalar (copy). Paralel Minor Garbage Collection için kök setinde yer alan nesneler birden fazla Garbage Collection threadine atanır. Birden fazla thread paralel olarak kök setindeki bir nesneden yola çıkarak hayatta kalan nesneleri tararlar. Bu şekilde işaretleme performansı artırılır ve işaretleme için harcanan zaman azalır.

Hayatta kalan nesnelerin aktif olan Survivor alanına da kopyalanma işlemi buna benzer bir şekilde gerçekleşir. Her threade Survivor hafıza alanında PLAB (PLAB – Parallel Local Alocation Buffer) ismi verilen bir alan atanır. Garbage Collection threadleri birbirlerinden bağımsız olarak keşfettikleri ve hayatta kalmış olan nesneleri kendi PLAB alanlarına kopyalarlar.

Paralel Garbage Collection paralel çalışan threadlere rağmen dünyayı durduran bir algoritmadır. Tekil threadle çalışan Garbage Collection algoritmasına göre daha hızlı çalışır ve uygulamanın durma zamanlarını kısaltır. Birden fazla işlemcisi (CPU – Central Processing Unit) olan bir sunucu üzerinde paralel Garbage Collection algoritmasını kullanmak bu kazancı getirir. Lakin sadece bir işlemcisi olan sunucularda paralel Garbage Collection’ın kullanılması tam tersi bir etki yaratır.

Yazımın ikinci bölümünde major Garbage Collection’ın nasıl çalıştığını inceleyeceğim.

EOF (End Of Fun)
Özcan Acar

Sanat ve sanat eserleri görecelidir. İnsanlik var olduğundan beri sanat vardır, ama hala bu konudaki tartışmalar son bulmamıştır. „Renkler ve zenkler tartışılmaz“ sözünü sıkça işitmişizdir. Bu her bireyin sanat algılayış tarzının değişikliğine işaret etmektedir. Benim beğendiğim bir resmi, başka bir insan beğenmeyebilir. Bu yüzden sanatı tanımlamak ve bu işin içinden çıkmak çok karmaşık bir şeydir. Programcılığın da bir sanat olarak algılanıp, savunulması bu açıdan baktığımızda anlaşılabilir bir durumdur.

Bir sanat ya da sanat eseri ruha, göze ve gönüle hitap eder. Sanatın doğasında soyutluk vardır ve insanın kendisine özgün yorumuna ihtiyaç duyar. Bu yüzden herkesin sanatı algılayış tarzı değişiktir. Herkes sanatı kendi tarzında yorumlar. Eğer yazılan bir program parçası bir sanat eseri olmuş olsaydı, o zaman bu programa bakan herkes başka bir şey algılayacaktı ya da ondan kendi yorumladığı bir davranış biçimi bekleyecekti. Böyle bir şeyin yazılımda ne anlama geldiğini düşünebiliyor musunuz? Programcılık deterministik sonuçlar üretmek, mantık çerçevesinde kalıp, çözüm sunmak zorundadır. Ruha, gönüle değil, mantığa hitap eder. Sadece bu özelliğinden dolayı bile bir sanat olma şansı yoktur. Kim bir programa bakarsa baksın, aynı davranış biçimini görür, görmek zorundadır. Bir program her zaman aynı sonucu üretmek zorundadır, kod nasıl yazılmış olursa olsun. İnsanların yorumuna ihtiyacı yoktur, çünkü herkes aynı şeyi görür, daha dogrusu görmek zorundadır.

Programlar ihtiyaçtan doğarlar. Aynı şeyi sanat eserleri için söylemek mümkün değildir. Sanatkar bir şeylerden esinlenerek sanatını icra eder, zorda kalmadan, birilerine sanatını nasıl icra etmesi gerektiğini danışmadan. Programlar müşterileri tarafından kendi gereksinimlerini tatmin etmek için sipariş edilir. Müşterinin gereksinimleri programı yoğururken ön plandadır. Programı oluşturulurken müşteri ile iletişim esastır. Onun istediği olur.

Bunu yanısıra programcının kod yazarken soyutluğu ifade etmek için çok fazla seçenegi yoktur. Java dilinde interface ya da abstract sınıfları kullanarak soyut bir şeyler ifade edebilebilir. Bu ressamın paletinde sadece bir, iki renk olduğu anlamına gelir. Sadece iki rengi kullanarak sanat eseri oluşturmak mümkün müdür? Belki! Bir ressamın paletinde onlarca renk vardır, bunları karıştırarak sonsuz sayıda yeni renk elde edebilir. Bu renklerin hepsini kullanma potansiyeline sahiptir ve bu sanatına yansır. Günümüzün programlama dillerinde böyle bir zenginlik söz konusu değildir. Kaldı ki en tabana indiğimizde bir programcı sıfır ve birlerden oluşan verilerden başka bir şeyle ugraşmaz. Sadece iki renkli olan bir dünyada yaşar ve bir takım verileri A’dan B’ye taşıyacak programlar yazar. İşin hepi, topu budur.

Günümüzde nesneye yönetlik programlama paradigması popülerdir. Ne olduğuna baktığımızda programcı olarak işimizi yapabilmemiz için çok kısıtlı sayıda araç ihtiva ettiğini görmekteyiz. Gerçek dünyayı modellemek için sınıfları, bu modellere hareket kabiliyeti verebilmek icin metotları kullanırız. Koca dünyayı modellemek için sadece bu iki aracı kullanabiliyoruz. Kod yazarken yapmak istediklerimizi ifade etmek için if ya da while gibi basit komutları kullanıyoruz. Kullanabileceğimiz başka ne var ki? Bu araçlardan faydalanıp nasıl bir sanat eseri ortaya koyabiliriz? Bu bir sanat eseri olsa bile fonksiyonel işlevi haricinde nesi kimi ilgilendirir?

Görüldügü gibi programcı sahip olduğu araçlar itibari ile çok kısıtlı bir dünyada yaşamaktadır. Oysaki bir sanatçının dünyası rengarenk ve pırıl pırıldır. Sayısız derecede kombinasyon imkanları vardır. Bunlardan faydalanarak sanatını icra eder ve sanat eserleri oluşturur. Biz programcılar sıkışıp kaldığımız mantıksal dünyada bu araç gerece ve lükse sahip degiliz.

Kanımca programcılıkta kreatif olma, sanat icrası ile karıştırılmaktadır. Programcılar kreatiftir. Devamlı karşılaştıkları sorunları aşmak için çözümler üretirler. Bunun için bir zanaatkar usta gibi bir takım alet, edevata ihtiyaç duyarlar. Usta programcılar örneğin tüm tasarım prensiplerine hakımdirler. Nerede hangi tasarım şablonunu kullanmaları gerektiğini bilirler. Az ve öz kod yazmayı yeğlerler. Yazdıkları kod roman gibi okunur, kod okundukça bir hikaye gibi kendisini anlatır. Burada bir tutam estetiklik yok değildir. Ama yinede bu aktivitelerin hiçbirisi bir sanat eseri ortaya koymaz.

Programcılık mantık işidir. Biz programcılar mantığın kölesiyiz. Programcılıkta bütün gidişati mantık yönetir. Mantığın bittiği yerde programcılık biter. Bir sanatçı hiçbir şeyin kölesi değildir. Aradaki fark budur. Mantıkla sanatı kavramaya çalışmak beyhude bir iştir.

EOF (End Of Fun)
Özcan Acar

Java Heap JVM tarafından oluşturulur ve aşağıdaki hafıza alanlarından oluşur:

• Eden – new operatörü ile oluşturulan tüm nesneler önce bu hafıza alanında oluşturulur.
• Survivor – nesneler old heap hafıza alanına transfer edilmeden önce bir müddet survivor hafıza alanlarında kalır. Buradaki amaç kısa ömürlü olan nesnelerin Garbage Collector tarafından toplanmasına ve old heap alanına geçmelerini engellemektir.
• Old – uzun ömürlü nesnelerin ölene kadar kaldıkları hazıfa alanıdır.
• Permanent – sınıfların ve statik değerlerin yer aldığı hazıfa alanıdir.

Yukarda yer alan resime baktığımızda JVM tarafından yönetilen hafıza alanının (Java Heap) toplamda 5 GB olduğunu, bunun 1 GB’lik gibi bir kısmının EDEN Heap space, 150 MB’sinin iki SURVIVOR Heap Space ve 4 GB’sinin OLD Heap space tarafından kullanıldığını görmekteyiz. Toplamda JVM’in yönettiği ve içinde Java nesneleri oluşturabileceğimiz alan 5 GB büyüklüktedir.

JVM hakkında daha geniş kapsamlı bilgiyi Matrix’de Yaşayan Programcılar başlıklı yazımda bulabilirsiniz.

EOF (End Of Fun)
Özcan Acar

Gelelim gerçek hayattaki Matrix’e. Java ile program yazan programcılar da yazdıkları programlar gibi bir Matrix içinde yaşarlar. Bu dünyanın ismi JVM – Java Virtual Machine yani Java Sanal İşlemcisi‘dir. JVM C++ dilinde yazılmış bir programdır. Bir Java programı javac.exe ile derlendikten sonra byte code ismi verilen bir ara sürüm oluşur. Byte code, ana işlem biriminin (CPU – Cental Processing Unit) anlayacağı cinsten komutlar ihtiva etmez, yani klasik Assembler değildir. Java byte code sadece JVM bünyesinde çalışır. JVM, derlenen Java programı için ana işlemci birimi olma görevini üstlenir. Bu özelliginden dolayı Java programlarını değişik platformlar üzerinde çalıştırmak mümkündür. Her platform için bir JVM sürümü Java programlarını koşturmak için yeterli olacaktır. Bu sebepten dolayı Java “write once, run anywhere – bir kere yaz, her yerde koştur” ünvanına sahiptir.

Java programları java.exe komutu kullanılarak koşturulur. java.exe işletim sistemi bünyesinde bir JVM meydana getirir yani Matrix’i oluşturur. Bu Matrix Java programının yaşaması için gerekli ortamı ihtiva eder. Sıra dışı olmayan Java programları bu Matrix içinde dış dünya ile ilişkileri kesik bir şekilde yaşayıp giderler. Onların ihtiyaç duyduğu herşeyi Matrix onlara sunar. Java programları hangi işletim sistemi ya da hangi donanım üzerinde koştuklarını bile zorda kalmadıkça bilmezler. Onlar için her donanım üzerinde bir integer 4 byte yani 32 bittir. Bu sebepten dolayı Java’da C/C++ dan tanıdığımız unsigned int bulunmaz. İnteger hangi donanım olursa olsun 32 bittir, işletim sistemi ya da donanıma göre değişmez. Bu Java dilini tasarlayan mühendislerin Java programcılarının hayatını kolaylaştirmak için aldıkları bir tasarım kararıdır. Bir Java programının gördüğü alt yapı her zaman aynıdır. Java programcıları bunu bildikleri için Matrix haricinde olup bitenlere pek önem vermeden kodlarını yazarlar ve Matrix içinde yaşamaya devam ederler, taki Morpheus gelip programcıya mavi ve kırmızı hapları taktim edene kadar.

Klasik kurumsal Java projelerinde çalışan Java programcısı Matrix’in dışında olup bitenlerle ilgilenmez. JVM ona ihtiyaç duyduğu herşeyi sağlar. O yüzden programcının tercihi mavi hap ve Matrix içinde yaşamaya devam etmek olur.

Java sadece kurumsal projeler için kullanılmaz. Sıra dışı projelerde de Java’ya rastlamak mümkündür. Şu an çalıştığım proje bunun en iyi örneklerinden birisidir. Navteq/Nokia firmasının GeoCoder (http://maps.nokia.com) isminde, harita üzerinde lokasyon arama yapan bir servisi bulunmaktadır. Bu servis aynı zamanda Bing ve Yahoo tarafından kullanılmaktadır. Kısa bir zaman sonra Facebook tarafından kullanılma planları yapılmaktadır. Ben lokasyon arama işlemlerinin programlandığı ekipte çalışıyorum. Bu gibi projelerde Morpheus’un verdiği kırmızı hapı yutup, Matrix’in dışına çıkmak gerekiyor, aksi taktirde Matrix, yani JVM içinde kalarak uygulamanın tabiyatındaki sıra dışılığı anlamak ve kodlamak mümkün değildir. Bu sıra dışılık programcıyı çok daha değişik kategorilerde düşünmeye ve değişik disiplinlerde çalışmaya zorlamaktadır.

Nokia’nin lokasyon arama servisi için dünya çapında altı değişik hosting lokasyonunda 300 den fazla VM (virtual Machine – sanal sunucu) kullanılıyor. Aşağıdaki resimde de görüldüğü gibi her JVM işletim sistemi bünyesinde 40 GB’den daha fazla yer kaplıyor. Neden JVM için bu kadar büyük bir hafıza alanının kullanıldığını anlamak için, uygulamanın tabiyatını anlamak gerekiyor.

Yukarıda yer alan resimde işletim sistemi (RedHat Linux) JVM için yeni bir işlem (process) oluşturmuştur. Bu işlemin işletim sistemi bünyesindeki hafıza büyüklüğü toplamda (VIRT – Virtual – sanal) 44GB’dir. JVM için kullanılan hafıza (Heap size) 5 GB’dir. Heap ayarı -Xmx5g ile yapılmaktadır. Peki geriye kalan 39 GB neyin nesidir? Bunu anlamak için Matrix’in dışına çıkmamız gerekiyor, çünkü geriye kalan 39 GB Matrix’in dışında olup bitenleri temsil etmektedir.

Lokasyon arama servisi için klasik veri tabanı sistemi kullanılmamaktadır. Klasik bir veri tabanı sisteminin kullanılması ve lokasyon arama işlemlerinin bu veri tabanı üzerinden yapılması arama süresini dakikalara çıkarabilir. Arama sonuçlarının 100 ms (100 milisecond bir saniyenin onda biridir) gibi bir zaman diliminde oluşturulması şartı bu projede klasik veri tabanlarının aksine bir tercihi zorunlu kılmıştır. Veri tabanından çekilen verilerle dosya tabanlı yeni bir veri tabanı oluşturulmakta ve bu dosyalar onlarca GB büyüklükte olabilmektedir. Bu veri tabanında bulunan verilere index dosyaları üzerinden erişilmektedir. Örneğin kullanıcı İstanbul Kadıköy lokasyonunu aradığında, arama işlemi önce index dosyasında yapılmaktadır. İndex dosyasında İstabul Kadıköy için bir veri bulunduğunda, bu veri adres nesnesinin dosya veri tabanındaki gerçek adresini (storage id) ihtiva etmektedir. Bu şekilde index üzerinden dosya veri tabanındaki adres nesnesine ulaşmak mümkün olmaktadır. Arama işlemlerinin hızlı yapılabilmesi için bu index ve diğer veri tabanı dosyalarının topluca hazıfaya yüklenmesi gerekmektedir. Aksi taktirde arama işlemleri çok uzun sürebilmektedir, çünkü arama esnasında hafızada yüklü olmayan bir adres nesnesi bulundu ise, bu nesnenin disk üzerinde bulunan veri tabanı dosyalarından yüklenmesi gerekmektedir. Bu gibi IO (Input/Output) işlemleri zaman aldığı için, genel olarak arama işlemi bu gibi durumlarda uzamaktadır. Bunun önüne geçmek için tüm dosyaların hafızaya yüklenmesi gerekmektedir. Bu işlemi yapmak için de Java Memory Mapped Files yapıları kullanılmaktadır.

-bash-3.2$ pmap PID komutunu girdiğimizde 39 GB alanın ne için kullanıldığını görebiliyoruz.

Yukarıda yer alan resimde görüldüğü gibi uygulama bünyesinde kullanılan tüm dosyalar işletim sistemi tarafından oluşturulan işleme (process) dahil edişmiştir. Bu dosyalara Java terminolojisinde Memory Mapped Files (hazıfada yüklü dosyalar) ismi verilmektedir. Yüksek performansın önemli olduğu durumlarda bu dosyaların %100 hafızaya yüklenmiş olmaları büyük önem taşımaktadır. Aksi taktirde dosyaların kullanılmak istendiğinde hafızada olmamaları performansı kötü etkilemektedir. Kullanılan hafıza alanının arkasında bir dosya yoksa yani bir memory mapped file kullanılmıyorsa, bu alanlar [ anon ] (anonim) olarak listede gözükmektedir.

Bizim örneğimizde ihtiyaç duyulan tüm dosyaların hepsinin %100 hafızaya yüklenmediğini görüyoruz. İlk resimde yer alan RES (resident – aktüel işgal edilen hazıfa alanı anlamnda) kolonuna göre JVM’in aslında 36 GB hafıza alanı işgal etmektedir. İşletim sistemi biz zorlamadıkça kullanılan tüm dosyaları %100 hafızaya yüklemez. Bu şekilde örneğin kullanılmayan fonsiyon kütüphanelerinin hafızada boş yere yer işgal etmesi engellenmiş olur. Bunun yanısıra işletim sistemi her program tarafından kullanılan ortak fonksiyon kütüphanelerini sadece bir kez hazıya yükleyerek, bu dosyaların değişik işlemler (process) tarafından ortaklaşa kullanılmasını sağlar. Birinci resimde SHR (shared – ortaklaşa kullanılan hafıza alanı anlamında) kolonuna baktığımızda bu değerin 12 GB oldugunu görmekteyiz, yani başka programlarla paylaştığımız 12 GB büyüklügünde dosyalar işlemci hafızamıza (Java Process Heap) yüklenmış durumdadır.

Belirttigim gibi bu dosyalar 5 GB’lik Java Heap içinde yer almamaktadırlar. Bu dosyalar daha önce bahsettiğim 39 GB’lik hafaza alanında yer almaktadir. Bu hafıza alanına Java Process Heap, normal Java nesnelerinin yer aldığı alana ise Java Heap ismi verilmektedir. Java Heap ve Java Process Heap bir araya geldiğinde 44 GB’lik, ilk resimde gördüğümüz Java işleminin tüm hafıza alanı ortaya çıkmaktadır. Java Process Heap alanı işletim sisteminden malloc() sistem fonksiyonu kullanılarak oluşturulan hafıza alanıdır. Java’da bu hafiza alanına genel olarak native memory ismi verilir. JNI (Java Native Interface) kullanılarak Java uygulamaları için native memory alanı oluşturmak ve kullanmak mümkündür. Java içinde ise hafıza alanı new operatörünü kullanarak tedarik edilir. Bu hafıza alanı oluşturduğumuz nesne için direk Java Heap bünyesinden gelir ve tamamen JVM tarafından, daha doğrusu Garbage Collector (kullanılmayan nesnelere garbage ismi verilir) tarafından yönetilir.

Yukarda yer alan resime baktığımızda JVM tarafından yönetilen hafıza alanının toplamda 5 GB olduğunu, bunun 1 GB’lik gibi bir kısmının EDEN Heap space, 150 MB’sinin iki SURVIVOR Heap Space ve 4 GB’sinin OLD Heap space tarafından kullanıldığını görmekteyiz. Toplamda JVM’in yönettiği ve içinde Java nesneleri oluşturabileceğimiz alan 5 GB büyüklüktedir.

Bahsettiğim index ya da veri tabanı dosyalarının normal heap içinde bulunmaları JVM’e fazladan yük getirmekte ve Garbage Collection işlemini uzatmaktadır. Bu tür dosyaları normal Heap içinden Java Process Heap’e (native memory alanına) taşımak için ByteBuffer sınıfı kullanılmaktadır. ByteBuffer.allocateDirect() metodu ile en fazla 2 GB büyüklüğünge, Java Heap dışında hafıza alanı rezerve etmek mümkündür. Bu hafıza alanı Java Process Heap içinde yer alacaktır. allocateDirect() metoduna baktğımızda native hafıza rezervasyonu için sun.misc.Unsafe sınıfının allocateMemory() metodunun kullanıldığını görmekteyiz. Bu native olarak tanımlanmış ve C++ dilinde kodlanmış bir metotdur. Buradan da anlaşıldığı gibi Java bünyesinde bu sınıfı kullanmadan native memory rezervasyonu mümkün değildir.

JVM bünyesinde tüm hafıza otomatik olarak JVM ve Garbage Collector tarafindan yönetilir. Programcının bu konuda yapması gereken fazla birşey yoktur. Java Heap dışında işlem yapmak zorunda kalındığında durum farklıdır. Native hafıza alanını JVM bünyesindeki Garbage Collector yönetmez. Programcının C/C++ dillerinde olduğu gibi native hafıza alanını kendisi yönetmesi gerekir. Bu yüzden Morpheus’un verdiği kırmızı hapı yutup, Matrix’in dışına çıkması gerekir. Sadece Matrix’in dışında olan programcılar gerçekte olup bitenlerden haberdardırlar.

EOF (End Of Fun)
Özcan Acar

Şimdi birkaç saniyeliğine bir dünya hayal edelim; İçinde IPhone ve Android akıllı telefonların olduğu, ama app denen birşeyin bilinmediği, bilgisayarların olduğu, ama işletim sistemi diye birşeyin icat edilmediği, internetin olduğu, ama iletişim kurmak için e-posta ve web sunucularının olmadığı bir dünya… Bu dünyada eksik olan nedir? Evet, yazılım yapılmıyor bu dünyada. Yazılım sistemlerini kim yapıyor? Evet, biz programcılar. Yani? Bu dünyayı daha yaşanır hale getiren, oluşturdukları yazılım sistemleri ile devrim yaratan, insanlığa yön veren, insanlık tarihinde dünyanın ilk kez kocaman bir köy olmasını sağlayan ve insanlığa hizmet eden biz programcılarız. Ameliyat eden robotlardan tutun, uzaya gönderilen uydulardan, havada uçan uçakların kontrol sistemlerine hadar her yerde, içinde program çalışan birşeyler görmek mümkündür. Yazılım sistemleri modern insanın sürdürdüğü yaşam tarzının vazgeçilmez bir parçası haline gelmiştir.

Hacker’ları bunun dışında tutmak şartıyla oluşturduğumuz birçok yazılım sistemi doğrudan insanlığa hizmet etmektedir. Bunun en güzel örneğini açık kaynaklı yazılım sistemleri oluşturmaktadır. Onların başında da Linux işletim sistemi gelmektedir. Toplum yazılım sistemlerinin insanlık için önemini anlamış olmalı ki, yazılımcılara nişanlar verilmektedir. Bunun bir örneğini geçtigimiz ay Linux işletim sisteminin mucidi Linus Torwald’e verilen Millennium Technology Prize 2012 nişanı teskil etmektedir.

Ödülü veren akademi tarafından yapılan açıklamada Linus’un açık kaynaklı bir yazılım sistemi geliştirmesinin dağıtık yazılım sistemleri oluşturmaya ve internetin özgür olmasına katkıda bulunduğu belirtilmektedir. Linux işletim sistemi milyonlarca, belki de milyarlarca insan tarafından kullanılma potansiyeline sahiptir. Linus yaptığı açıklamada, yazılım sistemlerinin modern dünyada çok önemli olduklarını ve insanlığa hizmet edebillmeleri için mutlaka açık kaynaklı olmaları gerektiğinin altını çizmiştir.

Durum böyle iken biz programcıların üstlendiği toplumsal sorumluluk artmaktadır. Hatasız yazılım sistemleri oluşturmamız gerekmektedir. Birçok insan günlük hayatında kullandıkları yazılım sistemlerinin hatasız çalışmasına güvenmek zorundadır. Yazılım hatalarının meydana gelmesi onların hata yapmasına sebep verebilmektedir. Baştan savma yazılım sistemleri oluşturarak onların güvenini yitirmeyelim.

Bu arada TIR sürücüsüne “navigasyon aygıtınız yok mu” sorusunu sormadan edemedim. “Var, ama çalışmıyor” dedi. Bir yazılım hatasıymış sanırım ;-) Yazılımda daha iyi olmamız lazım. İnsanlar bize güveniyor.

EOF (End Of Fun)
Özcan Acar

Benim kariyer planlamam şöyle:
Üniversite »» Ömür boyu programcılık

Ben programcıyım, yönetici değilim! Üniversitede eğitimini almadığım birşey nasıl olabilirim? Neden programcıların çoğu bir yerlere yönetici ya da müdür olmak istiyor? Bunun açıklaması kolay: daha fazla maaş alacaklarını düşündükleri ya da pozisyon itibariyle daha fazla dikkate alınmak istedikleri için.

Herşeyin statü sembolleri ile ölçüldüğü bir toplumda programcıların daha fazla para kazanmak için yönetici olma sevdalarını ayıplamıyorum. Bu sadece programcılar için geçerli bir durum değil. Benim ayıpladığım programcının bu uğurda ruhunu satmasıdır. Eğer bir insan programcı oldu ise, bu işe gönül verdiği için olmuştur. Mecburiyetten olan programcı zaten programcı sayılmaz. Eğer yaptığı işi sevmiyorsa, bırakıp başka bir iş yapması mübahtır. Aldığı para kendisini tatmin etmiyorsa, benim kişisel olarak yapabileceğim birşey yok (ama daha fazla nasıl kazanabileceğine daha sonra değineceğim). Ama bu işin birde manevi tarafı yok mu? Haz alarak yaptığı bir iş insanı mutlu etmez mi? Neden daha fazla maaş, insanı mutlu eden bir işe tercih edilir ki? Bunu anlamam çok zor.

Yöneticilik ya da müdürlük öyle her babayiğidin harcı değildir. Yönetici olmak isteyen programcılar bunu bilmiyor galiba. Bu işin bir defa eğitimini almak gerekir. Yönetim kademesindeki insanların liderlik, çalışanlara örnek olma, onları motive etme, güçlü iletişim gibi vasıflara ihtiyacı vardır. Çok ağır şartlarda çalışıp, neticesi geniş kapsamlı kararlar vermek zorunda kalırlar. Üstlerinde büyük sorumluluk taşırlar. Daha fazla maaşı hak ederler, ama bedelini de öderler.

Saydığım bu sebeplerden dolayı yöneticiliğe talip değilim. Ben bu işten anlamam. Ben bildiğim işi yapmayı yeğlerim. Programcıyken, yöneticiliğe soyunanlara da kazaları mübarek olsun derim.

Programcılar Yönetici Olmaya Zorlanıyor

Ömür boyu programcı olarak çalışmak isteyenler de yok değil. Nedendir bilmiyorum ama Türkiye’de „insan kırk yaşından sonra programcı olarak çalışmaz“ kanısı oluşmuş. Yaşlı programcılara kötü gözle bakıldığı bir toplum içinde yaşıyoruz. Hala bir baltaya sap olamamış ve programcılık yapıyor denilebiliyor. Aman allahım, inanılacak gibi değil!

Bu şartlar altında programcıların üzerinde yönetici olma doğrultusunda baskı oluşmuyor değil. Lakin bu baskıya karşı koyup, programcının programcı olarak yoluna devam etmesi şarttır. Programcının gönlünde yatan aslan bellidir. Programcılar kendi kariyer planlamalarını kendileri yapmalı, başkalarının buna müdahele etmesine karşı koymalıdırlar. Müdahele olduğunda buna baş kaldırıp, dik durmalı ve statükolarını korumalıdırlar. Yoksa sonuç bellidir: yaptığı işten memnun olmayan bir sürü eski programcı yönetici.

Bunun yanısıra birde firmalardaki kariyer yapma imkanlarına göz attığımızda, çoğu programcıya yönetici olmaktan başka seçenek kalmadığını görmekteyiz. Avrupa ve Amerika’da durum çok farklıdır. Büyük yazılım firmalarına baktığımızda, ömür boyu mühendis kalınabildiği, bu konuda uzmanlaşma imkanı veren kariyer patikalarının olduğunu görmekteyiz. Bunun bir örneğini IBM’in çalışanlarına sunduğu Distinguished Engineer olma imkanı teşkil etmektedir.

Programcılar Mutlu Değil

Programcılar ne yazık ki yaptıkları işten memnun ve mutlu değiller. Devamlı günü kurtarmaya çalışmak, verilen emeğe ilgi ve saygının olmaması, fazla mesai yapmaya zorlamalar programcının içindeki şevki kırabilir. Ama bir programcı yöneticiliğe upgrade yaptığında durum farklı mı olacaktır? Pek zannetmiyorum. Öyleyse gönül verdiğimiz işi yapacak şekilde ortam hazırlamaya bakalım.

Programcılar İşsiz Kalmaz

Programcılar şarap gibidir. Kendilerini geliştirmeleri, ustalaşmaları şartıyla yaşlandıkça kıymetlenirler. Yetkin bir programcının piyasada işsiz kalması imkansızdır. Herhangi bir işi yapan bir yöneticinin işsiz kalma ya da işten çıkarılma rizikosu yetkin bir programcıdan çok daha yüksektir. Yetkin bir programcıyı kolay kolay kimse işten çıkartamaz. Geliştirdiği uygulama hakkında o kadar çok bilgiye sahiptir ki yeri kolay kolay doldurulamaz. Yetkin programcılar piyasada freelancer olarak çalışıp, maaşlarının birkaç katı fazlasını kazanabilirler.

Bu kadar uzman progragramcının arandığı bir piyasada kim ne yapsın yöneticiliği. Programcılık güzel ve geleceği olan bir meslektir. Kıymetini bilelim.

EOF (End Of Fun)
Özcan Acar

Vikipedi’ye baktığımızda sanat ve zanaat için aşağıdaki tanımlamayı yapmakta:

Sanat en genel anlamıyla, yaratıcılığın ve hayalgücünün ifadesi olarak anlaşılır. Tarih boyunca neyin sanat olarak adlandırılacağına dair fikirler sürekli değişmiş, bu geniş anlama zaman içinde değişik kısıtlamalar getirilip yeni tanımlar yaratılmıştır. Bugün sanat terimi birçok kişi tarafından çok basit ve net gözüken bir kavram gibi kullanılabildiği gibi akademik çevrelerde sanatın ne şekilde tanımlanabileceği, hatta tanımlanabilir olup olmadığı bile hararetli bir tartışma konusudur. Açık olan nokta ise sanatın insanlığın evrensel bir değeri olduğu, kısıtlı veya değişik şekillerde bile olsa her kültürde görüldüğüdür. Sanat sözcüğü genelde görsel sanatlar anlamında kullanılır.

Zanaat , sermayeden çok nitelikli emeğe dayalı; öğrenimin yanısıra el becerisi ve ustalık gerektiren meslek. Zanaatkâr, zanaatle uğraşan kişi anlamına gelir. Marangozluk, ayakkabıcılık, kuyumculuk (takı üreten), kumaş boyama, çömlekçilik, berberlik, bakırcılık gibi mesleklerin hepsi birer zanaattir. Bir kimsenin zanaatkâr olması için el becerisi gerektiren bir malı veya hizmeti sadece satması değil, bilfiil üretmesi gerekir.

Yaptığımız işte he ikisinden de birşeyler var değil mi? Okunması kolay estetik kod yazarak bir sanatkar, müşteri gereksinimlerini tatmin eden uygulamalar geliştirerek bir zanaatkar olabiliyoruz. Ama gerçek hayatta durum ne yazık ki çok farklı. Sanatkar değiliz, çünkü müşterimiz güzel kod yazıyoruz diye bize iş vermiyor. Zanaatkar değiliz, çünkü yazılımcı olarak usta-çırak geleneğinden yetişerek işimizin başına gelmiyoruz. Neden böyle düşündüğümü bu yazımda sizinle paylaşmaya çalışacağım.

Birgün yolunuz Gaziantep’e düşerse Bakırcılar Çarşısı’na mutlaka uğrayın. Orada çalışan bakır ustaları kelimenin tam anlamıyla hem sanatkardırlar hem de zanaatkar. Sanatkardırlar, çünkü estetik değerler oluştururlar. Zanaatkardırlar, çünkü usta-çırak kültürüyle yetişip, el emekleri ile bu değerleri oluştururlar.

Bir bakır ustasının elinde vücut bulan ve yirmi ile yüz Türk Lirası arasında bir fiyata sahip bir bakır kupanın sadece su içmek için edinildiğini görmedim. Ufak bir sanat eseri olan bu bakır kupayı evimizdeki vitrinleri süslemek için ediniriz. Bizim için önemli olan kupanın fonksiyonel işlevi (kupadan su içmek) değildir. Daha ziyade kupanın estetik yönü ilgimizi çeker. Bu yüzden bakır kupa bir sanat eseridir, bakır ustası da bir sanatkar.

Peki camdan üretilen su bardakları sanat eserleri midir? Bu su bardaklarını üretenler sanatkar mıdır? Şüphesiz tanesi yüzlerce Türk Lirası’nı bulan su bardakları bulmak zor değildir. Ama pahalı olmaları sanat eserleri oldukları anlamına gelmez. Camdan yapılmış bir su bardağını su içmek için alırız. Bizim için su bardağının tatmin etmesi gereken fonksiyonel bir işlevi vardır. Su bardağının bu fonksiyonel işlevi yerine getirirken bir sanat eseri olup, olmadığı bizi ilgilendirmez. Herhangi bir marketten tanesi bir Türk Lirası olan onlarca su bardağı alıp, mutfaktaki dolaba koyarız. Su içmek istediğimizde bir bardak alıp, kullanırız. Bizim için camdan üretilmiş bir su bardağının fonksiyonel işlevi ön planda oldugu için, bu su bardağı bir sanat eseri değildir. Aynı şekilde bu bardakları üretenler de bizim gözümüde sanatkar değildirler.

Buradan çıkardığım sonuç şudur: Sanat eserlerinde fonksiyonel işlev önemli değildir. Dikkat bulan, icra edilen sanattır. İcra edilen bu sanat, sanat eserleri meydana getirir. Fonksiyonel işlevin önemli olduğu yerlerde ise sanat eserleri tercih edilmez. Sanat eseri ve sanatkar olmayı belirleyen faktör budur.

Programcılık Sanat, Programcı da sanatkar değildir.

Bazı programcılar program yazma aktivitesini sanat olarak, bu işi yaptıklarından dolayı kendilerini de sanatkar olarak görmektedirler. Bu ne yazık ki doğru değildir. Program yazmak fonksiyonel bir işlevi meydana getirmek için yapılan bir aktivitedir. Camdan su bardağı örneğinde olduğu gibi, müşterimiz bizim yazdığımız programın estetik kısmıyla ilgilenmez. Onun için oluşturulan uygulamanın tatmin etmesi gereken sadece fonksiyonel bir işlevi vardır. Uygulamanın ne kadar güzel kodlandığı ile ilgilenmez. Hiç, bir müşterinin kodu açıp, okumaya çalışıp, ne kadar güzel yazılmış, ya da yazılmamış diye yorum yaptığını görmedim. Durum böyle iken, müşteriye sattığımız uygulama bir sanat eseri değildir. Bir sanat eseri oluşturup, satmadığımıza göre, programcı olarak sanatkar olmamızda mümkün değildir.

Bir programcı olarak müşterinin gereksinimlerini tatmin eden, sadece fonksiyonel işlevi olan ürünler ortaya koyarız. Müşteri oluşturduğumuz uygulamaya baktığında bir sanat eseri, bize baktığında bir sanatkar görmez. Ama aynı şahıs bir bakır ustasına baktığında bir sanat eseri ve sanatkar görür. Demek oluyor ki sanat eserine ve sanatkara bu sıfatı değer görenler başkalarıdır. Kendi kendimize sanat eseri ortaya koyduğumuzu ve sanatkar olduğumuzu iddia etmemiz birşeyi değiştirmez. Bu yüzden programcının kendisini sanatkar olarak görmesi doğru değildir, çünkü müşterisinin gözünde sanatkar değildir.

Programcılar Zanaatkar Değildir

Zanaat demek ustalık demektir; gelenek demektir; ustadan öğrenmek demektir. Siz hiç bir berber çırağının ilk işe başladığı gün saç kestiğini gördünüz mü? Çırak önce ustasına hizmet edip, ondan birşeyler öğrenmeye ve yavaş yavaş olgunlaşmaya başlayacaktır. Usta ise çırağını kendi tecrübeleri doğrultusunda ve kendi ustasından öğrendigi şekilde yönlendirecektir. Belli bir zaman diliminden sonra çırak yavaş yavaş bir zanaatkara dönüşecektir. Bunun gerçekleşmesi için ustasının kendisine gösterdigi yolu takip etmesi gerekmektedir. Bu yolu gitmek yıllar sürebilir. Ama bu yolun sonunda çırak için kendi ustası gibi bir usta, bir zanaatkar olma ödülü vardır. Ustalaşmak ve bir zanaatkar olmak hiç te kolay olmayan bir süreçtir. Ustası olmayan bir çırağın, bu yolu tek başına giderek ustalaşması çok zor olacaktır ya da mümkün olmayacaktır.

Yukarda yer alan tanımlamaya gore programcılar zanaatkar değildir, çünkü programcılar usta-çırak geleneginden gelerek yetişmezler. Programcılar için işe başlama bariyeri yok denecek kadar azdır. Bir bilgisayar ya da başka bir mühendislik ögrencisi diplomasını eline aldığı andan itibaren programcı olarak çalışmaya başlayabilir. Hiç kimse senin ustan kim ya da kaç sene çırak programcı olarak çalıştın diye soru sormaz. Programcının daha önce hangi projelerde çalıştığı sorulur. Buradaki amaç daha çok programcının ne kadar tecrübeli olduğunu anlamaya çalışmaktır. Ama yıl bazında edinilen tecrübe, şahsın ustalık oranını göstermez. On sene tecrübesi olduğunu söyleyen bir programcı, son dokuz senesini, birinci sene öğrendiği şeyleri tekrarlamakla geçirdiyse, son dokuz sene tecrübe topladığı söylenemez.

Tecrübesiz ve bir usta tarafından yetiştirilmemiş bir programacının hemen program yazmaya başlamasını, diplomasını almış bir doktorun hemen kalp ameliyatı yapmaya başlamasıyla kıyasladığımızda, durumun programcılar açısından aslında ne kadar absürd olduğunu görebiliriz. Kalp ameliyatı yapmaya aday bir doktor yıllarını usta doktorlara asistanlık yapmakla geçirir. Bu ona kalp ameliyatlarının nasıl yapıldığını ustalarından öğrenme fırsatı verir. Asistanlık dönemi bittikten sonra, asistan doktor seçtiği dalda uzmanlaşma dönemine girer. Hem asistanlık hem de uzmanlaşma döneminde doktor adayı ustalarından gerekli herşeyi öğrenerek, onlarca seneyi bulacak bir zaman diliminden sonra kalp ameliyetlarını yapabilecek kıvama gelir. Yukarda da belirttiğim gibi programcılar için bunların hiçbirisi geçerli değildir. Programcı diplomasını alır, masasının başına oturur ve hemen müşteri için program yazmaya başlar. Neden birçok projenin yapılan hatalı kalp ameliyatlarından dolayı öldüğü ortadadır, çünkü ameliyatı yapan programcılar yetkin değildir.

Usta-çırak geleneğinin olmadığı yerde bir zanaatin icrası ya da yapılan işin zanaat olarak tanımlanması çok zordur. Programcılar ustasız yetiştikleri için, zamanlarının büyük bir kısmını deneme yanılmayla boşuna sarf ederler. Yıllarca aynı şeyleri yapıp, yerlerinde saysalar bile, bunu tecrübe yapmış olarak algılarlar. Kendilerine yön gösteren bir ustaları olmadığı için kendilerini geliştirmekte ve ustalaşmakta çok zorlanırlar. Bu sebepten dolayı birçok programcı ustalık mertebesine erişemez. Oysaki bir ustanın denetiminde olsalar ustalaşmaları çok daha kolay olacaktır.

Programcılık Zanaattir

Bir önceki bölümün başlığına baktığınızda bu bölümün başlığı tezat gibi algılanabilir. Bir önceki bölümde neden zanaatkar olamadığımızı anlatmaya çalıştım. Bu bölümde ise aslında neden zanaatkar olduğumuzu anlatmak istiyorum.

Zanaati, sermayeden çok nitelikli emeğe dayalı; öğrenimin yanısıra el becerisi ve ustalık gerektiren meslek şeklinde tanımlamıştık. Bunun yanısıra bir zanaat usta-çırak geleneğini kapsamaktadır. Bu tanımlama bir programcıya tamamen uygun yapıdadır. Eksik olan programcıların ustasız yetişmeleridir. Ama bu onların zanaatkar olmadıkları anlamına gelmez. Bu eksiği kapatmak için ustalığa giden yolun tarifini yapmamız gerekmektedir. Bilge Programcı programı (http://www.bilgeprogramci.com – şu an üzerinde çalıştığım, yapım aşamasında olan projemdir) böyle bir yolun tarifesini ihtiva eder. Daha once bu yoldan geçmiş, şimdilerde usta programcılardan kendimize örnek alarak, bizde yaptığımız işte ustalaşabiliriz. Ustalaştıkca bir zanaatkar olmaya başlarız ve yaptığımız iş bir zanaat haline dönüşür. Usta programcılar zanaatkardırlar. Genç programcılara da onlara çırak olmak düşer. Eti senin, kemiği benim misali :)

Not: Bu yazının devamı olarak Mantığın Köleleri başlıklı biz yazı daha oluşturdum. Bilginize sunarım.

EOF (End Of Fun)
Özcan Acar

Yeni bir ekibe katılan bir progrmacının kendini ispatlama stratejisi nasıl olmalıdır? Eğer programcının ünü yeni ekibe kendisinden önce ulaşmadı ise, o zaman programcının işi hiç te kolay değildir. Eğer ünü yoksa, durum daha da vahimdir. Kendisini o projede ispatlayana kadar canı çıkabilir, belki de bunu hiç başaramaz ve bu onu mutsuz olmaya itebilir.

Bu stratejinin nasıl olmaması gerektiği ile başlayalım isterseniz. Eğer programcı bir kenara çekilip, “bana verilen işleri yapmaya çalışayım” derse, o zaman baştan oyunu kaybetti demektir. Farklılık yaratmak ve profil oluşturmak istiyorsa, bir görevin (task) kendisine verilmesini beklemeyip, kendisi görev seçmelidir. Genelde kimsenin cesaret edip, üstlenemediği görevler ortada kalır. Bu tip görevler, diğer ekip arkadaşları arasından sıyrılıp, kendisini kısa zamanda ispatlamak için biçilmiş kaftan gibidir. Doğal olarak zor görevler yetkinlik gerektirir. Ama programcıyı pişiren bu tür görevlerdir. Örneğin her projede mutlaka ve mutlaka performans problemleri yaşanır. Uygulama sunucusu göçer, JVM takılır kalır, threadler bloke olur vs. Yaşanan bu tür problemler her programcının ilgi alanına girmediği için bu tür işlere bulaşmadan kendi işlerine devam ederler. Yeni programcı bunu fırsat bilip balıklama bu tür görevlerin üstüne atlamalıdır. Herkesin başını ağrıtan bu tür problemlerden birisini çözdüğü andan itibaren kendisini ispatlamış sayılır ve yeni ekibi kendisini sevgi, hürmet ve selamla kuçaklar. Buradan da anlaşıldığı gibi en büyük erdemlerden birisi cesarettir; cesaret edip görev üstlenmektir.

Hadi diyelim yeni programcı üstlenebileceği enteresan bir görev bulamadı ya da kendisine bir görev tayin edildi. Bu durumda işini en iyi şekilde tamamlayıp, elde ettiği neticeleri tüm ekibe duyurmanın yollarını bulmalıdır. Her ekibin kullandığı e-posta listeleri vardır. Bir e-posta iletisi ile tüm ekibe, hatta proje ve takım yöneticilerine erişmek mümkündür. Yeni programcı kod yazarken nasıl farklılık yaratarak, takım arkadaşlarının dikkatini çekebileceği hakkında düşünmelidir. Örneğin kendisine verilen görevi test güdümlü kodlayıp, elde ettiği yüksek seviyedeki testlerin kod kapsama alanı metriğini e-posta listesi üzerinden duyurabilir. Otomatik çalışan unit testleri, %90 üzerindeki code coverage (kod kapsama alanı), SOLID uyumlu ve kolay okunan sınıflar ekip arkadaşlarını etkileyecektir. Birçok projede programcılar unit testleri yazmadığı için, yeni programcının oluşturduğu ve otomatik çalışan testler dikkat çekmeyi kolaylaştıracaktır. Yerlerde sürünen kod kapsama alanı, yeni programcının oluşturduğu unit testleri ile birden bire tavana fırladığında, bakın bakalım kim anında yıldız programcı oluveriyor. Yeni programcının yazılımın nasıl olması gerektiği yönündeki dolaylı boy göstermeleri, onun kısa sürede ekibin sosyal ağına dahil olmasını kolaylaştıracaktır

Eger proje bünyesinde Jenkins, Sonar gibi araçlar kullanılmıyorsa, yeni programcının söz alıp, bu araçların kullanımının proje için ne kadar faydalı olduğunu dile getirmesinde fayda vardır. Örneğin yeni programcı Sonar kurulduktan sonra tüm kodun statik analizini yapıp, sonuçları daha önce bahsettiğim e-posta listesi üzerinden tüm ekip çalışanlarına duyurabilir. Kendisi bu gibi araçları kurmaya ve işletmeye talip olmalıdır. Bu onu bir vuruşta belli bir alanda söz sahibi yapar. Yeni araçları kullanmak isteyecek olan ekip çalışanları yeni programcıya danışmak isteyecekler ve bu şekilde yeni programcının ekibe entegre edilme sürecini kolaylaştıracaklardır. Yeni programcının, yazılım sürecini olumlu etkileyecek yeni fikirlerle gelmesi, kendisini ispatlama sürecini kısaltacaktır.

Yeni programcı ekip toplantılarında mutlaka kendi fikrini beyan etmelidir. Yanlışta olsa bir fikir beyan etmek, hiç fikir beyan etmemekten daha iyidir (tamamen saçmalamamak şartıyla). Eğer susup, konuşulanları dinlerse, ekip arkadaşları onu dikkate almamayı sürdüreceklerdir. Bir fikir sahibi olmayan ya da bunu beyan etmeyi bilmeyen bir insanın toplum içinde yer bulması zordur. Ekip içindeki programcılar karşılaştıkları problemleri e-posta aracılığı ile çalışma arkadaşlarına duyururlar. Bu gibi e-postalara herkesin okuyacağı şekilde cevap vermek, çözüm önerilerinde bulunmak, zaman içinde yeni programcının profilini biler.

Kendini ispatlamanın bir diğer yolu takım arkadaşları ile kod inceleme (code review) seansları düzenlemektir. Çoğu ekip bu tür bir alışkanlığa sahip değildir. Beraber kod inceleme seansları karşı tarafı eleştirme olarak algılanır ve bu yüzden bu aktiviteden kaçınılır. Yeni programcı bunu fırsat bilip, kendi kodunun ekip içinden başka bir programcı tarafından incelenmesini sağlamalıdır. Daha önce de bahsettiğim gibi kodun özenli yazılmış, her sınıfın sadece bir sorumluluğa sahip (SRP prensibi), diğer SOLID prensipleri ile uyumlu, otomatik çalışan unit testlerine sahip, değişken ve metot isimlerinin kodun ifade gücünü artıracak şekilde seçilmiş olması, kodu inceleyen programcıda hayranlık uyandıracaktır. Bunu kendisi için tutmaz ve mutlaka diğer ekip arkadaşları ile paylaşır. Bundan emin olabilirsiniz. Yeni programcı bu şekilde kendisi için bir taban oluşturduktan sonra, diğer programcılar tarafından kod inceleme seanslarına davet edilip, fikri alınan bir programcı olacaktır.

Her ekip içinde mutlaka en az bir tane, rahatsızlık veren, sivri, kendisinin yıldız programcı (star developer) olduğunu düşünen bir programcı vardır. Bu tip programcılarla çalışmak çok zordur. Yeni programcı da mutlaka bu yıldız programcının hışmına uğrayacaktır. Bu gibi durumlarda yeni programcı alttan almaya çalışmalı, ekip içinde soğuk bir atmosferin oluşmasını sağlayacak karşı karşıya gelmenin önüne geçmelidir. Eğer yeni programcı yıldız programcı ile karşı karşıya gelirse, diğer ekip çalışanları yıldızın yanında olmayı tercih edeceklerdir. Yeni programcı ne kadar haklı olursa olsun, ekip içinde bir nevi sürü içgüdüsü olduğundan, yıldız programcının tarafinda olacaklardir. Bu gibi durumlarda yıldız programcı ile aynı görev üzerinde beraber çalışma fırsatı kollanmalıdır. Yıldız ile iletişim içinde olmak onu yumuşatacaktır. Yeni programcı aynı zamanda yetkinliğini yıldıza gösterme firsatı bulursa, aradaki buzlar eriyip, diyalog normalleşecektir. Yeni programcı aynı zamanda firsatını yakaladığında yıldıza haddini bildirme cesareti göstermelidir. Örneğin sorduğu bir soruya alaylı bir cevap alıyorsa, takım liderinin de bulunduğu bir ortamda yıldıza neden böyle bir cevap verdiği sorulabilir. Yıldız kem, küm edip, afallayacaktır. Bu şekilde yeni programcı yıldızı hafiften ısırabilir ve yıldıza fazla üzerime gelme sinyali verebilir. Yeni programcı başını dik tutma cesareti gösterdiği andan itibaren, yıldızın davranış biçimi değişecektir. Kimse karşısında dik duramayan insana saygı göstermez. Yıldıza karşı dik durma yeni programcıya diger ekip arkadaşlarının saygısını getirir.

Ekibin dikkatini ve saygısını kazanmanın diğer bir yolu ekibe bilgi transferi (know-how tranfer) yapmaktır. Örneğin yeni programcı ekipden diğer bir programcıya “istersen üstlendiğin yeni görevi test güdümlü (Test Driven) ve eşli (pair programming) kodlayalım, bunun nasıl yapıldığını sana gösterebilirim” teklifini götürebilir. Böyle bir teklife, konuyla ilgili bilgisi olmayan programcı hayır diyemez. Teklifi alan programcı yeni birşeyler öğrenme hevesi ile yeni programcıya kendini ispatlama firsatını tanıyacaktır. Yeni edindiği bilgiler programcıda hayranlık uyandırır ve bunu mutlaka diğer ekip arkadaşları ile paylaşır.

Her programcının Xing ya da LinkedIn platformlarında mutlaka bir profili olmalıdır. Programcı bu profillerinde hakim olduğu konuları, daha önce çalıştığı projeleri, sahip olduğu ünvan ve sertifikaları ve kendi projelerini (örneğin açık kaynaklı bir yazılım) sergilemelidir. Bu tür profiller artık programcılar için kartvizit ya da vitrin görevini üstlenmektedir. Mülakata giden her programcı hakkında mutlaka internette araştırma yapılır. Bu tür profillerin keşfedilmesi, mülakatın gidişatını olumlu etkileyebilir. Bu tür profillerin önemli başka bir fonksiyonu daha mevcuttur. Yeni programcı ekip içinde yazılmamış, boş bir defter sayfasıdır. Ekip üyelerinin yeni programcı hakkında geniş çaplı fikirleri yoktur. Bunu değiştirmenin en kolay yolu, ekip üyelerinin internet profillerini araştırmak ve onlara bahsettiğim platformlar üzerinden arkadaşlık teklifi göndermektir. Arkadaşlık teklifi alan diğer programcılar, yeni programcının profilini inceleme ve onun hakkında fikir edinme fırsatı bulacaklardır. Hele hele yeni programcı ender sertifikalardan birine sahipse, bu yemek aralarındaki sohbetlere malzeme olacak ve bu şekilde yeni programcının ekibe entegrasyonunu kolaylaşacaktır.

Ekip elemanları ile smalltalk, onlara çalışma esnasında tatlı birşeyler ikram etmek ve ekip liderine düzenli olarak rapor vermek sayabileceğim diğer yöntemler arasındadır. Olumlu dikkat çekmek her zaman önemlidir. Yetkin ve tecrübeli bir programcı farkında olmadan yukarda saydığım konularda çalışma yapacaktır. Verimli olmanın en önemli şartı, en kısa sürede ekibe entegre olmaktır. Bunu başarmak programcının elindedir.

EOF (End Of Fun)
Özcan Acar

Eğer programcıya o imkanı sağladıysanız ve kitap okuma alışkanlığı varsa bol bol kitap okuyacaktır. Kitap okumaktan canı sıkıldığında kod yazacaktır. Kod yazmaktan canı sıkıldığında tekrar kitap okuyacaktır. Belki de hiçbir şey yapmayacaktır. Adada olduğunu hatırlayıp yüzmeye gidecektir. Gününü gün etmeye çalışacaktır. Bu durum programcıdan programcıya değişecektir. Bu şartlar altında programcının kendisini geliştirebileceğini pek düşünmüyorum. Gelişim için insanlar arası interaksiyon ve iletişim gereklidir. Çoğu zaman başka insanların davranış biçimlerini kopyalayarak gelişim sağlamak bile mümkündür. Sıfır-altı yaş gurubu çocuklarda bunu görmek mümkün; zamanlarının büyük bir kısmını ebeveynlerinin davranışlarını incelemek ve kopyalamakla geçer. Kendi kızımdan bir örnek vereyim. Şimdi iki yaşında. Evin içinde saklanbaç oynuyoruz. O saklandıktan sonra “baba ben oturma odasında, perdenin arasındayım” gibi anonslar yapıyor. Gidip, elimle koymuş gibi buluyorum. Kısa bir zaman önce oyunu tersine çevirip, ben saklanmaya başladım ve kızımın beni bulmasını istedim. Ben doğal olarak saklandığım yeri anons etmiyorum. Bu şartlarda kızımın evin içinde beni bulması zorlaşıyor. Ufaklık olayı çakmış, şimdilerde saklandığında “kızım nerdesin” diye sormama rağmen, gıkı çıkmıyor. Benden öğrendi ve olayı çaktı. Şimdi bu yazıyı yazarken mouse-pad’imi kaçırdı. Bir saniye gidip, alıp, geleyim…. {5 dakika sonra} -Mouse-pad kayıp, bulamıyorum. Nerede kızım diye soruyorum; oturma odasındaki masada, git ara diyor…

Gerçek hayatta da bazı programcılar bir adada yaşıyor gibi kod yazarlar. Diğer programcılarla bilgi alışverişinde bulunmadan ve kodu paylaşmak zorunda kalmadan işlerini görürler. Projeyi zamanında yetiştirme telaşı bu tip programcıların işine gelir. Hatta kodu sahiplenirler. Kimse ne yazdığımı anlamasın diye komplike kod yazan programcılar gördüm. Bunun maksadı Job Protection yapmaktır, yani çalıştığı iş yerini korumak ve başkalarına kaptırmamaktır. Ama bu yazımın konusu bu değil. Bu yazımda programcının kendisini geliştirmesi için neden diğer programcılarla interaksiyona girmesi gerekği konusunu incelemek istiyorum. Adada yaşayan programcılar için söylüyorum: kendi kendilerine kendilerini geliştirmeleri biraz zor gibi görünüyor.

Gelişim için insanlar arası interaksiyonun gerekliliğinden bahsettim. Bu özellikle programcılar için geçerli olan bir durumdur. İnsanlar adeta bir araya gelip beraberce çözüm üretmek için yaratılmıştır. Programcılar da kendi aralarındaki iletişimi ve beraber çalışmayı güçlendirerek, birbirlerinden çok şeyler ögrenebilirler. Eğer konumuz programcıların gelişimi ise o zaman bunun sağlandığı en önemli yerlerden birisi programcılar arası interaksiyondur. Bunun örneklerini eşli programlama (pair programming), beraber kod inceleme (code review) ve beraber pratik yapma (code retreat) aktiviteleri teşkil eder. Bu aktiviteleri ve programcıya kattığı artı değeri yakından inceleyelim.

Eşli Programlama (Pair Programming)

Eşli programlama Extreme Programming (XP) çevik süreci ile popüer olmuş bir programlama aktivitesidir. İki programcı bir araya gelerek, bir müşteri gereksinimini test güdümlü kodlarlar. Eşli programlama oturumunda programcılar sıkça klayveyi kendi aralarında değişirler. Bu hem fikir alışverişini, hem programcıların birbirlerinden öğrenmelerini, hem de ekipte her programcının proje hakkında aynı bilgiye sahip olmasını teşvik eder. Eşli programlama oturumlarda benim en büyük kazancım, partnerimden onun kullandığı yazılım tekniklerini öğrenerek kendi günlük işlerimde adapte etmem olmuştur. Bu şekilde çok şey öğrendigimi itiraf etmem lazım. Bu yüzden eşli programlama çok severek dahil olduğum bir aktivitedir. Eşli programlama yapan programcılar birbirlerinden farkında olmadan çok şey öğrenmektedirler. Bu programcının şimdiye kadar tanımadığı bir kısa yol tuşundan, değişik tasarım prenbiplerinin nasıl uygulandığına kadar geniş bir yelpazeyi kapsamaktadır.

Eşli programlama pratiği ekibe yeni katılmış ya da tecrübesiz programcıların hızlıca bilgilendirilip, takıma entegre edilme süreçlerini kısaltacaktır. Bu amaca doğru yola çıkılmak istendiğinde tecrübeli bir programcı ile tecrübesiz bir programcı bir araya getirilip, eşli programlama oturumunda bilginin serbestçe akışı sağlanabilir. Eşli programlama sadece bu durumda kullanılır diye bir kural yoktur. Mümkün mertebe her fırsatta uygulanması gereken bir aktivitedir. Eşli programlama metodu, iki programcının aynı işi yaptığı düşünüldüğü için zaman kaybı olarak algılanabilir. İlk etapta bu böyle olsa bile, bu yönde yapılmış olan yatırım projenin başarısına katkıda bulunacaktır. Eşli programlama oturumlarında iki çift göz kodu geliştirdiği için hata oranı daha düşük olacaktır. Bilgi ekip içinde eşit olarak dağıldığından, bir programcının projeden ayrılması proje gidişatını olumsuz yönde etkilemeyecektir.

Kod İnceleme (Code Review)

Eşli programlama oturumunda olduğu gibi birden fazla programcı bir araya gelerek bir kod parçasını beraberce incelerler (code review). Genelde bir müşteri gereksinimini kodlamış olan bir programcı çalışmasını tamamladığında, diğer bir çalışma arkadaşını beraberce kod incelemek üzere kendi çalışma masasına davet eder. Dört göz iki gözden daha fazla görür prensibinden yola çıkarak iki programcı kod parçasını beraberce incelerler.

Geçenlerde yaptığımız bir toplantıda beraber kod inceleme konusunda konuşurken, bir çalışma arkadaşım bu tür aktivitelerden hoşlanmadığını, çünkü parmağıyla bir kod satırını gösterip, burası olmamış demenin, kodu yazan tarafından yanlış algılanabileceğini söyledi. Doğru, bu çogu zaman olan birşey, ama birbirimizden birşeyler ögrenmek istiyorsak, o zaman egomuzu artık bir kenara koymamız gerekiyor. Herşeyi bilmemiz, doğru çalışan kod yazmamız her zaman mümkün değil. Bunu böyle kabul etmemiz gerekiyor. Bir çalışma arkadaşımızın kod inceleme oturumunda yanlışlarımızı yüzümüze vurmasını hakaret olarak değil, bir şans olarak algılamalıyız. Bu gibi durumlarda kendisine hakaret edildiğini düşünen programcı adada yaşayan bir programcıdır. Kendimizi geliştirmek istiyorsak kritiğe açık olmamız gerekiyor.

Beraber Pratik Yapma (Code Retreat)

Code retreat Corey Haines tarafından başlatılmış, bir tam gün boyunca 15-25 arası programcının bir araya gelerek, beraber kod yazdıkları bir aktivitedir. Böyle bir çalışmaya katılmış olan Ryan Weald bir günde ögrendiklerinin okulda bir sene öğrendiklerinden daha fazla olduğunu söylemekte. Bu tür aktivitelerin programcılar için ne kadar önemli olduğu ortadadır.

Diğer programcılarla interaksiyona girmeyen bir programcı, kendisini daha hızlı geliştirmek için sağlanan avantajlardan mahrum kalacaktır. Buradan çıkardığımız sonuç şudur: Job protection yapanlar aslında bindikleri dalı keseler. Oysaki bilgi paylaşımına açık olan programcılar diğer programcılarla olan ilişkilerinde devamlı yeni birşeyler öğrenerek, kendi piyasa değerlerine değer katarlar.

Adada yaşayan programcılara allah kolaylik versin. İşleri kolay değil.

EOF (End Of Fun)
Özcan Acar