Pair Programlamanın Götürdükleri

Bu makale yazım ve anlam hatalarının giderilmesi için güncellenmiştir.

Başlığa bakarak pair programlamayı sadece kötü taraflarından eleştireceğimi düşünmeyin. Ama o kısımlarından da bahsedeceğimden şüpheniz olmasın. Öncelikle pair programming ne olduğunu bilmeyenler için kısaca tanımını yapalım:

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator,[1] reviews each line of code as it is typed in. The two programmers switch roles frequently. (Wikipedia)

Tanıma bakınca gayet güzel duruyor. Aslında diğer herşey gibi doğru bir şekilde uygulandığı zaman çok faydalı olacak bir programlama yöntemi. Ama pair programlamanın arkasında yatan asıl motivasyon uzun ve kısa vadede daha kaliteli yazılımı daha kısa sürede bitirmektir. Eğer pair programlama yaparak bu sonucu alamıyorsanız, büyük bir ihtimal pair programlamayı doğru yapmıyorsunuz demektir.

Eleştirilerime geçmeden önce bir düşüncelerimi üzerine inşaa edeceğim bir temel atmak istiyorum. Pair programlama en verimli şekilde, yazılım mesleğinde uzman olanların öncülüğünde yapılabilir. Ufku, yazdığı programdan öteye geçemeyenlerin maalesef neyi neden yaptığına dair çok bir fikri olmayacak ve sadece kendisinden istenileni, istenildiği şekilde yapacaktır. Onun için uzmanların kesinlikle meseleye el atmaları gerekmektedir. Yeri gelmişken, uzman ifadesini ile neyi kasettiğimi basit bir örnek ile daha somutlaştırmaya çalışayım:

Eğer İnternet üzerinden bulduğunuz tarifler ile yemek yapan bir insansanız, siz büyük bir ihtimal sadece yemek yapmayı hobi olarak benimsemiş birisiniz demektir. Bir tarife ihtiyacınız vardır. Tarif ise size hangi malzemeden ne kadar koyacağınıza, kaç dakika karıştıracağınıza, ve nasıl pişireceğinize dair genel adımlar verir ve bunları anlaşılır bir dil ile basitçe anlatır. Ama o tariflerde aslında çok şey eksiktir. Eksik olması da gerekir. Aksi halde insanların tarifleri takip etmesi imkansızlaşmaya başlardı. İşte bu noktada sıradan bir yemek sevdalısı ile uzman bir aşcı arasında ki fark daha belirgin olmaya başlar. Uzman olmayanlar, yemek tarifinde de olduğu kendilerine yapılacak işi adım adım anlatacak bir rehberliğe ihtiyaç duyarlar. Böyle bir ihtiyaç temelde bir eksiklik ve kötü bir şey değildir. İnsanlar ilk başta bu şekilde öğrenir. Uzmanlığa giden yollar, hayatlarının ciddi bir bölümünü bu mesleğe adamış ve çok farklı tecrübeler kazanmış insanlar ile çalışmak ve onların bilgilerinden yararlamak ile örülüdür. Okuduğunuz kitaplar, dinlediğiniz konuşmalar, vs. bunun bir göstergesidir. Neyse… Yemekle hobi olarak uğraşan bir insandan farklı olarak, uzman bir aşcı ise, tarifin ötesine geçer ve kullandığı malzemenin kalitesinden, havada ki nemden, kullandığı fırının nasıl ısıttığından önemli çıkarımlar yapar ve aldığı tarifi ona göre yeniden düzenler. Hatta, tarif verenin nerede yaşadığını ve dolayısıyla kullandığı malzemenin kendi yaşadığı yerde yetişenlere göre nasıl farklılıklar gösterdiğini bile göz önünde bulunduracak ve kullandığı malzemeleri ve miktarları buna göre seçecektir. Bu şekilde davranmak işinde uzman olmaktır. Görülmeyen kısımları görmek ve onları da hesaba katarak en doğru çözümü getirmektir uzmanlık. Kendilerini izlediğiniz zaman, iş yapmalarından bir sanat eserini izliyormuşcasına zevk alıyorsanız, siz yaptığı işte uzman birisini izliyorsunuz demektir.

Yukarıda ki aşcıya benzer şekilde, meseleye sadece programlama değil, aynı zamanda içinde bulunduğu şirketin ihtiyaçları, takımın kalitesi, pair programming yapacağı kişinin durumu, vs. açılarından bakarak pair programming mantıklı mı değil mi sorusunun cevabını verecektir.

Çalıştığım şirketlerde farklı pair programlama politikaları vardı. Bazıları yapılmasını istemiyor, bazıları ise herkesin kesinlikle en az haftada belli bir saat pair programming yapmasını istiyordu. Hatta bazı şirketler, herkesi full-time pair olarak çalıştırıyordu. Bu aslında şirket hakkında şunu söylüyor: Bunlar takımlarını ve ihtiyaçlarını adam akıllı tanımaya önem vermiyorlar, dolayısıyla ne takım hakkında ne bu meslek hakkında ne de yazılıcımların genel karakterleri hakkında çok bilgi sahibi değiller. Bu tür yaklaşımlar, genelde mühendisler arasında sorunların ortaya çıkmasına neden oluyor. Çünkü bazı insanlar kendilerinin diğer mühendisler tarafından kullandığını düşünürken, başkaları ise gerekli yardımı almadığını ve dolayısıyla takımın kendisini yalnız bıraktığını düşünebiliyor. Pair programlamanın kısıtlanmaması ama devamlı teşvik edilmesi gereken birşey de olmaması lazım. Biraz bu meselenin mühendislerin özgürlüğüne bırakılması daha doğru olabilir. Tabi bu şekilde de sorunlar çıkabilir ama çözülmesi diğer durumlara göre çok daha kolay olacaktır.

Pair programlama en basit aşağıda ki şekillerde ile yardımcı olur:

1. Bilginin paylaşımı ve bunun programcıların en iyi anladığı yöntem olan kod yazmak ile yapmak. Bilgi paylaşımı, insanların benzer kısımları tek başlarına yapabilecekleri hale gelebilmeleri için önemli. İnsanlar neyin nasıl yapılması gerektiğini ve sistem içerisinde tutarlılığın sağlanması için nasıl kod yazmaları gerektiğini bu buluşmalarda görebilir ve takımlar uzun vadede bakımı daha kolay ve hatası daha az projeler çıkarabilirler.
2. Junior programcıların yetiştirilmesi ve daha bağımsız insanlar olmalarını sağlamak.
3. Senior programcıların üzerlerinde kafa yordukları bir sorunu beraber çözmeye çalışmak sayesinde 2 geliştirici haftası alacak işi belkide 1 geliştirici haftasına düşürmeye çalışmaları. Eğer bu yazılımcılar beraber çalışamıyor ve kendileri çalışınca daha hızlı olabiliyorlarsa, o zaman zorlamamak lazım. Zaten, pair programlama doğru bir politika ile yapılıyorsa, pair programlamaya ne zaman ihtiyaç var sorusunun cevabını insanlar kendi başlarına daha doğru vermeye başlayacaklar.

Buradan baktığınız da aslında iki temel şeyi geliştirmeye çalıştığını göreceksiniz, pair programlamanın: Improved developer velocity ve cost reduction, yani geliştiricilerin işlerinin hızlandırılması ve giderlerin azaltılması.

Yazılım mühendisliğinde kullandığımız yöntemlerin nedenlerinden bir tanesi, birden fazla programcının asekron bir şekilde çalışması içindir. Yanlış pair programlama politikalarının bu anlayışı baltamaları durumları olabilir. SOLID dediğimiz prensipler, programcılarının başkalarının kodlarını rahatlıkla anlaması ve üzerlerinde kolaylıkla çalışabilmeleri içindir. Eğer yazdığınız kodlar rahat anlaşılmıyorsa 3 sebepten dolayıdır:

1. Leş gibi kod yazıyorsunuzdur.
2. Sistemin essential complexity problemi yüksektir. Bunun için yapacak pek bir şey yok.
3. Maalesef kodu okuyan arkadaş yolun çok başındadır.

Leş gibi kod yazanlara, pair programlama önermek yerine önce döverek yardımcı olmaya çalışın. Şaka şaka… Sakın! Ama belki şirket politikası olarak anlaşmaya felan koysanız: “Kötü kod yazanları döveriz…” acaba hala illegal mı olur? İnsan kaynaklarından okuyanlar varsa, cevap verebilirler…

Projeniz, yazılım mühendisliğinin yıllarca çözmeye çalıştığı kod tekrarı, berbat sınıf ve değişken isimleri, okunması zor kodlar gibi sorunlar ile boğuşuyorsa, sizin çözümünüz pair programming değil, mühendislerinizi ya adam akıllı eğitmek ya da işe aldığınız insanları doğru seçmek işe başlamak olacaktır. Aksi halde pair programlama, kocaman bir sorunu yamamaya çalışmaktır.

Pair programlamanın zararlı olduğu zamanları görmek isterseniz, insanların projenizde ki benzer kısımların geliştirilmesi için tekrar tekrar pair programlama yapıp yapmadıklarına bakabilirsiniz. Diyelim ki Data Access Layer kısmına bazı repository sınıfları eklenecek. Bu hususta sizin takip ettiğiniz bir pattern olabilir. Bir programcı bu kısmı anlamadığını ve öğrenmek için sizinle pair programlama yapmak istedi. Kabul ettiniz. ProfileRepository sınıfını beraber yazdınız. Ama çok benzer olmasına rağmen, LoginRepository sınıfı için bir daha geldi. Tekrar yardım ettiniz. Ama AccountRepository için bir daha geldi, OrderRepository için, ProductRepository için, için, için… Bu pair programlamanın istismar edilmesidir ve yardım eden çoğu mühendisin istemeyeceği bir davranıştır şeklidir. Başkalarına yardım etmek başkadır, başkalarının işlerini yapmak başkadır. Böyle durumlar için yöneticilerin feedback almaya açık olmaları gerekmektedir. Pair programlama süper diye herşeye göz yuman bir yönetim, kendisinin kullanıldığını düşünen mühendislerini küstürecektir.

Pair programming ile dikkat edilmesi gereken diğer hususlar ise, bir mühendisin iş yapıp, diğerinin sessizce beklemesi ve sadece izlemesidir. Çoğu zaman izleyen adam ruhen çoktan başka yerlere gitmiş ve geçen sene yaptığı tatili düşünüyor ya da akşam nerede yemek yesem diye aklından geçiriyordur. Bu ise pair programlamayı o anda bitiren ve tamamiyle değersiz ve hatta zararlı kılmaya başlayan bir sorundur. Bu, sen yap ben yiyeyim demenin başka bir tarzıdır. Pair programming interaktif bir programlamadır ve herkesin aktif olarak katılması gerekmektedir. İzleyen kişi eğer öğrenme posizyonunda ise, o zaman notlar almalı, sorular sormalı ve gerçekten öğrenmeye çalışmalı ve bunu göstermelidir. Çünkü eğer bir problem pair programlamayı gerektiriyorsa, o zaman not alınması ve sorular ile daha iyi anlaşılması gerekecek kadar zor bir konudur. Yoksa iki kişinin de bildiği bir kısmı sırf eğlencesine pair olarak yapmak zaman israfı olabilir. Aynı zamanda, anlatan kişinin, öğrenme posizyonunda olan arkadaşına sabırlı olması gerekir. Sorularına anlaşılır cevaplar vermesi, hem kendisine yardımcı olması hemde arkadaşına yardımcı olması demektir. Nedenini size bırakayım.

Diğer bir durum ise, pair programlama yapacak insanların, başlamadan önce üzerinde çalışacakları kodları ve problemi biraz incelemeleri ve zihnen dolmuş olarak gelmeleri pair programlamayı etkili kılacak bir hazırlıktır. Eğer pair programlama için buluşduğu zaman: “Eveeet, şimdi ne yapıyoruz?…” diye başlanıyorsa ve yapılacak işten habersiz gelinmiş ise, o zaman pair programlama “Körler, sağırlar birbirini ağırlar.” moduna girmiştir.

Takım içinde pair programlama kültürünün olması ve bunun mantıklı olduğu zamanda yapılması gereken bir aktivite olduğunun kültür haline getirilmesi lazım. Pair programlama ihtiyaç olduğu zaman yapılması gereken, ve ihtiyacı belirleyen faktörlerin ise samimi olarak belirlenmesi ve başkalarına iş yıkmak şeklinde olmaması gerekmektedir. Takımın bu hususta hassas olması gerekmektedir.

Neyse, başka bir yazımda görüşmek üzere…