Üç gündür aynı hatadasın. Bulduğun cevapların hiçbiri tam senin durumuna uymuyor, izlediğin eğitim başka bir sürümü kullanıyor ve artık hatayı değil, yazılımın sana göre olup olmadığını sorguluyorsun. Sonra biri ekranına bakıp on dakikada sorunu buluyor: yanlış klasörde çalıştırdığın bir komut.
Bu sahne "yazılım tek başına mı öğrenilir, toplulukla mı?" sorusunun cevabını özetliyor gibi görünse de hikâyenin tamamı değil. Dürüst cevap şu: İkisi de gerekli, ama farklı şeyler için. Bu yazıda hangisinin neyi daha iyi öğrettiğini ve bir topluluğun somut olarak ne kazandırdığını anlatıyoruz.
Tek başına öğrenmenin güçlü yanları
Yalnız çalışmayı küçümseme. Bazı şeyler ancak tek başınayken öğrenilir:
- Derin odak: Özyineleme ya da veritabanı indeksleri gibi bir kavramı gerçekten anlamak sessiz ve kesintisiz zaman ister.
- Kendi temponda ilerlemek: Zor bir konuda yavaşlayabilir, bildiğin bir yeri hızlıca geçebilirsin.
- Boğuşmanın kendisi: Bir hatayla bir süre tek başına uğraşmak hata mesajı okumayı, dokümantasyonda gezinmeyi ve hipotez kurmayı öğretir. Her takıldığında hemen soran biri bu kası hiç geliştiremez.
Tek başına öğrenmenin kör noktaları
Sorun şu ki yalnız çalışmanın zayıflıkları içeriden görünmez:
- Ne bilmediğini bilmezsin. Kodun çalışıyor olabilir, ama başka birinin hemen göreceği bir güvenlik açığı ya da çok daha basit bir çözüm gözünden kaçabilir.
- Kodunun okunabilirliği hiç sınanmaz. Sadece senin okuduğun kod, sadece senin için anlaşılırdır.
- Eğitim döngüsü: Bir eğitimi bitirip hemen bir sonrakine başlamak, kendi projeni yapmamanın konforlu bir yoludur.
- Bitirmemek: Kimse beklemiyorsa proje sessizce yarım kalır.
- Ekip becerileri gelişmez. Git'te çakışma çözmek, review'a cevap vermek, başkasının koduna değişiklik önermek yalnız başına öğrenilemez.
Topluluğun somut faydaları
"Topluluk motivasyon verir" cümlesi doğru ama çok genel. Daha somut olalım.
Pair programming: birlikte kod yazmak
Pair programming'de iki kişi aynı kod üzerinde birlikte çalışır. En bilinen biçiminde biri klavyede yazar (driver), diğeri yazılanı takip eder, yön verir ve büyük resmi aklında tutar (navigator). Roller düzenli aralıklarla değişir. Test yazarak ilerleyenlerin sevdiği "ping-pong" biçiminde ise biri başarısız bir test yazar, diğeri o testi geçiren kodu yazar, sonra yer değiştirirler.
Öğrenen biri için faydası büyük. Başka birinin nasıl düşündüğünü, hatayı nasıl aradığını, hangi kısayolları kullandığını canlı olarak görürsün. Her adımı sesli anlatman gerektiği için dağılmak da zorlaşır.
Bir uyarı: Martin Fowler'ın sitesindeki pair programming yazısında da vurgulandığı gibi, eşli çalışmak yorucu olabilir. Kısa oturumlarla başla ve sık mola ver. Denemek için basit bir format: 45 dakika, her 15 dakikada bir rol değişimi ve başta tek bir küçük hedef, örneğin bir fonksiyon ve onun testi.
Code review: kodunun ikinci okuru
Kodunu başka biri okuduğunda iki şey olur. Gözden kaçırdığın hataları, isimlendirme sorunlarını ve daha basit çözümleri öğrenirsin. Ayrıca "bunu biri okuyacak" bilgisi, daha anlaşılır kod yazmanı sağlar.
Review vermek de en az almak kadar öğreticidir. Başkasının kodunu okurken "ben bunu nasıl yazardım?" diye düşünür, farklı yaklaşımlarla tanışırsın.
Küçük değişiklikleri review etmek çok daha kolaydır. Google'ın herkese açık mühendislik rehberi de daha hızlı ve daha dikkatli review için değişiklikleri küçük tutmayı önerir. Küçük pull request'lerle çalışmak bu yüzden öğrenirken de iyi bir alışkanlık.
Hesap verebilirlik: biri seni bekliyor
En sade ama belki en etkili fayda bu. "Bu hafta giriş ekranını bitireceğim" cümlesini sadece kendine söylediğinde esnetmek kolay. Bir ekip arkadaşına söylediğinde, hele onun işi seninkine bağlıysa, durum değişir.
Hesap verebilirliğin işe yarayan biçimleri:
- Haftanın başında ne yapacağını, sonunda ne yaptığını yazmak
- Tarihi belli demolar
- Bir parçayı uçtan uca sahiplenmek: başkası senin endpoint'ini ya da ekranını kullanacak
Soru sormayı ve cevaplamayı öğrenmek
Bir toplulukta zamanla iyi soru sormayı öğrenirsin: ne yapmaya çalıştığını, ne denediğini, tam hata mesajını ve sorunu tekrar üreten en küçük kod parçasını yazmak. Çoğu zaman soruyu böyle hazırlarken cevabı kendin bulursun.
Başkasının sorusunu cevaplamak ise bilgini sınar. Bir şeyi anlatamıyorsan, henüz tam anlamamışsındır.
Görünürlük ve referans
Birlikte proje yaptığın insanlar çalışmanı görür. İleride bir iş başvurusunda "bu kişiyle çalıştım, review'lara iyi cevap verirdi" diyebilecek biri, CV'deki bir satırdan çok daha güçlüdür.
Topluluğun da tuzakları var
Topluluk her derde deva değil:
- Konuşup kod yazmamak. Sohbet kanallarında saatler geçirip hiçbir şey üretmemek çok kolay.
- Kıyas kaygısı. İnsanlar genelde en iyi işlerini paylaşır. Başkasının vitrinini kendi mutfağınla kıyaslama.
- Pasif üyelik. Bir topluluğa katılmak kendiliğinden bir şey öğretmez. Değer, bir projede sorumluluk aldığında başlar.
İyi bir topluluk seçerken şunlara bak: Somut, devam eden projeler var mı? Kod gerçekten review ediliyor mu? Yeni başlayanların sorularına nasıl cevap veriliyor? Katılmak için ücret ya da açıkça yazılmamış bir şart var mı?
Dengeyi kurmak
İyi işleyen bir ritim genelde şöyle görünür:
- Haftanın büyük kısmında tek başına, odaklanarak çalış.
- Haftada en az bir kez kodunu birine review ettir ya da birinin kodunu review et.
- İki haftada bir, biriyle bir saatlik pair programming oturumu yap.
- Ayda bir, bitmiş küçük bir şeyi başkalarına göster.
Yalnız çalışmak derinliği, topluluk ise yönü ve sürekliliği sağlar.
re:make'te bu nasıl işliyor?
re:make, İzmir'de kurulmuş; geliştiricilerin, tasarımcıların ve teknolojiye meraklı insanların bir araya geldiği bağımsız ve ücretsiz bir topluluk. Üyelik ücreti yok, deneyim seviyesi önemli değil. Üyeler hub üzerinden sohbet odalarında konuşuyor, akışta paylaşım yapıyor, açık rolleri olan projelere katılıyor ve etkinliklere kaydoluyor.
Yukarıda anlattıklarımızın somut bir örneği, eğitim projesi emanet-app. Bu projede main'e doğrudan push yok; değişiklikler küçük pull request'lerle geliyor ve review'dan geçiyor. Herkes kendi özelliğini ekranından veritabanı tablosuna kadar uçtan uca yapıyor. Son hafta yeni özellik eklenmiyor; yalnızca hata düzeltme, dokümantasyon ve demo var. Yani review, hesap verebilirlik ve bitirmek, projenin kurgusunun içinde.
Son söz
Tek başına öğrenmeyi bırakma; sadece onu tek yol yapma. Kodunu okuyacak, takıldığında ekranına bakacak ve haftaya ne yaptığını soracak birkaç insan, öğrenme hızını en çok değiştiren şeylerden biri. re:make her pazar 15.00'te Buca'da buluşuyor; üye olmadan da gelebilirsin. Hub'a ve projelere katılmak istersen başvuru kısa ve her başvuruyu bir insan okuyor: remakeizmir.com/basvur
Bir sonraki not düştüğünde haberin olsun.