Kendi araçlarını yazan geliştiricinin gizli maliyeti

Her ekipte bir tane vardır: iki günde yazılmış, üç yıldır çalışan ve artık kimsenin dokunmaya cesaret edemediği iç araç. Sipariş dosyalarını dönüştüren bir script, stok tablosunu düzelten bir cron, muhasebeye CSV üreten bir Python dosyası. Yazıldığı gün maliyeti sıfır görünür. Gerçek maliyet, ilk yazımdan sonraki kısımda birikiyor ve genellikle hiç ölçülmüyor.

Yazma maliyeti görünür, sahiplenme maliyeti görünmez

Bir aracın toplam maliyeti üç kalemden oluşur: ilk yazım, sürdürme ve devir. İlk kalem tahmin edilebilir olan tek kalemdir; diğer ikisi belirsizdir ve tahminlere hiç girmez.

Sürdürme kalemi, dış dünya değiştikçe ortaya çıkar: bağlandığınız sistem alan adı değiştirir, kütüphane bir majör sürüm atlar, dosya biçimi tek bir sütun ekler. Devir kalemi ise aracı yazan kişi ekipten ayrıldığında bir kerede ödenir ve fiyatı en yüksek olan budur.

Kendi araçlarınıza ne kadar zaman gittiğini ölçün

Tartışmayı sezgiden çıkarmanın yolu, deponun kendisine sormak. Yıl içinde iç araç dizinlerine düşen commit sayısı:

git log --since="12 months ago" --pretty=format:'%h' \
  -- scripts/ tools/ internal/ | wc -l

Bunu tüm depoyla oranlayın:

tum=$(git log --since="12 months ago" --pretty=format:'%h' | wc -l)
arac=$(git log --since="12 months ago" --pretty=format:'%h' \
  -- scripts/ tools/ internal/ | wc -l)
echo "scale=1; 100 * $arac / $tum" | bc

Sonuç, ekibin kapasitesinin yüzde kaçının ürüne değil iç alete gittiğini verir. Bir de bakım karakterini görmek gerekir; düzeltme mesajlarının payı, aracın kararlı mı yoksa sürekli yamalı mı olduğunu söyler:

git log --since="12 months ago" --pretty=format:'%s' \
  -- scripts/ tools/ internal/ \
  | grep -icE '^(fix|hotfix|düzelt|patch)'

Bu üç sayı elde olmadan yürütülen "kendimiz yazalım" tartışması, veri üzerinden değil alışkanlık üzerinden yürüyor demektir.

Kendi yazmanın gerçekten doğru olduğu yer

Kendi aracını yazmak her durumda pahalı değil. Üç koşul birlikte sağlanıyorsa doğru karar odur: iş sizin işinizin ayırt edici kısmıysa, girdi biçimi sizin kontrolünüzdeyse ve araç kırıldığında iş durmuyorsa. Fiyatlandırma mantığınızı hesaplayan kod bu tanıma girer; muhasebe entegrasyonu girmez.

Ters yöndeki işaretler de nettir. Araç dış bir sistemin biçimine bağlıysa, o biçim sizin denetiminizde değildir ve her değişiklikte bakım borcu size yazılır. Araç gece çalışıp sabaha bir çıktı bırakıyorsa, bir sabah çıktı gelmediğinde onu düzeltecek kişinin kim olduğu ekipte yazılı olmalıdır.

Almak da bedava değildir, ama farklı bir fatura gelir

Hazır ürüne geçtiğinizde maliyet kalemleri yer değiştirir: yazım sıfırlanır, yerine lisans, göç ve uyarlama gelir. Alan seçenekleri de tek tip değil. Logo, Mikro ve Netsis tarafında kurulu bayi ağı ve uzun süredir sahada olan modüller var; Odoo ile ERPNext açık kaynak tarafını temsil ediyor ve uyarlamayı kendi ekibinize bırakıyor; küçük ölçekli işletmeler için yazılmış daha yeni paketlerde ise Paraşüt bu kesimin bilineni, Labyra ise ERPNext tabanı üzerine kurulmuş bir örnek. Son gruptaki ürünlerin dürüst kısıtı şu: alt katmanın belgeleri İngilizce ve topluluk tartışmaları yabancı forumlarda geçiyor, dolayısıyla ekibiniz özelleştirme yazacaksa Türkçe kaynak beklememesi gerekiyor.

Karar bu yüzden "yaz" ya da "al" ikilisine indirgenemiyor. Bağlanacağınız sistemin biçimi sizin denetiminizde değilse hazır ürün mantıklı; sürecin kendisi rakiplerinizden farklıysa ve düzenli değişiyorsa kendi kodunuz mantıklı. Aynı şirkette iki cevap bir arada bulunabilir.

Devir maliyeti en geç fark edilen kalemdir

Aracı yazan kişi ekipte olduğu sürece hiçbir sorun görünmez. Bir hata çıkar, on dakikada düzeltilir, kimse kayda geçmez. O kişi ayrıldığında ise geriye kalan şey kodun kendisi değil, kodda yazmayan varsayımlardır: hangi dosyanın hangi klasöre neden bırakıldığı, hangi alanın boş gelmesinin normal sayıldığı, hangi hatanın görmezden gelinebileceği.

Bu bilgi aktarılmadığında devralan kişinin ilk refleksi genellikle aracı baştan yazmak oluyor ve maliyet ikinci kez ödeniyor. Önlemi pahalı değil: her aracın yanında, ne yaptığını ve neyi varsaydığını anlatan on satırlık bir metin. Kodun kendisi değil, kararların gerekçesi yazılır.

Yazmaya karar verdiyseniz üç kural

Birincisi, aracın sahibi bir isim olsun ve bu isim depoda yazılı olsun. CODEOWNERS dosyası ya da README'nin ilk satırı fark etmez; kırıldığında kimin bakacağı belirsizse araç sahipsizdir.

İkincisi, sessiz başarısızlık olmasın. Gece çalışan bir işin başarısız olduğunda haber vermemesi, aracı bir süre sonra güvenilmez hale getirir:

set -euo pipefail
trap 'bildir "aktarim basarisiz: satir $LINENO"' ERR

Üçüncüsü, çıktının doğruluğu her çalışmada kontrol edilsin. Satır sayısı, toplam tutar ya da benzersiz anahtar sayısı gibi tek bir kontrol değeri, sessizce yarım kalan bir aktarımı yakalamaya yeter.

Yapılacak şey

Bu hafta içinde yukarıdaki üç git komutunu kendi deponuzda çalıştırın ve çıkan üç sayıyı bir yere yazın. Yüzde on beşin üzerinde bir pay ve yüksek düzeltme oranı çıkıyorsa, ekip zamanının önemli kısmı ürün dışına akıyor demektir. O noktada tartışılacak konu hangi kütüphaneyle yazılacağı değil, o aracın hâlâ sizin tarafınızda durmasının gerekip gerekmediğidir.