การพัฒนาแบบ README Driven (2010)

 (tom.preston-werner.com)
44 คะแนน โดย xguru 2024-06-25 | 9 ความคิดเห็น | แชร์ทาง WhatsApp
  • การพัฒนาแบบขับเคลื่อนด้วย README: แนวทางการพัฒนาซอฟต์แวร์ที่เขียน README ก่อน
  • เรามักได้ยินเกี่ยวกับแนวทางและเทคนิคการพัฒนามากมาย เช่น TDD, BDD, Extreme Programming, SCRUM
    • แต่หากซอฟต์แวร์ที่เราพัฒนาไม่สามารถตอบสนองความต้องการของผู้ใช้ได้ ทุกอย่างก็ไร้ความหมาย
    • ต่อให้การนำไปใช้งานจะสมบูรณ์แบบ แต่หากยึดตามสเปกที่ผิดก็ไม่มีคุณค่า และไลบรารีที่สวยงามแต่ไม่มีเอกสารประกอบก็แทบไม่มีค่าเช่นกัน
    • หากซอฟต์แวร์แก้ปัญหาผิดเรื่อง หรือไม่รู้วิธีใช้งาน ก็จะก่อให้เกิดปัญหาร้ายแรง

วิธีแก้: เริ่มจากเขียน README

  • เหตุผลที่ควรเขียน README ก่อน
    • ก่อนจะเขียนโค้ด เทสต์ หรือสตอรี ควรเริ่มจากการเขียน README ก่อน
    • การเขียน README เป็นขั้นตอนที่จำเป็นในการสร้างซอฟต์แวร์ที่ดี
    • จนกว่าจะได้เขียนอธิบายซอฟต์แวร์ออกมาเป็นข้อความ ก็ยังไม่ชัดเจนว่าจะต้องเขียนโค้ดอะไร
    • README ช่วยให้คิดเกี่ยวกับโปรเจ็กต์ได้อย่างเป็นระบบ
  • ข้อดีของการเขียน README ก่อน:
    • โอกาสในการคิดโปรเจ็กต์อย่างเป็นระบบ:
      • สามารถคิดโครงสร้างของโปรเจ็กต์อย่างเป็นระบบได้โดยไม่ต้องแก้โค้ด
      • ก่อนลงมือเขียนโค้ด สามารถพิจารณาโครงสร้างของโปรเจ็กต์และ API ที่จะรวมอยู่ได้
    • ได้เอกสารที่มีคุณภาพ:
      • สามารถเขียนเอกสารได้ตั้งแต่ช่วงเริ่มต้นของโปรเจ็กต์ ขณะที่ยังมีแรงจูงใจและความสนใจสูง
      • การมาเขียน README ทีหลังเป็นเรื่องน่าเบื่อ และอาจพลาดรายละเอียดสำคัญไป
    • เพิ่มประสิทธิภาพการทำงานเป็นทีม:
      • นักพัฒนาคนอื่นในทีมสามารถรับรู้ข้อมูลเกี่ยวกับอินเทอร์เฟซได้ก่อนโปรเจ็กต์เสร็จ ทำให้เริ่มงานอื่นได้อย่างมั่นใจ
      • หากทำงานโดยไม่มีอินเทอร์เฟซที่ชัดเจน อาจต้องมีการรื้อและแก้โค้ดครั้งใหญ่
    • เป็นฐานสำหรับการอภิปรายที่เป็นรูปธรรม:
      • เพียงแค่ลงมือเขียนวิธีแก้ปัญหาที่เสนอไว้เป็นข้อความ ทุกคนก็สามารถอภิปรายกันได้โดยมีภาพความคิดที่ชัดเจน
  • ลักษณะของการพัฒนาแบบ README Driven (RDD):
    • RDD อาจมองได้ว่าเป็นส่วนย่อยหรือเวอร์ชันที่จำกัดของ Documentation Driven Development (DDD)
    • RDD จำกัดเอกสารการออกแบบไว้ในไฟล์เดียว เพื่อป้องกันปัญหาการเขียนสเปกมากเกินไป
    • ช่วยผลักดันให้คงไว้ซึ่งไลบรารีขนาดเล็กที่มีการแยกส่วนอย่างเหมาะสม

บทสรุป

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

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

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

 
princox 2024-06-26

ไม่ว่าจะเป็นซอฟต์แวร์ นวนิยาย หรือภาพยนตร์ เวลาสร้างสรรค์ผลงานในรูปแบบใดก็ตาม
ผมคิดว่าถ้าได้วางแบบและวางแผนบนกระดาษก่อนลงมือทำ ก็น่าจะช่วยให้เก็บรายละเอียดต่าง ๆ ได้ง่ายขึ้นนะครับ.. :)
 
markman 2024-06-26

ผมลืมเรื่องพื้นฐานที่สุดไปมาตลอด ตอนนี้คงต้องเริ่มลงมือทำจริงแล้ว
 
halfenif 2024-06-25

เราเลยตกลงจะเรียกมันว่า "การออกแบบพื้นฐาน"
 
gargoyle92 2024-06-25

ดูเหมือนว่าจะคล้ายกับวิธีและบริบทการทำงานของผมโดยไม่ได้ตั้งใจ
ดูเหมือนว่าส่วนนั้นจะถูกถ่ายทอดออกมาในรูปแบบของ "README"

เวลาผมทำงาน ผมมักจะเขียน What, Why, How ฯลฯ ให้ชัดเจน แล้วค่อยดำเนินงานไปพร้อมกับค่อย ๆ กำหนดภาพรวมของสิ่งที่ต้องทำ ซึ่งก็คล้ายกันครับ
 
kandk 2024-06-25

การพัฒนาที่ขับเคลื่อนด้วย README
 
dbs0829 2024-06-25

ฉันทำงานอยู่ในองค์กรวิจัย เลยกังวลอยู่มากเรื่องการปล่อยผลงานวิจัยออกมาในรูปแบบโค้ด แต่ก็รู้สึกว่าแนวทางการพัฒนาแบบ README-driven น่าจะเหมาะกับพวกเรามาก ดูเป็นวิธีที่น่าลองคิดตั้งแต่ช่วงเริ่มต้นของงานวิจัยเลยครับ
 
jamsya 2024-06-25

คล้ายกันเลย ตอนทำฝั่งแบ็กเอนด์ผมก็มักจะเปิดหน้าจอไปด้วยแล้วลองเขียนเอกสาร API แบบคร่าว ๆ ก่อน
ซึ่งช่วยลดการลองผิดลองถูกได้มากพอสมควรครับ
 
bbulbum 2024-06-25

มองอีกแง่หนึ่ง ก็ทำให้นึกถึงความสำคัญของการนิยามปัญหาที่ต้องแก้ให้ชัดเจนตั้งแต่แรก
 
xguru 2024-06-25

เป็นบทความจากปี 2010 แต่บังเอิญไปเจอขณะอ่านบทความอื่นเลยเอามาแชร์ครับ