Unified เทียบกับ Split Diff

 (matklad.github.io)
3 คะแนน โดย GN⁺ 2023-10-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อธิบายข้อดีข้อเสียของการใช้ unified diff และ split diff ในการรีวิวโค้ด
  • unified diff และ split diff เหมาะกับการเปลี่ยนแปลงที่เรียบง่ายและขนาดเล็ก
  • สำหรับการเปลี่ยนแปลงที่ใหญ่และซับซ้อนนั้น unified diff หรือ split diff ไม่ได้เป็นตัวเลือกที่เหมาะเสมอไป
  • ผู้เขียนชอบตรวจสอบโค้ดเบสทั้งหมด ณ ช่วงเวลาหนึ่ง โดยโฟกัสที่บริเวณที่เพิ่งมีการเปลี่ยนแปลง แต่ก็ยังทำการตรวจสอบแบบทั่วไปด้วย
  • ผู้เขียนเสนอว่า diff view ในอุดมคติควรแสดงสถานะปัจจุบันของโค้ดไว้ทางซ้าย และแสดง unified diff ของโค้ดเบสที่กำลังมองเห็นอยู่ทางขวา พร้อมการเน้นส่วนที่เปลี่ยนแปลงอย่างพอดี
  • ชี้ให้เห็นว่ารูปแบบการรีวิวนี้ยังไม่ได้รับการรองรับที่ดีในเครื่องมือเดิม ๆ ที่เน้นการรีวิว diff มากกว่าตัวโค้ดจริง
  • ผู้เขียนใช้เวิร์กโฟลว์แบบโลว์เทคสำหรับสไตล์การรีวิวนี้ โดยใช้สคริปต์เพื่อตรวจสอบ pull request บนเครื่องโลคัล สคริปต์นี้จะลบคอมมิตทั้งหมดของ pull request แต่คงการเปลี่ยนแปลงทั้งหมดไว้
  • เวิร์กโฟลว์ของผู้เขียนช่วยให้ไปยังไฟล์ที่เปลี่ยนแปลงและทำเครื่องหมาย hunk ที่รีวิวแล้วได้ง่าย แต่ยังขาดการซิงก์อัตโนมัติระหว่าง status buffer กับไฟล์ที่เปิดอยู่ในเอดิเตอร์
  • ผู้เขียนต้องการเครื่องมือที่ช่วยให้รีวิวโค้ดในลักษณะนี้ได้ง่ายขึ้น และทำให้ทำได้โดยไม่ต้องสร้างเครื่องมือเฉพาะกิจแบบกำหนดเอง
  • ผู้เขียนยังชี้ด้วยว่า แม้บทความนี้จะพูดถึงวิธีการรีวิวโค้ด แต่เป้าหมายหลักของ code review ไม่จำเป็นต้องเป็นการรีวิวโค้ดเสมอไป พร้อมแนะนำโพสต์ที่เกี่ยวข้องผ่านลิงก์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-25
ความคิดเห็นบน Hacker News
  • บทความนี้อภิปรายความแตกต่างระหว่าง unified diff และ split diff ในการรีวิวโค้ด
  • ผู้แสดงความคิดเห็นบางคนระบุว่ารูปแบบการรีวิวแตกต่างกันไปตามทีมและ ticket โดยบางคนชอบการตรวจสอบเชิงสติด้วยสายตาคู่ที่สอง ขณะที่บางคนชอบการรีวิวฟังก์ชันเชิงลึกและมีโครงสร้างก่อน merge
  • มีการกล่าวถึงเครื่องมือชื่อ difftastic ซึ่งใช้ structural diffing เพื่อเน้นความแตกต่างของ diff ในระดับที่ละเอียดมากขึ้น
  • ผู้แสดงความคิดเห็นบางคนใช้สคริปต์ร่วมกับ vim เพื่อตรวจสอบการเปลี่ยนแปลงโดยเปิด PR ขึ้นมารีวิว
  • มีการเน้นถึงความยากของการรีวิวโค้ดใน codebase ขนาดใหญ่และซับซ้อน โดยปัญหาเกี่ยวข้องกับวัฒนธรรมและการแบ่งปันความรู้มากกว่าเรื่องเครื่องมือ
  • มีการกล่าวว่าฟีเจอร์หนึ่งของ GitHub คือการกด . เพื่อเข้าไปยัง IDE แบบเต็มภายในเบราว์เซอร์ ซึ่งมีประโยชน์ในการดูการเปลี่ยนแปลงในบริบทของทั้งไฟล์
  • ผู้แสดงความคิดเห็นบางคนตั้งคำถามต่อความชอบของผู้เขียนที่ลบบริบทที่ไม่จำเป็นออกจาก split diff ขณะที่บางคนคิดถึงความสามารถของเครื่องมืออื่นอย่าง p4merge
  • มีการแนะนำให้ใช้ VSCode ของ GitHub บนเบราว์เซอร์เพื่อดู diff view สำหรับการดูทั้งไฟล์และ diff ที่ซับซ้อนซึ่งอ่านได้ง่ายกว่า
  • มีการเสนอว่า Meld เป็นเครื่องมือที่ทำงานได้ดีสำหรับกรณีการใช้งานลักษณะนี้