PR'ı 800 Satır Göndermenin Bedeli

Branch bir hafta yaşadı. Migration, endpoint, form, test. 'Bir kerede bitsin' diye açtım. Review isteği öğleden sonra gitti, onay akşam geldi. Onay, okunmuş anlamına gelmedi. İkinci gün yanlış bir kolon adı production'a kadar yürüdü. Diff'te duruyordu. 800 satırın içinde durmuyordu.

Ne görünmez

Büyük PR'da insan önce mimariye, sonra isimlendirmeye, sonra yorgunluğa bakıyor. Yorgunluk kazanıyor. 'lgtm' bir inceleme sonucu değil, bir teslim bayrağı. Bunu yazan da, isteyen de biliyor; ikisi de takvime yeniliyor.

# tek PR — bakılamaz
feat: billing rewrite, webhooks, schema, settings ui

# üç PR — bakılır
feat(db): add webhook_events.idempotency_key
feat(api): reject duplicate webhook deliveries
feat(ui): show webhook last delivery status

git diff --stat origin/main ilk kontrolüm. Dosya listesi birden fazla katmanı aynı anda değişiyorsa PR'ı bölüyorum. Bölmek, işi üç gün uzatmak değil; incelemeyi mümkün kılmak. Mümkün olmayan inceleme, sıfır gün kazandırır, iki gün bug taşır.

Nasıl bölünür

Önce şema veya sözleşme, tek başına merge. Sonra onu kullanan iş. Arayüz en son. Tersi — önce UI, sonra API — review'u 'neden çalışmıyor'a çevirir. Test, değişen katmanla gelir; 'test sonra' büyük PR'ın kuzeni.

• Bir PR, bir cümlelik neden.
• Migration ayrı: geri alınabilir, okunabilir.
• Üretilen kod ve silinen kod aynı hikâyede olmalı.

İtirazlar

'Bu iş atomik, bölünmez.' Bazen doğru. Atomik olan çoğu zaman veri dönüşümü. Onu da önce yaz, sonra çağır. 'Zaman yok.' Zaman, 800 satırı gece onaylatmakta gidiyor; sabah hotfix'te geri geliyor. Hesap uymuyor.

Küçük PR bir erdem listesi değil. Bakılabilen bir yüzey. Yüzey bakılamıyorsa hız iddiası boş. Bunu böyle söylemek, 'daha çevik olalım' dan daha sıkıcı ve daha işe yarar.