Unified ve Split Diff

• Kod incelemede unified diff ve split diff kullanmanın artıları ve eksileri açıklanıyor
• unified diff ve split diff, basit ve küçük değişiklikler için uygun
• Büyük ve karmaşık değişikliklerde unified diff veya split diff ideal değil
• Yazar, belirli bir andaki tüm kod tabanını gözden geçirmeyi tercih ediyor; yakın zamanda değişen bölgelere odaklanırken genel bir inceleme de yapıyor
• Yazar, ideal diff görünümünün solda kodun güncel durumunu, sağda ise ince biçimde vurgulanmış değişikliklerle birlikte şu anda görünen kod tabanının unified diff görünümünü göstermesi gerektiğini öne sürüyor
• Bu inceleme biçiminin, gerçek koddan ziyade diff incelemeye odaklanan mevcut araçlar tarafından iyi desteklenmediğine dikkat çekiyor
• Yazar, bu inceleme tarzı için düşük teknolojili bir iş akışı kullanıyor ve pull request'i yerelde kontrol eden bir betikten yararlanıyor. Bu betik pull request'teki tüm commit'leri siliyor ama tüm değişiklikleri koruyor
• Yazarın iş akışı, değiştirilen dosyalar arasında kolay gezinmeyi ve incelenen hunk'ları işaretlemeyi sağlıyor, ancak durum tamponu ile editörde o anda açık dosya arasında otomatik senkronizasyon eksik
• Yazar, bu şekilde kod incelemeyi kolaylaştıran ve özel amaçlı ad-hoc araçlar geliştirmeyi gerektirmeden bunu mümkün kılan araçlar istiyor
• Yazar ayrıca yazının kod inceleme yöntemlerini tartıştığını, ancak kod incelemenin temel amacının her zaman kodu incelemek olmadığını da belirtiyor ve bu konuyla ilgili bir yazıya bağlantı veriyor

[GN⁺]

Hacker News görüşleri

• Bu yazı, kod incelemesinde birleşik diff ile bölünmüş diff arasındaki farkları tartışıyor.
• Bazı yorumcular, inceleme türünün ekibe ve bilete göre değiştiğini; bazılarının ikinci bir gözle yapılan zihinsel kontrolü tercih ettiğini, bazılarının ise birleştirme öncesi derin ve yapısal özellik incelemesini tercih ettiğini savunuyor.
• Daha ayrıntılı diff vurgulaması için yapısal diffing kullanan difftastic adlı bir araçtan söz ediliyor.
• Bazı yorumcular, incelemeye açılmış değişiklikleri gözden geçirmek için vim kullanan betiklerden yararlanıyor.
• Büyük ve karmaşık kod tabanlarında kod incelemesinin zorluğu vurgulanıyor; sorunun araçlardan çok kültür ve bilgi paylaşımıyla ilgili olduğu belirtiliyor.
• GitHub özelliklerinden biri olan, tarayıcı içinde tam IDE'ye geçmek için . tuşuna basmanın, değişiklikleri dosyanın tüm bağlamı içinde görmek açısından yararlı olduğu belirtiliyor.
• Bazı yorumcular, yazarın bölünmüş diff'te gereksiz bağlamı kaldırma tercihine karşı çıkarken, bazıları p4merge gibi başka araçların özelliklerini özlediklerini söylüyor.
• Diff görünümünü tarayıcıda görmek için GitHub'ın VSCode deneyimini kullanmanın, tüm dosyayı ve daha okunabilir karmaşık diff'leri görmek açısından önerildiği belirtiliyor.
• Meld, bu kullanım senaryoları için iyi çalışan bir araç olarak öneriliyor.