- ปี 2007, โค้ด 2000 บรรทัด

 (folklore.org)
1 คะแนน โดย GN⁺ 2024-03-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

  • ช่วงต้นปี 1982 ทีมซอฟต์แวร์ของ Lisa กำลังทุ่มเทกับงานช่วงสุดท้ายเพื่อออกซอฟต์แวร์ภายใน 6 เดือนข้างหน้า

  • ผู้จัดการบางคนคิดว่าการติดตามปริมาณโค้ดที่วิศวกรแต่ละคนเขียนในแต่ละสัปดาห์เป็นความคิดที่ดี จึงทำแบบฟอร์มที่ต้องส่งทุกวันศุกร์ โดยในแบบฟอร์มนั้นมีช่องให้กรอกจำนวนบรรทัดโค้ดที่เขียนในสัปดาห์นั้น

  • Bill Atkinson ผู้เขียน Quickdraw และผู้ออกแบบส่วนติดต่อผู้ใช้หลัก มองว่าการนับจำนวนบรรทัดโค้ดเป็นวิธีวัดผลิตภาพซอฟต์แวร์ที่ไร้สาระ เพราะมันเพียงแต่ส่งเสริมให้เขียนโค้ดที่รก พองเกินจริง และมีข้อผิดพลาด

  • Atkinson เพิ่งทำงานเพื่อปรับแต่งกลไกคำนวณ region ของ Quickdraw และได้เขียน region engine ใหม่ทั้งหมดโดยใช้อัลกอริทึมที่เรียบง่ายและทั่วไปกว่า ซึ่งหลังจากปรับจูนเล็กน้อยแล้วทำให้การทำงานเกี่ยวกับ region เร็วขึ้นเกือบ 6 เท่า

  • ผลข้างเคียงของการเขียนใหม่นี้คือสามารถลดโค้ดลงได้ราว 2000 บรรทัด

  • ในช่วงสุดท้ายของงานปรับแต่ง ถึงเวลาที่เขาต้องกรอกแบบฟอร์มของฝ่ายบริหารเป็นครั้งแรก และเมื่อมาถึงช่องจำนวนบรรทัดโค้ด เขาหยุดคิดอยู่ครู่หนึ่งก่อนจะใส่ตัวเลข -2000

  • ไม่แน่ชัดว่าผู้จัดการตอบสนองอย่างไร แต่หลังจากผ่านไปอีกไม่กี่สัปดาห์ พวกเขาก็เลิกขอให้ Atkinson กรอกแบบฟอร์ม และเขาก็ยินดีทำตาม

ความเห็นของ GN⁺

  • บทความนี้มอบบทเรียนสำคัญว่า ในการพัฒนาซอฟต์แวร์ ปริมาณโค้ดไม่ได้สะท้อนผลิตภาพที่แท้จริง การวัดผลงานด้วยจำนวนบรรทัดโค้ดไม่เพียงไม่มีประสิทธิภาพ แต่บางครั้งยังให้ผลตรงข้ามอีกด้วย
  • ตัวอย่างของ Bill Atkinson เน้นย้ำถึงความสำคัญของการปรับแต่งซอฟต์แวร์ การได้ประสิทธิภาพที่เร็วขึ้นด้วยโค้ดที่น้อยลงเป็นหนึ่งในหลักการสำคัญของวิศวกรรมซอฟต์แวร์
  • เรื่องนี้ช่วยให้เข้าใจว่าทำไมแนวปฏิบัติการพัฒนาสมัยใหม่ โดยเฉพาะแนวทางอย่าง Agile และการทำ CI/CD อย่างต่อเนื่อง จึงมีความสำคัญ เพราะแนวทางเหล่านี้ให้คุณค่ากับคุณภาพ ความสามารถในการบำรุงรักษา และประสบการณ์ผู้ใช้ มากกว่าปริมาณโค้ด
  • ในอุตสาหกรรมมีการใช้เครื่องมือและเมตริกหลากหลายเพื่อวัดและปรับปรุงคุณภาพโค้ด เช่น เครื่องมือวิเคราะห์โค้ดแบบสถิต กระบวนการรีวิวโค้ด และการติดตาม test coverage
  • บทความนี้เตือนนักพัฒนาว่า การโฟกัสที่คุณภาพของโค้ด หลีกเลี่ยงความซับซ้อนที่ไม่จำเป็น และปรับประสิทธิภาพให้เหมาะสม มีความสำคัญเพียงใด

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

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

 
GN⁺ 2024-03-25
ความคิดเห็นจาก Hacker News

  • ความขัดแย้งเรื่องจำนวนบรรทัดโค้ดระหว่าง Microsoft และ IBM

    • ในซีรีส์ทีวีของ PBS เรื่อง "Accidental Empires" มีฉากที่ Steve Ballmer อธิบายประสบการณ์ของเขาในช่วงที่ร่วมพัฒนา OS/2 โดย Microsoft ทำงานด้วยแนวคิดแบบบริษัทเล็ก ขณะที่ IBM ให้ความสำคัญกับการใช้จำนวนบรรทัดโค้ดภายในองค์กร (วัดเป็นพันบรรทัด หรือ KLoC) เป็นตัวชี้วัดผลิตภาพของโปรแกรมเมอร์ Ballmer วิจารณ์ว่า IBM สนใจเพียงปริมาณมากกว่าคุณภาพของโค้ด

  • ลิงก์ไปยังการถกเถียงก่อนหน้า

    • การถกเถียงเรื่องการใช้จำนวนบรรทัดโค้ดเป็นตัวชี้วัดผลิตภาพปรากฏขึ้นบ่อยครั้ง โดยมีลิงก์ที่แสดงให้เห็นการอภิปรายหลากหลายตั้งแต่ปี 2010 ถึง 2022

  • การใช้จำนวนบรรทัดโค้ดเป็นตัวชี้วัดผลผลิตเป็นเรื่องโง่อย่างมาก

    • มีการยกประสบการณ์แก้บั๊กอายุ 20 ปีที่แก้ไม่ได้ด้วยโค้ดเพียงบรรทัดเดียว หรือแก้บั๊กอายุ 3 ปีด้วย order by พร้อมตั้งคำถามว่าจะวัดผลกระทบของโค้ดเพียงหนึ่งบรรทัดได้อย่างไร อีกทั้งยังแบ่งปันประสบการณ์ว่ามักเป็นโปรแกรมเมอร์ที่ไม่เก่งซึ่งเขียนโค้ดมากกว่า และยกกรณีที่นักพัฒนาของ Microsoft เขียนโค้ดของ IBM จำนวน 33,000 อักขระใหม่ให้เหลือเพียง 220 อักขระ ส่งผลให้ผลงานของ Microsoft ถูกประเมินในเชิง "ติดลบ"

  • บางครั้งคำถามง่าย ๆ กลับสร้างผลกระทบได้มากที่สุด

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

  • แบ่งปันประสบการณ์การปรับโค้ดให้เหมาะสมในช่วงต้นอาชีพ

    • มีการเล่าประสบการณ์ปรับโปรแกรม C ที่ยาวเกิน 10,000 บรรทัดให้เหลือน้อยกว่า 500 บรรทัด โดยตั้งสมมติฐานง่าย ๆ ว่านักพัฒนาคนก่อนอาจไม่รู้จักการใช้ฟังก์ชันหรือวิธีส่งข้อมูลตัวแปรให้ SQL query จึงพบว่ามีการเขียน SQL คำสั่งเดียวกันแบบ inline ซ้ำ ๆ จากนั้นจึงเขียน SQL call ใหม่เป็นการเรียกฟังก์ชัน และแทนที่โค้ดซ้ำด้วยการดึงค่า bind ที่เปลี่ยนแปลงจากอาร์เรย์แล้วเรียกฟังก์ชันภายในลูป

  • การขาดทิศทางที่ชัดเจนเมื่อเริ่มต้นโครงการ

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

  • การทดลองทางความคิดเกี่ยวกับการใช้การลบโค้ดเป็นตัวชี้วัด

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

  • Atkinson Dither ของ Bill Atkinson

    • มีการให้ลิงก์เกี่ยวกับ Bill Atkinson และเทคนิค Atkinson Dither ของเขา

  • มุมมองต่อจำนวนบรรทัดโค้ด

    • มีการตั้งคำถามต่อการใช้ "จำนวนบรรทัดที่เพิ่ม - จำนวนบรรทัดที่ลบ" ระหว่างการเขียนโค้ด พร้อมแสดงความเห็นว่า เช่นเดียวกับการวิ่ง 10 กม. ที่เริ่มและจบ ณ จุดเดิมซึ่งเราไม่เรียกว่าวิ่ง 0 กม. เรื่องจำนวนบรรทัดโค้ดก็ควรมองเช่นเดียวกัน

  • บทบาทในฐานะพนักงาน

    • มีการแบ่งปันบทเรียนว่า ต่อให้ฉลาดระดับ Einstein ก็ยังเป็นพนักงานอยู่ดี และในฐานะพนักงานก็ยังมีสิ่งที่ต้องทำ