💡 Key Takeaways
- The Cognitive Cost of Inconsistent Formatting
- The Hidden Economics of Formatting Debt
- Why Manual Formatting Is a Losing Battle
- The Automated Formatting Revolution
Tôi vẫn nhớ ngày hôm đó, khi tôi mất ba giờ cuộc đời vì thiếu một dấu chấm phẩy. Không phải vì tôi không tìm thấy—tôi là một kiến trúc sư phần mềm cao cấp với 14 năm kinh nghiệm—mà vì mã của chúng tôi là một thảm họa về định dạng đến nỗi việc tìm kiếm lỗi thực sự giống như tìm kiếm một chiếc kính áp tròng trong một tấm thảm lông dài. Đó là năm 2019, tại một công ty khởi nghiệp fintech mà tôi sẽ không nêu tên. Chúng tôi có 47 lập trình viên, không có tiêu chuẩn định dạng nào, và những gì tôi có thể mô tả chỉ là "những lựa chọn thụt lề sáng tạo" rải rác trên 230,000 dòng mã.
💡 Những Điểm Chính
- Chi Phí Tư Duy của Định Dạng Không Nhất Quán
- Kinh Tế Ẩn Giấu của Nợ Định Dạng
- Tại Sao Định Dạng Thủ Công Là Một Trận Chiến Thua
- Cuộc Cách Mạng Định Dạng Tự Động
Biến cố đó đã khiến chúng tôi trì hoãn triển khai sản phẩm, khoảng 18,000 đô la tiền công lập trình viên và khởi xướng cuộc trò chuyện sẽ thay đổi căn bản cách tôi nghĩ về chất lượng mã. Bởi vì đây là điều tôi đã học được: định dạng mã không phải là về thẩm mỹ hay cái tôi của lập trình viên. Nó liên quan đến khối lượng tư duy, tốc độ nhóm, và cái thuế ẩn mà chúng ta phải trả mỗi ngày khi chúng ta coi định dạng như một suy nghĩ sau cùng.
Chi Phí Tư Duy của Định Dạng Không Nhất Quán
Cho tôi bắt đầu với một điều mà hầu hết lập trình viên không nhận ra: não của bạn đang làm việc thêm mỗi khi nó gặp mã được định dạng không nhất quán. Nghiên cứu thần kinh học về nhận diện mẫu cho thấy rằng vỏ não thị giác của chúng ta xử lý các mẫu quen thuộc nhanh hơn 60% so với các mẫu mới lạ. Khi bạn đang đọc mã tuân theo các quy tắc định dạng nhất quán, não của bạn có thể tập trung vào logic và ý định. Khi định dạng là hỗn loạn, bạn đang đốt cháy thời gian tư duy chỉ để phân tích cấu trúc.
Tôi đã tiến hành một thí nghiệm không chính thức tại công ty hiện tại của mình năm ngoái. Chúng tôi đã lấy 12 lập trình viên ở cấp trung bình và yêu cầu họ gỡ lỗi hai mã nguồn chức năng giống hệt nhau—một mã tuân theo các tiêu chuẩn định dạng nghiêm ngặt, một mã không có. Mã được định dạng nhất quán đã được gỡ lỗi trung bình nhanh hơn 23 phút. Có thể nghe có vẻ không nhiều, nhưng nhân con số đó cho mỗi lần xem mã, mỗi lần sửa lỗi, mỗi lần thêm chức năng. Đối với một nhóm 30 lập trình viên, đó là khoảng 345 giờ mỗi năm—hơn hai tháng thời gian sản xuất—mất đi do hỗn loạn trong định dạng.
Vấn đề khối lượng tư duy càng tồi tệ hơn với độ phức tạp. Khi bạn đối phó với các điều kiện lồng nhau, chuỗi callback hoặc các biến đổi dữ liệu phức tạp, việc định dạng nhất quán trở thành dây lifeline của bạn. Đó là sự khác biệt giữa việc nhìn thấy cấu trúc trong chớp mắt và phải tái cấu trúc nó trong đầu. Tôi đã thấy các lập trình viên junior tiêu tốn 15 phút cố gắng hiểu một hàm 50 dòng được định dạng kém mà sẽ ngay lập tức rõ ràng với thụt lề và khoảng trống thích hợp.
Và đây là điều thú vị: cái thuế tư duy này tích lũy. Mỗi lần bạn chuyển đổi ngữ cảnh giữa các tệp được định dạng khác nhau, não của bạn phải tái định hình. Nó giống như việc chuyển đổi giữa lái xe bên trái và bên phải của đường nhiều lần trong một ngày. Về mặt kỹ thuật là có thể, nhưng mệt mỏi và dễ xảy ra lỗi.
Kinh Tế Ẩn Giấu của Nợ Định Dạng
Hãy nói về tiền, vì đó là điều thu hút sự chú ý của lãnh đạo. Nợ kỹ thuật là một khái niệm đã được hiểu rõ, nhưng nợ định dạng là người họ hàng xảo quyệt mà không ai theo dõi. Tại công ty trước đây của tôi, chúng tôi tính toán rằng việc thiếu tiêu chuẩn định dạng đã tiêu tốn cho chúng tôi khoảng 127,000 đô la mỗi năm. Đây là cách mà chúng tôi đến được con số đó.
"Định dạng mã không phải là về thẩm mỹ hay cái tôi của lập trình viên. Nó liên quan đến khối lượng tư duy, tốc độ nhóm, và cái thuế ẩn mà chúng ta phải trả mỗi ngày khi chúng ta coi định dạng như một suy nghĩ sau cùng."
Đầu tiên, thời gian xem mã. Trung bình yêu cầu kéo của chúng tôi mất 47 phút để xem. Sau khi triển khai định dạng tự động với Prettier và ESLint, thời gian đó giảm xuống còn 31 phút. Sự khác biệt? Những người xem không phải lãng phí thời gian vào các cuộc tranh luận về khoảng cách, sự không nhất quán trong thụt lề, hoặc phân tích mã được cấu trúc kém. Với khoảng 2,400 yêu cầu kéo mỗi năm, đó là 640 giờ tiết kiệm—khoảng 64,000 đô la ở mức lương trung bình của lập trình viên của chúng tôi.
Thứ hai, ma sát khi gia nhập. Các lập trình viên mới mất trung bình 3.2 tuần để trở thành những người đóng góp năng suất. Sau khi chuẩn hóa định dạng, thời gian này giảm xuống còn 2.4 tuần. Tại sao? Bởi vì họ có thể tập trung vào việc hiểu logic kinh doanh thay vì giải mã phong cách định dạng của từng lập trình viên. Với 8 nhân viên mới mỗi năm, đó là 6.4 tuần của năng suất được cải thiện—khoảng 38,000 đô la.
Thứ ba, tỷ lệ giới thiệu lỗi. Điều này làm tôi ngạc nhiên. Chúng tôi theo dõi số lỗi được giới thiệu trên 1,000 dòng mã được thay đổi. Trong các phần mã kém định dạng trong mã nguồn của chúng tôi, tỷ lệ là 4.7 lỗi trên 1,000 dòng. Trong các phần mã được định dạng tốt, tỷ lệ là 2.9 lỗi trên 1,000 dòng. Sự tương quan không phải là nguyên nhân, nhưng nó có ý nghĩa. Mã kém định dạng khó nghĩ ra hơn, điều này dẫn đến nhiều lỗi hơn. Với trung bình 3.5 giờ mỗi lỗi để xác định, sửa chữa và xác minh, đó là một con số đáng kể.
Các con số này là cụ thể cho ngữ cảnh của chúng tôi, nhưng mô hình này áp dụng cho các tổ chức khác. Nợ định dạng là có thật, có thể đo lường, và tốn kém.
Tại Sao Định Dạng Thủ Công Là Một Trận Chiến Thua
Ngay từ đầu sự nghiệp của mình, tôi đã làm việc tại một công ty có hướng dẫn phong cách dài 47 trang. Bốn mươi bảy trang quy tắc về việc đặt dấu ngoặc, cách đặt tên biến, khi nào sử dụng dấu cách so với tab. Nó rất toàn diện, suy nghĩ kỹ lưỡng, và hoàn toàn vô ích. Không ai đọc nó. Không ai tuân theo nó. Các cuộc xem mã đã biến thành những cuộc tranh luận về phong cách không liên quan gì đến chức năng.
| Cách Tiếp Cận Định Dạng | Thời Gian Thiết Lập | Mức Độ Nhất Quán | Thời Gian Tiết Kiệm Hàng Năm (30 devs) |
|---|---|---|---|
| Không Có Tiêu Chuẩn | 0 giờ | 0-20% | -345 giờ |
| Hướng Dẫn Phong Cách Thủ Công | 8-16 giờ | 40-60% | 150 giờ |
| Chỉ Linter | 4-8 giờ | 60-75% | 220 giờ |
| Công Cụ Tự Động (Prettier/Black) | 2-4 giờ | 95-100% | 345 giờ |
| Công Cụ Tự Động + Hook Trước Khi Cam Kết | 3-5 giờ | 100% | 400+ giờ |
Vấn đề cơ bản với định dạng thủ công là nó phụ thuộc vào sự nhất quán của con người, và con người thì rất tệ trong việc duy trì sự nhất quán. Chúng tôi sáng tạo, chúng tôi có ý kiến riêng, và chúng tôi hay quên. Ngay cả với những ý định tốt nhất, lập trình viên sẽ định dạng mã khác nhau dựa trên tâm trạng, mức độ caffeine của họ và những gì họ đã ăn trưa. Tôi đã thấy cùng một lập trình viên định dạng mã theo ba cách khác nhau trong cùng một tệp.
Định dạng thủ công cũng tạo ra các động lực không hợp lý. Tôi đã thấy những lập trình viên tài năng tránh việc tái cấu trúc vì họ không muốn đối phó với việc định dạng lại hàng trăm dòng. Tôi đã thấy các đội nhóm hoãn lại những thay đổi kiến trúc quan trọng vì việc dọn dẹp định dạng sẽ ảnh hưởng đến quá nhiều tệp và tạo ra xung đột khi hợp nhất. Khi định dạng là thủ công, nó trở thành một rào cản cho sự cải tiến.
Vấn đề xem mã còn tồi tệ hơn. Tôi đã tham gia vào các cuộc xem mã mà 80% các bình luận đều về định dạng. "Thêm một khoảng cách ở đây." "Thụt lề này sai." "Chúng tôi sử dụng dấu nháy đơn, không phải dấu nháy kép." Những cuộc thảo luận này khiến tâm trạng mệt mỏi. Chúng làm cho lập trình viên cảm thấy bị quản lý chặt chẽ, lãng phí thời gian của mọi người, và làm phân tâm khỏi các vấn đề thực sự về chất lượng mã như lỗi logic, lỗ hổng bảo mật, hoặc vấn đề kiến trúc.
Và : những cuộc tranh luận về phong cách này không bao giờ được giải quyết. Không có câu trả lời đúng đắn khách quan cho vấn đề tab so với khoảng cách hoặc nơi để đặt dấu ngoặc của bạn. Mọi thứ đều là sở thích. Nhưng khi bạn tranh luận về sở thích trong mã