Giả sử bạn đang một task là nâng cấp một thư viện NPM lên bản mới nhất, hào hứng vì nó cũng là thử thách khả năng phân tích độ khả thi, rủi ro, và các thay đổi nếu có, cũng vừa có lập trình trong đó. Cho đến khi bạn nhận ra rằng thư viện đó.. không hề có phiên bản mới hơn 🙁
Một trong những câu mình nghe được từ anh/chị đi trước là: nếu nó chạy, đừng chạm vào. Hồi lúc đầu cũng suy nghĩ là tại sao họ lại sợ vậy ta, sợ cải tiến hay thay đổi chẳng hạn. Hồi đó mới ra trường mà, ứng dụng xây bởi mình cũng chẳng phải là hầm hố như hệ thống doanh nghiệp, nên nghĩ là cải tiến/thay đổi luôn là điều tốt. Việc này theo mình vẫn là đúng, nhưng giờ phải thêm một yếu tố khác nữa là độ ảnh hưởng, chi phí và lợi ích mà thay đổi đó mang lại.
Giả sử bỏ ra nhiều thời gian, công sức và chi phí cho một sự cải thiện nhưng không mang lại hiệu quả xứng đáng, thì đôi khi.. thôi.
Ủa vậy thì chẳng lẽ hệ thống nào cũng chỉ tới mức chạy được, còn cải tiến.. "thì thôi"?
Dĩ nhiên là không rồi. Tuỳ vào hoàn cảnh khi đó mà có quyết định có nâng cấp/cải tiến hay không. Có rất nhiều hệ thống xây dựng trên công nghệ cũ, có thể nói là rất chậm, giật lag, UI/UX thấy mà ghê, nhưng mà nó vẫn tồn tại cho tới giờ, đơn giản là vì nó "vẫn" còn đáp ứng được nhu cầu, như là lí do mà nó được xây nên.
Trở lại vấn đề, trong trường hợp này, cần xem xét độ "cần thiết" của việc nâng cấp. Rằng nó có thực sự cần thiết hay không?
Một thư viện xây nên bởi bên thứ 3 nên được bảo trì bởi những người dựng nên nó, hoặc chí ít là cộng đồng người sử dụng và đóng góp xây dựng/bảo trì nó. Tự dưng mình nhảy vào, không hiểu thư viện đó xây như thế nào, nó làm gì, cần kiểm tra gì... các thứ.. thì thôi!
Cần đánh giá rủi ro của việc này, nếu như việc thay đổi mang lại nhiều rủi ro hơn cho hệ thống/khách hàng/người dùng, thì cần được trao đổi thêm rồi đưa ra quyết định.
Sự rõ ràng là cần thiết
Cần trao đổi rõ ràng với khách hàng/đối tác hoặc quản lý của bạn về vấn đề này, nêu lên những rủi ro mà bạn thấy, tư vấn và yêu cầu quyết định từ họ trước khi chọn dừng lại hay tiếp tục nâng cấp.
Chọn không nâng cấp không phải là điều tệ hại nếu như đó là cách tối ưu nhất lúc này, nhất là khi hệ thống đang được sử dụng bởi người dùng.
Trong trường hợp bạn hiểu rằng mình phải nâng cấp nó, cách này hay cách khác, thì đây là một sự lựa chọn tham khảo.
Ví dụ:
Moment.js đã được khuyến cáo không sử dụng bởi nhà phát triển cho những ứng dụng mới vì những tính năng mà nó cung cấp đã được hỗ trợ bởi chính ngôn ngữ xây dựng (và lí do bảo mật). Trường hợp này, lựa chọn nâng cấp moment.js có vẻ không khả thi nếu như nó chẳng còn một phiên bản nào mới hơn và dựa vào khuyến cáo của nhà phát triển, bạn có lẽ nên tìm sự thay thế.
moment.js có giới thiệu một loạt các thư viện tương tự với sự cải tiến trong bảo mật và tính năng, vì vậy, những thư viện này có thể được xem xét thay thế cho moment.js như một sự nâng cấp.
Đây là bước cuối cùng trong sự xem xét, vì nó cũng mang lại nhiều rủi ro nhất cho dự án. Điều này cần được đánh giá trước khi thực hiện.
Điều này xảy ra khi thư viện bạn dùng quá chuyên hoá, khó có sự thay thế, nhưng xui cái là nhà phát triển cũng bỏ rơi nó luôn..
Ủa thế tại sao nó lại bị bỏ rơi? Mình không biết 🤷♀️.
Nhưng điều này xảy ra khi mà trước đó, bạn hoặc người trước bạn đã sử dụng nó mà quên xem xét hoặc cân nhắc tính lâu dài của thư viện. Mẹo là hãy nên sử dụng những thư viện có tiếng, được tải và sử dụng bởi nhiều người, để có cập nhật, bảo trì, báo lỗi gì cũng dễ hơn, và quan trọng là nó ổn định hơn.
Khi chọn tự nâng cấp, bạn cần phải biết bạn sẽ làm gì, và làm sao để kiểm tra sự thay đổi có phù hợp. Nhưng nếu bạn nâng cấp thành công, thì bạn là một cao thủ rồi còn gì nữa! Chúc mừng! 🥳🥳
