- Do thời gian gắn bó ngắn và tái cơ cấu tổ chức diễn ra thường xuyên ở các công ty công nghệ lớn, nhiều kỹ sư phải làm việc trên những codebase mà họ không quen thuộc
- Thực tế là phần đáng kể của các thay đổi mã được thực hiện bởi các kỹ sư ở mức “người mới” trong vòng 6 tháng đầu sau khi gia nhập
- Một số kỹ sư kỳ cựu “old hand” có thể bù đắp về chất lượng, nhưng họ cũng có giới hạn do khối lượng công việc quá tải và trách nhiệm không chính thức
- Doanh nghiệp ưu tiên tính cơ động của nhân sự và tính dễ quan sát (legibility) hơn chuyên môn, và đó là cái giá phải trả cho sự suy giảm chất lượng có chủ đích
- Kết quả là, bất kể năng lực cá nhân của kỹ sư ra sao, vấn đề gốc rễ của mã tệ là cấu trúc buộc họ phải làm việc gấp rút trên những hệ thống xa lạ để kịp tiến độ
Cấu trúc tạo ra mã tệ trong các tập đoàn lớn
- Các công ty công nghệ lớn tuyển dụng kỹ sư giỏi bằng mức lương cao, nhưng thời gian gắn bó thường chỉ 1–2 năm
- Cơ chế thưởng cổ phiếu (share grant) chỉ vesting hoàn toàn sau 4 năm, khiến thu nhập sau đó giảm xuống còn một nửa
- Dù có một số đợt refresh hằng năm, chúng không được bảo đảm, nên kỹ sư thường chọn chuyển việc
- Nếu tính cả điều chuyển nội bộ, việc ở lại cùng một codebase quá 3 năm là điều hiếm thấy
- Tái cơ cấu tổ chức (re-org) diễn ra mỗi năm, thậm chí còn thường xuyên hơn
- Trong khi đó, các codebase lại thường được duy trì hơn 10 năm, nên đa số kỹ sư luôn trong trạng thái “đang làm quen” với hệ thống mới
- Kết quả là phần lớn thay đổi mã lại do những người mới trong vòng 6 tháng đầu thực hiện
Vai trò và giới hạn của những “old hand”
- Một số kỹ sư ở lại lâu với một hệ thống cụ thể nên có được chuyên môn sâu
- Họ có thể phát hiện vấn đề sớm thông qua code review
- Tuy nhiên, cấu trúc này mang tính phi chính thức và không được thể chế hóa
- Doanh nghiệp ít quan tâm đến việc duy trì chuyên môn dài hạn, và thường điều chuyển người có kinh nghiệm sang đội khác
- Những người kỳ cựu này luôn phải chịu khối lượng công việc quá tải
- Không đủ thời gian để trực tiếp rà soát mọi thay đổi
- Nếu kết quả công việc cá nhân giảm xuống, họ còn có nguy cơ bị đánh giá bất lợi
Thực tế của một kỹ sư năng suất ở mức trung bình
- Một kỹ sư năng suất ở mức trung bình trong tập đoàn lớn thường có các đặc điểm sau
- Đủ năng lực để vượt qua tiêu chuẩn tuyển dụng, nhưng không quen với codebase hoặc ngôn ngữ mới
- Đồng thời phải làm việc để đáp ứng nhiều thời hạn chồng chéo của nhiều dự án
- Vì thế, họ buộc phải làm hết sức trong một môi trường ưu tiên tiến độ hơn chất lượng
- Ví dụ: một kỹ sư mới tạm vá lỗi trong phần mã xa lạ, rồi một người có kinh nghiệm xem qua nhanh và cho triển khai
- Vài năm sau, khi đoạn mã đó được phát hiện lại, người ta bắt đầu đặt câu hỏi “vì sao lại viết ra đoạn mã như thế này?”
Vì sao doanh nghiệp duy trì cấu trúc này
- Các tập đoàn lớn coi trọng tính dễ quan sát nội bộ (legibility) hơn năng suất
- Họ ưa thích một cấu trúc mà ai làm gì cũng rõ ràng và có thể bị điều chuyển bất cứ lúc nào
- Đây là một lựa chọn có chủ đích, chấp nhận hy sinh chuyên môn và chất lượng mã
- Họ chấp nhận mất mát về độ thành thạo để đổi lấy sự linh hoạt trong việc tái phân bổ nhân sự nhanh khi có vấn đề
- Đặc biệt trong bối cảnh cần chuyển hướng (pivot) nhanh sang các lĩnh vực mới như AI, chiến lược này vận hành có lợi cho doanh nghiệp
- Nhưng trong môi trường như vậy, số kỹ sư phải vội vàng làm việc trên các hệ thống xa lạ gần như chắc chắn sẽ tăng lên
Giới hạn của cá nhân kỹ sư và kỹ thuật “thuần/không thuần”
- Cá nhân kỹ sư không có sức mạnh để thay đổi cấu trúc này
- Tính đến năm 2025, trung tâm quyền lực đã chuyển từ kỹ sư sang ban điều hành
- Điều tốt nhất một cá nhân có thể làm là trở thành một “old hand” trong lĩnh vực cụ thể để giữ được mức chất lượng tối thiểu
- Nhưng can thiệp quá nhiều còn có thể khiến họ đối mặt nguy cơ bị đánh giá hiệu suất kém (PIP)
- Bài viết nêu ra sự khác biệt giữa kỹ thuật “thuần” (pure) và “không thuần” (impure)
- Kỹ thuật thuần: tập trung vào các dự án kỹ thuật độc lập (ví dụ: phát triển ngôn ngữ lập trình)
- Kỹ thuật không thuần: môi trường thực tế nơi người ta làm việc theo tiến độ trên các hệ thống xa lạ
- Phần lớn kỹ sư ở tập đoàn lớn thuộc về kỹ thuật không thuần, và trong trường hợp này, mã tệ là sản phẩm phụ khó tránh khỏi
- Chỉ cần hệ thống vận hành đủ ổn, dự án vẫn được xem là thành công
Kết luận: “codebase xa lạ” là nguyên nhân mang tính cấu trúc
- Các tập đoàn lớn có quyền điều chuyển kỹ sư một cách linh hoạt, và đó là lựa chọn của doanh nghiệp dù phải đánh đổi bằng việc mất chuyên môn
- Trách nhiệm cho mã tệ không nằm ở cá nhân, mà ở cấu trúc tổ chức và cách vận hành nhân sự
- Dù năng lực của mọi kỹ sư có tăng gấp đôi, sai sót khi làm việc trên codebase xa lạ vẫn sẽ tiếp tục xảy ra
- Nguyên nhân gốc rễ là “đa số kỹ sư phải thực hiện phần lớn công việc trên những đoạn mã mà họ không quen thuộc”
- Chỉ ra các ví dụ về mã tệ có thể giúp cải thiện, nhưng đối tượng cần bị phê phán không phải kỹ sư mà là cả hệ thống
5 bình luận
Theo kinh nghiệm của tôi, nếu nền tảng CS, đặc biệt là PLT, vững thì rốt cuộc trong bất kỳ môi trường nào cũng sẽ viết được mã tương đối tốt hơn.
Ngay cả khi không có kiến thức gì quá ghê gớm, chỉ cần là người hiểu những nguyên tắc cơ bản nhất thì nếu có đủ thời gian và làm với đoạn mã quen thuộc, vẫn sẽ tạo ra được chất lượng mã theo cách riêng. Refactor n lần thì ngay cả AI viết cũng sẽ trông ra gì đấy.
Dù bám vào một mã nguồn rất lâu, vẫn có nhiều người tự nhận là 20 năm kinh nghiệm nhưng chỉ biết tạo ra spaghetti code, thậm chí còn không biết vì sao không nên làm vậy.
Trừ khi có thể được cung cấp một môi trường hoàn hảo cùng thời gian và ngân sách vô hạn, tôi thấy đây là nội dung khá sáo rỗng và không có nhiều ý nghĩa. Dù là thời đại nào hay công việc nào thì chuyện này chẳng phải đều như nhau sao?
Viết được mã tốt hơn trên cùng một hệ thống rõ ràng đúng là năng lực của kỹ sư.
Sẽ rất tốt nếu hệ thống được thiết kế đủ dư địa và linh hoạt để có thể cung cấp chất lượng tốt. Và chắc chắn, xét trên mặt bằng chung, hiện nay mọi thứ đúng là như vậy hơn so với thời kỳ mà kỹ nghệ tổ chức và phương pháp phát triển còn kém phát triển hơn bây giờ.
Tuy vậy, trong mắt tôi, điều này nghe giống như lời bào chữa của một người có cái tôi với tư cách kỹ sư thì phình to, nhưng lại thiếu tinh thần trách nhiệm với tư cách là một thành viên của tổ chức, rằng tất cả những chuyện này không phải lỗi của mình mà là lỗi của ban lãnh đạo.
Kỹ sư xây dựng, nhà thiết kế công nghiệp, animator thì không có deadline, được đánh giá chỉ bằng tính sáng tạo và chất lượng chứ không phải năng suất, còn chỉ riêng lập trình viên là có deadline sao?
Đủ thứ linh tinh ở đâu đâu... Cái kiểu nói mã xấu hay mã tốt là thứ bọn junior hay bàn tán thôi, điều quan trọng hơn là có senior nào giỏi thiết kế phần mềm phù hợp với ngành đó hay không...
Những bài viết đăng ở đây nhìn chung có thể là trong một môi trường hơi khác với một số góc nhìn hay kinh nghiệm của thị trường SI trong nước, nơi ngay cả OCP cũng bị phớt lờ.
Dù sao thì Linus Torvalds cũng đâu phải junior...
Ý kiến trên Hacker News
Tôi đã đọc bài của người này nhiều lần, và lúc nào cũng còn lại một cảm giác khó chịu nào đó
Giờ thì có lẽ tôi biết lý do. Bản thân phần phân tích của bài viết là hợp lý, nhưng bên dưới nó dường như có một kiểu chủ nghĩa hư vô ẩn hiện
Có lẽ đây là một người từng là người theo chủ nghĩa lý tưởng, nhưng sau những trải nghiệm tồi tệ đã cố giải thích rằng “tin vào điều gì đó cũng vô ích”
Vì thế mới nảy ra những câu hỏi như — tại sao các tập đoàn lớn lại phải hành xử như vậy, tại sao code tệ lại hành hạ kỹ sư đến thế, cảm xúc đó thật sự là sai sao, hay là do cấu trúc kinh tế chúng ta đang sống, hoặc liệu thuận theo những thế lực khổng lồ có phải là trưởng thành không
Vì tôi phải chịu trách nhiệm cho kết quả của nó.
Tiến độ bị chậm vì phải sửa đống code nhếch nhác do người khác viết, và vì thế mà đánh giá cuối năm cũng bị trừ điểm
Tôi bị hỏi “sao lại mất nhiều thời gian thế”, nhưng đó là vì tôi phải bới qua đống rác để tìm ra vấn đề
Tôi đã cố suốt nhiều năm để khiến ban quản lý hiểu điều này, nhưng cuối cùng nó giống như lao động của Sisyphus
Giống như kiến trúc sư thấy một tòa nhà cẩu thả thì bức bối, hay đạo diễn thấy một bộ phim sơ sài thì khổ sở, kỹ sư giỏi luôn theo đuổi độ hoàn thiện
Tôi nghĩ trưởng thành không phải là thuận theo sự bất lực, mà là chiến đấu hết sức có thể
Thú vị ở chỗ, dù gọi tác giả là người hư vô, nhưng chính suy nghĩ “thế giới nằm ngoài kiểm soát” tự nó đã mang tính hư vô rồi
Trước đây tôi cũng nghĩ code không hoàn hảo thì là code tệ, nhưng sau khi đi qua nhiều công ty thì góc nhìn đã thay đổi
Giờ tôi thấy nếu nó đáp ứng mục tiêu kinh doanh và vượt qua ngưỡng chất lượng tối thiểu thì cũng ổn
Rốt cuộc hầu như mọi đoạn code đều luôn có chỗ để cải thiện
Tôi đồng cảm vì nó nói thẳng ra hiện thực lạnh lùng của engineering cấp Staff+
Lập luận “hãy làm điều công ty muốn, dù điều đó không đúng” thì có phần cay độc, nhưng tôi nghĩ vẫn tốt hơn là bị nghiền nát trong guồng máy công ty
Ông ấy đơn giản là không tin vào lý tưởng của bạn, chứ như vậy chưa hẳn là chủ nghĩa hư vô
Tôi nghĩ vấn đề không phải là thâm niên, mà là vấn đề động lực làm việc
Nó làm tôi nhớ đến câu thoại trong phim Office Space: “nếu làm chăm chỉ mà không có phần thưởng thì sẽ không có động lực”
Nhưng ban quản lý coi trọng kết quả hơn là code tốt
Vì họ không thể đánh giá giá trị của bảo trì, nên công việc đó không được ghi nhận
Cuối cùng người tung ra code cẩu thả lại được thăng chức
Tôi từng quan tâm đến team và code, làm việc rất cẩn thận, nhưng cuối cùng lại bị đánh giá bằng những chỉ số đơn giản như số lượng PR
Độ khó của code hay mức đóng góp cho team đều bị bỏ qua, chỉ có “những con số nhìn thấy được” là quan trọng
Cuối cùng chính người sếp đánh giá tôi cũng bị sa thải vài tháng sau
Trớ trêu là, nếu tôi đã thờ ơ thì có lẽ tôi đã không bị tổn thương vì chuyện này
Các tập đoàn lớn đối xử với kỹ sư như nguồn lực có thể thay thế
Đây không chỉ là vấn đề hiệu quả, mà còn là chiến lược để nghiêng cán cân quyền lực về phía quản lý
Mục đích là để các dự án cốt lõi không phụ thuộc vào một nhóm kỹ sư cụ thể nào
Họ muốn mọi lao động đều có thể thay thế được
Ngược lại, thường họ còn cố giữ chân các kỹ sư giỏi
Tức là văn hóa này không chỉ là vấn đề của riêng quản lý
Tôi thường thấy những trường hợp cú pháp và cấu trúc code thì đúng sách giáo khoa, nhưng cách tiếp cận gốc rễ lại sai
Review code chỉ tập trung vào cú pháp, còn bài toán kinh doanh hay độ phức tạp thì không được bàn tới
Ngắn hạn thì có vẻ ổn, nhưng về dài hạn nợ kỹ thuật sẽ bùng nổ
Kết quả là những cuộc tranh cãi nhỏ nhặt về chất lượng code lại làm PR bị trì hoãn nhiều ngày
Mọi người chỉ ám ảnh với sự sạch sẽ bề mặt của code
Còn việc xem xét tính hợp lý logic hay bức tranh lớn thì khó hơn nhiều, và reviewer thường cũng không có đủ ngữ cảnh
Nếu cả tổ chức không có đủ dư địa để tiếp nhận kiểu phản hồi này, thì cuối cùng sẽ phải dựa vào ‘một hệ thống chạy tạm được’
Các thiết kế lớn phải được xem xét trước khi đến giai đoạn review code
Xem như chúng ta đang tự động hóa chi phí dài hạn
Các tập đoàn lớn không quan tâm đến bản thân code
Code chỉ là phương tiện để công ty vận hành
Cuối cùng điều quan trọng không phải là code mà là quy trình
Cốt lõi là khi hệ thống sập thì có quy trình để khôi phục nó hay không
Mọi ngành khi mở rộng quy mô đều thực hiện những thỏa hiệp tương tự
Thay vì hoàn hảo, chất lượng ‘đủ tốt’ mới tạo ra lợi nhuận
Giống như khác biệt giữa ghế IKEA và ghế Herman Miller, chỉ là các ràng buộc khác nhau
Năng lực thật sự là biết nên thỏa hiệp ở đâu
Cấu trúc của các tập đoàn lớn buộc kỹ sư phải chấp nhận những thỏa hiệp như vậy
Kỹ sư senior giỏi không viết code tệ ngay từ đầu
Vấn đề là áp lực thành tích ngắn hạn và thiếu nền tảng cơ bản
Việc bỏ qua review hoặc không suy nghĩ đủ về kiến trúc mới là nguyên nhân thật sự
Như được mô tả trong bình luận này, trên một codebase tích tụ hàng triệu dòng hack chắp vá thì dù cố đến đâu cũng không thể làm nó sạch sẽ được
Cuối cùng chỉ như nhấc cả đĩa mì spaghetti lên mà thôi
Senior luôn bị đặt vào thế tiến thoái lưỡng nan giữa ‘làm cho đúng’ và ‘làm cho nhanh xong’
Không thể hiểu một codebase phức tạp chỉ sau một đêm, và nếu tổ chức không coi trọng tích lũy tri thức thì chất lượng sẽ đi xuống
Với nhân viên mới, giao cho họ việc tài liệu hóa hoặc dọn dẹp là cách tốt để họ nắm được cấu trúc của code
Dù có nhiều đoạn code cũ vá víu, cũng không thể động vào vì không được phép làm nó vỡ
Dù thiết kế có xuất sắc đến đâu, nếu nền móng là cát thì sớm muộn cũng sụp đổ
Kết luận của tác giả rằng ‘tính dễ đọc được ưu tiên hơn chất lượng’ có nghĩa là nếu vậy thì mọi dự án ở tập đoàn lớn đều phải bắt buộc có công cụ phân tích tĩnh và auto-formatter
Nhưng thực tế không phải vậy
Việc đưa vào những công cụ này là quyết định của quản lý phi kỹ thuật, và họ ghét chi phí ngắn hạn
Cuối cùng lịch phát hành áp đảo tất cả
Khi tôi tư vấn cho một tập đoàn sản xuất lớn, có một mô hình hóa đối tượng kỳ quặc xuyên suốt toàn bộ code
Lần theo nguyên nhân thì hóa ra khái niệm mà người thiết kế định nghĩa (bản thiết kế–khuôn–sản phẩm) đã bị đội phát triển hiểu sai hoàn toàn
Tôi đề nghị sửa lại, nhưng câu trả lời nhận được là “đã quá muộn rồi”
Kết quả là suốt hơn 10 năm, mô hình sai đó vẫn được giữ nguyên và tạo ra khoản nợ kỹ thuật khổng lồ
Thống kê thâm niên ngắn ở các tập đoàn lớn dễ gây hiểu lầm
Đó chỉ là vì số lượng nhân sự tăng vọt nên trung vị bị kéo xuống
Thực ra phải nhìn theo những người đã rời công ty thì mới chính xác
Đơn giản là trước đây số lượng lập trình viên ít hơn thôi