Lodash ประกาศภาวะล้มละลายของอิชชูและปิดอิชชูทั้งหมดกับ PR ที่เปิดอยู่

lodash ประกาศภาวะล้มละลายของอิชชูและปิดอิชชูทั้งหมดกับ PR ที่เปิดอยู่

[GN⁺]

ความคิดเห็นบน Hacker News

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

  • ถ้าเติมบริบทอีกนิด ผู้สร้างกำลังทำ การเขียนใหม่ทั้งหมด อยู่
    น่าจะเรียบร้อยกว่าถ้ารีลีสเวอร์ชันที่เขียนใหม่ก่อน แล้วค่อยปิด issue เดิมเป็น deprecated ส่วน issue ของสาขาที่เขียนใหม่ก็น่าจะแยกด้วยแท็กเวอร์ชันได้อยู่แล้ว ถ้าปิดตอนที่เวอร์ชันใหม่ยังไม่เสร็จ ผู้มีส่วนร่วมอาจเปิด issue ใหม่กับเวอร์ชันเดิมโดยไม่รู้ว่ามันไม่ได้รับการสนับสนุนแล้ว
    ถึงอย่างนั้น ก็ไม่ได้หมายความว่าพวกเขาเพิกเฉยต่อ issue แล้วปล่อยปัญหาไว้ใน codebase แต่ทั้งโปรเจกต์กำลังถูกปรับปรุงใหม่อยู่
    https://twitter.com/jdalton/status/1571863497969119238
  • จากมุมมองผู้ใช้ ถ้า “การจัดระเบียบ” แบบนี้หมายถึงการปิด issue ก็เป็นปัญหา ถ้า issue นั้นยังมีอยู่ในผลิตภัณฑ์ ก็ควรเปิดไว้ ทั้งเพื่อเป็นเอกสาร และเพื่อให้ผู้ใช้ที่เจอปัญหาเดียวกันค้นหาเจอและมาเพิ่มเติมข้อมูลได้ง่าย
    ผมคิดว่าโปรเจกต์ควรยอมรับการมีอยู่ของ issue และเปิดมันไว้อย่างตรงไปตรงมามากกว่า จากมุมมองนักพัฒนา ถ้าจำนวน issue ทำให้รำคาญ ก็ควรใช้ ฟิลเตอร์ ซ่อน issue เก่า ๆ ที่ไม่สำคัญน่าจะดีกว่า
  • ผมเองก็สองจิตสองใจ ด้านหนึ่ง ทุกครั้งที่กลับไปทำงาน JavaScript ผมก็ยังนึกถึง lodash แต่อีกด้านหนึ่ง ผมคิดว่าส่วนที่น้อยกว่าครึ่งหนึ่งเล็กน้อยของไลบรารีนี้ควรได้เข้าไปอยู่ใน standard library เสียที
  • งานแบบนี้ไม่ใช่สิ่งที่โมเดลภาษาขนาดใหญ่น่าจะทำได้ดีเหรอ หมายถึง สรุป ticket น่ะ
  • นั่นจึงเป็นเหตุผลที่ Basecamp ไม่เก็บ backlog ไว้ เรื่องสำคัญจะโผล่กลับขึ้นมาเอง

• jwz เคยพูดไว้แบบนี้

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

  • ถ้าเป็นโปรเจกต์ที่มีผู้ดูแลน้อยหรือเป็นโปรเจกต์คนเดียว ผมคิดว่าน่าจะสมเหตุสมผลกว่าที่ ผู้รายงานบั๊ก แต่ละคนใช้เวลา 10–15 นาทีตรวจสอบว่าปัญหายังมีอยู่ไหม แทนที่จะให้ผู้ดูแลคนเดียวใช้เวลาหลายวันถึงหลายสัปดาห์เพื่อตรวจยืนยัน
    โดยเฉพาะถ้าเป็นบั๊กที่ทำซ้ำได้ยากหรือซับซ้อน ก็ไม่แน่ด้วยซ้ำว่าผู้ดูแลจะทำซ้ำในสภาพแวดล้อมของตัวเองได้หรือไม่ และผู้รายงานก็น่าจะคุ้นเคยกับการสังเกตบั๊กนั้นมากกว่า
    ถ้ามีทีมใหญ่กว่านี้ หรือเป็นโปรเจกต์คู่กับบริการเชิงพาณิชย์ สมดุลนี้อาจเปลี่ยนไปเล็กน้อย
    สิ่งที่เห็นในโปรเจกต์ซอฟต์แวร์เสรี/โอเพนซอร์สจำนวนมากคือ มีคนน้อยมากที่ยอมพับแขนเสื้อเข้ามาลงมือทำ แต่ในขณะเดียวกันก็ใช้เวลาค่อนข้างมากไปกับการบอกว่าโปรเจกต์นั้นจำเป็นกับตัวเองแค่ไหน เรียกร้อง และเสนอแนะมากมาย
    คนส่วนใหญ่สร้าง issue ใหม่เพื่อแจ้ง wishlist หรือทิ้งรายงานบั๊กที่คลุมเครือมากไว้ บางส่วนก็ส่งรายงานบั๊กที่ดีได้เหมือนกัน แต่ความตั้งใจจะมีส่วนร่วมมักหยุดอยู่แค่นั้น
    ส่วนตัวแล้ว ผมคงไม่มีนิสัยเหมาะกับการดูแลโปรเจกต์ เพราะไม่มีความตั้งใจจะรับมืออย่างมีมารยาททางการทูตกับคอมเมนต์ส่วนใหญ่ที่เห็นบ่อย ๆ
    ถึงอย่างนั้น สำหรับ issue ที่ผมรายงานเอง ผมก็พยายามทำส่วนของตัวเองเสมอ ด้วยการไล่หาสาเหตุ และถ้าเป็นไปได้ก็ส่ง PR สำหรับแก้ไข
  • ยังมีอีกแบบหนึ่งด้วย คือมีรายงาน issue สำหรับเวอร์ชันหลักหนึ่ง พอเวอร์ชันหลักใหม่ออกมา ทั้งที่ไม่ได้เขียนใหม่ แค่เปลี่ยนแบบค่อยเป็นค่อยไป ก็ปิด issue ของรีลีสก่อนหน้า ทั้งหมด ด้วยเหตุผลว่าปัญหาอาจไม่มีอยู่แล้ว
  • ก็สร้าง PR ที่มีเทสต์ซึ่งควรผ่าน แต่ตอนนี้ทำเครื่องหมายให้ข้ามไว้ก็พอ แบบนั้นเมื่อ rebuild จะมีเส้นทางง่าย ๆ ให้ตรวจสถานะและดูว่าดีขึ้นหรือไม่
    ถ้าเป็นปัญหาที่ใส่ใจจริง ๆ ก็ควรแนบ เทสต์ มาด้วย
  • การค้นพบด้านความปลอดภัยบางครั้งก็ถูกจัดการแบบนั้นเหมือนกัน
  • จากประสบการณ์ของผม โปรเจกต์ซอฟต์แวร์แบบปิดซอร์สก็เหมือนกัน

• John-David Dalton ผู้เขียน lodash [เขียนไว้เมื่อปีที่แล้วแบบนี้][1]

  ในการเขียน lodash ใหม่ ผมขอประกาศล้มละลายทางหนี้เทคนิค เริ่มใหม่ตั้งแต่ต้นด้วย TypeScript และ Rollup ไม่มี FP wrapper กระแสนั้นจบแล้ว ขอแสดงความเสียใจกับเพื่อนร่วมงานของคนที่นำความปวดหัวนั้นเข้ามาใน codebase มันไม่เป็นมิตรทั้งกับทีมและกับคนเลย
  ไม่รู้ว่าจะเป็นไปตามนี้ 100% หรือไม่ แต่ดูเหมือนจะใกล้เคียงมาก
  [1]: https://twitter.com/jdalton/status/1571863497969119238

  • “กระแสนั้นจบแล้ว ขอแสดงความเสียใจกับเพื่อนร่วมงานของคนที่นำความปวดหัวนั้นเข้ามาใน codebase มันไม่เป็นมิตรทั้งกับทีมและกับคนเลย” — ผู้เขียนต้นฉบับไม่ใช่เจ้าตัวเองเหรอ?
    ฟังดูเหมือนมีคนอื่นเพิ่มความซับซ้อนที่เขากำลังวิจารณ์เข้าไป ถ้าเป็นสิ่งที่เขานำเข้ามาเอง ก็ดูเหมือนเขาพูดในทำนองว่าเคยพัฒนาโปรเจกต์ตามกระแส แล้วตอนนี้กระแสนั้นจบแล้ว ถึงเวลาย้ายไปสิ่งถัดไป มากกว่าจะพูดแบบทบทวนหรือเรียนรู้จากมัน
  • FP wrapper คืออะไร และมันเป็นกระแสแบบไหน?
  • ผมไม่ค่อยรู้เรื่อง issue ฝั่ง JavaScript เท่าไร ในบริบทนี้ functional programming มีปัญหาอะไรเหรอ?

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

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

• ข่าวที่ใหญ่กว่าคือ Lodash จะย้ายจาก Node.js ไปใช้ Bun: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...

  • ว้าว
    ผมเริ่มสนใจจะย้ายแพ็กเกจของตัวเองไป Bun แล้ว แต่ยังลังเลเพราะกังวลเรื่องความเข้ากันได้ และ Bun จะอยู่รอดต่อไปจริงไหม เคยเจ็บนิด ๆ กับ “Modern Yarn” มาก่อนด้วย แต่พอเห็น lodash ย้ายแล้ว ตอนนี้ก็อยากพิจารณาอย่างจริงจังมากขึ้น
  • นี่เป็นข่าวใหญ่จริง โดยเฉพาะเมื่อคิดว่าถึงจะเพิ่งออก v1.0 ไปไม่นาน แต่บน Windows ยังมี ปัญหาด้านประสิทธิภาพ อยู่

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

  • แต่ผู้ใช้ส่วนใหญ่ใช้เวลาเพียงเล็กน้อยในการเขียน issue รายงานบั๊กส่วนใหญ่คุณภาพแย่มาก
  • issue ถูกปิด ไม่ได้หายไป ถ้ายังเกี่ยวข้องอยู่ ก็น่าจะขอใหม่ได้ในภายหลัง

• ติดแท็ก issue bankruptcy แล้วปิด 363 issue: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl...
  PR ก็ 325 รายการ ถูกจัดการแบบเดียวกัน: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...

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

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

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

  • แน่นอนว่ามันสะดวก แต่สุดท้ายถ้าจำเป็น ผมน่าจะชอบยูทิลิตีเวอร์ชันที่ทำเองมากกว่า
  • เห็นด้วยอย่างยิ่ง แค่ spread syntax หรือพูดตรงๆ คือ ... อันเดียว ก็ให้ผลลัพธ์มหาศาลแล้ว https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... iterator helpers ก็กำลังจะถูกปล่อยออกมาเร็วๆ นี้ ซึ่งจะช่วยได้มาก ส่วน async iterator helpers น่าจะล่าช้าไปอีกสักพัก https://github.com/tc39/proposal-iterator-helpers
    เมื่อก่อนรู้สึกว่าใน codebase ที่ทำอยู่ ต้องใช้ .apply() หลายครั้งต่อสัปดาห์เพื่อเรียกฟังก์ชันแบบสร้างสรรค์ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... ตอนนี้สิ่งเหล่านั้นหายไปหมดแล้ว และถ้าถามว่าสมาชิกทีม 50% รู้จัก .call กับ .apply ไหม ผมว่าคงประมาณครึ่งต่อครึ่ง
    Chrome 117 มี Object.groupBy() เข้ามา และน่าจะช่วยได้มากในการกำจัดจุดท้ายๆ หลายจุดที่ทำให้ต้องใช้ lodash https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  • ผมไม่ได้ใช้ lodash หรือ underscore.js มาตั้งแต่ 8 ปีก่อนแล้ว ไม่ค่อยแน่ใจว่ามีอะไรที่ทำด้วย map, filter, find ฯลฯ ไม่ได้ง่ายๆ บ้าง

• issue tracker มีการใช้งานสองแบบที่ทับซ้อนกันอยู่ แบบหนึ่งคือเป็นวิธีให้ maintainer ติดตามงานที่ต้องทำ อีกแบบหนึ่งคือเป็นวิธีให้ชุมชนและผู้ใช้ในวงกว้างติดตามข้อบกพร่องของซอฟต์แวร์
  การประกาศ “issue bankruptcy” นั้นสมเหตุสมผลสำหรับการใช้งานแบบแรก แต่สำหรับแบบที่สอง มันคือการลบ ข้อมูลที่มีคุณค่า เกี่ยวกับ issue ที่ยังมีอยู่ในเวอร์ชันปัจจุบัน