Cứ vài năm lại có người nhận ra rằng các công ty công nghệ lớn đôi khi tạo ra những đoạn code cẩu thả một cách đáng ngạc nhiên. Nếu bạn chưa từng làm ở một công ty lớn, điều này có thể khó hiểu. Các công ty này trả lương đủ cao để thu hút nhiều kỹ sư giỏi. Họ cũng vận hành đủ chậm để có vẻ như có thời gian làm việc cẩn thận. Vậy tại sao code tệ vẫn xuất hiện?
Phần lớn thay đổi code đến từ người “mới”
Tôi nghĩ lý do chính là các công ty lớn có rất nhiều kỹ sư làm việc ngoài vùng chuyên môn của họ. Thời gian gắn bó trung bình của một nhân sự ở big tech thường chỉ khoảng một đến hai năm.
Thậm chí, các gói lương thưởng thường được thiết kế với chu kỳ bốn năm: sau bốn năm, cổ phần ban đầu được vest hết, khiến tổng thu nhập có thể giảm tới 50%. Điều này tạo động lực để kỹ sư chuyển việc thay vì ở lại.
Nếu tính cả việc luân chuyển nội bộ thì còn tệ hơn. Bản thân tôi hiếm khi ở cùng một team hoặc codebase quá ba năm, và việc tái cấu trúc tổ chức có thể xảy ra mỗi năm, thậm chí thường xuyên hơn.
Trong khi đó, tuổi thọ của một codebase tại công ty lớn lại dài hơn rất nhiều — thường hơn 10 năm và trải qua nhiều thế hệ người phụ trách. Điều này đồng nghĩa với việc phần lớn kỹ sư luôn trong trạng thái “vừa làm vừa học”.
Một tỷ lệ lớn thay đổi code được thực hiện bởi những người “mới”:
-
mới vào công ty,
-
mới tiếp cận codebase,
-
hoặc thậm chí mới với ngôn ngữ lập trình.
Những người “có kinh nghiệm lâu năm”
Vấn đề này phần nào được giảm nhẹ nhờ những kỹ sư kỳ cựu — những người đã gắn bó đủ lâu với hệ thống để hiểu sâu. Họ có thể review code tốt và phát hiện lỗi rõ ràng.
Nhưng việc phụ thuộc vào nhóm này có hai vấn đề:
Thứ nhất: hoàn toàn không chính thức. Công ty không thực sự đầu tư vào việc xây dựng và giữ lại chuyên môn dài hạn cho từng hệ thống. Những người này thường bị điều chuyển sang dự án khác, và phải:
-
hoặc tiếp tục hỗ trợ hệ thống cũ một cách “tình nguyện”,
-
hoặc bỏ nó và lại trở thành người mới ở hệ thống khác.
Thứ hai: họ luôn quá tải.
Là một trong số ít người hiểu sâu hệ thống đồng nghĩa với:
-
không thể review mọi thay đổi,
-
không thể tham gia mọi quyết định,
-
vẫn phải hoàn thành công việc cá nhân.
Nếu dành quá nhiều thời gian review, họ có thể bị đánh giá kém vì thiếu “đầu ra cá nhân”.
Một kỹ sư “trung bình nhưng hiệu quả” trông như thế nào?
Khi ghép tất cả lại, một kỹ sư điển hình tại big tech thường:
-
đủ năng lực để vượt qua vòng tuyển dụng,
-
nhưng đang làm việc với hệ thống hoặc ngôn ngữ chưa quen, hoặc
-
đang cố theo kịp lượng thay đổi lớn trong khi vẫn phải xử lý công việc riêng.
Họ gần như chắc chắn đang chạy theo deadline — thậm chí nhiều deadline chồng chéo.
Nói cách khác, họ đang cố làm tốt nhất có thể trong một môi trường không được thiết kế để tạo ra code chất lượng cao.
Đây chính là cách code “rõ ràng là tệ” được tạo ra. Ví dụ:
Một kỹ sư mới nhận một ticket sửa bug khó chịu trong codebase mà họ gần như chưa hiểu. Họ mất vài ngày để tìm ra vấn đề và đưa ra một giải pháp mang tính “vá tạm”.
Một kỹ sư kỳ cựu (nếu may mắn) xem qua trong nửa tiếng, bác bỏ giải pháp đó và đề xuất phương án tốt hơn một chút — đủ để chạy được.
Người mới triển khai lại, test thấy chạy ổn, được review nhanh, deploy, và tất cả chuyển sang việc ưu tiên cao hơn.
Năm năm sau, ai đó nhìn lại và nghĩ: “Code này tệ thật — sao công ty lớn lại viết kiểu này?”
Công ty lớn chấp nhận điều này
Các công ty lớn thực ra chấp nhận thực trạng này.
Họ ưu tiên khả năng quản lý và điều phối nội bộ — tức là biết ai đang làm gì và có thể điều chuyển nhanh — hơn là tối ưu chất lượng code dài hạn.
Điều đó đồng nghĩa với việc:
-
kỹ sư bị coi như nguồn lực có thể thay thế,
-
bị luân chuyển liên tục,
-
khó phát triển chuyên môn sâu trên một hệ thống.
Đây là một sự đánh đổi có chủ đích:
hy sinh một phần chất lượng phần mềm để đổi lấy khả năng phản ứng nhanh với các ưu tiên mới (ví dụ như AI hiện nay).
Kỹ sư cá nhân không thể thay đổi hệ thống này
Một cá nhân gần như không thể thay đổi cấu trúc này.
Điều tốt nhất bạn có thể làm là trở thành người có kinh nghiệm sâu trong một lĩnh vực — và dùng kiến thức đó để:
-
chặn những thay đổi tệ nhất,
-
định hướng quyết định kỹ thuật hợp lý hơn.
Nhưng ngay cả điều đó cũng đi ngược lại dòng chảy tổ chức, và nếu làm không khéo, bạn còn có thể bị đánh giá kém.
Kỹ sư “thuần túy” vs “thực dụng”
Một phần vấn đề nằm ở sự khác biệt giữa hai kiểu kỹ sư:
Kỹ sư thuần túy:
làm việc trên các dự án kỹ thuật khép kín (ví dụ: ngôn ngữ lập trình), nơi code tệ thường bị coi là do năng lực kém.
Kỹ sư thực dụng:
giống thợ điện hoặc thợ ống nước — làm việc với deadline, hệ thống lạ, và nhiều ràng buộc thực tế.
Với họ, code tệ là điều không thể tránh. Miễn hệ thống vẫn hoạt động, dự án vẫn được coi là thành công.
Ở công ty lớn, kỹ sư không được chọn mình thuộc loại nào — họ làm theo nhu cầu của tổ chức.
Kết luận
Việc chỉ trích code tệ ở các công ty lớn là hợp lý — thậm chí đôi khi giúp sửa được vấn đề cụ thể.
Nhưng đổ lỗi chính cho kỹ sư là sai.
Ngay cả khi tất cả kỹ sư giỏi hơn gấp đôi, code tệ vẫn tồn tại. Vì gần như không ai có thể bước vào một codebase hoàn toàn mới và ngay lập tức viết code hoàn hảo.
Nguyên nhân gốc rễ là:
phần lớn kỹ sư tại công ty lớn buộc phải làm việc trên những hệ thống mà họ chưa thực sự hiểu rõ.