Clean Code: 10 Principles That Make You a Better Developer — cod-ai.com

Tôi vẫn nhớ ngày tôi thừa hưởng một mã nguồn 50,000 dòng khiến tôi phải suy nghĩ lại về sự lựa chọn nghề nghiệp của mình. Đó là năm 2015, tôi đã làm việc được ba năm với vai trò là một lập trình viên chính tại một startup fintech, và kỹ sư trưởng của chúng tôi vừa mới rời đi mà không để tài liệu lại. Mã nguồn chạy - gần như vậy - nhưng việc đọc nó giống như giải mã những ký tự cổ xưa viết bởi một người mà rõ ràng ghét những lập trình viên trong tương lai. Trải nghiệm đó đã dạy tôi nhiều điều về mã sạch hơn bất kỳ cuốn sách nào có thể làm được.

Tiến nhanh tới chín năm, và giờ tôi là một kỹ sư chính tại một công ty quản lý các hệ thống xử lý hơn 2 triệu giao dịch hàng ngày. Tôi đã xem xét hàng ngàn yêu cầu kéo, hướng dẫn hàng chục lập trình viên, và tái cấu trúc nhiều mã nguồn cũ hơn tôi muốn thừa nhận. Qua tất cả những điều này, tôi đã tinh lọc những gì phân biệt mã tốt với mã tuyệt vời thành mười nguyên tắc cơ bản đã biến đổi không chỉ công việc của tôi mà còn công việc của mọi lập trình viên mà tôi đã đào tạo.

Mã sạch không chỉ là về việc theo nguyên tắc hoặc làm theo quy định vì lợi ích của những quy định đó. Nó là về sự tôn trọng - tôn trọng cho chính bạn trong tương lai, cho đồng nghiệp của bạn và cho người tiếp theo sẽ duy trì công việc của bạn lúc 2 giờ sáng khi sản xuất bị ngừng. Hãy để tôi chia sẻ những gì tôi đã học được.

Chi Phí Thực Sự của Mã Bẩn

Trước khi chúng ta đi vào các nguyên tắc, hãy nói về lý do tại sao điều này quan trọng. Trong vai trò hiện tại của tôi, chúng tôi đã tiến hành một nghiên cứu nội bộ theo dõi năng suất của lập trình viên trên các nhóm kỹ thuật của chúng tôi. Chúng tôi thấy rằng các lập trình viên dành trung bình 65% thời gian của họ để đọc và hiểu mã nguồn hiện tại, so với chỉ 35% thực sự viết mã mới. Tỷ lệ này càng tệ hơn với mã được viết kém - tăng lên 80/20 trong các hệ thống cũ của chúng tôi.

Đây là điều đáng ngạc nhiên: chúng tôi tính toán rằng chỉ riêng việc sử dụng tên biến không rõ ràng đã tiêu tốn của nhóm khoảng 127 giờ mỗi quý. Điều đó có nghĩa là hơn ba tuần làm việc chỉ để tìm hiểu xem x, temp hoặc data2 thực sự đại diện cho cái gì. Nhân con số đó lên với một nhóm 40 kỹ sư, và bạn đang nhìn vào một chi phí hàng năm lên đến sáu con số từ thứ đơn giản như quy ước đặt tên kém.

Tôi đã thấy các dự án thất bại không phải vì tính không khả thi về mặt kỹ thuật, mà vì mã nguồn trở nên rối rắm đến mức ngay cả những thay đổi đơn giản cũng mất nhiều tuần thay vì chỉ vài giờ. Một khách hàng thương mại điện tử mà tôi tư vấn đang mất khoảng 50,000 USD mỗi ngày trong doanh thu tiềm năng vì hệ thống thanh toán của họ quá mong manh đến mức việc thêm một phương thức thanh toán mới cần một chu kỳ phát triển ba tháng. Sau một đợt tái cấu trúc mã kéo dài sáu tuần áp dụng nguyên tắc mã sạch, sự thay đổi đó chỉ mất bốn ngày.

Trường hợp kinh doanh là rõ ràng: mã sạch tác động trực tiếp đến lợi nhuận của bạn, tinh thần của nhóm bạn, và khả năng đổi mới của bạn. Giờ hãy khám phá cách để đạt được điều đó.

Nguyên Tắc 1: Tên Có Ý Nghĩa Là Dòng Tài Liệu Đầu Tiên Của Bạn

Tôi từng làm việc với một lập trình viên người khăng khăng rằng tên biến ngắn làm cho mã nhanh hơn để gõ. Anh ấy viết những thứ như let u = getUserData() hoặc const p = calculatePrice(). Khi tôi yêu cầu anh ấy giải thích mã của mình ba tháng sau, anh ấy không thể. Anh ấy đã quên hệ thống viết tắt của chính mình.

Tên biến, hàm và lớp của bạn nên kể một câu chuyện. Chúng nên tiết lộ ý định mà không cần đến bình luận. So sánh hai ví dụ này:

Kém: const d = 86400;

Tốt: const SECONDS_PER_DAY = 86400;

Sự khác biệt có vẻ không đáng kể cho đến khi bạn đang gỡ lỗi lúc nửa đêm và cố gắng hiểu tại sao một phép toán lại sai. Phiên bản thứ hai ngay lập tức cho bạn biết con số kỳ diệu đó đại diện cho cái gì.

Đây là danh sách kiểm tra đặt tên mà tôi chia sẻ với mỗi lập trình viên trẻ mà tôi hướng dẫn:

• Sử dụng tên có thể phát âm - nếu bạn không thể nói trong một buổi kiểm tra mã, thì đó là quá khó hiểu
• Sử dụng tên có thể tìm kiếm - biến một chữ cái sẽ không thể tìm thấy với Ctrl+F
• Tránh việc lập bản đồ tinh thần - đừng khiến người đọc phải dịch các viết tắt của bạn
• Chọn một từ cho mỗi khái niệm - đừng trộn fetch, retrieve, và get cho cùng một thao tác
• Sử dụng tên miền giải pháp - các lập trình viên khác sẽ đọc mã của bạn, vì vậy AccountVisitor hoặc JobQueue là hợp lý

Trong thực tế, tôi đã thấy rằng việc dành thêm 30 giây để nghĩ về một cái tên tiết kiệm trung bình 15 phút mơ hồ sau đó. Đó là một khoản đầu tư hoàn vốn 30x. Khi bạn nhân điều đó lên với hàng trăm biến trong một dự án, thời gian tiết kiệm trở nên rất lớn.

Một kỹ thuật mà tôi sử dụng: nếu tôi không thể giải thích điều gì đó một cách rõ ràng trong một câu, thì tên đó không đủ tốt. Hãy thử chính bạn - nếu bạn gặp khó khăn trong việc đặt tên cho một thứ gì đó, đó thường là dấu hiệu cho thấy chính thứ đó đang làm quá nhiều và cần phải được chia nhỏ.

Nguyên Tắc 2: Hàm Nên Thực Hiện Một Việc và Thực Hiện Tốt Nó

Nguyên Tắc Trách Nhiệm Đơn Lẻ không chỉ là lý thuyết học thuật - đây là chiến lược sinh tồn. Tôi đã học điều này theo cách khó khăn khi gỡ lỗi một hàm 400 dòng có tên processOrder xác thực đầu vào, tính thuế, cập nhật kho hàng, gửi email, ghi lại dữ liệu phân tích, và xử lý thanh toán. Việc tìm lỗi trong phép tính thuế có nghĩa là phải lội qua mã tạo mẫu email không liên quan.