โค้ดติดลบ 2,000 บรรทัด
(folklore.org)- ในช่วงต้นปี 1982 ทีมซอฟต์แวร์ Lisa อยู่ภายใต้แรงกดดันที่จะต้องออกซอฟต์แวร์ให้ได้ภายใน 6 เดือน จึงพยายามวัดความคืบหน้าจากจำนวน บรรทัดโค้ด รายสัปดาห์ของวิศวกรแต่ละคน
- Bill Atkinson มองว่าจำนวนบรรทัดไม่สามารถสะท้อนผลิตภาพได้อย่างเหมาะสม และยังขัดกับเป้าหมายในการสร้าง โปรแกรมที่เล็กและเร็ว
- เมื่อนำเอนจินคำนวณพื้นที่ของ QuickDraw มาเขียนใหม่ด้วยอัลกอริทึมที่ง่ายและใช้ได้ทั่วไปมากขึ้น การทำงานเกี่ยวกับพื้นที่จึง เร็วขึ้นเกือบ 6 เท่า และโค้ดก็ ลดลงราว 2,000 บรรทัด
- ในแบบฟอร์มสำหรับผู้บริหารฉบับแรก ตรงช่องที่ถามจำนวนบรรทัดโค้ดที่เขียนในสัปดาห์นั้น Bill เขียนว่า
-2000ทำให้เห็นช่องโหว่ของวิธีวัดนี้อย่างชัดเจน - ไม่กี่สัปดาห์ต่อมา ผู้จัดการก็เลิกขอให้ Bill ส่งแบบฟอร์มดังกล่าว และเรื่องเล่านี้แสดงให้เห็นว่าการบริหารแบบ ยึดจำนวนบรรทัดโค้ดเป็นหลัก อาจมองข้ามการปรับปรุงที่แท้จริงได้
การวัดจำนวนบรรทัดโค้ดของทีม Lisa
- ในช่วงต้นปี 1982 ทีมซอฟต์แวร์ Lisa ต้องการเร่งความเร็วการทำงานเพื่อออกซอฟต์แวร์ภายใน 6 เดือนข้างหน้า
- ผู้จัดการบางคนพยายามติดตามความคืบหน้าจาก จำนวนบรรทัดโค้ด ที่วิศวกรแต่ละคนเขียนได้ในแต่ละสัปดาห์
- วิศวกรได้รับแบบฟอร์มให้ส่งทุกวันศุกร์ และในนั้นมีช่องให้กรอกจำนวนบรรทัดโค้ดที่เขียนในสัปดาห์นั้น
-2000 ของ Bill Atkinson
- Bill Atkinson ผู้สร้าง QuickDraw และนักออกแบบส่วนติดต่อผู้ใช้คนสำคัญ มีบทบาทสำคัญในการพัฒนา Lisa
- Bill มองว่าตัวชี้วัดจำนวนบรรทัดโค้ดไม่สามารถวัดผลิตภาพได้อย่างเหมาะสม
- เขาเชื่อว่าเป้าหมายของซอฟต์แวร์ที่ดีคือการเขียน โปรแกรมที่เล็กและเร็วที่สุดเท่าที่เป็นไปได้
- ตัวชี้วัดที่กระตุ้นให้จำนวนบรรทัดเพิ่มขึ้น อาจผลักดันให้เขียนโค้ดที่หยาบ เทอะทะ และพังง่าย
- ตอนนั้นเขากำลังปรับแต่ง เอนจินคำนวณพื้นที่ ของ QuickDraw
- เขาเขียนเอนจินพื้นที่ขึ้นใหม่ทั้งหมดด้วยอัลกอริทึมที่ง่ายและใช้ได้ทั่วไปมากขึ้น
- หลังการปรับปรุง การทำงานเกี่ยวกับพื้นที่ เร็วขึ้นเกือบ 6 เท่า
- พร้อมกันนั้นโค้ดก็ ลดลงราว 2,000 บรรทัด
- ตอนกรอกแบบฟอร์มสำหรับผู้บริหารครั้งแรก เขามองช่องจำนวนบรรทัดโค้ดอยู่ครู่หนึ่งก่อนจะเขียนว่า
-2000 - แม้จะไม่แน่ชัดว่าผู้จัดการตอบสนองอย่างไร แต่ไม่กี่สัปดาห์ต่อมา Bill ก็ไม่ถูกขอให้ส่งแบบฟอร์มนี้อีกต่อไป
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
นึกถึงกรณี ความขัดแย้งเรื่องจำนวนบรรทัดโค้ด ระหว่าง Microsoft กับ IBM
ในซีรีส์ทีวีของ PBS ที่อ้างอิงจาก Accidental Empires ของ Bob Cringely มีฉากที่ Steve Ballmer อธิบายประสบการณ์ตอนร่วมพัฒนา OS/2 กับ IBM
Microsoft มีท่าทีแบบบริษัทเล็ก ๆ ที่มุ่งทำงานให้เสร็จ ส่วน IBM ว่ากันว่าโฟกัสกับตัวชี้วัดภายใน โดยเฉพาะการวัดผลิตภาพของโปรแกรมเมอร์ด้วย KLoC (จำนวนบรรทัดโค้ดเป็นหน่วยพันบรรทัด)
Ballmer กล่าวว่า “สิ่งที่พวกเขาสนใจก็มีแต่ KLoC, KLoC และ KLoC” และดูเหมือนว่า IBM จะดูปริมาณโค้ดมากกว่าดูว่าโค้ดนั้นดีหรือไม่
https://ubiquity.acm.org/article.cfm?id=1022357
คนที่รู้เรื่องราวดีมอง “การฉลอง” นั้นเหมือนงานศพ
การนับ จำนวนบรรทัดโค้ด เป็นตัวชี้วัดผลิตภาพนั้นโง่มากจริง ๆ
เคยแก้บั๊กอายุ 20 ปีที่แก้ไม่ตกได้ด้วยโค้ดหนึ่งบรรทัด และจำได้ว่าแก้บั๊กอายุ 3 ปีได้ด้วย
order byเพียงอันเดียว แล้วจะวัดผลกระทบของโค้ดหนึ่งบรรทัดได้อย่างไร? จากประสบการณ์ โปรแกรมเมอร์แย่ ๆ มักเขียนโค้ดเยอะกว่ามากเรื่องที่นักพัฒนา Microsoft เขียนโค้ด IBM ยาว 33,000 ตัวอักษรใหม่ให้เหลือ 220 ตัวอักษร[1] ก็ลืมไม่ลง ว่ากันว่าผลคือปริมาณงานของ Microsoft กลายเป็น “ติดลบ” จนเกิดศึกกันขึ้น
[1] https://archive.org/details/bigbluesunmaking00carr/page/4/mode/2up หน้า 101
ตัวอย่างในยุคนี้คือบางบริษัทใช้ “อิทธิพล/ผลกระทบ” หรือการเปิดตัวผลิตภัณฑ์ใหม่เป็นเกณฑ์เลื่อนตำแหน่ง ผลคือมีแนวโน้มจะเกิดผลิตภัณฑ์ล้มเหลวที่ไม่มีใครดูแลต่อจำนวนมาก
ในบรรดานักวิทยาการคอมพิวเตอร์และวิศวกรผู้ยิ่งใหญ่ มีคนที่สร้างโค้ดออกมาในปริมาณมหาศาล และผมเชื่อว่าสิ่งนั้นเชื่อมโยงโดยตรงกับอิทธิพลไม่ทางใดก็ทางหนึ่ง ปัญหาคือทันทีที่จำนวนบรรทัดโค้ดกลายเป็นตัวชี้วัดผลงาน
เมื่อนั้นกฎของ Goodhart ก็จะทำงาน: “เมื่อมาตรวัดกลายเป็นเป้าหมาย มันก็ไม่ใช่มาตรวัดที่ดีอีกต่อไป”
จากมุมมองของตัวชี้วัดผลิตภาพ โค้ดถูกจัดเป็นสินทรัพย์ แต่มุมมองที่ใกล้ความจริงกว่าคือฟีเจอร์เป็นสินทรัพย์ ส่วนตัวโค้ดเองเป็นหนี้สิน
หัวข้อนี้ถูกยกขึ้นมาบ่อย การถกเถียงก่อนหน้านี้มีดังนี้
https://news.ycombinator.com/item?id=33483165 (2022)
https://news.ycombinator.com/item?id=26387179 (2021)
https://news.ycombinator.com/item?id=10734815 (2015)
https://news.ycombinator.com/item?id=7516671 (2014)
https://news.ycombinator.com/item?id=4040082 (2012)
https://news.ycombinator.com/item?id=1114223 (2010)
https://news.ycombinator.com/item?id=1545452 (2010)
ช่วงต้นอาชีพ เคยปรับแต่ง โปรแกรมภาษา C ที่รับช่วงต่อมาและยาวกว่า 10,000 บรรทัด ให้เหลือน้อยกว่า 500 บรรทัด เป็นโปรแกรม C ที่เรียก SQL ไปยังฐานข้อมูล Sybase
ไม่ใช่เพราะมีข้อคิดลึกซึ้งอะไร แต่เป็นเพราะสมมติฐานง่าย ๆ ว่าคนก่อนหน้าอาจไม่รู้วิธีใช้ฟังก์ชัน หรือไม่รู้วิธีใช้พารามิเตอร์เพื่อใส่ข้อมูลที่เปลี่ยนแปลงได้ลงในคิวรี SQL จริง ๆ แล้วเขาเขียน SQL เดิมซ้ำแบบอินไลน์ทุกครั้ง โดยเปลี่ยนแค่ค่าบางตัว
จึงเขียนโค้ดเรียก SQL ใหม่ให้เป็นการเรียกฟังก์ชัน และส่ง bind variables เป็นพารามิเตอร์ของฟังก์ชัน โค้ดอินไลน์ที่ซ้ำ ๆ ถูกแทนที่ด้วยการรับค่า bind ที่เปลี่ยนไปจากอาร์เรย์ แล้วเรียกฟังก์ชันในลูป
ผลกระทบที่ใหญ่ที่สุดบางครั้งมาจากการตั้ง คำถามง่าย ๆ อย่าง “แล้ว X จะจัดการอย่างไร?” จนทำให้ไม่ต้องสร้างบางอย่างขึ้นมาเลย
ถ้าสิ่งนั้นไม่มีแม้แต่โอกาสจะทำงานได้อย่างถูกต้อง ก็เท่ากับประหยัดต้นทุนทั้งหมดของการพยายามสร้างมัน
เรื่องแบบนี้ไม่เพียงวัดด้วยตัวเลขไม่ได้ แต่ยังทำให้มีศัตรูได้ด้วย ถึงอย่างนั้นก็ขอปรบมือให้คนที่กล้าทำแบบนั้น
คนที่มองว่าการเขียนโปรแกรมคล้ายกับการพิมพ์เร็ว มีความคล้ายคลึงกับ LLM ที่น่าสนใจ คือเขียนโค้ดที่ไม่ได้ถูกใช้อย่างดีทั้งหมดขึ้นมาแล้วลบทิ้ง แล้วก็เขียนใหม่แล้วลบทิ้งซ้ำ ๆ
คำขอข้อมูลราวครึ่งหนึ่งที่เข้ามาในแผนกมักมาในทำนองว่า “สำคัญมาก ต้องการเดี๋ยวนี้ และจะทำเงินหรือประหยัดเงินได้มาก” แต่คำตอบที่ชัดเจนคือ “คำนวณจากข้อมูลที่มีอยู่แล้วสิครับ/ค่ะ คุณมีเครื่องคิดเลขกับสเปรดชีตอยู่นี่นา เอาดินสอไหม?”
การหลีกเลี่ยงย่อมดีกว่าการทำให้ระบบรองรับ X กรณีพิเศษที่อาจถูกใช้แค่ครั้งสองครั้งทำให้ระบบบวมขึ้น และไม่มีใครรู้ว่ากรณีพิเศษหรือโปรแกรมแบบนั้นมีอยู่หรือไม่ หรือจริง ๆ แล้วมันทำอะไร ต่อให้เอกสารถูกทำไว้อย่างดี คนก็ไม่ได้ใช้เวลาไปเรียนรู้ว่าทำอะไรได้บ้าง ดังนั้นฟีเจอร์พิเศษส่วนใหญ่แบบนั้นจึงกลายเป็นการเสียเวลาในทางปฏิบัติ
อาจคิดการทดลองทางความคิดในสถานการณ์ตรงข้ามได้เช่นกัน ถ้าผู้จัดการอ่านบทความนี้แล้วตัดสินใจวัดแบบง่าย ๆ ด้วย จำนวนบรรทัดโค้ดที่ลบไป จะดีขึ้นหรือแย่ลง?
การวัดแบบนี้โดยรวมแทบไม่มีประโยชน์ เว้นแต่ว่าจะมีแนวปฏิบัติในการรีวิวโค้ดที่แข็งแรงโดยทั่วไป ซึ่งตรงข้ามกับสิ่งที่คนแถวนี้อยากเชื่อ แนวปฏิบัติแบบนั้นพบได้น้อย แต่ถ้ามีการรีวิวที่ดี ก็จะจับผลงานต่ำหรือการปั่นตัวชี้วัดได้อยู่แล้ว ทำให้เหตุผลที่จะนำตัวชี้วัดแบบนี้มาใช้ตั้งแต่แรกลดลง
เช่น แนวคิดเก่าแก่ที่ว่าให้กำจัดวิศวกรซอฟต์แวร์และข้อความโค้ดที่เข้าใจยากทั้งหมด แล้วแทนที่ด้วยการให้ผู้จัดการผลิตภัณฑ์วาดไดอะแกรมหรือผังงานพิเศษเพื่อสร้างผลลัพธ์แบบ “low-code” หรือ “no-code”
ถ้านับบรรทัดที่เพิ่มและลบแยกกัน แพตช์
+50,-150จะถูกคำนวณเป็น 200 ΔSLOCนี่ไม่ใช่มาตรวัดผลิตภาพที่ดี โดยเฉพาะเมื่อใช้เดี่ยว ๆ ยิ่งไม่ใช่ แต่ในฐานะตัวชี้วัดแบบคำนวณคร่าว ๆ เพื่อประเมินปริมาณการเปลี่ยนแปลงก็ถือว่าสมเหตุสมผล การที่นักพัฒนาที่มี ΔSLOC สูงจะมีผลิตภาพมากกว่าเพื่อนร่วมงานที่ไม่มี ΔSLOC เลยตลอด 1–2 สัปดาห์หรือไม่นั้น ขึ้นอยู่กับว่าเพื่อนร่วมงานคนนั้นกำลังทำอะไรอยู่ แต่สิ่งที่แน่ชัดคือในช่วงเวลาที่วัด คนแรกกำลังเปลี่ยนโค้ดเบสมากกว่า
ถ้าผลิตภัณฑ์ “เสร็จสมบูรณ์” แล้ว ก็อาจเท่าเดิมหรือดีกว่าได้ แต่ถ้าไม่ใช่ การเปลี่ยนแปลงจำนวนบรรทัดโค้ดเป็นลบก็คงไปไม่ถึงขั้น deploy
แต่ผลิตภัณฑ์ส่วนใหญ่ยังคงวิวัฒนาการต่อไป นั่นจึงเป็นเหตุผลที่เราสามารถอยู่กับโปรเจกต์เดียวกันได้เป็นปี ๆ และการมีส่วนร่วมที่มีแต่การลบ สุดท้ายก็ไม่ได้เพิ่มอะไรเลย
เรื่องจริงคือบางครั้งตอนเริ่มโปรเจกต์ เราไม่รู้แน่ชัดว่าจะไปทางไหน
ระหว่างทำไปก็เข้าใจปัญหาและคำตอบที่ต้องการได้ดีขึ้นมาก แล้วจึงสามารถรื้อส่วนใหญ่ ๆ ออกและแทนที่ด้วยสิ่งที่เล็กกว่าและดีกว่าได้
และอย่าลืมว่าคนเหล่านี้ต้องยัดทุกอย่างลงใน ROM 64KB รวมถึงโค้ด
-2000บรรทัด และยังมี โค้ดแอสเซมบลี ด้วย แรงกดดันให้ทำให้เล็กลงจึงสูงมากก็ยังไม่แน่ชัดว่ามันอยู่ใน ROM จริง ๆ หรืออยู่ในฟลอปปีดิสก์บูตกันแน่ เพิ่มเติมคือ ตาม Wikipedia ROM ของ Lisa มีขนาด 16KB
[1] https://computerhistory.org/blog/the-lisa-apples-most-influential-failure/
[2] https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/
คือ Bill Atkinson ผู้โด่งดังจาก Atkinson Dither https://beyondloom.com/blog/dither.html
ในกระบวนการนั้น เขาต้องคิดค้นวิธีใหม่ ๆ ที่อินเทอร์เฟซผู้ใช้จะทำงาน และวิธีเขียนซอฟต์แวร์เพื่อแก้โจทย์เหล่านั้นอย่างต่อเนื่อง เขาปรับให้เหมาะสมทั้งเพื่อให้ “รันได้เร็วบนฮาร์ดแวร์ Mac” และ “มอบประสบการณ์ผู้ใช้ที่ยอดเยี่ยม” ไปพร้อมกัน และการผสานกันนั้นก็ทิ้งร่องรอยของเขาไว้ในสุนทรียะโดยรวมของ Mac ขาวดำยุคเก่า สไตล์ dithering นั้นก็เป็นอีกตัวอย่างหนึ่งของการผสาน อัจฉริยภาพเชิงอัลกอริทึม เข้ากับเซนส์ด้านความงาม
เซนส์แบบนี้ยังเห็นได้ในสิ่งอย่างกรอบเลือกแบบ “marching ants” (https://en.wikipedia.org/wiki/Marching_ants) ด้วย เช่นเดียวกับฟีดแบ็กจำนวนมากใน UI ของ Mac คลาสสิกที่แสดงด้วยการกลับค่าสีพิกเซล ไม่ว่าจะเป็นการเลือกข้อความ การไฮไลต์เมนู ลักษณะที่ปุ่มแสดงผลขณะกดปุ่มเมาส์ หรือเส้นขอบตอนลากหน้าต่าง และการวาดทับด้วยโหมด XOR ก็เป็นวิธีที่เหมาะมากในการสร้างเอฟเฟกต์เหล่านี้
วิธีที่ QuickDraw ผสานเครื่องมือเหล่านี้เข้าด้วยกัน นำไปสู่บทสนทนาอันโด่งดังเรื่องสี่เหลี่ยมมุมมนกับ Steve Jobs (https://www.folklore.org/Round_Rects_Are_Everywhere.html) ซึ่งท้ายที่สุดทำให้ใน QuickDraw สามารถวาดสี่เหลี่ยมมุมมนได้ง่ายพอ ๆ กับสี่เหลี่ยมธรรมดา และทำให้สี่เหลี่ยมมุมมนปรากฏไปทั่วระบบปฏิบัติการ
ความสำเร็จของ UI บน Mac ไม่ได้เป็นเพียงเพราะมันดูดีเท่านั้น ส่วนสำคัญมากมาจากการที่ Bill Atkinson สร้างชุดเครื่องมือเล็ก ๆ อันชาญฉลาดที่ทำให้การสร้างสิ่งที่ดูดีทำได้ง่าย
ไอคอนยอดเยี่ยมของ Susan Kare ก็คงไม่ถูกจดจำด้วยความรักเช่นนั้น หาก Bill ไม่ได้สร้างเครื่องมือที่ทำให้สามารถใส่บิตแมปมาสก์ขนาด 32x32 พิกเซลลงใน UI ได้ง่าย และกลับสีเมื่อคลิกได้
บทเรียนคือ ต่อให้ฉลาดเท่า Einstein สุดท้ายก็ยังเป็น พนักงาน และในฐานะพนักงานก็ต้องทำสิ่งที่ควรทำ
ผมไม่เคยเข้าใจเลยว่าทำไมเวลาผู้คนพูดถึงจำนวนบรรทัดโค้ดที่เขียน จึงมักคำนวณเป็น “บรรทัดที่เพิ่ม - บรรทัดที่ลบ” เสมอ
ต่อให้ผม วิ่ง 10 กม. แล้วกลับมาที่จุดเริ่มต้น ก็ไม่ได้แปลว่าผมวิ่งไป 0 กม.
เช่น เปลี่ยนรูปแบบ
if cond { ... return; } ...ให้เป็นif cond { ... return; } else { .... }แต่คำอธิบายนั้นก็ไม่ได้ครอบคลุมทั้งหมด