Pair Programming’in Faydaları Nelerdir? Eşli Programlama’nın Faydaları Nelerdir?

Eşli Programlama aşağıdaki faydaları sağlar. Ne yazık ki Scrum gibi Eşli Programlama’nın faydaları da Eşli Programlama yapmaya başladıktan sonra anlaşılır. Yapmadığınız sürece bu faydaları zihninizde canlandıramazsınız. Bu nedenle faydalar gerçek değilmiş gibi görünebilir. İşin kötü tarafı faydası olmayacağını düşünmektir ve bu düşünceyi destekleyen -iki kişinin aynı servis üzerinde çalışması zaman kaybı ve çöptür- düşüncesinin çok daha somut görünmesidir.

• Disiplini artırır. Eş olan partnerler genellikle “doğru şeyi yap” yaklaşımındadır. Bunu yaşadığım bir örnekle anlatmaya çalışacağım. Partnerler birbirlerinin dikkat dağınıklıklarını önleme eğiliminde olurlarsa Eşli Programlama’nın faydalarından yararlanabilirler. Birkaç hafta önce Takım arkadaşımla Günlük Scrum-Daily Scrum- sonrası oturduk ve yukarıda bahsettiğim servisleri yazmaya devam ettik. Sabah Sürücü koltuğuna oturan arkadaşımdı ve nedenini bilmediğim şeylerden ötürü dikkatinin çok kolay dağıldığının ve normalde yapmayacağı hataları yaptığının farkındaydım. Burada Gözlemci’nin yaklaşımının çok önemli olduğunu biliyordum. İlk önce daha fazla hata yapmasını engellemek için yaptığı birkaç hatayı gösterdim. Aklının çok çabuk dağıldığını oda söyledi. O zaman isterse onu yalnız bırakabileceğimi ya da kısa bir ara verip yazmaya devam edebileceğimizi söyledim. Biraz sohbet ederek o an yaptığımız işten uzaklaştık, bu süre en fazla 10-15 dakikaydı. Biraz gülüp, eğlendikten sonra tazelenmiş kafayla oturduk ve konstrasyonumuz bozulmadan yazmaya devam ettik.

• Kod kalitesini artırır. Eşli Programlama’yla kod yazılırken iki geliştiricinin tecrübelerinden yararlanılır. Farklı bakış açıları, problem çözme şeklindeki farklılıklar ve farklı tecrübelerin birleştiği bu etkinlikte yazılan kod dolayısıyla bir geliştiricinin yazdığı koddan daha kaliteli olur. Bu kadar farklılıktan elbet çatışmalarda doğar işin kaliteli olmasını sağlayan da bu çatışmalar ve bu çatışmaların çözümüdür. Eşli Programlama’nın amacı hataları yapmadan önlemektir. Bir hatanın geliştirme sürecinde bulunmasıyla üretim ortamında bulunması arasındaki maliyet farkını aşağıdaki diyagram adım adım en güzel haliyle anlatıyor.

Diyagrama göre bir hata Eşli Programlama yapılırken bulunduğunda bunun değişim maliyeti çok düşüktür. Bu hata, bir diğer Çevik Pratik olan, Sürekli Entegrasyon aşamasında bulunduğunda maliyeti birazcık artar. Bir tasarım ya da programlama hatası TYG(Test Yönelimli Geliştirme, TDD) yapılırken bulunduğunda maliyet yine düşük miktarda artmaktadır. İhtiyaçlar belirlenirken bir problem oluştuysa eğer proje paydaşları aktif katılım gösteriyor ve ürünü denetliyorlarsa hata yine bulunabilir, tabi geliştirme ve test yapılmıştır dolayısıyla maliyet biraz daha artmıştır.

Sistem tamamıyla test edilirken hatanın düzeltilmesi için yapılması gereken değişikliğin maliyeti iyice artmıştır. Eğer hatanız kullanıcı kabul testinde ortaya çıkıyorsa zirveye oynuyorsunuz demektir. Eğer hata üretim ortamında bulunduysa zirvedesiniz demektir. Hatanın düzeltilmesi için şirketiniz en yüksek maliyeti bu aşamada ödeyecektir. Ayrıca son kullanıcının güvenini biraz sarstınız, bunu unutmayın.

• Akış* daha kolay yakalanır. Partnerler sürekli olarak iletişim halinde olmalı ve konuşmalıdırlar. Burada dikkat çekmek istediğim bir nokta var. Akışı* yakalamış bir Sürücü’yü eğer hata yapmıyorsa yada daha iyi bir fikri yoksa Gözlemci’nin bölmemesidir. Sürücü ve Gözlemci’nin nasıl iletişim kurulacağını iyi bilmesi gerekir. Akış, bir işi gerçekleştiren kişinin gerçekleştirdiği işe tam olarak konsantre olma durumudur. Bu bir zihin durumudur ve dışarıdan gelen dikkat dağıtıcılar tarafından kolaylıkla bozulabilir. Yazılım geliştirme gibi soyut işlerle uğraşanların Akışı yakalamaları zordur ve yakaladıklarında dikkatlerinin dağılmaması gerekir. Akışın yakalandığı durumlarda verimlilik en yüksek seviyededir. Dışarıdan bir dikkat dağıtıcı yada iş bölücü bir durum geldiğinde bu Sürücü’ye ulaşmadan Gözlemci’nin araya girmesi gerekir. Ayrıca akış sadece tek başına çalışıldığında yakalanan bir durum değildir. İşbirliği içinde olan kişilerin akışa girmesi daha kolaydır.

*Bir işi gerçekleştirirken sürekli konsantrasyon hali.

• Morali artırır. İyi yapılan Eşli Programlama tek başına kod yazmaktan daha zevklidir. Kötü yapılan Eşli Programlama ise tam bir baş belası olabilir ve partnerler içlerinden bitsede gitsek diye düşünebilir.

• Ortak kod sahipliği. Bir projede beraber çalışan herkes Eşli Programlama yaptığında ve partnerler sıkça değiştiğinde projede çalışan herkesin tüm kod hakkında bilgisi olur. Bilginin yayılaşması için çok iyi bir yoldur.

• Takım olma hissi. Eşli Programlama yapanlar birbirini daha iyi tanırlar. Eşli Programlama yapan takımlar takım olma yolunda daha hızlı yol alır.

• Daha az bölünme. İnsanların iki kişiyi beraber çalışırken gördüğünde onlara soru sorma ya da yaptıkları işi bölme isteği daha az olur.

Eş Olma Varyasyonları

Usta – Usta: Usta – Usta eş olma yüksek verimlilik için istenen ilk seçenek olabilir ve mükemmel sonuçlar üretilebilir. Bu eşleşmede görülen en büyük problem iki eşinde çok deneyimli olması ve problem çözerken yeni ve yaratıcı fikirleri düşünme zahmetine girmeyecek olmalarıdır.

Usta – Çırak : Usta – Çırak eşleştirmesiyse usta partnerin çırak partnere akıl hocalığı yapması için çok iyi bir şanstır. Bu eşleşmede yeni ve yaratıcı fikirler çırak partner tarafından keşfedilebilir. Bu durumda usta partner bu yeni ve yaratıcı fikirlere karşılık var olan yaklaşımları çırağa aktarır. Bu, usta partnerin aynı zamanda var olan yaklaşımları sorgulamasını da sağlar. Bu eşleşmenin kötü yanıysa çırak partner çok çekinikse ustayı izle fenomenini yaşayabilir.

Çırak – Çırak: Bu eşleştirme güzel sonuçlar verebilir fakat diğer eşleştirmeler kadar faydalı olma olasılığı düşüktür. Bu nedenle önerilmez.

Uzaktan Eşli Programlama

*Uzaktan Eşli Programlama, Sanal Eşli Programlama ya da Dağıtık Eşli Programlama ifadeleri iki yazılım geliştiricinin farklı lokasyonlarda bulunmasını fakat aynı iş üzerinde eş zamanlı olarak çalışmasını anlatır. Partnerler kod geliştirirken gerçek zamanlı editorler, masaüstü ekran paylaşımı ya da uzaktan eşli programlama IDE eklentilerinden yararlanır. Yüzyüze olmamak bilginin paylaşılmasında ve iletişimde problemlere neden olabilir.

Ping – Pong Eşli Programlama

Ping – Pong Eşli Programlama klasik Eşli Programlama’dan biraz farklı bir yaklaşım olarak ortaya çıkmıştır. Genellikle eXtreme Programming takımlarının kullandığı bu yaklaşım A ve B kişilerinden oluşan çiftlerde aşağıdaki gibi gerçekleştirilmektedir.

• A, bir test yazar ve testin başarısız olduğunu görür.
• B Sürücü koltuğuna oturur ve testi geçecek en küçük kod parçacığını yazar.
• B yeni bir test yazar ve testin geçmediğini görür.
• A Sürücü koltuğuna oturur ve testi geçecek en küçük kod parçacığını yazar.
• A yeni bir test yazar ve testin geçmediğini görür.

Bu şekilde kod yazılmaya devam edilir. Refactor işlemi gerektiğinde sürücü koltuğunda kim oturuyorsa refactor işlemini gerçekleştirir.

Kodun bu şekilde geliştirilmesindeki amaç her iki yazılım geliştiricinin odağını kaybetmemesi, sürekli uyanık kalmasını sağlamaktır.

Bu yazı bir serinin devamıdır. Yazının tamamına erişmek için lütfen tıklayınız.