การฟอร์แมตและการควบคุมเวอร์ชัน

เรื่องการจัดรูปแบบรหัส แม้เรื่องการเยื้อง และความมั่นคงมีความสำคัญมากกว่าการปรับปรุงเล็กน้อย แต่โครงการมักจะไม่มีคู่มือสไตล์ชัดเจนชัดเจนตรวจสอบได้และบังคับใช้ตั้งแต่วันที่ 1 และการปรับปรุงที่สำคัญอาจมาถึงทุกวัน บางทีคุณอาจพบว่า

SELECT id, name, address
FROM persons JOIN addresses ON persons.id = addresses.person_id;

อาจเขียนได้ดีกว่า / เขียนได้ดีกว่า

SELECT persons.id,
       persons.name,
       addresses.address
  FROM persons
  JOIN addresses ON persons.id = addresses.person_id;

ในขณะที่ทำงานเพื่อเพิ่มคอลัมน์เพิ่มเติมในแบบสอบถาม บางทีนี่อาจเป็นคำถามที่ซับซ้อนที่สุดในทั้งสี่ข้อความในรหัสของคุณหรือข้อความค้นหาเล็กน้อยในหมู่คนนับพัน ไม่ว่าการเปลี่ยนแปลงจะทำได้ยากเพียงใดคุณตัดสินใจได้ว่ามันคุ้มค่า แต่คุณจะติดตามการเปลี่ยนแปลงของรหัสในการเปลี่ยนแปลงการจัดรูปแบบที่สำคัญได้อย่างไร คุณเพียงแค่ยอมแพ้และพูดว่า "นี่คือจุดที่เราเริ่มต้นอีกครั้ง" หรือคุณสามารถฟอร์แมตแบบสอบถามทั้งหมดในประวัติพื้นที่เก็บข้อมูลทั้งหมด

หากคุณใช้ระบบควบคุมเวอร์ชันแบบกระจายเช่น Git คุณสามารถย้อนกลับไปสู่การคอมมิทครั้งแรกและฟอร์แมตใหม่จากที่นี่ไปเป็นสถานะปัจจุบัน แต่มันเป็นงานจำนวนมากและทุกคนจะต้องหยุดทำงานชั่วคราว (หรือเตรียมพร้อมสำหรับแม่ของการรวมทั้งหมด) ในขณะที่มันกำลังดำเนินอยู่ มีวิธีที่ดีกว่าในการเปลี่ยนประวัติศาสตร์ซึ่งให้ผลลัพธ์ที่ดีที่สุด:

• สไตล์เดียวกันในทุกการกระทำ
• ผสานงานน้อยที่สุด

?

การชี้แจงนี้ไม่ได้เกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดเมื่อเริ่มต้นโครงการ แต่ควรทำอย่างไรเมื่อการปรับโครงสร้างขนาดใหญ่ถือว่าเป็น Good Thing ™ แต่คุณยังต้องการประวัติย้อนหลังได้ ไม่เคยเขียนประวัติศาสตร์ใหม่ยอดเยี่ยมหากเป็นวิธีเดียวที่จะทำให้แน่ใจว่าเวอร์ชันของคุณใช้งานได้เหมือนเดิมเสมอ แต่ประโยชน์ของนักพัฒนาของการเขียนใหม่ทั้งหมดจะเป็นอย่างไร โดยเฉพาะอย่างยิ่งถ้าคุณมีวิธี (การทดสอบคำจำกัดความของไวยากรณ์หรือไบนารีที่เหมือนกันหลังจากการรวบรวม) เพื่อให้แน่ใจว่ารุ่นที่เขียนใหม่จะทำงานในลักษณะเดียวกับต้นฉบับหรือไม่

ทำการฟอร์แมตใหม่แยกต่างหาก สิ่งนี้จะรบกวนประวัติย่อเล็กน้อยและคุณควรเห็นได้อย่างรวดเร็วว่าการกระทำนั้นเป็นการฟอร์แมตใหม่และการเปลี่ยนรหัสจริง มันอาจเบ้git blameและคล้ายกัน แต่ถ้าชี้ไปที่การฟอร์แมตอย่างเดียวมันจะค่อนข้างตรงไปข้างหน้าเพื่อหาการเปลี่ยนแปลงก่อนหน้านี้ก่อนหน้านั้น

อย่าเขียนประวัติ VCSซ้ำอีก:มันขัดกับหลักการของ VCS

อย่าพยายามแก้ไขการจัดรูปแบบโดยอัตโนมัติ:เป็นการรักษาอาการไม่ใช่ปัญหาจริง (= นักพัฒนาไม่ปฏิบัติตามมาตรฐานการเข้ารหัส)

กำหนดมาตรฐานการเข้ารหัสและการจัดรูปแบบแนวปฏิบัติที่ดีที่สุดในเอกสารทั่วไปและให้นักพัฒนาทั้งหมดเห็นด้วย

คุณพูดถึง Git ซึ่งยอดเยี่ยมเพราะมันเผยแพร่ ด้วย DVCS มันง่ายมากที่จะบังคับใช้ปฏิบัติที่ดีที่สุดผ่านขั้นตอนการทำงานยาม Gatekeepers ปฏิเสธข้อเสนอการรวม (= คำขอการดึงใน Git) ที่ไม่สอดคล้องกับหลักเกณฑ์ทั่วไป และฉันหมายถึงการปฏิเสธเป็นตัวอักษรหนามิฉะนั้น coder ที่ละเมิดจะไม่สนใจที่จะปฏิบัติตามกฎและทำซ้ำความผิดพลาดเดิมต่อไป

เทคนิคนี้ใช้ได้ดีสำหรับฉัน โคเดอร์ต้องการให้งานของพวกเขารวมเข้าด้วยกันดังนั้นหลังจากความผิดพลาดเล็กน้อยในตอนแรกพวกเขาก็เริ่มทำตามกฎ

ตามการแก้ไขรหัสฐานที่มีอยู่ ... ฉันขอแนะนำให้ทำอย่างค่อยเป็นค่อยไปบางทีอาจเป็นโมดูลโดยโมดูลหรือตามที่เหมาะสมสำหรับโครงการของคุณ ทดสอบอย่างรอบคอบในแต่ละขั้นตอน อาจฟังดูงี่เง่า แต่มีข้อผิดพลาดเกิดขึ้นแม้ว่าจะมีการเปลี่ยนแปลงเล็กน้อยเช่นการจัดรูปแบบดังนั้นควรเตรียมพร้อมสำหรับการกระแทกเล็กน้อยบนท้องถนน

คำตอบสำหรับคำถามที่แท้จริงของคุณคือ "คุณทำไม่ได้" ฉันรู้ว่าไม่มีเครื่องมือ SCM ในปัจจุบันที่สามารถติดตามการเปลี่ยนแปลงในตรรกะจากโค้ดที่จัดรูปแบบในวิธีเดียวผ่านการเปลี่ยนแปลงการจัดรูปแบบที่สำคัญและผ่านการเปลี่ยนแปลงเพิ่มเติมหลังจากโค้ดถูกจัดรูปแบบในรูปแบบใหม่ และคุณรู้สิ่งนี้การสูญเสียประวัติในโค้ดบางส่วนนั้นไม่ดี

ดังนั้นฉันจะโต้แย้งประโยคแรกของคุณเล็กน้อย รหัสการจัดรูปแบบไม่สำคัญว่ามาก สวยดี แต่ไม่ใช่สิ่งที่เราทำ ผมเข้าใจเช่นเดียวกับทุกคนที่ได้รับการโยนลงไปคนอัปรีย์เก่าแปลก K & R ตัวแปรรหัสกับเยื้องสองพื้นที่ดูด (1) แต่ ... การจัดรูปแบบไม่จริงเป็นอุปสรรคต่อการทำความเข้าใจสิ่งที่เกิดขึ้นนอกจากจะเป็นสิ่งที่พิเศษเกี่ยวกับพยาธิวิทยา และในกรณีนี้คุณจะมีปัญหาในการเปลี่ยนรหัสอย่างไรก็ตามไม่ควรรบกวนมัน

ดังนั้นจึงไม่คุ้มค่าที่จะทำการเปลี่ยนแปลงโค้ดที่สร้างขึ้นอย่างเข้มงวดเพื่อทำการฟอร์แมทใหม่ การเปลี่ยนชื่อตัวแปรการเลิกใช้ฟังก์ชันที่ยาวนานสิ่งที่ refactoring ที่ดีทั้งหมดที่เปลี่ยนแปลงเนื้อหาใช่ แต่ไม่ใช่การฟอร์แมตใหม่

1) - ฉันเคยเป็นเจ้าของ Windows Clipboard Viewer มาระยะหนึ่งแล้ว สิ่งทั้งหมดคือหนึ่งโมดูล 150k โมดูล ฉันพบจุดที่ผู้คนต่างใช้กันฉันคิดว่ารูปแบบวงเล็บปีกกาห้าแบบภายในสามสิบบรรทัดของกันและกัน แต่ส่วนของสิ่งที่ทำงาน ฉันอุ้มโค้ดที่พิมพ์มาสิบปี แต่ฉันไม่ได้กระตุ้นเพราะประวัตินั้นสำคัญและรหัสนั้นอยู่ในซอร์สต้นไม้อย่างน้อยสามต้น (Windows 3.x, NT, 95 ในอนาคต) ที่อาศัยอยู่ทั้งหมด ในอาคารต่าง ๆ

แต่คุณจะติดตามการเปลี่ยนแปลงของรหัสในการเปลี่ยนแปลงการจัดรูปแบบที่สำคัญได้อย่างไร

การเปลี่ยนแปลงการจัดรูปแบบที่มีการเปลี่ยนแปลงรหัส; ปฏิบัติต่อพวกเขาเหมือนที่คุณจะเปลี่ยนแปลงรหัสของคุณ ทุกคนที่ทำงานในโครงการสำคัญอาจจะเห็นข้อบกพร่องและปัญหาอื่น ๆ ที่สร้างขึ้นเมื่อมีคนตัดสินใจที่จะ "ฟอร์แมต" เพียงแค่ฟอร์แมตโค้ดใหม่

แต่มันเป็นงานจำนวนมากและทุกคนจะต้องหยุดทำงานชั่วคราว (หรือเตรียมพร้อมสำหรับแม่ของการรวมทั้งหมด) ในขณะที่มันกำลังดำเนินอยู่

ทำไมคุณต้องฟอร์แมตใหม่ทุกอย่างในเวลาเดียวกัน โดยเฉพาะอย่างยิ่งหากการจัดรูปแบบไม่เปลี่ยนความหมายของรหัสคุณควรจะสามารถฟอร์แมตไฟล์แยกต่างหากและตรวจสอบในขณะที่คุณไป ดีกว่าให้ทุกคนในทีมของคุณเห็นด้วยกับสไตล์ (ไม่เช่นนั้นจะไม่มีประเด็นในการจัดรูปแบบใหม่) และให้พวกเขาดูแลการฟอร์แมตในงานอื่น ๆ ของพวกเขา หลังจากผ่านไปครู่หนึ่งคุณจะได้ครอบคลุมส่วนใหญ่ของรหัสโดยไม่กระทบกับส่วนที่เหลือของโครงการ

มีสองแนวทางปฏิบัติที่ฉันได้เห็นในเรื่องนี้

1. ฟอร์แมตโค้ดบน commit-hook

แม้ว่าขั้นตอนแรกคือการปลูกผมเพื่อเปลี่ยนรหัสหลังจากที่พวกเขาส่งมันหากขั้นตอนการจัดรูปแบบของคุณ (เช่นastyle ) ไม่ทำให้รหัสเกิดความเสียหาย แต่เป็นการทำงานที่ปลอดภัย เมื่อเวลาผ่านไปทีมงานทุกคนจะชื่นชมว่ารหัสทั้งหมดในที่สุดดูเหมือนกัน เห็นได้ชัดว่ามีการทดสอบหน่วย / อัตโนมัติที่ครอบคลุมจะช่วยให้มั่นใจได้ว่าไม่มีอะไรพัง

2. การฟอร์แมตใหม่เพียงครั้งเดียวของรหัสทั้งหมด

สิ่งนี้เป็นสิ่งที่อันตรายมากสำหรับประสบการณ์ของฉันและทำให้ปัญหาการติดตามของบิ๊กแบงยาก แต่ก็เป็นไปได้ การรันการทดสอบทั้งหมดหลังจากนั้นเป็นสิ่งจำเป็น สำหรับรูปแบบการเข้ารหัสความแตกต่างส่วนใหญ่เกี่ยวข้องกับการใช้ช่องว่าง - เยื้องหรือการขึ้นบรรทัดใหม่ เครื่องมือผสานที่ดีควรบอกให้ละเว้นความแตกต่างของช่องว่างทั้งหมดดังนั้นสิ่งนี้จะช่วยในการผสาน