Reinvent the wheel
Phát minh lại chiếc bánh xe

Đừng phát minh lại chiếc bánh xe

Lời khuyên này có thể được áp dụng ở nhiều khía cạnh khác nhau trong cuộc sống. Tuy nhiên, ở bài viết này, mình chỉ xét trong lập trình. Có thể các bạn đã từng nghe ai đó khuyên rằng “Đừng phát minh lại chiếc bánh xe”. Hay cụ thể hơn là hãy dùng đến các thư viện, framework, dịch vụ sẵn có thay vì viết code từ đầu (from scratch). Đa phần thì lời khuyên đó đúng. Bởi vì viết lại một tính năng mới từ đầu sẽ tiêu tốn nhiều thời gian, nhưng nó chưa chắc đã tốt hơn cái sẵn có. Lợi ích của việc dùng các thư viện, framework, dịch vụ sẵn có là không thể chối cãi. Bài viết này mình không đi phân tích lợi ích của nó.

Mặc dù vậy, lời khuyên này không phải lúc nào cũng đúng, không phải áp dụng được cho mọi hoàn cảnh. Vậy khi nào thì lời khuyên này không phù hợp?

Khi học lập trình

Khi học lập trình thì việc “phát minh lại chiếc bánh xe” không nhất thiết phải tạo ra “cái bánh xe” hoàn chỉnh, mục tiêu của việc này là để hiểu và để rèn luyện tư duy.

Có những bài tập, mà khi học lập trình, các học viên, sinh viên vẫn phải tự làm, từ khóa trước đến khóa sau. Mặc dù các bài tập đó không phải quá khó và hầu hết là ở đâu đó trên mạng đã có sẵn bài giải. Có những bài tập mà đề yêu cầu không được thế này, không được thế kia… Mục đích là để hướng học viên, sinh viên đi đúng hướng theo nội dung kiến thức (mới) được học thay vì dùng những thứ khác.

Khi giấy phép bản quyền, điều khoản dịch vụ không phù hợp

Nếu thư viện, framework, dịch vụ mà bạn đang muốn sử dụng vào dự án, nhưng nó lại có giấy phép, hay điều khoản dịch vụ không phù hợp với dự án mà bạn làm. Trong khi đó bạn không tìm được thư viện, framework, dịch vụ thay thế, có giấy phép, điều khoản dịch vụ phù hợp với dự án. Thì lúc này bạn phải tự mình làm thôi (Hoặc bạn cũng có thể thuê người khác làm). VD: Viết phần mềm để bán, nhưng lại dùng thư viện có giấy phép GPL.

Dùng dao mổ trâu để giết gà

Nếu tính năng bạn cần rất đơn giản, nhưng bạn lại dùng đến thư viện lớn, framework lớn, dịch vụ lớn thì đó chẳng phải là “dùng dao mổ trâu để giết gà” hay sao.

Tăng kích thước project

Giả sử bạn cần chuyển dữ liệu sau sang định dạng csv (bằng code javascript):

Nếu dùng đến thư viện như exceljs thì bạn sẽ bổ sung khoảng 3MB code (chưa nén) vào dự án. Trong khi đó nếu bạn tự viết code thì lượng code được thêm vào dự án nó nhỏ hơn nhiều. Có thể nó sẽ trông như thế này:

Giảm hiệu suất

Đối với các thư viện, framework, service, đa phần người ta đều đã tối ưu hiệu suất. Tuy nhiên, vì chúng được thiết kế cho một lớp các bài toán mang tính tổng quát, do đó rất có thể chúng bao gồm cả những xử lí mà chúng ta không cần đến, những xử lí này có thể làm giảm hiệu suất của ứng dụng. Ví dụ, một thư viện đơn giản được thiết kế để tính hàm toán học f(x) = sqrt(x) + 3 như sau:

Trong khi đó code trong dự án chúng ta đang làm như sau:

Rõ ràng ở đoạn code này chúng ta thấy x của chúng ta không âm, do đó việc kiểm tra isNegative là không cần thiết. Trong ví dụ mình đưa ra thì  isNegative nó quá đơn giản, nó ảnh hưởng không đáng kể đến hiệu suất. Nhưng giả sử hàm f(x) không đơn giản như vậy nữa và  isNegative phải tốn 0.2 giây, và 300KB bộ nhớ để thực hiện thì việc có nên sử dụng thư viện này hay không, cũng đáng để cân nhắc.

Độ tin cậy của thư viện, framework, dịch vụ

Khi chúng ta có ý định dùng thư viện, framework, dịch vụ nào đó thì cũng ta cũng cần xem xét độ tin cậy của nó. Cụ thể hơn thì chúng ta xem xét trả lời các câu hỏi như:

  • Liệu nó có nhiều bug không? Liệu nó có hoạt động ổn định hay không?
  • Liệu có đủ document hay không? Có được hỗ trợ hay không? Có tiếp tục phát triển hay đã dừng lại rồi? Cộng đồng sử dụng nó như thế nào?
  • Liệu có malware, có cài cắm thứ gì trong đó hay không?
  • Liệu dịch vụ có vi phạm “terms of service”  mà chính họ đã đưa ra hay không?
  • Liệu dịch vụ có bị dừng, hoặc tạm dừng hay không?

Khi bạn có thể làm tốt hơn

Nếu bạn có thể làm được chiếc bánh xe tốt hơn tất cả những chiếc bánh xe mà những người khác làm thì tại sao lại không phát minh ra chiếc bánh xe mới. Trong trường hợp này mình dùng cụm từ “phát minh ra” thay cho “phát minh lại”. “Phát minh ra” không phải là “phát minh lại”, nhưng tại sao mình lại đề cập ở đây? Vì theo quan điểm của từng người sẽ có sự khác nhau. Đối với những người cho rằng bánh xe mà bạn phát minh tốt hơn những chiếc bánh xe khác, thì họ xem là bạn “phát minh ra”. Còn đối với những người cho rằng bánh xe mà bạn phát minh không hơn những chiếc bánh xe khác thì họ xem là bạn “phát minh lại”.

Nhưng lưu ý trước khi phát minh ra chiếc bánh xe mới: Bạn phải chắc chắn rằng bạn không ảo tưởng sức mạnh.

Kết

Cũng như nhiều lời khuyên khác, lời khuyên sẽ đúng nếu đặt nó vào đúng hoàn cảnh. Cũng có những lời khuyên thoạt nhìn có vẻ trái ngược nhau. Vậy thì lời khuyên nào đúng và lời khuyên nào sai? Chúng chỉ trái ngược khi đặt chung vào cùng một hoàn cảnh, và sẽ có cái đúng cái sai. Nhưng nếu đặt mỗi lời khuyên vào một hoàn cảnh riêng phù hợp với nó, thì cả 2 đều đúng.

“Đừng phát minh lại chiếc bánh xe” cũng vậy. Nó sẽ đúng khi áp dụng vào hoàn cảnh phù hợp với nó.