การเขียนโค้ดให้มนุษย์ยากกว่าการเขียนโค้ดให้คอมพิวเตอร์

 (erikbern.com)
1 คะแนน โดย GN⁺ 2024-09-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การเขียนโค้ดสำหรับคอมพิวเตอร์นั้นยาก แต่การเขียนโค้ดสำหรับมนุษย์ยิ่งยากกว่า

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

การเริ่มต้นใช้งานก็คือตัวผลิตภัณฑ์

  • การรับฟังความคิดเห็นของผู้ใช้เป็นเรื่องสำคัญ แต่ความคิดเห็นส่วนใหญ่มักมาจาก power user ที่ใช้ผลิตภัณฑ์อยู่บ่อยครั้ง
  • มี survivorship bias อยู่เสมอ แทบไม่ได้ยินความคิดเห็นจากผู้ใช้ที่ยังเริ่มต้นใช้งานไม่ได้เลย
  • ผลิตภัณฑ์สำหรับผู้บริโภคปรับปรุงกระบวนการ onboarding มานานแล้ว เครื่องมือสำหรับนักพัฒนาก็ควรทำเช่นเดียวกัน
  • ควรมองกระบวนการ onboarding ว่าเป็นส่วนหนึ่งของผลิตภัณฑ์ และลดการตั้งค่าให้น้อยที่สุด เพื่อให้ผู้ใช้เริ่มใช้งานได้ภายในไม่กี่นาที

มนุษย์เรียนรู้จากตัวอย่าง ไม่ใช่จาก 'แนวคิดหลัก'

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

ตกหลุมพรางของความสำเร็จ

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

หลีกเลี่ยงภาวะโอเวอร์โหลดทางแนวคิด

  • การต้องทำความเข้าใจแนวคิดใหม่ก่อให้เกิดแรงเสียดทาน
  • แนวคิดใหม่ 2-3 อย่างยังพอรับได้ แต่การต้องเรียนรู้แนวคิดใหม่ 8 อย่างนั้นหนักเกินไป
  • เฟรมเวิร์กที่ดีควรมอบความสามารถทรงพลังด้วยแนวคิดจำนวนน้อย ตัวอย่างเช่น React มอบความสามารถสูงด้วยแนวคิดง่าย ๆ ไม่กี่อย่าง

หลักการเป็ดเชิงแนวคิด

  • เมื่อต้องแนะนำแนวคิดใหม่ การใช้คำที่ผู้ใช้คุ้นเคยเป็นเรื่องสำคัญ
  • ตัวอย่างเช่น การเรียกสิ่งที่ประเมินค่าใหม่ว่า 'ฟังก์ชัน' จะดีกว่า เพราะช่วยให้ผู้ใช้ใช้ mental model เดิมที่มีอยู่แล้วได้

Programmability

  • ผู้ใช้จะทำงานอย่างสร้างสรรค์กับ codebase
  • เกือบทุกอย่างในเฟรมเวิร์กควรเป็นสิ่งที่ 'เขียนโปรแกรมได้'
  • ควรเปิดให้เรียกใช้งานได้โดยตรงจากโค้ดแทน CLI และเปลี่ยนการตั้งค่าให้เป็น SDK หรือ API

ควรระวังเวทมนตร์ ค่าเริ่มต้น และไวยากรณ์น้ำตาล

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

การเขียนโค้ดสำหรับมนุษย์นั้นยาก

  • สิ่งต่าง ๆ ส่วนใหญ่ควรเป็น immutable
  • ควรหลีกเลี่ยง 'scaffolding' (การสร้างโค้ดอัตโนมัติ)
  • ต้องทำให้ feedback loop เร็วมาก
  • ควรมีขั้นตอนการเลิกใช้หรือทิ้งสิ่งเดิมเพื่อให้ผู้ใช้รับมือได้ง่าย
  • ควรใช้การทดสอบอัตโนมัติกับโค้ดสไนเป็ตในเอกสารและตัวอย่าง

สรุปโดย GN⁺

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

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

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

 
GN⁺ 2024-09-28
ความเห็นจาก Hacker News

  • ผู้คนเรียนรู้กันคนละแบบ

    • ชอบทำความเข้าใจแนวคิดหลักก่อนแล้วค่อยดูตัวอย่าง
    • บทสอนจำนวนมากเป็นแบบจับมือทำเหมือนต่อเลโก้
    • อยากรู้ว่าควรตัดสินใจอย่างไรและเพราะอะไร
    • เมื่อต้องเข้าไปทำความรู้จักไลบรารีหรือเฟรมเวิร์กใหม่ ๆ จะอ่านบทเกริ่นนำก่อน และข้ามตัวอย่างโค้ด "Getting started" ไป
    • ในส่วนขั้นสูงมักมีการอภิปรายเรื่องแนวคิดมากกว่า จึงมักไปสำรวจส่วนนั้นก่อน

  • การเขียนและความสามารถในการเอาใจเขามาใส่ใจเรามีความสำคัญ

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

  • ไม่ใช่ทุกคนที่เรียนรู้จากตัวอย่าง

    • บางคนเรียนรู้จากภาพรวมไปสู่รายละเอียด
    • คนกลุ่มนี้มักถูกมองข้ามในระบบการศึกษา K12

  • โค้ดถูกเขียนขึ้นเพื่อมนุษย์

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

  • อ้างอิงจาก Code Complete

    • "ส่วนเล็ก ๆ ของการเขียนโปรแกรมคือการเขียนโปรแกรมให้คอมพิวเตอร์อ่านได้ ส่วนที่ใหญ่กว่าคือการเขียนให้มนุษย์คนอื่นอ่านได้"

  • การเขียนโค้ดมีไว้เพื่อมนุษย์

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

  • ความเห็นเกี่ยวกับพัฒนาการของ IDE

    • intellisense พื้นฐานดีขึ้นแล้ว แต่แนวคิดของการเขียนโค้ดยังแทบไม่เปลี่ยน
    • การเข้าถึงเครื่องมือและไลบรารีใหม่ ๆ ทำได้ง่ายขึ้น
    • อยากมอบงานเขียนโค้ดให้คอมพิวเตอร์ แล้วโฟกัสกับการสร้างสรรค์
    • ต้องการเครื่องมือที่จัดการรายละเอียดปลีกย่อยของภาษาให้อัตโนมัติ
    • อยากแสดงหลายเมธอดบนหน้าจอพร้อมกัน
    • อยากให้จัดการการแปลงข้อมูลให้อัตโนมัติ

  • โปรโมตบล็อกโพสต์

    • เขียนบล็อกโพสต์ชื่อ "Move Fast & Document Things"
    • แบ่งปันวัฒนธรรมการเขียนโค้ด

  • ความเห็นเกี่ยวกับวิธีเรียนรู้การเขียนโปรแกรม

    • เรียนรู้ด้วยการเขียนโปรแกรมเล็ก ๆ
    • เพราะพื้นฐานความรู้ไม่แน่นพอ จึงไม่สามารถสมัครงานพัฒนาซอฟต์แวร์ที่ดีกว่าได้
    • การเรียนพื้นฐานอยู่เสมอเป็นสิ่งสำคัญ

  • ความสำคัญของตัวอย่างและแนวคิดหลัก

    • ทั้งตัวอย่างและแนวคิดหลักล้วนสำคัญ
    • ต้องมีแนวคิดหลักที่นิยามไว้อย่างชัดเจนและมีเอกสารกำกับอย่างดี
    • คู่มือ "Getting Started" ควรมีตัวอย่างรวมอยู่ด้วย