Tôi đã viết phần mềm được hơn một thập kỷ rồi, và một trong những bài học quan trọng nhất tôi từng học được đến từ một cuộc trò chuyện hồi đầu sự nghiệp.
Tôi đã nói với một đồng nghiệp
– một kỹ sư thực sự xuất sắc
– “Anh biết đấy, code trong ứng dụng của chúng ta hơi tệ.”
Anh ấy mỉm cười, gật đầu như một nhà sư già trên núi, và nói:
“Ở đâu cũng tệ thôi.”
Và thành thực mà nói?
Càng ở trong nghề này lâu, tôi càng nhận ra điều đó đúng đến khó tin như thế nào.
Mọi công ty, mọi đội, mọi dự án
– lớn hay nhỏ
– cuối cùng đều có một hương vị hỗn loạn riêng.
Thế mà chúng ta cứ giả vờ rằng ở đâu đó ngoài kia, có thể ở Google, hay Netflix, hay một công ty khởi nghiệp bí ẩn nào đó ở Scandinavia…
ai đó đang viết code sạch sẽ hoàn hảo.
Tiết lộ:
họ không làm vậy đâu 🙃
Và điều đó cũng ổn thôi.
Thật đấy.
Nội dung chính
✨ Thậm chí “Code Sạch”LàCái Gì?
(Thành thật đi…
không ai có một định nghĩa duy nhất)
Qua nhiều năm, tôi đã nghe nhiều định nghĩa hơn tôi có thể đếm.
“Dễ đọc.” “Đơn giản.” “Nhất quán.” “SOLID.” “Thanh lịch.” “Bất cứ thứ gì tôi cá nhân sẽ viết nếu tôi có nhiều thời gian hơn và ít deadline hơn.”
Tất cả chỉ là cảm giác.
Không ai đồng ý với ai về bất cứ điều gì.
Hỏi mười lập trình viên code sạch nghĩa là gì và bạn sẽ nhận được hai mươi bảy câu trả lời khác nhau.
Code sạch không thực sự là một tiêu chuẩn
– nó là mộtcảm giác.
Đó là khoảnh khắc bình yên khi não bạn nghĩ, “được rồi, ít nhất phần này sẽ không ám ảnh tôi sau ba tháng nữa.”
Một định nghĩa phổ quát?
Ừ…
hãy cho tôi biết khi bạn tìm thấy một cái nhé 😌
🚧 Dự Án Thực Tế Không Bắt Đầu Một Cách Sạch Sẽ
Chúng bắt đầu với áp lực.
Với những người quản lý muốn có thứ gì đó “trên màn hình.”
Với các nguyên mẫu chứng minh khái niệm.
Với deadline.
Với những lập trình viên mới đang cố gắng hết sức.
Với code được viết lúc 2 giờ sáng trong một sprint đáng lẽ không nên tồn tại.
Các kho code không bắt đầu một cách lộn xộn.
Chúng bắt đầu một cách mong manh
– và thực tế phá vỡ chúng ngay lập tức.
🔥 Nguyên Mẫu Chứng Minh Khái Niệm Vô Tình Trở Thành Sản Phẩm
Đây là một câu chuyện huyền thoại.
Có một nguyên mẫu nhanh được xây dựng bởi các lập trình viên mới.
Nó không được dự định tồn tại lâu hơn một tuần.
Về cơ bản nó chỉ là băng dính nhưng có cảm xúc.
Rồi một quản lý xông vào và nói, “Chúng ta chỉ cần THÊM một thứ nữa
– thêm một biểu đồ nhanh để chúng ta có thể thắng hợp đồng này!”
Biểu đồ được hack vào.
Hợp đồng đã thắng.
Bản POC được đưa thẳng vào môi trường production 😭
Các nhà phát triển đã dành HÀNG NĂM để sửa lỗi trong khu vực đó.
Mọi người cứ nói “chúng ta sẽ tái cấu trúc nó sớm thôi,” nhưng bằng cách nào đó luôn có thứ gì đó quan trọng hơn.
Và đó là cách di sản được sinh ra
– không phải bởi những nhà phát triển tồi, mà bởi nhữngvụ hack thành công.
⛏️ Cuộc Tái Cấu Trúc Năm Năm (mà vẫn “sắp xong”)
Một lần khác, một nhóm bắt đầu tái cấu trúc một mô-đun lớn.
Một cách có trách nhiệm.
Cẩn thận.
Từng bước một.
Một năm trôi qua.
Rồi một năm nữa.
Và một năm nữa.
Tôi tình cờ gặp người quản lý một thời gian sau và cô ấy tự hào nói, “Chúng tôi sắp hoàn thành việc tái cấu trúc mô-đun đó rồi!”
Sắp xong.
Sau năm năm.
Việc tái cấu trúc không bao giờ kết thúc.
Nó chỉ từ từ chuyển thành truyền thuyết dân gian.
🎻 Chuyên Gia Cầu Toàn Vô Tình Tạo Ra Mớ Spaghetti
Có lần tôi làm việc với một lập trình viên backend cao cấp thực sự xuất sắc.
Các đánh giá mã của anh ấy là những bài luận.
Anh ấy phân tích các trường hợp biên mà chưa ai từng hỏi đến.
Anh ấy viết lại tên biến như đang biên tập một cuốn tiểu thuyết.
Vậy mà…
bằng cách nào đó ứng dụng lại là một thảm họa.
Đầy lỗ hổng.
Không nhất quán.
Không ổn định.
Tại sao?
Bởi vì mọi người sợ hãi khi hỏi anh ấy.
Không ai muốn anh ấy review PR của họ.
Không ai muốn đụng vào “mã của anh ấy.”
Và khi các nhà phát triển sợ hãi, họ không cải thiện mọi thứ
– họ làm việc xung quanh chúng.
Một cách lặng lẽ.
Bí mật.
Cẩn thận.
Và không gì phát triển nhanh hơn trong sự im lặng bằng mớ spaghetti 🍝
Chủ nghĩa cầu toàn không tạo ra mã sạch.
Chủ nghĩa cầu toàn tạo ra nỗi sợ.
Và nỗi sợ tạo ra sự hỗn loạn.
😂 Phép Màu[enableSpecialMode]="true"Đáng Lẽ Không Nên Tồn Tại
Được rồi, chuyện này từrất lâurồi
– nhưng nó vẫn là một trong những chuyện tôi thích nhất.
Đã có một lỗi.
Sửa nó lại gây ra một lỗi khác.
Các quản lý đang chơi bóng bàn chính trị về việc nên sửa cái gì trước.
Deadline đang gào thét.
Và cách sửa nhanh nhất, an toàn nhất
– cách mà sẽ không phá hỏng bất cứ thứ gì khác
– là đập kiệt tác nhỏ bé này vào một component:
[enableSpecialMode]="true" Phần buồn cười nhất?
Không hề có “chế độ đặc biệt” nào cả.
Nó không tồn tại.
Cái tên là một lời nói dối.
Nhưng này
– nó hoạt động.
Nó sửa vấn đề ngay lập tức.
Tất cả chúng tôi đều hứa sẽ tái cấu trúc nó “sau”.
Tất cả chúng tôi đều biết “sau” có nghĩa là “không bao giờ”.
Và đúng vậy
– không ai từng tái cấu trúc nó cả 😂
Mẹo hack sống lâu hơn hầu hết các kỹ sư.
🤖 AI:
Mớ Hỗn Độn Trông Sạch Sẽ Nhất Mà Bạn Từng Thấy
Giờ chúng ta có AI.
AI viết code màtrôngsạch sẽ.
Nó được định dạng đẹp mắt, nhất quán, gọn gàng, dễ đọc…
và hoàn toàn mất kiểm soát bên dưới.
AI vui vẻ giới thiệu các phụ thuộc mới, giải quyết triệu chứng thay vì nguyên nhân, bỏ qua kiến trúc, và tạo ra logic mà không ai hiểu.
Nó giống như có một thực tập sinh rất nhanh, rất tự tin, người không bao giờ hỏi “tại sao” và tạo ra 300 dòng vô nghĩa thanh lịch trong ba giây ✨
Tương lai của di sản là do máy tạo ra
– và được thụt lề một cách đau đớn.
📊 Kinh Doanh vs Code Sạch:
Một Cuộc Chiến Mà Code Sạch Luôn Thua
Lập trình viên muốn sự ổn định, rõ ràng, khả năng bảo trì, cấu trúc.
Kinh doanh muốn tốc độ, tính năng, thời hạn, bản demo.
Không phải vì kinh doanh đang tệ
– mà là vì kinh doanh vận hành như vậy.
Code sạch là điều tuyệt vời.
Nhưng code sạch không giúp bạn ký được hợp đồng.
Code sạch không gây ấn tượng với các nhà đầu tư.
Code sạch không thể một cách kỳ diệu đánh bại đối thủ cạnh tranh.
Excel mới là thứ chiến thắng.
Luôn luôn.
🤔 Vậy…
Code Sạch Có Đáng Để Phấn Đấu Không?
Có.
Chắc chắn là có.
Nhưng không phải là phiên bản huyền thoại trong sách.
Không phải là kho code hoàn hảo, lấp lánh, tinh khiết như chén thánh có thể tồn tại nguyên vẹn qua nhiều năm.
Code sạch không phải là một điểm đến
– nó là một hướng đi.
Nó là một ý định.
Một tư duy.
Một sự tử tế với chính bản thân bạn trong tương lai.
Một cách để làm mọi thứbớt đau đớnhơn thay vì hoàn hảo.
Hãy viết code sạch nhất mà bạn có thể một cách hợp lý.
Tái cấu trúc khi nó quan trọng.
Hãy giải thích những đoạn hack của bạn.
Hiểu rõ những đường tắt bạn chọn.
Ưu tiên sự rõ ràng bất cứ khi nào có thể.
Nhưng đồng thời
– và điều này rất quan trọng:
💛 Đừng trừng phạt bản thân vì những phần lộn xộn.
💛 Đừng cảm thấy tội lỗi vì những thỏa hiệp bạn buộc phải thực hiện.
💛 Đừng so sánh code thực tế của bạn với code trong sách giáo khoa.
💛 Đừng cho rằng bất kỳ ai khác đã hiểu hết mọi thứ
– họ không phải vậy đâu.
Tất cả chúng ta đều có những góc tối trong kho code của mình.
Tất cả chúng ta đều có những file đáng xấu hổ ẩn sâu trong repo.
Tất cả chúng ta đều có thứ gì đó kiểu như:
[enableSpecialMode]="true" đang ẩn nấp đâu đó trong môi trường production.
Và đoán xem?
Chúng ta vẫn là những lập trình viên giỏi.
Chúng ta vẫn đang học hỏi.
Chúng ta vẫn đang cố gắng hết sức.
Code sạch quan trọng
– nhưng đối xử tử tế với bản thân còn quan trọng hơn 💛✨
