เหตุผลที่ผมชอบโค้ดทิ้ง (Throwaway Code) มากกว่าเอกสารออกแบบ

 (softwaredoug.com)
3 คะแนน โดย GN⁺ 2024-12-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การพัฒนาซอฟต์แวร์มักไม่สามารถเดินจากเอกสารออกแบบไปสู่ PR ที่สะอาดเรียบร้อยได้โดยตรง เพราะสมมติฐานมักสั่นคลอนระหว่างลงมือเขียนโค้ดจริง ดังนั้นการสำรวจการออกแบบด้วย โค้ดที่จะทิ้ง อาจเร็วกว่า
  • เสนอแนวทางให้สร้างโปรโตไทป์หรือ proof of concept ใน draft PR ที่ไม่ได้ตั้งใจจะ merge รับรีวิวตั้งแต่ต้นเพื่อปรับทิศทางให้ตรงกัน แล้วเก็บไว้เป็นบันทึกของไอเดียการออกแบบ
  • เงื่อนไขตั้งต้นของวิธีนี้คือ วุฒิภาวะขององค์กร ที่กล้าทิ้งวิธีแก้ปัญหาแรกได้ และทัศนคติที่พร้อมลอง implement ปัญหาเดียวกัน 2–3 วิธีถือเป็นสัญญาณของความเป็น senior
  • PR สามารถเป็น เอกสารที่ค้นพบได้ ซึ่งบันทึกเจตนาและการอภิปรายของ implementation ณ ช่วงเวลาหนึ่ง แต่เอกสารออกแบบถ้าไม่อัปเดตบ่อย ๆ ก็มีแนวโน้มกลายเป็น “undead documentation” ที่ไม่ตรงกับความจริง
  • เอกสารออกแบบยังจำเป็นในกรณีที่ต้องรวบรวม feedback จาก stakeholder หลายฝ่าย, ใช้เป็นเอกสาร North Star ระยะยาว, มีไอเดียช่วงต้นที่ยังยากจะลงโค้ด หรืออยู่ในองค์กรที่มีความเสี่ยงว่าโปรโตไทป์จะถูกนำไป deploy ทั้งอย่างนั้น

สำรวจการออกแบบด้วย Throwaway PR

  • กระบวนการพัฒนาในอุดมคติมักใกล้เคียงกับการเขียนเอกสารออกแบบ, merge PR ขนาดเล็กทีละชุดเพื่อปล่อยฟีเจอร์ และรักษา Git history ให้สะอาด
  • แต่ในความเป็นจริง หลังจากเริ่มเขียนโค้ดแล้ว สมมติฐานในเอกสารออกแบบมักเริ่มสั่นคลอน และบ่อยครั้งต้องตัดสินใหม่ว่าจะปล่อยของตามลำดับใด
  • ดังนั้นการสร้างการทดลองโค้ดขนาดใหญ่ก่อน แล้วค่อยวางแผนจริงจากผลลัพธ์นั้น อาจมีประสิทธิภาพกว่า

  • ขั้นตอนที่เสนอ

    • implement โปรโตไทป์หรือ proof of concept ด้วย draft PR ที่ไม่มีเจตนาจะ merge
    • รับมุมมองจากคนอื่นตั้งแต่ต้นเกี่ยวกับ refactoring ขนาดใหญ่หรือแนวทางของฟีเจอร์ เพื่อให้ได้ การปรับทิศทางให้ตรงกัน
    • จัดทำเอกสารแนวทางไว้ภายใน draft PR เพื่อให้เป็นบันทึกเชิงประวัติศาสตร์ของไอเดียการออกแบบ
    • เตรียมพร้อมที่จะทิ้ง draft PR ทั้งหมดให้เร็วที่สุดเท่าที่ทำได้
    • ค่อย ๆ ดึง PR ที่ deploy ได้จริงออกมาจาก draft PR โดยแบ่งเป็น PR สำหรับปล่อยที่สะอาดเรียบร้อยในช่วงเวลาประมาณหนึ่งสัปดาห์
    • ระหว่างแบ่ง PR เป็นลำดับขั้น ค่อย ๆ เติมช่องว่างด้านการทดสอบและความแข็งแรงของโค้ด

  • เงื่อนไขของทีมที่วิธีนี้ต้องการ

    • เงื่อนไขที่สำคัญที่สุดคือ วุฒิภาวะ ที่สามารถทิ้งไอเดียแรกที่ตัวเองเขียนโค้ดขึ้นมาได้
    • ความสบายใจในการลองเขียนโค้ดแก้ปัญหาเดียวกัน 2–3 วิธี ถือเป็นสัญญาณสำคัญของความเป็น senior
    • คุณค่าที่ส่งมอบไม่ได้อยู่ที่จำนวนบรรทัดโค้ดที่เข้า production แต่อยู่ที่ความรู้ที่องค์กรได้รับ
    • หากได้ alignment ตั้งแต่ต้นในส่วนสำคัญ การทำ prototyping ต่อจากนั้นจะไม่จบลงเป็นเพียงความสูญเปล่า
    • ต้องคุ้นเคยกับ codebase มากพอที่จะเชื่อมส่วนสำคัญ ๆ ได้อย่างรวดเร็ว และพนักงาน senior ควรมีระดับความสบายใจเช่นนั้น
    • วิธีนี้ทำได้ไม่ใช่แค่ระดับบุคคล แต่ทำในระดับทีมได้ด้วย

การทำเอกสารผ่าน PR และบทบาทจริงของเอกสารออกแบบ

  • PR เป็นรูปแบบเอกสารอย่างหนึ่งที่มีประโยชน์ต่อ developer
    • เป็นหนึ่งในที่แรก ๆ ที่จะไปค้นหาเมื่ออยากเข้าใจว่าทำไม implementation หนึ่งจึงออกมาเป็นแบบนั้น
    • ไม่ได้อ้างว่าสะท้อนสถานะปัจจุบัน แต่คงอยู่เป็น ผลลัพธ์เชิงประวัติศาสตร์ ที่บันทึกสถานะ ณ ช่วงเวลาหนึ่ง
  • เอกสารออกแบบถ้าไม่ได้ดูแลให้ทันสมัยอยู่เสมอ ก็มีแนวโน้มกลายเป็น undead documentation ที่สะท้อนความจริงที่ล้าสมัย
  • โปรโตไทป์เหมาะกับการ “แสดงให้เห็นมากกว่าพูด” และเมื่อต้องสร้างการเปลี่ยนแปลง โค้ดอาจมีประสิทธิภาพกว่าเอกสาร
  • อย่างไรก็ตาม ในองค์กรที่ไม่มีวินัย โปรโตไทป์มีความเสี่ยงที่จะถูกมองเป็น “คำตอบ” ไม่ใช่ “คำถาม”
    • เจตนาเดิมใกล้เคียงกับคำถามว่า “เราควรทำสิ่งนี้ หรือควรทำอย่างอื่น?”
    • หากองค์กรรับสารเป็น “เราต้องทำสิ่งนี้” ก็จะเกิดปัญหา

  • กรณีที่เอกสารออกแบบยังเหมาะสม

    • มีประโยชน์เมื่อต้องรวบรวมและเก็บ feedback จาก stakeholder หลายฝ่าย, manager และทีมภายนอก
    • การใช้แค่ GitHub อาจจัดการความร่วมมือแบบนั้นได้ยาก
    • หากไอเดียเป็นเชิงแนวคิดและระยะยาวมากจนยังเขียนโค้ดทันทีได้ยาก เอกสาร North Star ในระดับหนึ่งจะช่วยได้
    • มีประโยชน์เมื่อการสื่อสารด้วยข้อความมีประสิทธิภาพกว่าร่างโค้ดแรก หรือเมื่อยัง onboarding กับ codebase ไม่เพียงพอและอยากทิ้งร่างไว้เพื่อรับ feedback
    • หากบริษัทผลักดันให้ deploy ไป production ทันทีโดยไม่มีวินัยในการทิ้งวิธีแก้ปัญหาแรก โปรโตไทป์อาจแข็งตัวกลายเป็น “วิธีแก้ปัญหา” ไปทั้งอย่างนั้น
    • ในองค์กรที่พนักงาน junior โต้แย้งการ implement ไอเดียของ senior developer ได้ยาก อาจต้องมี ผลลัพธ์ที่นุ่มนวลกว่า เพื่อให้ตั้งคำถามได้อย่างปลอดภัยขึ้น

  • กรณีที่เอกสารออกแบบถูกใช้ด้วยเหตุผลที่ไม่ดี

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

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

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

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

  • สิ่งนี้เรียกว่า การทำโปรโตไทป์ และเป็นส่วนที่มีคุณค่าในกระบวนการออกแบบ บางคนเรียกมันว่า “pathfinding”
    สิ่งเหล่านี้ล้วนเป็นข้อมูลป้อนเข้าสู่การออกแบบ แต่การออกแบบในขนาดที่เหมาะสมก็ยังจำเป็นอยู่ มิฉะนั้นก็เป็นแค่การสร้างไปตามแต่สถานการณ์เฉพาะหน้า ต้องนิยามให้ชัดว่าปัญหาที่พยายามแก้คืออะไร และแนวทางแก้คืออะไร บางครั้งเอกสาร 1 หน้าที่ไม่มีการรีวิวอย่างเป็นทางการก็เพียงพอแล้ว บางครั้งก็ต้องใช้เอกสารหลายหน้าที่ผ่านการรีวิวและวนรับฟีดแบ็กนานหลายสัปดาห์
    อย่าลืมว่า: “การเขียนโค้ดหลายสัปดาห์ช่วยประหยัดการวางแผนไม่กี่ชั่วโมงได้” ;)

    • การออกแบบ จำเป็นต้องถูกทำความเข้าใจ แต่ไม่ได้หมายความว่าต้องเป็นเอกสารหรือผลงานถาวรเสมอไป ถ้าต้องการบันทึกถาวร PR ก็เป็นสื่อที่ดีพอได้
      แต่ในความเป็นจริง ฝั่งตรงข้ามมักเกิดขึ้นบ่อยกว่ามาก ผู้คนวางแผนแล้ววางแผนอีก จนแผนนั้นไม่ใช่แค่ไร้ความหมาย แต่เริ่มทำลายประสิทธิภาพการทำงานอย่างจริงจัง
    • เรื่องนี้ใกล้เคียงกับการต้องเลือกเอาอย่างใดอย่างหนึ่ง ต้องมีทั้ง การออกแบบและโปรโตไทป์
      การเขียนโค้ดหลายสัปดาห์อาจช่วยประหยัดการวางแผนไม่กี่ชั่วโมงได้ แต่การวางแผนหลายสัปดาห์ก็อาจสูญเปล่าได้เช่นกัน บนกระดาษ เขียนสิ่งที่ไม่สมเหตุสมผลหรือเป็นไปไม่ได้ได้ง่ายมาก เช่น “ทาสีกองเรือยูนิคอร์นให้เป็นสีที่เศร้าครึ่งหนึ่ง”
      ตามอุดมคติแล้ว การออกแบบกับโปรโตไทป์ควรวิวัฒน์ไปด้วยกัน การทำซ้ำของฝั่งหนึ่งผลักดันการทำซ้ำครั้งถัดไปของอีกฝั่ง พัฒนาเป็นเกลียวเหมือนเกลียวคู่ของ DNA ข้อดีใหญ่เมื่อเอนเอียงไปทางการสร้างโปรโตไทป์คือ เมื่อจบหนึ่งรอบ จะเหลือซอฟต์แวร์ที่ทำอะไรบางอย่างได้จริง แต่เมื่อจบรอบการออกแบบ มักแทบไม่เหลือสิ่งที่จับต้องได้
    • ไม่มีเหตุผลอะไรที่ทำทั้งสองอย่างไม่ได้ ผมคิดว่าควรเขียนทฤษฎีก่อน จากนั้นใช้ โปรโตไทป์ แสดงให้เห็นว่ามันทำได้หรือไม่ได้ แล้วค่อยเขียนเอกสารออกแบบจริง
      และจนถึงขั้นตอน implement ก็ควรให้ความสำคัญกับการทำให้โค้ดทิ้งได้ง่ายต่อไป ยิ่งลบง่ายยิ่งดี
    • พูดถูกแล้ว: การทำโปรโตไทป์ และ pathfinding นั้นโอเคอย่างสมบูรณ์ และส่วนใหญ่ก็จำเป็น
      แต่ software engineering ที่ไม่มีเอกสารออกแบบหรือสเปกใด ๆ เลย ไม่ว่าจะกระชับแค่ไหน ก็ไม่ใช่วิศวกรรม แต่ใกล้เคียงกับการสร้างกระท่อมบนต้นไม้มากกว่า
      ยิ่งโปรเจกต์มีขนาดและความสำคัญมากขึ้น ปัญหาและหนี้ทางเทคนิคก็จะเริ่มปรากฏเร็วขึ้น
    • “การวางแผนหลายสัปดาห์ก็อาจช่วยประหยัดการเขียนโค้ดไม่กี่ชั่วโมงได้” :)

  • การเขียนมีประโยชน์มากจริง ๆ ในการ สำรวจพื้นที่ของปัญหา
    หลายครั้งที่คิดว่าตัวเองเข้าใจปัญหาอย่างแน่นอนแล้ว แต่พอเริ่มเขียนออกมา กลับเกิดคำถามใหม่ ๆ ที่สำคัญขึ้นมา สิ่งเหล่านี้มักมองเห็นได้ดีกว่าจากมุมมองเชิงนามธรรม หรืออาจไม่ปรากฏใน milestone การ release ช่วงแรก ๆ
    นึกถึง mentor คนหนึ่งที่เจอช่วงต้นอาชีพ เขาเคยออกแบบย้อนหลังให้ payment gateway เป็นโครงสร้าง active/active แล้วเปิด Lucidchart พร้อมพูดว่า “ไดอะแกรมนี้แทนชีวิตผม 6 เดือน”
    ไม่ได้จำเป็นหรือช่วยได้เสมอไป แต่เวลาที่จำเป็น การวางแผนไม่กี่วันช่วยประหยัดการเขียนโค้ดได้หลายสัปดาห์

    • ผมเคยมีหัวหน้าที่จบคณิตศาสตร์ เขาวาด flow ตั้งแต่ต้นจนจบบน ไวท์บอร์ด เหมือนนักคณิตศาสตร์ในทีวีหรือหนัง
      เขาคาดการณ์จุดที่จะเกิดปัญหาได้ล่วงหน้าไกลมาก โปรเจกต์จึงราบรื่นเสมอ ถ้าเห็นปัญหาหรือความไม่แน่นอน ก็จะ modeling เฉพาะส่วนนั้น แล้วกลับไปที่ไวท์บอร์ดเพื่อทำต่อ
      ถ้าเปรียบก็เหมือนการวางแผน road trip ด้วยแผนที่ ทุกวันนี้เอกสารออกแบบมักแค่ระบุเส้นทางแล้วก็ขับออกไปทันที แต่แผนที่ไวท์บอร์ดของหัวหน้าคนนั้น “วางแผนเกินจำเป็น” ไปถึงว่าจะเติมน้ำมันที่ไหน เวลาเปิดปิดสถานที่ท่องเที่ยว เอกสารผ่านแดน งบประมาณทั้งหมด ชุดฉุกเฉิน รวมถึง Plan A และ Plan B
      น่าเบื่อสุด ๆ แต่ดีกว่าโค้ดแบบใช้แล้วทิ้งมาก ตอนนี้การไม่วางแผนเกินจำเป็นกลับรู้สึกเหมือนความขี้เกียจไปแล้ว
      แน่นอนว่าคำพูด “ทุกคนมีแผนจนกว่าจะโดนต่อย” นั้นถูกต้อง แต่นั่นใช้กับสงคราม การเมือง และการเจรจา ไม่ใช่การเขียนโค้ด
    • เห็นด้วยว่าการเขียนมีประโยชน์ แต่ผมคิดว่าการเขียนโค้ดก็ให้ผลแบบเดียวกัน จากประสบการณ์ของผม การสำรวจต้องให้ทั้งสองอย่างไปด้วยกัน
      สุดท้าย PR ที่ดีก็มีการเขียนเยอะ และให้ผลแบบเดียวกัน ผมคิดว่า draft PR ที่มีเอกสารประกอบอย่างดีดีกว่าข้อเสนอการออกแบบล้วน ๆ เพราะถ้าเขียนแต่ข้อความอย่างเดียว จะลืมข้อจำกัดสำคัญที่มักนึกออกเฉพาะตอนอยู่ในโค้ด
    • “การเขียนคือวิธีของธรรมชาติในการบอกให้รู้ว่าความคิดของคุณหละหลวมแค่ไหน”
      -- Dick Guindon

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

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

  • เพื่อหลีกเลี่ยงการต่อสัญญา เราต้องสร้างและปล่อยอะไรสักอย่างให้ทันกำหนด และสัญญานั้นมีมูลค่าหลายล้านดอลลาร์ แต่เราพบว่าด้วยทรัพยากรและแนวทางที่วางไว้ จะทำไม่ทันเวลา
    ดังนั้นเราจึงได้รับอนุมัติให้สร้างเวอร์ชันชั่วคราว บางส่วน และไม่ใช่ทางเลือกที่ดีที่สุดอย่างรวดเร็วได้ และด้วยเหตุนี้จึงสามารถ “ขึ้นบิน” ได้ทันเวลา
    มันทำให้เราบินไปได้ชั่วคราว ระหว่างที่คนอื่น ๆ ทำเวอร์ชันถาวรที่ถูกต้องสำหรับส่วนนั้นของปีกให้เสร็จ
    จริง ๆ แล้วระหว่างบิน เรายังค้นพบข้อกำหนดที่ตกหล่นจากการออกแบบเดิมด้วย เรื่องนี้ทำให้การปล่อยเวอร์ชัน production ที่ถูกต้องล่าช้าออกไป แต่ผมสามารถเพิ่มเข้าไปในเวอร์ชันแฮ็กของผมได้อย่างรวดเร็ว และทำให้ยังบินต่อไปได้
    เวอร์ชันแฮ็กของผมยังทำหน้าที่เป็น เครื่องมือซัพพอร์ต production ด้วย เมื่อเวอร์ชันถาวรมีบั๊กจนต้องหยุด มันก็เป็นเส้นทางสำรองได้ แม้จะเป็นแฮ็กที่ทำได้แค่บางส่วนและไม่สมบูรณ์ แต่ก็มีข้อดี
    มีคนบ่นด้วยว่า ภาษาที่ใช้ไม่ค่อยแพร่หลาย แต่ต้องจำไว้ว่าด้วยทรัพยากรและแนวทางเดิม เราไม่มีทางขึ้นบินได้ตั้งแต่แรก
    ถ้าจะให้ทันเดดไลน์ ก็คงต้องมีนักพัฒนาที่ใช้ภาษาที่ทีมชอบได้มากกว่านี้หรือเร็วกว่านี้ หากในพนักงานปัจจุบันมีใครสักคน รวมถึงตัวผมเอง ที่มีเวลาและความสามารถพอจะทำงานด้วยภาษาที่ทีมชอบได้ productive เท่ากับแฮ็กด้วยภาษานอกกระแสของผม คนนั้นก็คงถูกมอบหมายให้สร้างทางออกถาวรให้ทันเวลาไปแล้ว แต่ทางเลือกแบบนั้นไม่มี
    อย่างไรก็ดี ถ้ามีเครื่องมือซัพพอร์ต production อยู่แล้ว มันก็เป็นที่ที่ ฟีเจอร์ต้นแบบ จะอาศัยอยู่ได้สักพักเช่นกัน

    • เป็นภาษาอะไร?

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

    • เห็นด้วยอย่างยิ่ง ผมไม่แน่ใจว่าคำว่า “เอกสารออกแบบ” ตรงไหม ผมเรียกมันว่า การวิเคราะห์ทางเทคนิค มากกว่า แต่การเขียนเอกสารที่เชื่อมความต้องการทางธุรกิจและผลิตภัณฑ์เข้ากับรายละเอียดการ implement มีประโยชน์มากในการทำให้ทุกคนเข้าใจ requirements และ deliverables ตรงกัน
      ถ้า requirements ชัดเจน และทุกคนก็ชัดเจนว่าผมจะส่งมอบอะไร ก็ไม่จำเป็น สามารถไป prototyping ได้เลย แต่ในโปรเจกต์จริงจัง กรณีแบบนี้พบได้น้อยมาก มักมี unknown unknowns ที่ต้องดึงออกมาจากผู้มีส่วนได้ส่วนเสียเสมอ และการวิเคราะห์ทางเทคนิคเป็นวิธีที่ดีในการทำสิ่งนั้น
    • นั่นแหละคือประเด็นของผม ผมมองว่า “อย่าพูด ให้โชว์” สร้างฉันทามติได้ดีกว่า
      สี่เหลี่ยมกับเส้นประมีข้อจำกัดของมัน เมื่ออยู่ห่างจากโค้ดจริง เราจะลืมข้อจำกัดที่แท้จริง สิ่งที่ทำให้ช้าจริง ๆ ไม่ปรากฏใน Google Docs จากประสบการณ์ของผม การชี้ไปที่ draft PR พร้อมพูดว่า “นี่คือสิ่งที่ผมคิดไว้” ไปได้ไกลกว่า
      และใช่ นี่เป็นความเห็น 100% เป็นบล็อกส่วนตัว ไม่ใช่เปเปอร์ peer-reviewed :) ผิดก็ไม่เป็นไร
    • โค้ดที่เขียนเพื่อทิ้งดีกว่าเอกสารออกแบบ เพราะมันเป็น ตัวอย่างที่เป็นรูปธรรม
      ถ้าไม่มีสิ่งที่จับต้องได้แบบโค้ดเพื่อยึดบทสนทนาไว้ การคุยกันเรื่องการออกแบบเชิงนามธรรมก็มักไหลไปเป็นการถกเถียงไร้ข้อสรุปทำนองว่า “เชือกในจินตนาการของฉันยาวกว่าเชือกในจินตนาการของเธอ”
    • คนที่มีความเชื่อแบบนี้มีแนวโน้มจะเคลื่อนที่ได้เร็วขึ้นมากด้วย LLM มากกว่าที่ LLM จะมาแทนที่งานนี้ทั้งหมด
    • “ข้อมูล” ของบทความแบบนี้ บางครั้งอาจเป็นประสบการณ์ส่วนตัวหลายสิบปีก็ได้

  • จากประสบการณ์ของผม ฟีดแบ็กต่อโค้ดกับฟีดแบ็กต่อการออกแบบเป็นคนละประเภทกัน อย่างมหาศาล
    เอกสารออกแบบกระตุ้นคำถาม “ทำไม” ที่ทำให้ทุกคนคิดถึงพื้นที่ของปัญหา เช่น อาจมีคอมเมนต์ว่า “ในบริษัทยังไม่มีใครชำนาญ Rust แล้วทำไมถึงเสนอเว็บเซิร์ฟเวอร์ Rust?”
    คำถามละเอียดอ่อนแบบนี้จะยกขึ้นมาพูดได้ยากขึ้นมากหลังจาก prototype เริ่มทำงานแล้ว มันมักกลายเป็นว่า “ทำไมประสบการณ์ของทีมถึงสำคัญล่ะ? มันรันได้ดีขนาดนี้แล้วนะ! ถ้าไม่มาขวาง เราแค่ขัดเกลา prototype นิดหน่อยก็เอาเข้า production ได้ในหนึ่งสัปดาห์!”

    • นั่นไม่ได้แปลว่าแย่เสมอไป คำถาม “ทำไม” จำนวนมากจริง ๆ แล้วเป็น การถกเถียงเรื่องโรงเก็บจักรยาน ที่ไม่สร้างผลลัพธ์
      โดยเฉพาะเวลาตรวจแค่การออกแบบ ไม่ใช่โค้ดที่ทำงานได้

  • เรามักจินตนาการว่างานซอฟต์แวร์ไหลไปอย่างสะอาดและเป็นระเบียบ
    เขียนเอกสารออกแบบ ทำการเปลี่ยนแปลงเล็ก ๆ แบบค่อยเป็นค่อยไปใน PR เพื่อปล่อยฟีเจอร์ และประวัติ Git ก็สะอาดเป็นระเบียบ ดูเหมือนความคืบหน้าอย่างต่อเนื่อง
    ใครกันที่จินตนาการแบบนี้? อาจารย์ที่สอนวิชาวิศวกรรมซอฟต์แวร์หรือ?
    สิ่งนี้ทำให้นึกถึงคนที่คิดว่าการเขียนร้อยแก้ว เอสเซย์ เรื่องเล่า นวนิยาย ฯลฯ คือการเขียนโครงร่างก่อน แล้วค่อย “เติม” ให้เป็นร้อยแก้ว ราวกับว่าในกระบวนการนั้นจะไม่มีการค้นพบอะไรเลยที่ทำให้ต้องเขียนหรือจัดโครงสร้างเอกสารใหม่ ไม่มีใครเขียนแบบนั้น ร่างแรกมักแย่เสมอ และงานเขียนที่ดีแทบทั้งหมดเป็นผลลัพธ์ของการแก้ไขครั้งใหญ่
    การเขียนโค้ดใกล้เคียงกับ การเขียนหนังสือ มากกว่าการสร้างบ้านหรือสะพานมาก

    • ผมมักรู้สึกว่าการดีบักโค้ดที่เพิ่งเขียนมีคุณค่ามาก
      การไล่ดูตรรกะใหม่ทีละบรรทัด และดูตัวแปรกับหน่วยความจำ ช่วยปรับปรุงโค้ดได้จริง ๆ ผมจะพบเรื่องอย่าง “อ้อ ตัวแปร local นี้ไม่จำเป็น”, “ตรงนี้ควรเพิ่มตัวแปรชั่วคราวเพื่อให้ดีบักง่าย”, “ถ้า collection ที่วนลูปอยู่ว่าง โค้ดนี้จะแปลก ๆ”
      ไม่ว่าจะอายุมากแค่ไหน หรือเขียนโค้ดมามากแค่ไหน ทุกครั้งที่ดีบักโค้ดที่เพิ่งเขียน ผมก็มักค้นพบอะไรใหม่เสมอ อาจเปรียบได้กับนักเขียนที่เขียนร่างแรกแล้วกลับมาอ่านอีกครั้ง หรืออ่านออกเสียงให้ตัวเองหรือคนอื่นฟัง

  • ผมชอบกระบวนการนี้มาก ที่บันทึกการตัดสินใจด้านการออกแบบไว้เป็น เธรดคอมเมนต์ ที่ดำเนินต่อเนื่อง แทนที่จะพยายามทำให้เป็นทางการในเอกสารฉบับเดียว
    ผมใช้ GitHub issue แบบนี้ แต่ในเชิงฟังก์ชันก็เหมือนกับการใช้ PR นั่นแหละ จริง ๆ แล้ว PR ก็คือ GitHub issue ที่มี branch โค้ดแนบอยู่
    บทความที่ผมเขียนเพิ่มเติมเกี่ยวกับวิธีของผมอยู่ที่นี่: https://simonwillison.net/2022/Jan/12/how-i-build-a-feature/...

    • แล้วคุณสื่อสารฉันทามติล่าสุดของแต่ละ issue อย่างไร? เช่น สำหรับคนที่เพิ่งเข้าทีมและไม่อยากไล่อ่านการสื่อสารย้อนหลังหลายเดือน หรือสมาชิกทีมที่ตามเธรดมาตลอดแต่หาไม่เจอง่าย ๆ ว่าทีมตกลงกันไว้ตรงไหนในประเด็นหนึ่ง ๆ คุณทำอย่างไร?
      พูดอีกอย่างคือ คุณสรุปเธรดนั้นให้เป็นเอกสารสุดท้ายอย่างไร?

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

    • เห็นด้วย
      สำหรับคนที่ไม่ใช่ผู้เขียน หรือไม่ได้คุ้นเคยกับโค้ดมากนัก การทำความเข้าใจการเปลี่ยนแปลงทั้งหมดในแวบเดียวเป็นเรื่องยากมาก เพื่อให้ผู้อ่านสร้าง mental model ที่ถูกต้องและเข้าใจการเปลี่ยนแปลงในบริบทได้อย่างรวดเร็ว จำเป็นต้องมีคำอธิบายและเอกสารในระดับสูง
      ถ้าคุณดู diff 1,000 บรรทัดแล้วบอกได้อย่างแม่นยำว่ามันทำอะไร และที่สำคัญกว่านั้นคือมันส่งผลกระทบต่อ upstream และ downstream อย่างไร แสดงว่าคุณกำลังโกหกอยู่ หรือไม่ก็ทำงานอยู่ในสภาพแวดล้อมที่ปิดสมบูรณ์และตรวจสอบได้อย่างสมบูรณ์แบบจนผม/ฉันอิจฉาจริง ๆ

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