Türkiye'nin en büyük inovasyon ve girişimcilik bültenine katılın
Kanallar İlham Uygulamalar SSS Sözlük Giriş Üye Ol

Yazılım Geliştirme

/yazilim · 8.YIL

Fikirden çalışan ürüne yazılımın her hali: web, backend, veritabanı, mimari kararlar, kod kalitesi ve araçlar. Dil ve framework fark etmez; yazan herkesin ortak kanalı.

25 içerik Katıl
#yazılım geliştirme akışına dön
@noway · 22 gün önce

kod review'da neye bakıyorsunuz, bizim ekipte tartışma çıktı

Ekipte review süresi çok uzadı ve insanlar birbirine sinirlenmeye başladı. Oturup neye bakacağımızı yazdık, sonra tartışma bitti.

Sorunun kaynağı şuydu: herkes farklı şeye bakıyordu. Biri isimlendirmeye takılıyor, biri mimariye, biri boşluk karakterine. Aynı PR üç farklı yönden eleştiri alıyordu.

Şimdi üç kategoriye ayırdık ve yorumun başına etiket koyuyoruz.

Engelleyici. Birleştirilmemesi gereken şeyler. Güvenlik açığı, veri kaybı riski, yanlış mantık, eksik yetki kontrolü, testi olmayan kritik akış.

Öneri. Düzeltilirse iyi olur ama şart değil. Daha iyi bir yaklaşım, isimlendirme, tekrar eden kod.

Soru. Anlamadığım yer. Bazen cevap yeterli oluyor, bazen kodun açıklanması gerektiğini gösteriyor.

Biçimlendirme tartışmalarını tamamen kaldırdık. Otomatik biçimlendirici koyduk ve konu kapandı. İnsanların noktalı virgül tartışmasına harcadığı süre inanılmazdı.

Birkaç kural daha koyduk:

PR büyükse review kalitesi düşüyor. Dört yüz satırı geçen PR'ları bölmeyi istiyoruz.

Yazar kendi PR'ını önce kendi okuyor ve zor kısımlara açıklama yorumu bırakıyor. Bu tek alışkanlık review süresini yarıya indirdi.

İki günden fazla bekleyen PR için sorumluluk yazarda değil, review edende.

Tartışma üç mesajı geçerse yazışmayı bırakıp konuşuyoruz.
0 3 yorum
Yorumlar (3)
@gokhancetin · 20 gün önce 2
PR'ı yazarın kendi okuması kısmı bizde de en çok fark yaratan şey oldu.

Kendi değişikliğinize dışarıdan bakınca yarısını siz düzeltiyorsunuz. Review'a gelen kod daha temiz oluyor.

Bir ekleme: PR açıklamasına neden yazmak da çok işe yarıyor. Ne yaptığını koddan görüyorum zaten, neden yaptığını göremiyorum.

Bizde şablon var: ne değişti, neden değişti, nasıl test edildi, riskli bir yer var mı.
@sametay · 17 gün önce 0
Biçimlendirmeyi otomatikleştirme kararına katılıyorum ama bir noktada ihtiyatlıyım.

Otomatik biçimlendirici koyarken eski kodun tamamını bir anda biçimlendirmeyin. Tek bir devasa commit oluşuyor ve sonrasında kim ne yazmış hiç göremiyorsunuz.

Biz dosya dosya, o dosyaya dokunduğumuzda biçimlendirdik. Bir yıl sürdü ama geçmiş okunabilir kaldı.

Bir de o toplu biçimlendirme commit'ini suçlama çıktısından hariç tutmanın yolu var, onu kullanmak gerekiyor.
@nikea · 14 gün önce 3
Dört yüz satır sınırına katılmıyorum, sayı tek başına anlamlı değil bence.

Bin satırlık bir taşıma işi review edilebilir, elli satırlık karmaşık bir algoritma değişikliği çok daha zor.

Bence ölçüt satır sayısı değil, kaç farklı fikir içerdiği olmalı. Bir PR tek bir şey yapmalı.

Mekanik değişiklikleri ayrı PR'a almak, gerçek değişikliği görünür kılıyor. Bizde kural şu: yeniden adlandırma ve taşıma işlemleri ayrı PR olur.