Bài viết được sự cho phép của tác giả Phạm Bình
Chào các bạn,
Các dự án phần mềm ngày nay thường được tích hợp rất nhiều các thư viện bên thứ 3. Một phần vì chúng quá tốt, một phần vì các developer ngày càng… lười code. Mặc dù không phủ nhận được việc tích hợp thư viện bên thứ 3 giúp chúng ta tiết kiệm được một lượng lớn thời gian để code và debug, nhưng bên cạnh đó việc làm này cũng tiềm ẩn nhiều rủi ro cho dự án. Rủi ro thế nào thì mời các bạn cùng lắng nghe quan điểm của mình nhé.
I. Thư viện bên thứ 3 là gì?
Giải thích một chút.
Thư viện bên thứ 3 trong bài viết này là ý chỉ những thư viện được phát triển bởi một bên khác, nhưng bạn lại mang về sử dụng. Trong lập trình web php, một số thư viện bên thứ 3 nổi tiếng có thể kể đến như: Phpmailer, PHPExcel, Ddoctrine,… chẳng hạn.
II. Nhược điểm của việc thường xuyên sử dụng thư viện bên thứ 3
2.1 Không có gì là mãi mãi
Không có gì đảm bảo thư viện thứ 3 mà bạn đang tích hợp sẽ được duy trì mãi mãi, nó có thể “chết” bất cứ lúc nào. Đồng ý rằng điều này rất khó xảy ra ở các thư viện được nhiều người sử dụng vì không có người này thì sẽ có người kia duy trì. Tuy nhiên lại xảy ra như cơm bữa đối với các thư viện ít người dùng.
Bản thân mình đã từng gặp trường hợp này 2 lần, chính tác giả của thư viện đó còn để lại một dòng nhắn nhủ “thư viện đã dừng hỗ trợ, vui lòng thử thư viện khác thay thế” – thật đáng buồn.
2.2 Khó kiểm soát
Thông thường các công cụ quản lý gói như composer, npm sẽ thay chúng ta kiểm soát các thư viện. Tuy nhiên việc kiểm soát chỉ có hiệu quả khi tác giả của thư viện tuân theo đúng quy tắc và không bao giờ bị nhầm lẫn.
Ví dụ một thư viện chỉ chạy được trên phiên bản PHP 7.0, nhưng tác giả lại “lỡ tay” để cấu hình phiên bản PHP tối thiểu là 5.0. Điều này khiến các sản phẩm chạy trên php 5.0 có thể không hoạt động. Việc nhầm lẫn tưởng chừng như “đùa” này thực tế vẫn xảy ra, mình đã gặp 1 lần (có thể do số mình đen) và chứng kiến một số trường hợp trên khác qua các github issue.
Việc khó kiểm soát system requirements như ví dụ trên đã đủ làm dự án bị “chao đảo”. Đó là còn chưa kể tới việc chúng ta rất khó kiểm soát được bên trong thư viện đó viết gì, có gặp phải lỗi nghiêm trọng nào không, thuật toán xử lý có tối ưu không, có gắn code đào bitcoin hay không,…
2.3 Cồng kềnh
Một thư viện được viết ra để giải quyết nhiều bài toán chứ không riêng gì bài toán của bạn, vì vậy nó thường hỗ trợ nhiều tính năng “thừa” mà có thể bạn chẳng bao giờ dùng tới. Điều này vô tình làm cho source code dự án của bạn càng ngày càng phình to.
Nếu như bạn cảm thấy việc source phình to không phải là vấn đề vì server của bạn unlimited dung lượng, vậy thì việc làm giảm hiệu năng của dự án có làm bạn lo lắng? Đúng vậy, vì một thư viện có thể giải quyết nhiều trường hợp nên “dữ liệu đầu vào” của bạn cũng sẽ phải đi qua nhiều logic hơn trước khi nó được “chế biến” thành kết quả mong muốn. Điều này chắc chắn sẽ ảnh hưởng tới hiệu năng của sản phẩm.
Bạn cần biết rằng có rất nhiều doanh nghiệp chi không ít tiền chỉ hệ thống của họ chạy nhanh hơn 0.1s.
2.4 Làm “teo não” của các developer
Việc thường xuyên tích hợp thư viện bên thứ 3 vô tình tạo nên thói quen lười suy nghĩ cho developer. Thậm chí mình từng nghe thấy có người nói rằng “Trước khi làm tính năng gì đó, hãy search thư viện trước, nếu có thì mang về dùng luôn cho tiện“.
Thói quen này khiến chúng ta trở nên thụ động, bị phụ thuộc vào người tạo ra thư viện và hạn chế khả năng tư duy của bản thân. Về lâu về dài, đây chính là nguyên sẽ giết chết bạn trên con đường sự nghiệp.
2.5 Tưởng chừng tiết kiệm thời gian mà lại chẳng phải
Lợi ích lớn nhất của việc sử dụng thư viện là để tiết kiệm thời gian, nhưng đôi khi lại ngược lại – càng dùng thư viện càng tốn thời gian. Tại sao lại vậy ưu? Bởi vì bạn sẽ phải tốn thời gian để đọc tài liệu sử dụng, tốn thời gian để xem cộng đồng nói gì về nó, tốn thời gian để nghiên cứu nó có thật sự giải quyết được vấn đề của bạn, hoặc tốn thời gian để debug chính cái thư viện đó… Bằng từng ấy thời gian nếu bạn tự code thì có khi đã xong lâu rồi.
III. Kết luận
Qua loạt phân tích trên, vậy thì Có nên sử dụng thư viện bên thứ 3 trong dự án? Câu trả lời của mình là có, nhưng phải chọn lọc. Bởi nếu không sử dụng thì chúng ta sẽ bỏ qua một nguồn tài nguyên to lớn, thậm chí nhiều ngôn ngữ lập trình, hay framework, opensouce thì nhiều thư viện còn là một lợi thế. Nhưng nếu cứ sử dụng tùy tiện, bừa bãi thì sẽ có ngày bạn nhận hậu quả.
Bạn sẽ thấm hơn nhiều nếu sản phẩm đang chạy trên production bị ngưng hoạt động chỉ vì bạn vừa update thư viện sáng nay.
Sau nhiều lần số đen, mình đã rút ra kinh nghiệm Cái gì mình control được, thì cứ control vẫn hơn là phụ thuộc vào một thằng khác.
Bài viết được viết dựa trên góc nhìn cá nhân, rất mong nhận được góp ý của các bạn.
Bài viết gốc được đăng tải tại phambinh.net
Có thể bạn quan tâm:
- Hướng dẫn sử dụng design system framework cho iOS
- Framework và Library khác nhau thế nào?
- Dùng .NET Framework với IronPython
Xem thêm các việc làm Developer hấp dẫn tại TopDev
