Xe đạp trong lập trình: nó là gì, nguyên nhân và cách tránh

Xe đạp trong lập trình là gì

Xe đạp là một thuật ngữ từ cộng đồng nhà phát triển chỉ việc tạo triển khai riêng của một chức năng đã có sẵn dưới dạng thư viện, framework hoặc dịch vụ. Trong môi trường nói tiếng Anh, cụm từ reinventing the wheel — phát minh lại bánh xe — được sử dụng.

Nguồn gốc của ẩn dụ liên quan đến thực tế rằng bánh xe là một trong những phát minh lâu đời nhất của nhân loại. Cố gắng phát minh lại nó trong thế kỷ 21 là vô nghĩa. Trong lập trình, sự tương tự còn chính xác hơn: các thư viện có sẵn là những “bánh xe” đã được tối ưu hóa bởi hàng ngàn kỹ sư qua nhiều năm. Tạo bánh xe chất lượng thấp hơn của riêng bạn là lãng phí tài nguyên.

RedMonk trong một báo cáo phân tích (2023) đã tính toán rằng ứng dụng thương mại trung bình sử dụng khoảng 500 phụ thuộc bên ngoài. Nếu nhà phát triển phải viết từng cái một độc lập, chi phí dự án sẽ tăng gấp mười lần và thời gian đưa ra thị trường sẽ kéo dài nhiều năm. Hệ sinh thái trình quản lý gói (npm, Maven, PyPI, NuGet) tồn tại chính xác để tránh phát minh lại bánh xe.

Dấu hiệu của xe đạp

Mã là xe đạp có thể được nhận ra bởi một số dấu hiệu: nó giải quyết một vấn đề chuẩn theo cách không chuẩn, không có kiểm tra hay tài liệu, và không xử lý các trường hợp biên đã được giải quyết từ lâu trong các thư viện có sẵn. Thường mã này được viết với kỳ vọng về “yêu cầu duy nhất” của dự án, trong khi thực tế những yêu cầu này không khác gì so với các yêu cầu điển hình.

Sự khác biệt giữa xe đạp và giải pháp tùy chỉnh

Giải pháp tùy chỉnh được biện minh khi thư viện có sẵn không phù hợp do hạn chế về kiến trúc hoặc giấy phép. Xe đạp được tạo ra mà không có lý do khách quan — từ mong muốn “thử nghiệm,” không tin tưởng vào mã của người khác, hoặc không biết về công cụ hiện có. Sự khác biệt là cơ bản: tùy chỉnh là một lựa chọn có ý thức, xe đạp là một sai lầm.

Tại sao nhà phát triển phát minh lại bánh xe

Lý do đầu tiên và phổ biến nhất là không biết về các giải pháp hiện có. Một nhà phát triển junior có thể không biết rằng thư viện chuẩn có hàm tích hợp để phân tích JSON. Thay vào đó, họ sẽ viết một trình phân tích thủ công. Vấn đề này đặc biệt liên quan đến người mới bắt đầu tham gia hệ sinh thái ngôn ngữ.

Lý do thứ hai là ảo tưởng kiểm soát. Các nhà phát triển có kinh nghiệm đôi khi tin rằng họ “có thể viết tốt hơn” tác giả của một thư viện phổ biến. Thống kê nói ngược lại: xác suất lỗi trong một thư viện được hàng triệu dự án sử dụng thấp hơn đáng kể so với mã mới viết. Theo Synopsys (2024), mã nguồn mở chứa trung bình 0,1 lỗi trên một nghìn dòng, trong khi mã doanh nghiệp chứa 1–2.

Lý do thứ ba là thiếu văn hóa tái sử dụng. Trong các công ty không có thói quen nghiên cứu các giải pháp hiện có trước khi bắt đầu công việc, mỗi nhà phát triển tạo ra “xe đạp của riêng mình.” Điều này dẫn đến phân mảnh mã: một dự án có thể có ba triển khai trình khách HTTP khác nhau được viết bởi các nhân viên khác nhau.

Khía cạnh tâm lý

Hiệu ứng IKEA là một hiện tượng tâm lý nơi một người đánh giá những gì họ tự tạo ra cao hơn những thứ có sẵn tốt hơn một cách khách quan. Trong lập trình, điều này thể hiện như niềm tự hào về “xe đạp của riêng mình” và không muốn thay thế nó bằng thư viện có sẵn ngay cả khi thư viện đó có lợi thế rõ ràng.

Hậu quả của việc tạo xe đạp trong dự án

Hậu quả kinh tế là rõ ràng nhất. Theo ước tính của Stripe (2022), nhà phát triển dành tới 35% thời gian làm việc để tạo mã đã tồn tại dưới dạng giải pháp có sẵn. Đối với một nhóm 10 người, điều này tương đương với khoảng 200.000 đô la mỗi năm chi cho việc phát minh lại bánh xe.

Hậu quả kỹ thuật bao gồm sự phát triển của cơ sở mã, giảm độ bao phủ kiểm tra (mã tự viết thường được kiểm tra kém hơn), và tăng lỗi và lỗ hổng bảo mật. Hơn nữa, mỗi thành phần tự viết là một điểm hỏng hóc khác cần được giám sát và bảo trì.

Google trong nghiên cứu “Why Google Stores Billions of Lines of Code” (2023) đã lưu ý rằng ngay cả trong công ty công nghệ lớn nhất cũng có một quy trình ra quyết định nghiêm ngặt cho việc thêm phụ thuộc mới hoặc viết triển khai riêng. Hầu hết các nhóm nội bộ trước tiên tìm kiếm giải pháp có sẵn trong kho mã duy nhất.

Tác động lên nhóm

Xe đạp tạo ra sự bất đồng bộ thông tin: khi một nhà phát triển rời đi, thành phần tự viết của họ không có tài liệu và hỗ trợ. Các thành viên nhóm mới phải hiểu mã không chuẩn, lãng phí thời gian có thể được sử dụng cho công việc hiệu quả.

Ví dụ về xe đạp phổ biến trong mã

Ví dụ phổ biến nhất là phân tích thủ công JSON hoặc XML, mặc dù hầu hết các ngôn ngữ hiện đại đều có công cụ tích hợp. Nhà phát triển viết các hàm đệ quy để duyệt cây đối tượng mà không biết rằng JSON.parse() giải quyết vấn đề trong một dòng.

Ví dụ thứ hai là triển khai trình khách HTTP tự viết. Các thư viện chuẩn (fetch, axios, OkHttp, URLSession) hỗ trợ bộ nhớ đệm, kết nối lại, thời gian chờ và bảo mật. Trình khách tự viết thường không đáp ứng ít nhất một trong những yêu cầu này, dẫn đến lỗi trong sản xuất.

Ví dụ thứ ba là hệ thống ghi log tự viết thay vì sử dụng SLF4J, Winston hoặc Log4j. Một nhà phát triển dành hàng tuần để viết những gì thư viện có sẵn làm ngay lập tức với hỗ trợ xoay vòng, cấp độ log, ghi bất đồng bộ và tích hợp hệ thống giám sát.

# xe đạp — phân tích CSV thủ công
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# sử dụng thư viện chuẩn thay vì
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Phản mẫu: ORM tự viết

Viết ORM (Object-Relational Mapping) của riêng bạn có lẽ là xe đạp đắt nhất. Các ORM có sẵn như Hibernate, Entity Framework hoặc SQLAlchemy đã được phát triển qua nhiều năm, hỗ trợ bộ nhớ đệm, tải lười, di chuyển và hàng chục DBMS. ORM tự viết thường bị giới hạn ở một cơ sở dữ liệu và chứa lỗi nghiêm trọng trong quản lý kết nối.

Khi nào xe đạp được biện minh

Học tập là tình huống duy nhất mà xe đạp không chỉ được biện minh mà còn hữu ích. Viết trình phân tích, máy chủ HTTP hoặc ORM của riêng bạn cho mục đích giáo dục giúp hiểu các công cụ này hoạt động bên trong như thế nào. Điều quan trọng là không nhầm lẫn dự án học tập với mã sản xuất: điều tốt cho dự án cá nhân là không thể chấp nhận trong phát triển thương mại.

Yêu cầu duy nhất thực sự có thể yêu cầu triển khai riêng. Nếu không có thư viện nào hỗ trợ một giao thức, định dạng dữ liệu hoặc nền tảng phần cứng cụ thể, việc tạo giải pháp tùy chỉnh là chính đáng. Nhưng trước đó, cần đảm bảo nhiệm vụ thực sự duy nhất và không chỉ là nghiên cứu kém.

Hạn chế về giấy phép là một lý do chính đáng khác. Một số giấy phép mã nguồn mở (GPL, AGPL) có thể không tương thích với mô hình kinh doanh của công ty. Trong những trường hợp như vậy, phát triển triển khai riêng với giấy phép cho phép hơn là chính đáng.

Quy tắc ba lần thử

Có một quy tắc thực tế: trước khi viết triển khai riêng, hãy thử tìm và kiểm tra ba giải pháp có sẵn khác nhau. Nếu không có giải pháp nào phù hợp, hãy tạo giải pháp của riêng bạn, nhưng hãy ghi lại tài liệu tại sao các lựa chọn hiện có bị từ chối. Điều này bảo vệ khỏi việc vô tình phát minh lại bánh xe.

Cách tránh tạo xe đạp

Bước đầu tiên là hình thành thói quen tìm kiếm giải pháp có sẵn trước khi bắt đầu bất kỳ nhiệm vụ chuẩn nào. Sử dụng tìm kiếm trong trình quản lý gói, GitHub, Stack Overflow. Thời gian dành cho nghiên cứu được đền bù gấp nhiều lần nhờ tránh viết mã tự viết.

Bước thứ hai là áp dụng đánh giá mã tập trung vào việc phát hiện xe đạp. Trong quá trình đánh giá, hãy đặt câu hỏi: “Tại sao chúng ta không sử dụng thư viện có sẵn cho nhiệm vụ này?” Nếu câu trả lời không chứa lý do khách quan — đó là xe đạp. Trong các công ty lớn (Google, Meta), đánh giá mã bao gồm một điểm bắt buộc để kiểm tra việc phát minh lại bánh xe.

Bước thứ ba là tạo sổ đăng ký kiến thức nội bộ. Ghi lại tài liệu những thư viện và công cụ được sử dụng trong dự án và những nhiệm vụ chúng giải quyết. Nhà phát triển mới nên có quyền truy cập vào thông tin này để không tạo ra xe đạp vì không biết. Duy trì danh sách Quyết định Kiến trúc (ADR) với lý do cho mỗi lựa chọn.

• Nghiên cứu trình quản lý gói trước khi bắt đầu nhiệm vụ mới
• Kiểm tra thư viện chuẩn của ngôn ngữ — nó bao phủ 80% nhiệm vụ điển hình
• Sử dụng đánh giá mã để phát hiện xe đạp
• Ghi lại tài liệu các quyết định về lựa chọn thư viện
• Cập nhật kiến thức về hệ sinh thái tại hội nghị và blog

Hội chứng Not Invented Here

Hội chứng NIH (Not Invented Here) là một thành kiến tổ chức chống lại việc sử dụng các giải pháp bên ngoài. Các công ty mắc hội chứng NIH thích phát triển mọi thứ trong nội bộ, từ chối các thư viện mã nguồn mở ngay cả khi chúng vượt trội hơn sự phát triển của chính họ. Hội chứng này là phiên bản doanh nghiệp của xe đạp.

Một ví dụ kinh điển là Netscape vào cuối những năm 1990, khi công ty dành nhiều năm để viết lại trình duyệt từ đầu thay vì phát triển cơ sở mã hiện có. Kết quả — mất thị phần và bị AOL mua lại. Ngược lại, Android được xây dựng trên nhân Linux và sử dụng hàng ngàn thành phần mã nguồn mở — điều này cho phép đưa sản phẩm ra thị trường trong thời gian kỷ lục.

Một nghiên cứu của Harvard Business Review (2023) cho thấy rằng các công ty có mức độ hội chứng NIH thấp đưa sản phẩm ra thị trường nhanh hơn 40% và chi tiêu ít hơn 30% cho phát triển. Văn hóa tái sử dụng mã là một lợi thế cạnh tranh trong phát triển hiện đại.

// xe đạp — triển khai sắp xếp tùy chỉnh
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// sắp xếp tích hợp — giải pháp chuẩn
arr.sort((a, b) => a - b);