Tek başına çalışırken kod incelemesi: kime yazıyorsun?
Dört ürünü tek başıma yazıyorum, yani PR'ımı onaylayan kimse yok. İnceleme yerine kapı koydum — ve tartışmayı tercih meselesi olmaktan çıkarınca daha sıkı çalıştı.
Solo çalışırken kod incelemesinin en bariz eksiği ikinci bir çift göz değil. En bariz eksiği, kararını birine anlatmak zorunda olmaman.
İki kişilik bir ekipte "bu neden böyle" sorusu kendiliğinden geliyor. Tek başınaysan gelmiyor, ve kötü bir karar hiç sorgulanmadan kod tabanına yerleşiyor. Aylar sonra o kararı bulduğunda hatırladığın şey gerekçesi değil, sadece orada olduğu oluyor.
Benim çözümüm insan yerine kural koymak oldu. Ama işe yarayan kısım kuralların kendisi değil — hangi kuralın tartışmaya kapalı olduğuna karar vermek.
Tercihler ve kapılar
Bir kuralın iki hâli var. Ya bir tercih, yani bugün uyacaksın yarın acele edip geçeceksin. Ya da bir kapı, yani geçmezse kod girmiyor.
Tercihler solo çalışırken hiçbir işe yaramıyor. Çünkü tercihi esneten kişi ile onu koyan kişi aynı, ve o kişi cuma akşamı yorgun.
Xaron'da tartışmaya kapalı olan üç şey var. Üretim kodunda unwrap() veya expect() yok — hatalar değer olarak en tepeye kadar taşınıyor. Yeni bir endpoint hız sınırı olmadan girmiyor; eksikse bu bir sonraki bilet değil, doğrudan engel. Ve tek bir kapı var: biçimlendirme, uyarıların hata sayıldığı linter, çalışma alanı testleri, WASM derlemesi, entegrasyon testleri, bağımlılık denetimi — hepsi hem yerelde hem CI'da aynı komutla.
Bu üçünün ortak özelliği şu: hiçbiri "iyi kod" hakkında bir görüş değil. Hepsi ölçülebilir. Tartışmaya açık olmayan kural, tartışılamayacak kadar net olmak zorunda.
Solo çalışırken disiplin bir karakter özelliği değil. Bir otomasyon problemi.
İnceleme yerine gecikme
İkinci alışkanlık daha basit: kendi kodumu aynı gün incelemiyorum.
Yazdığım şeye bir gün sonra bakmak, o gün içinde bakmaktan tamamen farklı. Yazarken kafamdaki bağlam kodun eksiklerini dolduruyor — neyi kastettiğimi biliyorum, o yüzden okunmayan isim okunuyor gibi geliyor. Bir gün sonra o bağlam gitmiş oluyor ve kod kendi başına ne kadar anlaşılırsa o kadar anlaşılır oluyor.
Bu, bir başkasının incelemesine en çok yaklaştığım an. Çünkü ertesi günkü ben, o kodu ilk kez okuyan biri.
Yazmadığın şey
Üçüncüsü, ve en çok işe yarayanı: kararın gerekçesini koda değil, yanına yazmak.
Bir sınırı neden oraya çektiğimi, bir yaklaşımı neden reddettiğimi kısa bir notla bırakıyorum. Ne yaptığını anlatan yorum işe yaramıyor — kod onu zaten söylüyor. İşe yarayan, neyi yapmadığımı ve neden yapmadığımı anlatan not.
Aylar sonra o notu bulduğumda iki şeyden biri oluyor: ya gerekçe hâlâ geçerli ve dokunmuyorum, ya artık geçersiz ve rahatça değiştiriyorum. İkisi de not olmadığında yaşadığım şeyden iyi — ki o şey, dokunmaya korkup etrafından dolaşmak.
Bunun ekip için karşılığı
Bu alışkanlıkların hiçbiri solo çalışmaya özgü değil, sadece solo çalışırken zorunlu hâle geliyor.
Bir ekibe katıldığımda getirdiğim şey de bu olurdu: kaç kişi olduğunuzdan bağımsız, hangi kuralların kapı hangilerinin tercih olduğunu yazılı hâle getirmek. Çünkü ekipte de aynı şey oluyor — sadece cuma akşamı esneten kişi bu kez başkası.