Etiket arşivi: kata

Uzaktan Eşli Programlama

Eşli programlama yapmak için illa iki programcının aynı mekanda olması gerekmiyor. Eclipse kullanıyorsanız Saros pluginini kurarak, uzak bir bilgisayardaki bir şahıs ile eşli programlama yapabilirsiniz.

Uzaktan eşli programlama için neler gerekli?

Eclipse >> Help >> Install new Software menüsünden http://dpp.sourceforge.net/update Saros update sayfasını kullanarak gerekli plugini kurabilirsiniz.

Kurulumun nasıl yapıldığı Saros kurulum sayfasında yer almaktadır.

Kurulum işlemi tamamlandıktan ve Eclipse kapatılıp, yeniden açıldıktan sonra yukarıda yer alan login paneli görünecektir. İki programcının beraber aynı proje üzerinde çalışabilmeleri için aynı sunucuya bağlantı kurmuş olmaları gerekmektedir. Saros sunucu olarak bir Jabber sunucusu kullanıyor. Yeni bir hesap oluşturduktan sonra sunucuya bağlanabilirsiniz.

Eşli programlama yapmak istediğiniz şahsın Saros hesabını edinmeniz ve aşağıda yer aldığı gibi Saros paneli üzerinden Buddy listenize eklemeniz gerekiyor.

Buddy ekleme işlemi tamamlandıktan sonra eğer Buddyniz online ise, herhangi bir Eclipse projesini karşı taraf ile paylaşıp, eşli programlamaya başlayabilirsiniz. Proje üzerinde yaptığınız her değişiklik anında karşı tarafa yansıyacaktır.

Ben bu altyapıyı genelde uzakta bir bilgisayar kullanan bir programcı ile beraber kata yapmak için kullanıyorum. Kata seansında iletişimi kolaylaştırmak için Skype kullanılabilir.

Benimle kata yapmak isterseniz koordinatlarım şöyle:

Saros hesabım: ozcanacar@saros-con.imp.fu-berlin.de
Skype hesabım: oezcanacar

Bana bir e-posta gönderin ve hangi katayı benimle birlikte eşli programlama yöntemi ile yapmak istediğinizi bildirin. Birlikte bir zaman dilimi bulmaya ve katayı yapmaya çalışalım.

EOF (End Of Fun)
Özcan Acar

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

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 →

Kod Kata ve Pratik Yapmanın Önemi

Bizim ailede müzisyen geni var, babamdan bana geçmiş olsa gerek. Babam çok iyi bir ses sanatçısıdır. Keşke benim de onun kadar güzel sesim olsa diye düşünmüşümdür her zaman. Ama ne yazık ki yaratıcının benimle olan planları başka türdenmiş. İyi bir dinleyici olduğumu düşünüyorum. TSM parçalarını seslendirmeye çalıştığımda babam, detone olmadığımı söyler. Ama sesimin ne kadar kötü olduğunu ben bilirim. Keşke babam gibi güzel bir sesim olsaydı. Ufakken hatırlıyorum: TV yok; internet yok; radyo var; arkası yarın ve TSM var. TRT radyo yayınlarını dinleyerek büyüdüm; ne güzel günlerdi…

Bendeki müzisyen genini aktif hale getirmek için 2002 senesinde bir elektro gitar aldım. Aradan tam on sene geçmiş ve ben hala gitar çalamıyorum. Bir müzik aletini çalmaya çalışmak büyük fedakarlık istiyor. Eğer motivasyon yoksa o zaman başarı sağlamak hemen hemen imkansız. Motivasyonun yanısıra düzenli olarak pratik yapmak gerekiyor. Ben bunları ne yazik ki beceremedim ve gitar çalmak benim için her zaman bir hayal olarak kalacak. Şimdi bunun programcılıkla ne alakası var diyeceksiniz. Anlatmaya çalışayım.

Müzisyenler performans ve pratik yapma arasında ayrım yaparlar. Biz programcılar yapmayız! Müzisyenler için sahnede olmak performans yapmaktır. Programcılar için de iş yerine giderek kod yazmak performanstır. Müzisyenler düzenli olarak sahne harici pratik yaparlar. Biz programcılar yapmayız. İş yerinde yazdığımız kodları pratik yapmak olarak algılarız. Çok iyi müzisyenler pratik yapmaya çok önem verirler ve daima saatler boyu bu konuda çalışırlar. Bu yüzden sahnede çok muazzam bir performans ortaya koyarlar, çünkü yaptıkları pratikler onların sular seller gibi müzik yapmalarını sağlar. Biz programcılar pratik eksikliğinden dolayı zaman zaman kod yazmakta zorlanırız. Sular seller gibi program yazamayız, çünkü pratik yapma özürlüyüzdür. Pratik yapmanın ne olduğunu tam olarak bilmeyiz ve performansla pratiği birbirine karıştırırız. Bu yüzden ustalaşma sürecimiz zora girer. Orta halli idare edip gideriz. İçinde çalıştığımız projeler bizi sanki orta halde tutmak için ağız birliği yapmış gibidir. Proje yöneticilerinin ya da iş verenlerin, programcıların orta halden ustalığa geçmesi için çaba sarfettikleri enderdir. Doğruyu söylemek gerekirse biz onlar için kağıt üzerinden sağa sola kaydırdıkları kaynaklardan başka birşey değillizdir. Belki de çok iyi olmamızı bile istemezler, çünkü daha fazla maaş isteme ya da daha iyi bir iş bulma fikri aklımıza gelebilir. Bu yüzden ustalaşma sürecinde onlardan medet ummak doğru değildir. Kendi başımızın çaresine bakmamız gerekir.

Nasıl pratik yapmayan bir müzisyenin sonu sahnede performans yaparken vahim olacaksa, pratik yapmayan programcının da sonu bundan farklı olmayacaktır. Pratik yapmayan programcı bir şeyleri çok kısa bir zaman diliminde bitirmek zorunda kalıp, strese girdiğinde yıllardan beri farkında olmadan geliştirdiği ve öyle pekte verimli olmayan yöntem ve mekanizmaları kullanmaya başlayacaktır (bu konuya daha sonra detaylı olarak değineceğim). Bunun önüne geçmek için programcının iş haricinde pratik yapması gerekmektedir.

Karate yapanlar katanın ne olduğunu bilirler. Kata bir karate ögrencisinin tekrar tekrar uyguladığı belli beden hareketlerinden oluşan şemadır. Sahip olduğu kuşağa göre karate ögrencisinin yaptığı katalar değişir. Karate ögrencisi katalarını yaparak karate yapma yeteneğini pekiştirir. Tekrar tekrar aynı kataları yapar, bıkmadan, sıkılmadan, usanmadan. Zamanı geldiğinde, örneğin kuşak imtihanlarında katalarını sular seller gibi sergiler ve bir üst kuşağa geçer. İmtihan olma ve katalarını ustalarına gösterme bir karate ögrencisi için performantır. Başarı sağlayabilmek için imtihan gününe kadar daima kataları üzerinde çalışır, yani pratik yapar. Katalarını yapmayan bir karate ögrencisinin imtihan günündeki hali malumur. Ama burada kata yapmanın ana amacı imtihanan geçmek ve bir üst kuşağı kazanmak değildir. Maksat usta bir karateci olmaktır. Bunun yolu da katadan geçer yani pratik yapmaktan.

Kata, programcıların kullanabileceği bir metafordur. Programcının uyguladığı kod katasıdır. Performans harici zamanlarımızda her gün on beş dakika, yarım saat ya da bir saat kod kata pratiği yapabiliriz. Örneğin benim sık yaptığım katalardan birisi roma rakamları kod katasıdır. Her gün ya da gün aşırı bu ve buna benzer kod kataları yaparım. Burada amaç çalışır bir program geliştirmek değildir. Çok basit bir kod katası bile işinizi görecektir, örneğin FizBuz kod katası.

Uyguladığımız kod kataları yaptığımız bazı işlemlerin, kod yazarken verdiğimiz tasarım kararlarının otomatikleşmesini sağlar. Örneğin ben yazılım geliştirme aracı olarak Eclipse kullanıyorum. Yaptığım kod kataları Eclipse bünyesinde bulunan ve fare kullanmandan yazılım yapmayı sağlayan kısa yol tuşlarını – shortcut key (örneğin STRG+SHIFT+F otomatik kod formatlaması için kullanılır) aklımda pekiştirmemi sağladı. Artık kod yazarken hiç düşünmeden neredeyse otomatikleşmiş bir seviyede kısa yol tuşlarını kullanıyorum ve çok daha hızlı programlayabiliyorum. Öğrenmem gereken daha çok kısa yol tuş kombinasyonu var, ama nasıl verimli bir şekilde öğrenebileceğimi biliyorum. Kod katası yapmadan önce birçok kısa yol tuşunu performansım (iş yerinde kod yazma) esnasında kullanmışımdır. Bazen internetten araştırma yapmışım ve yeni tuş kombinasyonları öğrenmişimdir. Lakin birkaç temel kısa yol tuş kombinasyonu harici bunları devamlı aklımda tutmam mümkün olmamıştır. Çok egzotik tuş kombinasyonları var. Bunları akılda tutmak için her gün kod pratiği yapmam gerekiyor. Kataları yaparken tekrar tekrar aynı kıya yol tuşlarını kullandığım için bunları akılda tutmam ve ezberlemem kolaylaşıyor. Ezberimde olan kısa yol tuşlarını da performansım esnasında kullanmam da çok kolay oluyor.

Kısa yol tuşlarına hakimiyet verebileceğim en basit örneklerden sadece bir tanesi. Kod kataları yaparak bir programcı yazılım esnasında gerek duyduğu yetenekleri geliştirebilir. Örneğin test güdümlü kod kataları yapmaya alışmış bir programcı, iş yerinde kod yazarken ister istemez bir test sınıfı oluşturarak işe başlayacaktır, çünkü bunu yapmaya alışmıştır. Test yazsam mı yazmasam mı diye kara kara düşünmez ve hemen test kodunu oluşturmaya başlar. Kafasındaki çalışma kalıbı artık bu şekildedir (doğru olan çalışma tarzı zaten budur). Test sınıfı ve metotları parmaklarından adeta akar gider. Bu durumu gitar çalan bir müzisyenle kıyaslayalım. Gitarist çalmak istediği parçayı devamlı çalıştığı için performansı esnasında beyninde oluşan kalıplar devreye girer ve müzisyen farkında bile olmadan parmakları perdeler üzerinde gider gelir. O esnada gitarist hangi parmakları ile hangi perdeye gidip hangi notayı basması gerektiğini düşünmez bile. Eğer düşünürse o zaman pratik eksikliği var demektir ve çaldığı parça bu durumun göstergesi olacaktır. Yeniden yapılandırma (refactoring) kataları yapan bir programcı bir switch komutunu ya da bir for düngüsünü nasıl yok edeceğini ya da yeniden yapılandıracağını bilir. Bu konuda tecrübesiz bir programcı genelde switch komutunun kullanılmasını bir sorun olarak bile algılamayabilir. Bunu sorun olarak algılasa bile bir switch komutunu nesneye yönelik programlama teknikleri kullanarak ortadan kaldırmada zorlanabilir. Buna karşın bu konuda pratik yapmış bir programcı hiç gözünün yaşına bakmadan switch komutunu dakikalar içinde yok edecek ve kodu bakımı ve geliştirilmesi daha kolay bir hale getirecektir. Pratik yapmış programcı için başka bir alternatif yoktur; switch komutunu görür görmez beyni ne yapması gerektiğini bilir; programcı hemen harekete geçer.

Buradan yola çıkarak yıllar içinde farkında olmadan geliştirdiğimiz bazı yöntem ve kalıpların neden verimsiz program yazmamıza sebep olduklarına değinmek istiyorum. Hiç zaman yetersizliğinden dolayı çok hızlı bir şekilde program yazmak zorunda kaldınız mı? Böyle bir durumda nasıl kod yazıyorsunuz? Kullandığınız yöntem ve kalıplar nelerdir? Burada tasarım kalıplarından (design pattern) bahsetmiyorum. Değinmek istediğim daha çok beyninizde hangi mekanizmaların çalıştığı ve ellerindenizden hangi kod satırlarının nasıl döküldüğü. Ben kendimdem örnek vereyim. Kata, refactoring ve diğer yazılım tekniklerine kullanmadan önce oluşturduğum sınıflar ve metotlar binlerce ya da yüzlerce satırdan oluşmakta idi. Özellikle sürüm zamanı yaklaşmaya başlayınca panik olur, saçma sapan, ama en azından çalışan kod yazardım. İki gün sonra yazdığım kodları okuduğumda bu kadar kötü mü yazılır kod diye hayretlere düşerdim. Test sınıfları oluşturmamam da cabasıydı. Programcı bu gibi durumlarda ister istemez yıllarca farkında olmadan geliştirdiği ve öyle pekte verimli olmayan yöntemlerine geri döner. Normal şartlar altında özenle seçilen sınıf, metot ve değişken isimleri, zor şartlar altında artık pek önemsenmez, çünkü stresten dolayı ve günü kurtarmamız gerektiği için otomatik olarak beynimizdeki verimli olmayan mekanizmalar devreye girer. Bu davranışı hayatı tehlikede olan bir canlı ile kıyaslayabiliriz. Canlı kendini tehlikede hissettiği anda iç güdüleri ile haraket edip, tehlikeden uzaklaşmaya çalışacaktır. İnsanlarda da durum farklı değildir. Kendimizi tehlikede hissettiğimiz zaman ya da hayatımızı kaybetme rizikosuyla karşılaştığımızda beynimiz adrenalin hormonunu salgılar. Panik oluruz, ama iç güdüsel davranarak tehlikeye karşı koymaya çalışırız. Bu esnada beynimizde çalışan programlara hükmetmemiz hemen hemen imkansızdır. Onlar otomatik olarak çalışır ve bizim teklikeye karşı koymamızı sağlarlar. Aynı şekilde stres altında olan programcı da iç güdüsel hareket edecek ve daha önce geliştirdiği ve kullandığı tehlikeden kurtulma rutinleri devreye girecektir. Programcı bir an önce çalışan bir kod oluşturmak istiyecek ve bunun için sahip olduğu tüm prensipleri ayaklar altına alacaktır. Böylece okunması çok güç yüzlerce, binlerce satırdan oluşan metotlar, sınıflar oluşacaktır. Bu programcının gücüne gitmez, çünkü kendisi de farkında olmadan böyle çalışmak zorunda kalmıştır. Oysaki programcı sık pratik yapmış olsa böyle yapıların oluşması mümkün değildir. Neden? Kod kataları programcının beynini bir nevi yeniden programlar. Kod kataları programcının beyninde yeni kalıpların ve mekanizmaların oluşmasını sağlar. Programcı strese girdiğinde bu yeni mekanizmalar devreye girer. Aynı gitar çalan usta bir gitaristin parmaklarını farkında olmadan perdeler üzerinde oynatması gibi programcı da edindiği yeni mekanizmaları otomatik olarak kullanmaya başlar. Katacı programcı metotların uzun olmasına izin vermez, metot, sınıf ve değişken isimlerini yine özenle seçer, beyni programcıyı devamlı bu yönde çalışmaya zorlar, çünkü programcının beyninde yaptığı katalar ile yeni bir repertuar oluşmuştur ve beyin bunları otomatik olarak kullanmaya başlar. Kullanılan eski yöntemler kaybolur ve programcı stres altında bile çok verimli olabilir. Beyinde bu repertuarı oluşturmak için kod katası yapmak gerekiyor. İş yerinde program yazarak bu repertuarı oluşturmak hemen hemen imkansız. Usta programcılar ağaçta yetişmiyor ya da gökten düşmüyor. Usta programcı olmak isteyen kişinin büyük fedakarlıklar yapması lazim. Bunun başlangıcı da kod kataları.

Özetle usta bir programcı olma yolunda kod katası yapmak çok büyük önem taşıyor. Bunun yanısıra kataların düzenli olarak yapılması gerekli, aksi taktirde beklenen neticeleri elde etmek zor olabilir. Ben kataları mecbur olduğum için yapmıyorum, işimi ve programcılığı sevdigim ve kod katası yapmayı zevkli bulduğum için yapıyorum. Bir hobi olarak değerlendirebilirsiniz. Kimse mecbur olduğu için karate kursuna gitmiyor, bu işten zevk aldığı ve karateyi öğrenmek istediği için gidiyor. Aynı şekilde bende daha iyi bir programcı olabilmek için kod katalarımı yapıyorum. Her yaptığım katayla yeni birşeyler öğreniyorum. Her kata seansında bir sorunu çözmek için daha kestirme yollar keşfedebiliyorum, başka tasarım kararları vererek başka çözümler üretebiliyorum. Bir zaman sonra artık bazı işlemleri yapmak otomatikleşiyor sanki. İş hayatımda, yani performans yaparken bunun faydasını görüyorum. Programcı olarak kendime olan güvenim artıyor.

Siz daha iyi bir programcı olmak için ne yapıyorsunuz? Kod katası yapmıyorsanız mutlaka denemelisiniz :)

Ustayı usta yapan pratikleridir.

Not: Yaptığım kataları KodKata.com‘da sizinle paylaşıyorum. Bir göz atmanızı tavsiye ederim.


EOF (End Of Fun)
Özcan Acar