Việc này thật sự khá hai mặt. Một mặt thì rất hay. Chắc ai cũng từng trải qua những cuộc họp dọn backlog kiểu cào từ trên xuống dù biết là sẽ không bao giờ chạm tới cuối, và cảm giác đó rõ ràng là rất khổ sở.
Mặt khác, vấn đề đâu có biến mất, chỉ là đổi nhãn thôi; nếu tất cả chỉ là chuyện gắn thẻ và sắp xếp, thì có lẽ cứ để nó trôi theo dòng chảy thay vì cố kiểm soát một kiểu không tưởng giả tạo là danh sách issue hoàn toàn trống. Chắc chắn cũng có lợi ích khi để những ghi chú như vậy ở nơi mọi người thấy được. Cảm giác giống như khi tổng vệ sinh, đã quyết định vứt đi nhưng tiềm thức vẫn bảo giữ lại vì biết đâu sau này cần.
Dù vậy, nhìn chung tôi nghiêng về phía ủng hộ. Ít nhất thì nó có thể mang lại cảm giác giải phóng và giúp nạp lại năng lượng cho các issue mới.
Bổ sung thêm chút bối cảnh: tác giả đang viết lại toàn bộ.
Có lẽ sẽ gọn gàng hơn nếu phát hành bản viết lại trước rồi đóng các issue cũ dưới dạng deprecated. Các issue của nhánh viết lại cũng có thể được tách bằng tag phiên bản. Nếu đóng khi phiên bản mới vẫn chưa xong, người đóng góp có thể mở issue mới cho phiên bản cũ mà không biết rằng nó không còn được hỗ trợ nữa.
Dù vậy, không phải họ phớt lờ issue và để vấn đề nằm lại trong codebase; cả dự án đang được chỉnh trang lại từ đầu. https://twitter.com/jdalton/status/1571863497969119238
Từ góc nhìn người dùng, nếu kiểu “dọn dẹp” này nghĩa là đóng issue thì có vấn đề. Nếu đó là issue vẫn còn tồn tại trong sản phẩm, nó nên được để mở, cả vì mục đích tài liệu hóa lẫn để người dùng gặp cùng vấn đề có thể dễ dàng tìm thấy và bổ sung thông tin.
Tôi nghĩ dự án thừa nhận sự tồn tại của issue và để nó mở thì trung thực hơn. Từ góc nhìn nhà phát triển, nếu số lượng issue gây khó chịu thì tốt hơn nên dùng bộ lọc để ẩn các issue cũ không quan trọng.
Tôi cũng thấy hai mặt. Một mặt, mỗi khi quay lại làm việc với JavaScript tôi lại tìm đến lodash. Mặt khác, tôi nghĩ gần một nửa thư viện này đáng lẽ phải nằm trong thư viện chuẩn.
Chẳng phải đây là việc mà các mô hình ngôn ngữ lớn nên làm tốt sao? Ý tôi là tóm tắt ticket.
Vì vậy Basecamp không duy trì backlog. Việc quan trọng rồi sẽ tự nổi lên lại.
jwz từng nói thế này:
Tôi nghĩ đây là cách phổ biến nhất mà các bug tôi báo cáo cho dự án phần mềm nguồn mở bị đóng lại. Bạn báo bug, nó không được đọc trong 1 năm, đôi khi 2 năm, rồi một ngày nọ module đó được viết lại từ đầu. Và maintainer mới thì không có ý định kiểm tra xem phiên bản mới có thật sự giải quyết các vấn đề đã biết từng tồn tại ở phiên bản trước hay không.
Với dự án có ít maintainer hoặc dự án một người, chẳng phải hợp lý hơn nếu người báo bug tự dành 10–15 phút mỗi người để kiểm tra xem vấn đề còn tồn tại không, thay vì maintainer đơn độc phải mất từ vài ngày đến vài tuần để xác minh sao?
Đặc biệt nếu bug khó tái hiện hoặc phức tạp, ngay từ đầu cũng chưa chắc maintainer có thể tái hiện trong môi trường của họ, và người báo cáo có khả năng quen với việc quan sát bug đó hơn.
Nếu có một đội ngũ lớn hơn hoặc đó là dự án đi kèm một dịch vụ thương mại, cán cân này có thể hơi khác.
Điều thường thấy ở nhiều dự án phần mềm tự do/nguồn mở là rất ít người sẵn sàng xắn tay vào làm, nhưng đồng thời lại dành khá nhiều thời gian để nói dự án đó thiết yếu với họ ra sao, đưa ra yêu cầu và rất nhiều đề xuất.
Đa số tạo issue mới để thông báo danh sách mong muốn, hoặc để lại báo cáo bug rất mơ hồ. Một số trong đó cũng đưa ra báo cáo bug tử tế, nhưng ý chí đóng góp thường chỉ đến vậy.
Cá nhân tôi không có ý chí xử lý một cách ngoại giao phần lớn các bình luận thường thấy, nên tính cách tôi không hợp làm maintainer dự án.
Dù vậy, với các issue tôi báo cáo, tôi luôn cố làm phần việc của mình bằng cách truy nguyên nguyên nhân và, nếu có thể, gửi PR sửa lỗi.
Cũng có biến thể của chuyện đó. Một issue được báo cho một phiên bản chính, rồi khi phiên bản chính mới ra, dù không phải viết lại mà chỉ là thay đổi dần dần, họ vẫn đóng toàn bộ issue của bản phát hành cũ với lý do vấn đề có thể không còn nữa.
Chỉ cần tạo một PR chứa test đáng lẽ phải pass nhưng hiện được đánh dấu là bỏ qua. Khi đó, lúc tái xây dựng sẽ có một đường dễ dàng để kiểm tra tiến độ và xem nó có được cải thiện hay không.
Nếu thật sự quan tâm đến vấn đề thì nên thêm test.
Các phát hiện về bảo mật đôi khi cũng bị xử lý như vậy.
Trải nghiệm của tôi với các dự án phần mềm nguồn đóng cũng tương tự.
John-David Dalton, tác giả của lodash, [đã viết như sau vào năm ngoái][1]:
Trong lần viết lại lodash, tôi tuyên bố phá sản nợ kỹ thuật. Bắt đầu lại từ đầu với TypeScript và Rollup. Không có FP wrapper. Trào lưu đó đã kết thúc. Xin chia buồn với đồng nghiệp của người đã đưa cục nợ đó vào codebase. Nó hoàn toàn không thân thiện với đội ngũ lẫn con người.
Tôi không biết liệu có đúng 100% như vậy không, nhưng có vẻ khá gần.
[1]: https://twitter.com/jdalton/status/1571863497969119238
“Trào lưu đó đã kết thúc. Xin chia buồn với đồng nghiệp của người đã đưa cục nợ đó vào codebase. Nó hoàn toàn không thân thiện với đội ngũ lẫn con người” — chẳng phải tác giả gốc chính là ông ấy sao?
Nghe như thể có ai khác đã thêm sự phức tạp mà ông ấy đang phê phán. Nếu chính ông ấy đưa vào, cách nói này giống như: dự án được phát triển theo một trào lưu, giờ trào lưu đó hết thời nên đã đến lúc chuyển sang thứ tiếp theo, hơn là một sự nhìn lại hay bài học rút ra.
FP wrapper là gì, và đó là trào lưu nào?
Tôi không rành các issue phía JavaScript, nhưng trong bối cảnh này thì lập trình hàm có vấn đề gì?
Làm tốt lắm
Chỉ cần nhìn vài PR ở đầu danh sách cũng thấy những thứ như sau
Thêm một từ vào chú thích, thêm file cấu hình để quảng bá dịch vụ phát triển, đổi var thành let, thay đổi hành vi đã được thiết lập tốt của một hàm cốt lõi, xóa dấu chấm phẩy, v.v.
Phần lớn có lẽ được mở với ý định tốt là cải thiện thư viện, nhưng đến một lúc nào đó với maintainer thì chúng chỉ trở thành spam, hoặc tệ hơn là thành gánh nặng làm tăng cảm giác tội lỗi khi càng không thể để tâm tới
Giống như người nổi tiếng thuê vệ sĩ và đi khoang hạng nhất hoặc máy bay riêng để tránh sự chú ý không ngừng và giữ gìn tinh thần, tôi tự hỏi các dự án mã nguồn mở nổi tiếng có thể có biện pháp gì
Cá nhân tôi, với tư cách maintainer mã nguồn mở, thích nhất các PR sửa lỗi chính tả, chỉnh câu chữ, refactor tự động. Chúng gần như không tốn công review nên hầu như lúc nào tôi cũng merge rất nhanh
Tốn thời gian nhất là các PR triển khai tính năng khổng lồ. Vì cần nhiều review và thảo luận nên tôi cứ trì hoãn việc xem kỹ
Đã có một thời gian việc mở các PR vụn vặt cho các dự án nổi tiếng trở thành trào lưu. Tôi nghĩ đó là nỗ lực để làm đẹp CV
Từng có một người dùng GitHub nhất định liên tục gửi PR chỉ đổi var thành let cho nhiều dự án JavaScript
Cảm giác như để lấp đầy hồ sơ GitHub
Wow
Tôi bắt đầu thấy hứng thú với việc chuyển package của mình sang Bun, nhưng vẫn do dự vì lo về khả năng tương thích và liệu Bun có thật sự sống sót lâu dài không. Tôi cũng từng hơi “bị bỏng” với “Modern Yarn”. Nhưng thấy lodash chuyển sang thì giờ tôi muốn xem xét nghiêm túc hơn
Đây đúng là tin lớn. Đặc biệt nếu xét đến việc dù mới có bản phát hành v1.0 gần đây, Bun vẫn có vấn đề hiệu năng trên Windows
Tôi cố tránh bảo các nhà phát triển mã nguồn mở phải vận hành dự án của họ thế này thế kia. Tôi cũng là nhà phát triển mã nguồn mở, và nếu người khác làm vậy với tôi thì tôi sẽ khó chịu
Nhưng nếu tôi là người dùng đã dành khá nhiều thời gian viết issue và giúp giải quyết vấn đề, hoặc là người đã làm bản sửa hay tính năng mới rồi gửi PR, thì lúc này chắc tôi sẽ khá nản
Nhưng phần lớn người dùng chỉ bỏ ra rất ít thời gian để viết issue. Đa số báo cáo lỗi đều rất tệ
Issue chỉ bị đóng chứ không biến mất. Nếu vẫn còn liên quan thì có lẽ sau này có thể yêu cầu lại
Phá sản issue là có thật. Theo kinh nghiệm cá nhân, đến một lúc nào đó việc duy trì mã nguồn mở trở nên khó dung hòa với cuộc sống ngoài đời
Công việc thì miễn phí và thường không được cảm ơn. Tất nhiên không phải lúc nào cũng vậy. Vấn đề thì phức tạp, lại phải cạnh tranh với các trách nhiệm đời thực như công việc, gia đình và nghỉ ngơi. Người ta dễ nổi cáu, thường xuyên muốn tranh luận hoặc nhờ đọc tài liệu hộ. Khi mã nguồn mở nổi tiếng thì cũng kéo theo trách nhiệm khổng lồ
Tôi dự đoán sẽ có một sự sụp đổ lớn trong hệ sinh thái mã nguồn mở khi những người dẫn dắt dự án nói “thôi đủ rồi” và rời đi để làm những việc quan trọng hơn
Tôi hiểu điều đó. Dạo này tôi thậm chí nghĩ rằng các dự án cá nhân không hề nhỏ giống nghiện ngập hoặc tự hại bản thân hơn là dự án thực sự
Tuy vậy, hệ sinh thái mã nguồn mở cực kỳ kém hiệu quả. Có lodash, underscore và vô số thư viện khác, nhưng không phải tất cả đều cần tồn tại. Cũng có nhiều thư viện chỉ làm một việc, và thường là tập con của những thư viện này
Phần lớn những thứ này được dùng cùng minifier và tree shaking, các chức năng không dùng sẽ bị loại bỏ. Ngay cả thư viện nặng cũng dễ tối ưu và phần lớn gồm các phần tách rời, nên không nhất thiết cần thư viện nhẹ; nỗ lực phát triển nhìn chung tăng gần như tuyến tính
Nếu không phải vì lập trình viên yêu sự tao nhã và đơn giản hơn tất cả, và cứ muốn viết lại để làm tốt hơn dù chỉ một chút, thì tôi nghĩ mã nguồn mở vẫn có đủ nhân lực ngay cả khi mọi người chỉ dành một phần tư thời gian so với hiện tại
Lodash là một thư viện tuyệt vời. Hầu như dự án nào tôi làm cũng dùng một chút
Nhưng khi JavaScript ngày càng tốt hơn, lượng Lodash tôi dùng cũng ngày càng giảm. Mỗi khi định dùng, tôi đều kiểm tra xem việc mình muốn làm có tính năng tích hợp sẵn hay không. Tôi cũng khá thường xuyên bình luận trên PR kèm link rằng “cái này không cần Lodash”
Dù vậy, tôi hy vọng đây không phải là tín hiệu dự án đang rút lui
Chắc chắn là tiện lợi, nhưng rốt cuộc nếu cần, có lẽ tôi vẫn thích phiên bản tiện ích tự viết hơn
Từ 8 năm trước tôi đã không dùng lodash hay underscore.js nữa. Tôi không rõ có gì mà không thể làm dễ dàng bằng map, filter, find, v.v.
Trình theo dõi issue đang chồng lấn hai mục đích. Một là cách để maintainer theo dõi những việc cần làm, mục đích còn lại là cách để cộng đồng rộng hơn và người dùng theo dõi các lỗi của phần mềm
Việc tuyên bố “phá sản issue” có lý với mục đích thứ nhất, nhưng với mục đích thứ hai thì đó là xóa đi thông tin có giá trị về các issue vẫn tồn tại trong phiên bản hiện tại
1 bình luận
Ý kiến trên Hacker News
Việc này thật sự khá hai mặt. Một mặt thì rất hay. Chắc ai cũng từng trải qua những cuộc họp dọn backlog kiểu cào từ trên xuống dù biết là sẽ không bao giờ chạm tới cuối, và cảm giác đó rõ ràng là rất khổ sở.
Mặt khác, vấn đề đâu có biến mất, chỉ là đổi nhãn thôi; nếu tất cả chỉ là chuyện gắn thẻ và sắp xếp, thì có lẽ cứ để nó trôi theo dòng chảy thay vì cố kiểm soát một kiểu không tưởng giả tạo là danh sách issue hoàn toàn trống. Chắc chắn cũng có lợi ích khi để những ghi chú như vậy ở nơi mọi người thấy được. Cảm giác giống như khi tổng vệ sinh, đã quyết định vứt đi nhưng tiềm thức vẫn bảo giữ lại vì biết đâu sau này cần.
Dù vậy, nhìn chung tôi nghiêng về phía ủng hộ. Ít nhất thì nó có thể mang lại cảm giác giải phóng và giúp nạp lại năng lượng cho các issue mới.
Có lẽ sẽ gọn gàng hơn nếu phát hành bản viết lại trước rồi đóng các issue cũ dưới dạng deprecated. Các issue của nhánh viết lại cũng có thể được tách bằng tag phiên bản. Nếu đóng khi phiên bản mới vẫn chưa xong, người đóng góp có thể mở issue mới cho phiên bản cũ mà không biết rằng nó không còn được hỗ trợ nữa.
Dù vậy, không phải họ phớt lờ issue và để vấn đề nằm lại trong codebase; cả dự án đang được chỉnh trang lại từ đầu.
https://twitter.com/jdalton/status/1571863497969119238
Tôi nghĩ dự án thừa nhận sự tồn tại của issue và để nó mở thì trung thực hơn. Từ góc nhìn nhà phát triển, nếu số lượng issue gây khó chịu thì tốt hơn nên dùng bộ lọc để ẩn các issue cũ không quan trọng.
jwz từng nói thế này:
Đặc biệt nếu bug khó tái hiện hoặc phức tạp, ngay từ đầu cũng chưa chắc maintainer có thể tái hiện trong môi trường của họ, và người báo cáo có khả năng quen với việc quan sát bug đó hơn.
Nếu có một đội ngũ lớn hơn hoặc đó là dự án đi kèm một dịch vụ thương mại, cán cân này có thể hơi khác.
Điều thường thấy ở nhiều dự án phần mềm tự do/nguồn mở là rất ít người sẵn sàng xắn tay vào làm, nhưng đồng thời lại dành khá nhiều thời gian để nói dự án đó thiết yếu với họ ra sao, đưa ra yêu cầu và rất nhiều đề xuất.
Đa số tạo issue mới để thông báo danh sách mong muốn, hoặc để lại báo cáo bug rất mơ hồ. Một số trong đó cũng đưa ra báo cáo bug tử tế, nhưng ý chí đóng góp thường chỉ đến vậy.
Cá nhân tôi không có ý chí xử lý một cách ngoại giao phần lớn các bình luận thường thấy, nên tính cách tôi không hợp làm maintainer dự án.
Dù vậy, với các issue tôi báo cáo, tôi luôn cố làm phần việc của mình bằng cách truy nguyên nguyên nhân và, nếu có thể, gửi PR sửa lỗi.
Nếu thật sự quan tâm đến vấn đề thì nên thêm test.
John-David Dalton, tác giả của lodash, [đã viết như sau vào năm ngoái][1]:
Nghe như thể có ai khác đã thêm sự phức tạp mà ông ấy đang phê phán. Nếu chính ông ấy đưa vào, cách nói này giống như: dự án được phát triển theo một trào lưu, giờ trào lưu đó hết thời nên đã đến lúc chuyển sang thứ tiếp theo, hơn là một sự nhìn lại hay bài học rút ra.
Làm tốt lắm
Chỉ cần nhìn vài PR ở đầu danh sách cũng thấy những thứ như sau
Thêm một từ vào chú thích, thêm file cấu hình để quảng bá dịch vụ phát triển, đổi
varthànhlet, thay đổi hành vi đã được thiết lập tốt của một hàm cốt lõi, xóa dấu chấm phẩy, v.v.Phần lớn có lẽ được mở với ý định tốt là cải thiện thư viện, nhưng đến một lúc nào đó với maintainer thì chúng chỉ trở thành spam, hoặc tệ hơn là thành gánh nặng làm tăng cảm giác tội lỗi khi càng không thể để tâm tới
Giống như người nổi tiếng thuê vệ sĩ và đi khoang hạng nhất hoặc máy bay riêng để tránh sự chú ý không ngừng và giữ gìn tinh thần, tôi tự hỏi các dự án mã nguồn mở nổi tiếng có thể có biện pháp gì
Tốn thời gian nhất là các PR triển khai tính năng khổng lồ. Vì cần nhiều review và thảo luận nên tôi cứ trì hoãn việc xem kỹ
varthànhletcho nhiều dự án JavaScriptCảm giác như để lấp đầy hồ sơ GitHub
Tin lớn hơn là Lodash sẽ chuyển từ Node.js sang Bun: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...
Tôi bắt đầu thấy hứng thú với việc chuyển package của mình sang Bun, nhưng vẫn do dự vì lo về khả năng tương thích và liệu Bun có thật sự sống sót lâu dài không. Tôi cũng từng hơi “bị bỏng” với “Modern Yarn”. Nhưng thấy lodash chuyển sang thì giờ tôi muốn xem xét nghiêm túc hơn
Tôi cố tránh bảo các nhà phát triển mã nguồn mở phải vận hành dự án của họ thế này thế kia. Tôi cũng là nhà phát triển mã nguồn mở, và nếu người khác làm vậy với tôi thì tôi sẽ khó chịu
Nhưng nếu tôi là người dùng đã dành khá nhiều thời gian viết issue và giúp giải quyết vấn đề, hoặc là người đã làm bản sửa hay tính năng mới rồi gửi PR, thì lúc này chắc tôi sẽ khá nản
Họ đã gắn nhãn
issue bankruptcyvà đóng 363 issue: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl...PR cũng có 325 cái theo cách tương tự: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...
Phá sản issue là có thật. Theo kinh nghiệm cá nhân, đến một lúc nào đó việc duy trì mã nguồn mở trở nên khó dung hòa với cuộc sống ngoài đời
Công việc thì miễn phí và thường không được cảm ơn. Tất nhiên không phải lúc nào cũng vậy. Vấn đề thì phức tạp, lại phải cạnh tranh với các trách nhiệm đời thực như công việc, gia đình và nghỉ ngơi. Người ta dễ nổi cáu, thường xuyên muốn tranh luận hoặc nhờ đọc tài liệu hộ. Khi mã nguồn mở nổi tiếng thì cũng kéo theo trách nhiệm khổng lồ
Tôi dự đoán sẽ có một sự sụp đổ lớn trong hệ sinh thái mã nguồn mở khi những người dẫn dắt dự án nói “thôi đủ rồi” và rời đi để làm những việc quan trọng hơn
Tuy vậy, hệ sinh thái mã nguồn mở cực kỳ kém hiệu quả. Có lodash, underscore và vô số thư viện khác, nhưng không phải tất cả đều cần tồn tại. Cũng có nhiều thư viện chỉ làm một việc, và thường là tập con của những thư viện này
Phần lớn những thứ này được dùng cùng minifier và tree shaking, các chức năng không dùng sẽ bị loại bỏ. Ngay cả thư viện nặng cũng dễ tối ưu và phần lớn gồm các phần tách rời, nên không nhất thiết cần thư viện nhẹ; nỗ lực phát triển nhìn chung tăng gần như tuyến tính
Nếu không phải vì lập trình viên yêu sự tao nhã và đơn giản hơn tất cả, và cứ muốn viết lại để làm tốt hơn dù chỉ một chút, thì tôi nghĩ mã nguồn mở vẫn có đủ nhân lực ngay cả khi mọi người chỉ dành một phần tư thời gian so với hiện tại
Lodash là một thư viện tuyệt vời. Hầu như dự án nào tôi làm cũng dùng một chút
Nhưng khi JavaScript ngày càng tốt hơn, lượng Lodash tôi dùng cũng ngày càng giảm. Mỗi khi định dùng, tôi đều kiểm tra xem việc mình muốn làm có tính năng tích hợp sẵn hay không. Tôi cũng khá thường xuyên bình luận trên PR kèm link rằng “cái này không cần Lodash”
Dù vậy, tôi hy vọng đây không phải là tín hiệu dự án đang rút lui
..., đã mang lại hiệu quả rất lớn. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Các iterator helper cũng sắp được phát hành, nên sẽ giúp ích rất nhiều. Async iterator helper có lẽ sẽ còn chậm một thời gian. https://github.com/tc39/proposal-iterator-helpersTrước đây tôi có cảm giác trong codebase mình làm việc, hầu như tuần nào cũng phải dùng
.apply()nhiều lần để gọi hàm theo cách sáng tạo. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Giờ thì tất cả đã biến mất, và nếu nói 50% đồng đội biết.callvà.applythì có lẽ cũng chỉ là năm ăn năm thuaChrome 117 có
Object.groupBy(), và tính năng này sẽ giúp loại bỏ nhiều điểm cuối cùng khiến người ta còn phải dùng lodash. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...map,filter,find, v.v.Trình theo dõi issue đang chồng lấn hai mục đích. Một là cách để maintainer theo dõi những việc cần làm, mục đích còn lại là cách để cộng đồng rộng hơn và người dùng theo dõi các lỗi của phần mềm
Việc tuyên bố “phá sản issue” có lý với mục đích thứ nhất, nhưng với mục đích thứ hai thì đó là xóa đi thông tin có giá trị về các issue vẫn tồn tại trong phiên bản hiện tại