เบื้องหลังหนังสือ "100 ข้อผิดพลาดและวิธีแก้ใน Go"

 (thecoder.cafe)
5 คะแนน โดย GN⁺ 2025-04-12 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นเรื่องราวที่เน้นทั้งจุดเริ่มต้นที่ทำให้หลงใหลในภาษา Go และเส้นทางส่วนตัวที่นำไปสู่การเขียนหนังสือ
  • จากความสำเร็จของบล็อกโพสต์ สู่การเซ็นสัญญากับ Manning และประสบการณ์การทำหนังสือจนเสร็จตลอด 3 ปี
  • บทความนี้บรรยายทั้งการลองผิดลองถูกมากมาย ความขึ้นลงทางอารมณ์ โดยเฉพาะความขัดแย้งในกระบวนการบรรณาธิการได้อย่างชัดเจน

การพบกับภาษา Go ครั้งแรก และจุดเปลี่ยน

  • ในปี 2018 หลังทำงาน PoC ด้วย Scala/Akka ที่สวิตเซอร์แลนด์ เขาหลงใหลในประสิทธิภาพและความเรียบง่ายของภาษา Go
  • เมื่อย้ายไปบริษัทใหม่และได้ใช้ Go ในงานจริง เขาสั่งสมประสบการณ์การทำงาน และเริ่มเขียนบล็อกเมื่อเห็นเพื่อนร่วมงานทำข้อผิดพลาดเดิมซ้ำ ๆ
  • บล็อกโพสต์ที่ลงบน Medium ได้รับกระแสตอบรับเกินคาด ทำให้เขามั่นใจในการเขียนมากขึ้น

จุดเริ่มต้นของการตีพิมพ์หนังสือ: จากไอเดียสู่สัญญา

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

กระบวนการเขียนและการทำงานร่วมกับบรรณาธิการ

  • หลังตั้ง “ผู้อ่านขั้นต่ำที่เหมาะสม (MQR)” แล้ว ก็กล้าตัดเนื้อหาพื้นฐานที่ไม่จำเป็นออก
  • ได้พัฒนาทักษะการเขียนผ่านการทำงานร่วมกับ development editor (DE) ซึ่งไม่ใช่บรรณาธิการสายเทคนิค
  • มีบางบทที่ถูกเขียนใหม่มากกว่า 10 รอบ ผ่านการรีวิวและแก้ไขซ้ำแล้วซ้ำอีก

การรีวิวจากภายนอกและการรับฟังฟีดแบ็ก

  • หนังสือถูกแบ่งรีวิวเชิงเทคนิคภายนอกเป็น 3 ช่วง (1P, 2P, 3P) และคะแนนก็ค่อย ๆ ดีขึ้น
  • 1P: ผู้รีวิว 13 คน คะแนนเฉลี่ย 4.10 → 2P: 4.15 → 3P: 4.6
  • หลักการรับฟีดแบ็กมาจากคำแนะนำของ Bill Kennedy ที่ว่า “อย่ามองข้ามแม้แต่ฟีดแบ็กเพียงข้อเดียว”

วิกฤตครั้งใหญ่ในกระบวนการบรรณาธิการ

  • technical development editor (TDE) ที่ถูกกำหนดในช่วงแรกกลับขาดแม้แต่ความรู้พื้นฐานเกี่ยวกับ Go จนเกิดความไม่พอใจ
  • ระบบตรวจแก้และวิธีการทำงานร่วมกันที่ซับซ้อนและไร้ประสิทธิภาพ อีกทั้งบรรณาธิการยังใส่ข้อผิดพลาดจำนวนมากเข้ามาเอง
  • เขารู้สึกผิดหวังอย่างหนักจนประกาศหยุดงาน แต่ Manning ก็รีบจัดบรรณาธิการคนใหม่มาแก้ปัญหา

เส้นทางสู่ความสมบูรณ์ และความหดหู่หลังตีพิมพ์

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

ความสำเร็จของหนังสือและเสียงตอบรับจากชุมชน

  • หลังหนังสือออกไม่นาน ก็มีการแชร์ต่อกันเองบน Reddit, Twitter และที่อื่น ๆ โดยแทบไม่ต้องโปรโมตยาวนาน
  • หนึ่งปีต่อมา ได้เปิดเว็บไซต์โอเพนซอร์ส 100go.co เพื่อเผยแพร่สรุปเนื้อหาฟรี
  • ฝั่ง Manning เองก็ตอบรับดีมาก และยังเสนอให้มีบทบาทช่วยเหลือผู้เขียนในอนาคตด้วย

ค่าลิขสิทธิ์ รายได้ และความหมายที่มากกว่านั้น

  • ณ สิ้นปี 2024 ฉบับภาษาอังกฤษขายได้ 11,452 เล่ม และสร้างรายได้รวมราว $47,000
  • แม้รายได้ต่อชั่วโมงจะไม่สูง แต่เขามองว่าความหมายที่แท้จริงอยู่ที่การมีส่วนร่วมกับชุมชนและความสำเร็จส่วนตัว มากกว่าเรื่องเงิน
  • หนังสือเล่มนี้ยังส่งอิทธิพลต่อซีรีส์ภาคต่อเกี่ยวกับ Java, C++, SQL Server เป็นต้น

บทสรุปและคำมั่นส่วนตัว

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

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

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

 
zihado 2025-04-14

https://product.kyobobook.co.kr/detail/S000211704725
นี่คือหนังสือเล่มนี้ครับ
 
GN⁺ 2025-04-12
ความคิดเห็นบน Hacker News
  • มีการอธิบายเวิร์กโฟลว์การรีวิวแบบอิง PR และเสนอแนวทางปรับปรุง แต่คู่กรณีไม่ค่อยอยากลองใช้ ต้องการให้กระบวนการทำงานร่วมกันลื่นไหลและมีประสิทธิภาพมากขึ้น
  • น่าแปลกใจที่ copy editor คุ้นเคยกับการใช้ git มากกว่าเครื่องมือรีวิวบนเว็บ โดยเฉพาะตอนรีวิวหนังสือ Go ดูเหมือนจะไม่ได้รู้เรื่อง Go มากนัก
  • รู้สึกแปลกที่ Manning มี copy editor อยู่ด้วย
  • มีการแชร์ประสบการณ์แย่ ๆ กับ Manning กำลังเขียนหนังสือและทำ self-publishing อยู่ จึงเคยถามถึงความเป็นไปได้ในการเสนอตีพิมพ์ฉบับพิมพ์ครั้งที่สองกับ Manning และได้รับคำตอบว่าพวกเขาปฏิเสธข้อเสนอ
  • แม้จะพูดถึงแค่ Google Docs ในฐานะรูปแบบเอกสาร แต่จากโพสต์ในบล็อกดูเหมือนว่ารองรับ AsciiDoc ด้วย
  • มีการกล่าวถึงปัญหาที่เกี่ยวข้องกับ sync.Pool พร้อมแชร์ลิงก์ที่เกี่ยวข้อง
  • หากดูการใช้ sync.Pool ใน standard library ของ Go จะพบว่ามี tiered pools หลายขนาด และรายการที่มีขนาดใหญ่มักถูกทิ้งบ่อยครั้ง
  • มีการแชร์ประสบการณ์การเขียนหนังสือกับ Manning ด้วย DocBook หลัง copy editing แล้ว เนื้อหาทั้งหมดกลับมาเป็นบรรทัดเดียวจนน่าผิดหวัง จึงเปลี่ยนไปทำ self-publishing
  • การติดต่อกับ O'Reilly ในช่วงแรกเริ่มจากอีเมล และมีการบอกว่าเครื่องมือของพวกเขายอดเยี่ยมมาก สามารถสร้างเวอร์ชันเต็มของรูปแบบที่รองรับได้จาก git commit
  • มีการบอกว่ารูปแบบของหนังสือเหมาะกับชมรมหนังสือมาก ความผิดพลาดต่าง ๆ กลายเป็นหัวข้อสนทนาที่ดี และคนที่มีประสบการณ์ก็ได้แชร์ว่าพวกเขาหลีกเลี่ยงความผิดพลาดเหล่านั้นอย่างไร
  • "ความผิดพลาด" หลายข้อในหนังสือเป็นการแนะนำบางแง่มุมของ Go เช่น "ไม่ใช้ fuzzing" และ "ไม่ใช้ errgroup"
  • มีการบอกว่ารีวิวของ Tim มีคุณค่ามาก แต่ก็ผิดหวังที่ไม่มีคำอธิบายเจาะจงเกี่ยวกับตัวรีวิว
  • ผู้เขียนคนอื่นของ Manning ชื่นชมหนังสือเล่มนี้ โดยบอกว่ามีข้อมูลเชิงปฏิบัติจำนวนมาก และวางแผนจะกลับมาอ้างอิงอีกครั้งเมื่อเริ่มโปรเจกต์ Go ใหม่
  • มีการตั้งคำถามเกี่ยวกับตัวอย่างที่เกี่ยวกับ goroutine ว่าหากสร้าง function closure โดยไม่ใช้ goroutine มันจะอ้างอิงตัวแปร i ตัวเดิมเหมือนกันหรือไม่
  • มีการแสดงความชื่นชมต่อผู้เขียนในเรื่องการรับฟัง feedback และการเรียนรู้วิธีสื่อสาร รวมถึงการวางท่าทีอย่างหนักแน่นต่อ copy editor ที่มีปัญหา
  • มีการแชร์ประสบการณ์การรีแฟกเตอร์ legacy codebase ภาษา C++ ในสวิตเซอร์แลนด์ บรรยากาศที่ได้ลองใช้สแตกใหม่ ๆ และถ้ายากเกินไปก็เปลี่ยนไปลองอย่างอื่นได้ถือว่าดีมาก
  • มีการกล่าวถึงการรวบรวมหน้าข้อมูลบน Sensei's Library เกี่ยวกับความผิดพลาดที่เกิดขึ้นใน Go