แนวโน้มที่นิยม Throwaway Code มากกว่าเอกสารออกแบบ

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

  • เรามักจินตนาการว่าการพัฒนาซอฟต์แวร์จะเป็นไปตามกระบวนการที่สะอาดและเป็นระเบียบ

    • เขียนเอกสารออกแบบ แล้วค่อย ๆ ปล่อยการเปลี่ยนแปลงเล็ก ๆ ผ่าน PR เพื่อพัฒนาฟีเจอร์
    • ประวัติ Git ดูสะอาดและเป็นระเบียบ
    • แต่ความเป็นจริงไม่เป็นแบบนั้น

  • ความต่างระหว่างเอกสารออกแบบกับการลงมือทำจริง

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

  • วิธีการออกแบบแบบใหม่: ดิ่งไปกับการเขียนโค้ด

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

  • ความสำคัญของความเป็นผู้ใหญ่

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

  • วิธีใช้ PR เป็นเอกสารประกอบ

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

  • ความสำคัญของต้นแบบ

    • ต้นแบบมีค่ามากกว่าเอกสารออกแบบ 1000 ฉบับ
    • หากต้องการขับเคลื่อนการเปลี่ยนแปลง ต้องทำผ่านโค้ด ไม่ใช่เอกสาร
    • องค์กรควรมองต้นแบบเป็นคำถาม ไม่ใช่คำตอบ

  • ประโยชน์ของเอกสารออกแบบ

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

  • การใช้งานเอกสารออกแบบอย่างผิดทาง

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

  • หากทีมมีวินัยเพียงพอ การแฮ็กลงมือทำจะมีประสิทธิภาพกว่าการออกแบบมาก

    • แนะนำให้องค์กรสร้างวินัยลักษณะนี้ขึ้นมา
    • สุดท้ายแล้ว โค้ดทรงพลังกว่าคำพูด

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

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

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

  • การทำต้นแบบเป็นส่วนสำคัญของกระบวนการออกแบบ และจำเป็นต้องนิยามปัญหาและทำให้แนวทางแก้ไขชัดเจน

    • บางครั้งเอกสารสั้นๆ ก็เพียงพอ แต่บางครั้งก็ต้องการฟีดแบ็กจำนวนมากและการทำซ้ำหลายรอบ
    • มีคำกล่าวว่า "การเขียนโค้ดไม่กี่สัปดาห์อาจช่วยประหยัดเวลาวางแผนได้ไม่กี่ชั่วโมง"

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

    • ทำให้นึกถึงกรณีที่เมนเทอร์ใช้ Lucidchart เพื่ออธิบายงานตลอดช่วง 6 เดือน

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

    • วิธีแก้ชั่วคราวนั้นยังถูกใช้เป็นเครื่องมือสนับสนุนการใช้งานจริง และถูกนำมาใช้เป็นเส้นทางสำรองเมื่อเวอร์ชันถาวรถูกยกเลิก

  • ปัญหาใหญ่ที่สุดของเอกสารออกแบบคือไม่มีใครอ่าน

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

  • ฟีดแบ็กต่อโค้ดกับต่อการออกแบบแตกต่างกันมาก

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

  • ถ้าหน้าที่งานคือการเขียนโค้ดจำนวนมากเพื่อดูว่าอะไรใช้ได้ผล GPT ก็อาจเข้ามาแทนที่ได้เร็วกว่าและถูกกว่า

    • การทำให้ทุกคนเห็นพ้องกันว่าจะต้องสร้างอะไรยังคงเป็นความท้าทายเสมอ

  • แทบไม่มีใครจินตนาการว่าการพัฒนาซอฟต์แวร์จะดำเนินไปตามกระบวนการที่สะอาดและเป็นระเบียบ

    • การเขียนโค้ดคล้ายกับการเขียนหนังสือ ร่างแรกมักจะแย่เสมอ และงานเขียนที่ดีต้องผ่านการแก้ไขมากมาย

  • เคยเห็นกรณีที่โค้ดถูกกองซ้อนกันเหมือนเกม Jenga จนไม่มีใครอยากแตะต้อง

  • ชอบกระบวนการที่ใช้เธรดคอมเมนต์ต่อเนื่องเพื่อบันทึกการตัดสินใจด้านการออกแบบ

    • ใช้ GitHub Issues เพื่อดำเนินกระบวนการนี้

  • กำลังครุ่นคิดกับแนวทางนี้ และในกรณีเลวร้ายที่สุดอาจเสียเวลาไปมาก

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