สำรวจว่าทำไมแค่ทำตามคอมมิตแบบธรรมดาถึงไม่เพียงพอในการเขียนข้อความคอมมิตที่ดี และแนะนำกลยุทธ์การคิดที่สำคัญในการพัฒนากระบวนการพัฒนาและสร้างคอมมิตที่มีความหมายโดยธรรมชาติ
การค้นหาอย่างรวดเร็วบนอินเทอร์เน็ตจะแสดงบทความมากมายที่สอนวิธีการเขียนข้อความคอมมิต 90% ของบทความเหล่านี้บอกให้คุณใช้ คอมมิตแบบธรรมดา อย่างไรก็ตาม นักพัฒนาจำนวนไม่น้อยยังคงมีปัญหากับเรื่องนี้ พวกเขารู้ว่าควรทำตามแนวทางเหล่านี้ แต่พวกเขากลับพบว่ามันยากที่จะนำไปใช้ในทางปฏิบัติ ทุกครั้งที่พวกเขาคอมมิตโค้ด พวกเขารู้สึกหงุดหงิดว่าจะเขียน "refactor" หรือ "chore" ฉันเคยเห็นโครงการทีมีข้อความคอมมิตที่เหมือนกันทั้งหมดว่า "feat: add page" เพราะการเขียนข้อความคอมมิตสำหรับพวกเขานั้นท้าทายเกินไป และพวกเขาก็เพิ่งยอมแพ้
ฉันไม่ได้บอกว่าคอมมิตแบบธรรมดาไม่ดี มันมีประโยชน์ที่เป็นที่รู้จักอย่างมากมาย:
อย่างไรก็ตาม เมื่อผู้พัฒนายังคงประสบกับความยากลำบากในการเขียนข้อความคอมมิตที่ดีแม้ว่าจะได้ใช้คอมมิตแบบธรรมดาแล้ว การยัดเยียดบทความเกี่ยวกับวิธีใช้คอมมิตแบบธรรมดาให้พวกเขา สอนพวกเขาว่า feat แปลว่าอะไร และ fix แปลว่าอะไร จะไม่มีประโยชน์จริงๆ เพราะมันก็เหมือนกับการให้ตำราการทำอาหารขั้นสูงให้คนที่ไม่รู้วิธีการทำอาหาร โดยไม่สอนวิธีใช้วัตถุดิบและอุปกรณ์ขั้นพื้นฐาน แต่บทความที่กล่าวถึงเช่นนี้ก็มีอยู่มากมายบนอินเทอร์เน็ต พวกเขาไม่รู้ว่าคอมมิตแบบธรรมดาจะมีประสิทธิผลอย่างแท้จริงเมื่อผู้พัฒนามีการคิดที่ชัดเจนและความสามารถในแบ่งแยกภารกิจอย่างแม่นยำเท่านั้น
ดังนั้น คอมมิตแบบธรรมดาไม่แย่ แต่ก่อนที่จะไปถึงจุดนั้น เราจำเป็นต้องสร้างทัศนคติการพัฒนาที่ถูกต้องและใช้การคิดแบบมีเหตุผลของนักพัฒนาทำสิ่งต่างๆ
ในการพัฒนาซอฟต์แวร์ "ทำสิ่งหนึ่งในแต่ละครั้ง" เป็นหลักการที่สำคัญ นี้ไม่เพียงแต่ใช้ในการเขียนโค้ดแต่ยังใช้ในการคอมมิตโค้ดด้วย เมื่อเรามุ่งเน้นไปที่หนึ่งภารกิจหรือการเปลี่ยนแปลงที่เฉพาะเจาะจงในแต่ละครั้ง โค้ดของเราจะชัดเจนขึ้นและเจตนาของเราชัดเจนยิ่งขึ้น วิธีนี้ไม่เพียงแต่ช่วยเพิ่มประสิทธิภาพในการอ่านโค้ด แต่ยังทำให้กระบวนการตรวจสอบโค้ดง่ายลงอย่างมาก ผู้ตรวจสอบสามารถเข้าใจและตรวจสอบวัตถุประสงค์ของแต่ละการเปลี่ยนแปลงได้ง่ายขึ้น
ยิ่งไปกว่านั้น วิธีนี้มอบความสะดวกสบายในการย้อนโค้ดที่อาจมีปัญหา ถ้าเกิดมีปัญหา เราสามารถค้นหาและย้อนการเปลี่ยนแปลงที่เฉพาะเจาะจงได้ง่ายขึ้นโดยไม่กระทบกับส่วนอื่นที่ไม่เกี่ยวข้อง ที่สำคัญที่สุด เมื่อแต่ละการเปลี่ยนแปลงทำสิ่งหนึ่งเท่านั้น ข้อความคอมมิตที่บรรยายการเปลี่ยนแปลงนั้นก็จะกลายเป็นชัดเจนและมีความหมายโดยธรรมชาติ
ในการปฏิบัติ หมายความว่าเราต้องกำหนดภารกิจที่จะดำเนินการให้ชัดเจนก่อนที่เราจะเริ่มเขียนโค้ด หลังจากดำเนินภารกิจสำเร็จแล้ว เราควรคอมมิตโค้ดทันที แทนที่จะรอจนเมื่อหลายภารกิจสำเร็จแล้วค่อยคอมมิตพร้อมกัน ถ้าเราพบว่ามีพื้นที่อื่นที่ต้องการการปรับปรุงขณะที่กำลังทำงานกับภารกิจปัจจุบัน วิธีที่ดีที่สุดคือการจดบันทึกเอาไว้และจัดการแยกออกมาที่หลังจากภารกิจปัจจุบันเสร็จ ตัวอย่างเช่น เมื่อคุณกำลังดำเนินการคุณสมบัติหนึ่งและพบว่ามีข้อบกพร่องบางอย่างที่มีอยู่แล้ว สิ่งที่คุณควรทำคืไม่แก้ไขข้อบกพร่องทันทีพร้อมกับโค้ดคุณสมบัติใหม่ของคุณ แต่จะต้องดำเนินการคุณสมบัติก่อน จากนั้นแก้ไขข้อบกพร่องที่คุณพบในคอมมิตอื่น หรือแก้ไขข้อบกพร่องก่อนแล้วคอมมิตคุณสมบัติ
นักพัฒนาหลายคนเพิ่งเริ่มคิดว่าจะเขียนข้อความคอมมิตอย่างไรหลังจากทำโค้ดเสร็จสิ้น แต่จริงๆ แล้ว ข้อความคอมมิตควรมีอยู่ก่อนที่เราจะเริ่มโค้ด นี่เป็นเพราะข้อความคอมมิตเป็นภาพสะท้อนของขั้นตอนที่เราดำเนินการเพื่อดำเนินงานให้สำเร็จ กล่าวอีกอย่างคือพวกมันเป็นรายการที่ต้องทำของเรา
เมื่อเราเริ่มงาน เราควรคิดก่อนว่าต้องมีขั้นตอนเฉพาะอย่างไรบ้างในการดำเนินภารกิจให้สำเร็จ ขั้นตอนเหล่านี้เป็นรายการที่ต้องทำของเราและในขณะเดียวกัน ก็เป็นข้อความคอมมิตในอนาคตของเรา เมื่อเรามีรายการที่ต้องทำนี้ การเปลี่ยนแปลงโค้ดแต่ละรายการมีวัตถุประสงค์ชัดเจน รักษาเรามีสมาธิขณะเขียนโค้ดและป้องกันเราจากการเบี่ยงเบนจากภารกิจ
ที่สำคัญกว่านั้น วิธีนี้สามารถปรับปรุงประสิทธิภาพของเราได้อย่างมาก เมื่อเราทำขั้นตอนใดขั้นตอนหนึ่งสำเร็จ ข้อความคอมมิตที่ตรงกับนั้นก็พร้อมใช้งานอยู่แล้ว และเราสามารถใช้มันได้โดยตรง ลดเวลาที่ใช้ในการคิดว่าจะอธิบายการเปลี่ยนแปลงอย่างไร ที่ขณะเดียวกัน เนื่องจากข้อความคอมมิตเหล่านี้เสร็จสมบูรณ์เมื่อเรามีความเข้าใจอย่างครอบคลุมในแต่ละภารกิจ พวกมันมักมีคุณภาพสูงกว่าและมีข้อมูลที่ครบถ้วนมากกว่า
สมมุติว่าคุณต้องการดำเนินการคุณสมบัติการลงทะเบียนผู้ใช้ใหม่ คุณอาจวางแผนขั้นตอนภารกิจของคุณเช่นนี้:
ข้อความคอมมิตที่ตรงกับขั้นตอนภารกิจเหล่านี้อาจเป็นดังนี้:
refactor: enhance existing form component for reusabilityfeat: create user registration formfeat: implement user registration API integrationtest: add unit tests for user registrationdocs: update documentation for user registration featureด้วยวิธีนี้ คุณมีขั้นตอนภารกิจที่ชัดเจนและข้อความคอมมิตที่กระชับตรงกันก่อนที่คุณจะเริ่มเขียนโค้ด ข้อความคอมมิตเหล่านี้เป็นจริงๆ แล้วคือรายการที่ต้องทำของคุณ ไกด์คุณตลอดกระบวนการดำเนินการคุณสมบัติ
เมื่อคุณทำแต่ละขั้นตอนสำเร็จ คุณสามารถใช้ข้อความคอมมิตที่ตรงกันเพื่อคอมมิตโค้ดของคุณ สิ่งนี้ไม่เพียงช่วยให้คุณจัดระเบียบและดำเนินการภารกิจได้ดีขึ้น แต่ยังทำให้แน่ใจว่าคอมมิตแต่ละรายการมุ่งเน้นไปที่ขั้นตอนเฉพาะ ทำให้กระบวนการพัฒนาทั้งหมดชัดเจนและจัดการง่ายขึ้น ถ้าคุณต้องการปรับข้อความคอมมิตเล็กน้อยในระหว่างการเขียนโค้ดจริง คุณสามารถปรับเปลี่ยนเล็กน้อยเพื่ออธิบายการเปลี่ยนแปลงที่เกิดขึ้นจริงได้อย่างแม่นยำมากขึ้น
เมื่อเราพัฒนาทัศนคติการพัฒนาที่ถูกต้อง การใช้คอมมิตแบบธรรมดากลายเป็นธรรมชาติ ในขั้นตอนนี้ คุณจะพบว่าการเลือกคำนำหน้าประเภทที่เหมาะสม (เช่น feat, fix, refactor, ฯลฯ) กลายเป็นเรื่องง่าย เพราะข้อความคอมมิตของคุณได้สะท้อนขั้นตอนภารกิจของคุณอย่างชัดเจนแล้ว
ถ้าคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการใช้คอมมิตแบบธรรมดา มีบทความที่ยอดเยี่ยมมากมายออนไลน์ แต่จำไว้ว่า มาตรฐานเหล่านี้สามารถมีประสิทธิภาพได้จริงๆ ก็ต่อเมื่อมันถูกสร้างขึ้นบนพื้นฐานของทัศนคติการพัฒนาที่ถูกต้อง
การเขียนข้อความคอมมิตที่ดีไม่ใช่แค่การทำตามรูปแบบใดรูปแบบหนึ่ง มันต้องให้เรามีการคิดที่ชัดเจนระหว่างกระบวนการพัฒนา ชัดเจนวัตถุประสงค์ของแต่ละการเปลี่ยนแปลง และคิดว่าควรอธิบายงานของเราอย่างไรก่อนที่เราจะเริ่มเขียนโค้ด
คอมมิตแบบธรรมดาเป็นเครื่องมือที่มีประโยชน์จริงๆ แต่สามารถมีผลสูงสุดได้เมื่อรวมกับทัศนคติการพัฒนาที่ถูกต้อง ด้วยการฝึกฝนสองหลักการ "ทำสิ่งหนึ่งในแต่ละครั้ง" และ "คิดเกี่ยวกับข้อความคอมมิตล่วงหน้า" เราสามารถไม่เพียงแต่ปรับปรุงคุณภาพของข้อความคอมมิต แต่ยังเพิ่มประสิทธิภาพการพัฒนาโดยรวมและคุณภาพของโค้ดอีกด้วย
ฉันหวังว่าบทความนี้จะช่วยให้คุณหวนคิดถึงกระบวนการพัฒนาของคุณและกระตุ้นให้คุณลองใช้วิธีการเหล่านี้ จำไว้ว่าพฤติกรรมการพัฒนาที่ดีนั้นต้องใช้เวลาในการพัฒนา แต่เมื่อมันเกิดขึ้นแล้ว มันจะเพิ่มประสิทธิภาพการทำงานและคุณภาพของโค้ดของคุณได้อย่างมาก