นิ้วกลางของ Chesterton
(arp242.net)- แม้ Chesterton’s fence จะเป็นคำแนะนำว่าอย่าแก้โค้ดส่งเดชหากยังไม่รู้เหตุผลว่าทำไมมันถึงเป็นแบบนั้น แต่ โค้ดและประวัติ commit ที่ไม่ทิ้งเหตุผลไว้ ก็เป็นการโยนภาระแบบเดียวกันให้ผู้พัฒนาคนถัดไป
- เนื้อหา commit ตลอด 13 ปีที่ผ่านมา ของรีโพซิทอรีนี้มีเพียง 295 บรรทัดตามเกณฑ์ของคำสั่ง และถ้าตัดเนื้อหาที่เกี่ยวกับ dependabot, revert, typo ออก ก็จะเหลือ 167 บรรทัด
- ชื่อ commit เองก็แทบไม่ให้บริบท แม้กับการเปลี่ยนแปลงใหญ่ เช่น “fix page A” และแทบไม่มีเอกสารแยกหรือคอมเมนต์ในโค้ด ทำให้ ตามรอยเหตุผลของการเปลี่ยนแปลงได้ยาก
- ในโค้ดยังมีทั้งรีแฟกเตอร์ที่ทำไม่เสร็จ, ซากของฟีเจอร์ที่ถูกลบ, ฟีเจอร์ที่เพิ่มเข้ามาแต่ไม่ได้เชื่อมต่อหรือถูกใช้งาน, และฟีเจอร์ที่ดูเหมือนไม่มีใครใช้
- ข้อความ commit และเอกสารควรทิ้งข้อมูลขั้นต่ำไว้ว่า “เปลี่ยนอะไร, ทำไมถึงเปลี่ยน, และทำไมวิธีแก้นี้จึงดี” เพราะถ้าไม่ทิ้งอะไรไว้เลย ต้นทุนจะตกไปอยู่กับนักพัฒนาที่มาทีหลัง
ภาระที่โค้ดไร้เหตุผลทิ้งไว้
- Chesterton’s fence เป็นอุปมาว่า ถ้ายังไม่เข้าใจว่าทำไมบางอย่างถึงถูกทำไว้แบบนั้น ก็ไม่ควรไปเปลี่ยนมันส่งเดช
- ในการเขียนโปรแกรมก็เช่นกัน อาจมีกรณีที่ไป “แก้” โค้ดที่ดูแปลก แล้วภายหลังค่อยพบว่าความแปลกนั้นมีเหตุผลของมัน
- แต่กรณีนี้เผยให้เห็นปัญหาอีกด้านหนึ่ง
- มีโค้ดและการตัดสินใจแปลก ๆ มากมาย แต่ไม่มีบันทึกที่บอกได้ว่าทำไมถึงเป็นเช่นนั้น
- นักพัฒนาคนก่อน ๆ ก็ออกไปหมดแล้ว จึงไม่มีใครให้ถาม
- ประวัติ commit ของรีโพซิทอรีนี้แทบไม่ให้บริบทที่ใช้งานได้จริงเลย
- เนื้อหา commit ตลอด 13 ปีที่ผ่านมา รวมแล้วมี 295 บรรทัด
- หากตัดเนื้อหา commit ของ dependabot, “revert commit”, “fix typo” ออกด้วยมือ จะเหลือ 167 บรรทัด
- เฉลี่ยแล้วประมาณเดือนละหนึ่งบรรทัด
- ชื่อ commit ส่วนใหญ่ก็ยังไม่เพียงพอจะอธิบายการเปลี่ยนแปลงใหญ่ ๆ เช่น “fix page A”
- ไม่มีเอกสารแยก และแทบไม่มีคอมเมนต์ในโค้ด
- สถานการณ์แบบนี้ใกล้เคียงกับ Chesterton’s middle finger มากกว่า คือเหมือนจะบอกว่า “เราทำอะไรแปลก ๆ ไว้เยอะ แต่จะไม่บอกว่าทำไม”
บันทึกขั้นต่ำที่นักพัฒนาควรทิ้งไว้
- ในโค้ดเบสยังมีโค้ดค้างคาและโค้ดตกค้างหลายประเภท
- รีแฟกเตอร์ ที่ทำไม่เสร็จ
- ซากของฟีเจอร์ที่ถูกลบ
- ฟีเจอร์ที่ถูกเพิ่มเข้ามาแต่ไม่ได้เชื่อมต่อหรือใช้งาน
- ฟีเจอร์ที่ดูเหมือนไม่มีใครใช้งาน
- โดยรวมแล้วยังดูเหมือนมีปัญหา Chesterton’s gap หนักพอสมควร
- คือสถานการณ์แบบ “ยังไม่มีรั้ว งั้นเรามาสร้างกัน” โดยไม่ถามก่อนว่าจริง ๆ แล้วจำเป็นต้องมีรั้วหรือไม่
- การเขียนให้ดีเป็นเรื่องยากก็จริง แต่การทิ้งคำอธิบายระดับที่พอใช้งานได้นั้นไม่ใช่เรื่องยาก
- บันทึกการเปลี่ยนแปลงควรตอบคำถามพื้นฐาน 3 ข้อ
- เปลี่ยนอะไร
- ทำไมถึงเปลี่ยน
- ทำไมวิธีแก้นี้จึงเป็นทางออกที่ดี
- บางครั้งแค่ “Implement new feature X” ก็อาจเพียงพอ แต่ส่วนใหญ่แล้วมักมีเรื่องให้เขียนต่อว่าฟีเจอร์นั้นถูกเพิ่มเข้ามาทำไม หรือทำไมถึงเพิ่มด้วยวิธีนั้น
- สำหรับการแก้บั๊ก การรีแฟกเตอร์ หรือการเปลี่ยนแปลงที่มีสาระสำคัญ โดยทั่วไปมักเขียนอธิบายสิ่งที่เปลี่ยนและเหตุผลได้อย่างน้อยสักหนึ่งหรือสองย่อหน้า
- สิ่งเหล่านี้ไม่ใช่เรื่องเลือกทำหรือไม่ทำ แต่เป็นส่วนหนึ่งของ งานของนักพัฒนาซอฟต์แวร์
- ไม่จำเป็นต้องเขียนสละสลวย
- ไม่จำเป็นต้องเป็นภาษาอังกฤษที่สมบูรณ์แบบ
- ไม่จำเป็นต้องเป็นบทความยืดยาว
- ต่อให้ตกหล่นบางส่วน ก็ยังดีกว่าไม่เหลืออะไรไว้เลยมาก
- หากไม่ทิ้งอะไรไว้เลย ก็เท่ากับโยนปัญหาให้ทุกคนที่ตามมาภายหลัง
1 ความคิดเห็น
ความคิดเห็นจาก Lobste.rs
บางครั้งในตอนนั้นยังไม่ชัดเจนว่าอะไรจะกลายเป็นสิ่งสำคัญในภายหลัง ถ้ามีการบันทึกกระบวนการทั้งหมดที่นำไปสู่การคอมมิตไว้แบบเปิดเผยก็จะช่วยได้มาก แต่ผู้เกี่ยวข้องทุกคนมักมีบริบทอยู่ในหัวเยอะมากอยู่แล้ว จึงมีบางอย่างที่ถูกมองว่า “ชัดเจนเกินไป” จนตกหล่นไป
ถ้าไม่มีการบันทึกการอภิปรายไว้ การขุดค้นกระบวนการตัดสินใจก็จะยากขึ้นมาก ราวกับทำ โบราณคดีดิจิทัล สุดท้ายแล้วบางครั้งเราต้องรับมือกับสิ่งที่ไม่รู้ว่าเหตุใด “รั้ว” นี้ถึงตั้งอยู่ตรงนั้น และต้องประเมินมันจากบริบทปัจจุบันกับความรู้ระบบของผู้คนในตอนนี้
ถ้ามีคนที่อยู่กับโปรเจกต์มานานพอจนได้ทั้งความเข้าใจภาพรวมของระบบและสัญชาตญาณ ก็จะช่วยได้มาก องค์กรที่มองนักพัฒนาเป็นเหมือน เฟืองที่เปลี่ยนแทนกันได้ จะไม่มีใครอยู่นานพอ และสุดท้ายก็ทำผิดซ้ำแบบเดิมพร้อมกับประดิษฐ์วงล้อขึ้นมาใหม่เรื่อย ๆ
เมื่อคนถัดไปมาดูโค้ด ก็จะไม่ถึงกับมีโอกาสเป็นศูนย์ที่จะเข้าใจว่าทำไมมันถึงเป็นแบบนี้
ฉันไม่เคยเข้าใจนักพัฒนาที่เขียนข้อความคอมมิตแค่ว่า “fix” หรือ “WIP commit” อะไรทำนองนั้นเลย น่าจะเป็นเพราะไม่เคยทำ โบราณคดีโค้ด แบบจริงจัง หรือไม่ก็ไม่เคยคิดด้วยซ้ำว่ามันเป็นสิ่งที่ทำได้
ฉันพยายามพลาดไปในทางที่ให้ข้อมูลมากเกินไปเสมอ อย่างน้อยเวลามีอะไรพังขึ้นมา ตัวฉันในอนาคต คนที่มารับช่วงต่อ หรือคนที่น่าสงสารที่ถูกตามตัวมาตอนระบบล่ม ก็ยังพอมีโอกาสจะหาสาเหตุได้ว่าทำไมบางอย่างถึงพัง
ในกรณีนั้นจะติดตามในหัวได้ยากว่ามีอะไรเปลี่ยนไปหลังแต่ละจุดเช็กพอยต์ หรือจะใส่คำอธิบายที่มีความหมายก็ยาก และมันจะใกล้เคียงกับการใช้คอมมิตเหมือนปุ่ม “บันทึก” ในวิดีโอเกม มากกว่าจะใช้เป็นวิธีแบ่งงานออกเป็นหน่วยที่นิยามชัดเจน
ในทางกลับกัน ถ้าคุณสร้างคอมมิตใหญ่จากผลของการรีแฟกเตอร์ API ครั้งใหญ่ คำอธิบายที่สั้นกว่าระดับเอกสารออกแบบก็มักจะไม่เพียงพอ และถ้าไม่ได้จะเขียนถึงขนาดนั้น ความหมายของข้อความยาว ๆ ก็อาจคลุมเครือไปด้วย เพียงแต่บางคนกลับเอาเรื่องนี้ไปเป็นเหมือนเหรียญเชิดชู แล้วเริ่มเขียนใน release note แค่ว่า “แก้บั๊กและปรับปรุงฟีเจอร์” ซึ่งเป็นข้อสรุปที่ผิดอย่างชัดเจน
นักพัฒนาหลายคนมักลืมอยู่บ่อย ๆ ว่า “คนอื่น” ที่ต้องมาอ่านและทำความเข้าใจเบื้องหลังของการเปลี่ยนแปลงนั้น อาจเป็นตัวเองในอนาคตก็ได้ คงคุ้นกันดีเวลานั่งเกาหัวดูบล็อกโค้ดแล้วสั่ง
git blameก่อนจะเจอชื่อตัวเองจ้องกลับมาข้อความคอมมิตที่ดีช่วยย่นเวลาการไปรื้อดู issue, อีเมล และแชตล็อกเพื่อหาคำตอบว่า ทำไม ลงไปได้หลายชั่วโมง บางครั้งถึงขั้นหลายวัน นับครั้งไม่ถ้วน แม้แต่ในกรณีที่ฉันควรจะตอบได้ทันทีแบบไม่ต้องคิดก็ยังเป็นอย่างนั้น
ควรใจดีกับตัวเองในอนาคต เททุกอย่างที่คุณรู้ สิ่งที่คุณคิด และสิ่งที่เคยถกเถียงกันไว้ลงใน git log ไปเลย ไม่มีทางชัดเจนหรอกว่าอีก 5 ปี อะไรจะยังคงเป็นเรื่องที่ “เห็นได้ชัดอยู่แล้ว”
git blameอย่างน้อยสำหรับเรื่องที่มีเหตุผลรองรับ ฉันกลับไม่ค่อยเจอเท่าไร เรื่องที่ดูสุ่มเหมือนพฤติกรรมประหลาดของคนอื่นนั้น ถ้าไม่เห็นกระบวนการฝั่งนั้นก็มักยากจะอธิบายให้เป็นประโยชน์ แต่ถ้าเป็นสิ่งที่ครั้งหนึ่งเคยมีเหตุผลสำหรับฉัน พอกลับมาอ่านอีกทีก็มักจะเข้าใจขึ้นมาใหม่ได้วิธีเรียนรู้ของฉันดูจะคล้ายกับ การทับถมเป็นชั้นลาวา มากกว่า ตั้งแต่จบมัธยมมา ฉันไม่ได้เปลี่ยนไปแบบพลิกหน้ามือเป็นหลังมือ แต่ค่อย ๆ เติมสิ่งที่รู้และวิธีใช้มันเพิ่มเข้าไปเรื่อย ๆ
เมื่อไม่นานมานี้มีคนหนึ่งอ้างว่าถ้าข้อความคอมมิตยาวเกินหนึ่งประโยค โดยมากก็มักเป็นการเสียเวลาเปล่า ฉันอยากโต้แย้งอย่างหนัก แต่กลับอธิบายเหตุผลคัดค้านนั้นได้ไม่เก่งอย่างที่คิด
คำถามหนึ่งคือ ข้อมูลแบบไหนควรอยู่ใน ข้อความคอมมิต และข้อมูลแบบไหนควรอยู่ในคอมเมนต์แบบอินไลน์, ADR หรือเอกสารแบบยาวอื่น ๆ
ฉันยังคงพยายามเขียนข้อความคอมมิตที่ดีอยู่ แต่ที่ทำงานคงหมดหวังไปแล้ว และแม้แต่ในโปรเจกต์เล่นส่วนตัวก็ยังทำได้ไม่สม่ำเสมอ
แต่โค้ดสุดท้ายก็ควรเข้าใจได้โดยไม่ต้องอ่านข้อความคอมมิต หากมีส่วนใดในโค้ดใหม่ที่ต้องมีเหตุผลกำกับ สิ่งนั้นควรอยู่ในคอมเมนต์
พูดอีกแบบคือ ข้อความคอมมิตอธิบายว่าทำไมเราจึงทำการเปลี่ยนแปลงนี้ ตอนนี้ ส่วนคอมเมนต์อธิบายว่าทำไมโค้ด ณ จุดที่การเปลี่ยนแปลงเสร็จสิ้นแล้วจึงอยู่ในสภาพนั้น
การเปลี่ยนแปลงขนาดใหญ่ โดยเฉพาะฟีเจอร์ใหม่ ควรมีเอกสารการออกแบบอยู่ที่ไหนสักแห่ง อาจเป็นเอกสารจริงในรีโพซิทอรีถ้าต้องการการรีวิว หรืออาจอยู่ใน issue tracker ก็ได้
ข้อความคอมมิตควรอ้างถึงเอกสารนั้น และอาจต้องอธิบายรายละเอียดที่เกิดขึ้นระหว่างการถ่ายทอดดีไซน์ลงมาเป็นโค้ดด้วย ถ้าเป็นไปได้ก็ควรใส่บทคัดย่อสั้น ๆ ของเอกสารการออกแบบไว้ด้วย เรื่องนี้สำคัญเป็นพิเศษเมื่อมีผู้รีวิวที่เป็นไปได้หลายคน เพราะมันช่วยส่งสัญญาณว่าใครควรสนใจมากที่สุด และช่วยจับกรณีที่คนซึ่งควรให้ฟีดแบ็กตั้งแต่ขั้นออกแบบหลุดไป
git logหรือjj logแต่เกือบตลอดจะเห็นผ่าน การแสดงคอมเมนต์ระดับบรรทัดบรรทัดหัวเรื่องมีประโยชน์มากอย่างกว้าง ๆ สำหรับตัดสินว่าควรขุดลึกต่อหรือไม่ ถ้าในเนื้อความมีข้อมูลว่าทำไมการเปลี่ยนแปลงนี้จึงเกิดขึ้น ก็จะช่วยมากเมื่อเหตุผลนั้นไม่ได้ชัดเจนโดยสัญชาตญาณ
ตัวอย่างเช่น ต่อให้มีโค้ดเพิ่มเข้ามาค่อนข้างมาก หลายครั้งแค่ “admin: add impersonation” ก็เพียงพอแล้ว แต่ถ้าเป็น “auth: shorten JWT timeouts” ฉันก็อยากเห็นสักหนึ่งหรือสองประโยคว่าเหตุใดจึงต้องลดเวลา timeout ลง
ฉันมักมองว่าข้อความคอมมิตแบบยาวมาก ๆ ในทางปฏิบัติค่อนข้างไม่มีประโยชน์ เหตุผลก็ส่วนใหญ่ตรงกับที่บทความชี้ไว้ รูปแบบนั้นน่าจะมาจาก workflow ที่ข้อความคอมมิตทำหน้าที่เป็นคำอธิบาย PR ไปในตัว เช่น workflow แบบอีเมลหรือ Gerrit เป็นต้น ในกรณีนั้นมันก็ไม่ได้เป็นโทษ แต่ก็ยากจะบอกว่าเพิ่มคุณค่าอย่างจำเป็นเสมอไป
ฉันก็อยู่ในสถานการณ์คล้ายกัน ในกลุ่มงานที่กว้างกว่าที่ทำงาน มีแค่ฉันกับอีกคนเดียวที่เขียนข้อความคอมมิตแบบละเอียด
ถึงจะรู้ว่ารั้วถูกสร้างขึ้นมาทำไม ก็อาจไม่รู้ว่าทำไมมันยังอยู่ตรงนั้นในตอนนี้ ต่อให้เป็นคนที่สร้างรั้วแบบ Chesterton เอง ก็อาจไม่รู้ว่าควรรื้อมั้ย
ต้นไม้ความพึ่งพาซึ่งกันและกันที่ตั้งใจไว้ตอนสร้างระบบ เป็นเพียงสับเซตของต้นไม้ความพึ่งพาจริง ณ ช่วงเวลาใดช่วงเวลาหนึ่งเท่านั้น เพราะงั้นต่อให้นักพัฒนาที่สมบูรณ์แบบจะอธิบายได้ทั้งหมดว่าทำไมถึงสร้างรั้วนี้ขึ้นมา ประโยชน์ของข้อมูลนั้นก็มีขีดจำกัด
สิ่งที่พวกเขารู้คือทำไมมันถึงถูกสร้างขึ้น ไม่ใช่คำตอบของคำถามว่า “ถ้าเอารั้วนี้ออก จะมีอะไรพังบ้าง?” ดู https://xkcd.com/1172/ ได้ มี use case ตลก ๆ บางอย่างที่อาจดูว่าไม่สำคัญ แต่การใช้งานที่สมเหตุสมผลซึ่งแม้แต่นักพัฒนาต้นฉบับเองก็ไม่อาจรู้ได้ มีอยู่เสมอ
การรู้ว่าผู้พัฒนาต้นฉบับคิดอะไรอยู่หรือสูบอะไรไปก็ดีอยู่หรอก แต่ข้อมูลนั้นอยู่ตรงกลางระหว่างไม่สมบูรณ์กับไม่เกี่ยวข้อง
ยกตัวอย่างสมมติว่า เดิมทีรั้วแบบ Chesterton ถูกตั้งขึ้นเพื่อกันเด็ก ๆ ออกจากแอ่งน้ำ ตอนที่ทั้งสองฝั่งยังเป็นไร่อยู่ แต่ตอนนี้มีทางหลวงเกิดขึ้นแล้ว และรั้วนั้นอาจกลายเป็นสิ่งเดียวที่บังเอิญช่วยป้องกันการชนกันระหว่างกวางกับรถ ซึ่งอาจทำให้สัตว์และคนตายจำนวนมาก
ไม่มีใครรู้ข้อเท็จจริงนี้ ไม่เพียงแต่ไม่เคยทดสอบการมีทางหลวงโดยไม่มีรั้ว แต่สภาพนั้นไม่เคยมีอยู่จริงด้วย และทั้งผู้สร้างทางหลวงกับกรมทรัพยากรธรรมชาติก็ไม่รู้ว่าทำไมถนนเส้นนั้นถึงมี roadkill น้อย ผ่านไปอีกหลายปี ถ้าพื้นที่ไร่ทั้งหมดกลายเป็นหมู่บ้านจัดสรรและไม่ใช่เส้นทางอพยพหลักของสัตว์อีกต่อไป รั้วนี้ก็อาจหมดประโยชน์ หรืออาจไม่ก็ได้
ถ้าสิ่งนี้ฟังดูฝืน ๆ หรือรู้สึกว่าไม่เกี่ยวกับตัวเอง ก็ขออิจฉา จากประสบการณ์ของฉัน นอกจากบริษัทที่มีขนาดระดับหนึ่งและไม่ได้เก่ามาก ส่วนใหญ่แล้วงานก็มักเป็นแบบนี้
ความจริงคือ ทุกสิ่งที่เราทำเป็นส่วนหนึ่งของระบบนิเวศ และพึ่งพาสิ่งต่าง ๆ ที่เราไม่เคยตกลงกันอย่างชัดเจนว่าจะมีปฏิสัมพันธ์ด้วย ทั้งยังถูกสิ่งเหล่านั้นพึ่งพาอยู่ด้วย เราอาจลดขอบเขตของ API และไม่ให้รายละเอียด implementation ทั้งหมดกลายเป็นธุระของทีมข้างเคียงได้ แต่ การเชื่อมโยงกันโดยไม่ตั้งใจ เป็นกฎของจักรวาลที่เลี่ยงไม่ได้พอ ๆ กับการเพิ่มขึ้นของเอนโทรปี
สำหรับบางคน สิ่งนี้อาจฟังดูเป็นแนวคิดแบบสิ้นหวังและยอมแพ้ อาจบอกว่าเราควรสู้กับเอนโทรปีไม่ใช่หรือ แต่ฉันคิดว่าการใช้เวลาและการลงทุนที่คุ้มค่าที่สุด มาจากการยอมรับว่านี่ไม่ใช่สิ่งที่ต้องสู้กับมันโดยพื้นฐาน แต่เป็นสิ่งที่ต้อง จัดการ
ถ้าคิดไปเองว่าเรารู้สถานะของโลกได้ตลอดเวลา ก็เท่ากับจองความล้มเหลวและการโทษตัวเองเอาไว้ล่วงหน้า เหมือนกับที่ uptime 100% ไม่มีอยู่จริง และยังเป็นเป้าหมายที่ผิดสำหรับสิ่งส่วนใหญ่ด้วย
ถ้ายอมรับว่าเรากำลังจัดการกระบวนการที่มีความไม่แน่นอนแบบไฮเซนเบิร์กอยู่ระดับหนึ่ง เราก็จะเลือกได้ว่าจะใช้เวลาจำกัดในแต่ละวันอย่างไรให้เกิดผลลัพธ์ที่ดีกว่า โดยเฉพาะจะทำให้เราหาจุดสมดุลอย่างชาญฉลาดระหว่างการรับมือเชิงป้องกันกับการรับมือภายหลังได้ และเข้าใจด้วยว่าการทำให้การรับมือภายหลังเป็นศูนย์นั้นเป็นไปไม่ได้ และบางครั้งก็ไม่สมเหตุสมผลที่จะทำงานเชิงป้องกันนานหนึ่งปีเพื่อหลีกเลี่ยงการรับมือภายหลังแค่หนึ่งวัน
แล้วเราควรเขียนเอกสารใน commit มากแค่ไหน? ควรมี design doc หรือ test plan กี่ชิ้น? ฉันก็ไม่รู้เหมือนกัน แต่ถ้าจะโยนตัวเลือกหนึ่งออกมา เอกสารทุกชิ้นถูกเขียนขึ้นเพื่อผู้อ่าน
ถ้าคุณเปลี่ยน codebase คนในทีมปัจจุบันรวมถึงคนที่จะเข้ามาใหม่ ควรจะสามารถสืบค้นและเข้าใจได้ว่าการเปลี่ยนแปลงนั้นทำอะไร และทำไปทำไม พร้อมมีคำเตือนบางอย่างเกี่ยวกับพื้นที่เสี่ยงหรือบั๊กที่ค้ำโครงสร้างไว้
สิ่งนี้มักไม่ใช่ร้อยแก้วเยิ่นเย้อ แต่ควรอยู่ในรูปของ pointer ไปยังบริบทเพิ่มเติมที่ช่วยปูฉากให้เข้าใจ เช่น “ขั้นตอนนี้ต้องมีการยืนยันตัวตน เพราะเป็นส่วนหนึ่งของนโยบายที่กำหนดให้ทุกการเปลี่ยนแปลงต้องได้รับการอนุมัติหลายฝ่าย see: go/multiparty”
ระบบที่ไล่ตามความสมบูรณ์แบบขณะต้องรับมือกับมนุษย์นั้นใช้งานลำบากมาก อย่างเช่น DRM, trusted computing, remote attestation, Faro Plague, smart contracts
ระบบที่รีบูตเข้า service mode แล้วแก้ไขได้ดีกว่ามาก เพราะเราไม่อาจคาดเดาได้ว่าซอฟต์แวร์ควรวิวัฒน์ไปทางไหนจึงจะช่วยผู้คนได้จริงในอนาคต ทำให้แก้ไขง่ายย่อมดีกว่าล็อกมันให้แน่นหนา 100%
พวกเราแทบไม่เขียนเนื้อหา commit เลย แต่เขียนหัวข้อกันได้ค่อนข้างดี ถ้านั่นคือเกณฑ์วัด ก็ไม่แน่ใจว่าเป็นเกณฑ์ที่วัดอะไรกันแน่
ใน codebase ขนาดใหญ่ บ่อยครั้งโค้ดที่ชัดเจนกับ test coverage ที่เพียงพอ มีประโยชน์กว่าเอกสารมาก
มีหลายกรณีที่มีการเปลี่ยนแปลงซึ่งสมเหตุสมผลอย่างยิ่ง และเทสต์ก็อัปเดตตามนั้น แต่พอมาดูทีหลังก็ไม่ชัดเจนเลยว่าทำไมการเปลี่ยนนั้นถึงจำเป็น โดยเฉพาะเมื่อบรรทัดที่เปลี่ยนทำให้เกิดพฤติกรรมที่ไม่คาดคิดหรือพฤติกรรมเพิ่มเติมในระบบ production
การ revert ตรง ๆ อาจไม่ใช่ทางเลือกที่ดี และในจุดนี้การมีประวัติเต็มว่าเหตุใดจึงมีการเปลี่ยนแปลงนั้นจะช่วยได้มาก
ฉันเห็นมาหลายครั้งว่าไอเดียนั้นถูกต้อง แต่เกิดผลลัพธ์ที่ไม่คาดคิด ถ้ารู้เจตนา เราก็จะหาการแก้ไขที่ ถูกต้องจริง ๆ ซึ่งทั้งแก้ปัญหาใหม่และยังรักษาเหตุผลเดิมของการเปลี่ยนแปลงไว้ได้
ถ้าจะยืนกรานให้มีแค่ commit บรรทัดเดียว อย่างน้อยก็ใส่เลข ticket ไว้ เพื่อให้ไปอ่านประวัติต่อจากตรงนั้นได้
ฉันหาเงินได้ค่อนข้างดีจากการตระเวนไปยังสถานที่แปลกห่างไกลตลอด 5 ปีเพื่อกู้ codebase แบบนี้ @arp242, ขึ้นราคาเสมอ และนอนโดยเอา https://archive.org/details/working-effectively-with-legacy-code ไว้ใต้หมอน
โชคดีที่เครื่องผลิตของรกจาก AI เขียน ข้อความ commit ยาวมหาศาล ให้เรา อย่างน้อยบางครั้งมันก็เกี่ยวข้องกับการเปลี่ยนจริงอยู่บ้าง ดังนั้นอย่างน้อยเรื่องนั้นก็คงถือว่าแก้ได้แล้ว