Nghỉ giải lao #103. Bảo vệ “Code sạch”: 100 lời khuyên vượt thời gian

Nguồn: Hackernoon “Clean Code” của Robert C. Martin là cuốn sách lập trình được khuyên dùng nhiều nhất mọi thời đại. Tìm kiếm sách bằng truy vấn “sách hay nhất dành cho nhà phát triển phần mềm” và bạn gần như chắc chắn sẽ tìm thấy cuốn sách này trong kết quả tìm kiếm. Và trong khi một số người cảm thấy Clean Code không đáng để quan tâm, tôi cho rằng những quan điểm như vậy là sai lầm sâu sắc. Đúng vậy, một số lời khuyên trong cuốn sách còn đáng nghi ngờ. Có, một số nội dung có vẻ đã lỗi thời. Có, một số ví dụ có thể gây nhầm lẫn. Đó là tất cả sự thật. Nhưng chúng ta cũng đừng vội bỏ qua nhiều lời khuyên hữu ích mà cuốn sách này mang lại! Bỏ qua hoàn toàn Clean Code chỉ vì một vài ý tưởng tồi không phải là giải pháp tốt nhất. Vì vậy, không dài dòng nữa, hãy xem những mẹo hay nhất mà Clean Code cung cấp! Chúng ta sẽ đi qua từng chương, tóm tắt những ý tưởng mà chú Bob và các đồng tác giả đưa ra.

Chương 1: Mã sạch

1. Tổng số lượng lộn xộn tăng theo thời gian.

2. Khôi phục lại một hệ thống lỗi thời từ đầu là rất khó khăn. Tái cấu trúc và cải tiến gia tăng sẽ là lựa chọn tốt nhất cho việc này.

3. Trong một cơ sở mã lộn xộn, các tác vụ lẽ ra chỉ mất vài giờ nhưng lại có thể mất vài ngày hoặc vài tuần để hoàn thành.

4. Hãy dành thời gian để hành động nhanh chóng.

5. Mã sạch làm tốt một việc. Mã xấu cố gắng làm quá nhiều.

6. Mã sạch được kiểm tra tốt.

7. Khi đọc mã được viết tốt, mỗi hàm sẽ thực hiện gần đúng những gì bạn mong đợi.

8. Nếu bạn không đồng ý với một nguyên tắc được giảng dạy bởi một người có nhiều năm kinh nghiệm, ít nhất bạn nên xem xét quan điểm của họ trước khi bỏ qua nó.

9. Mã được đọc thường xuyên hơn nhiều so với được viết.

10. Mã dễ đọc hơn thì dễ thay đổi hơn.

11. Để lại cơ sở mã tốt hơn so với khi bạn tìm thấy nó (Quy tắc Hướng đạo sinh).

Chương 2: Ý nghĩa của những cái tên

1. Chọn tên biến của bạn một cách cẩn thận.

2. Chọn tên hay là khó.

3. Tên của một biến hoặc hàm phải cho biết nó là gì và nó được sử dụng như thế nào.

4. Tránh sử dụng tên biến có một ký tự, ngoại trừ những tên thường được sử dụng, chẳng hạn như i cho biến đếm trong vòng lặp.

5. Tránh sử dụng chữ viết tắt trong tên biến.

6. Tên biến phải dễ phát âm để bạn có thể nói và nói thành tiếng về chúng.

7. Sử dụng tên biến dễ tìm.

8. Các lớp và đối tượng phải có tên ở dạng danh từ.

9. Tên phương thức và hàm phải là động từ hoặc cặp động từ-danh từ.

Chương 3: Chức năng

1. Chức năng nên nhỏ.

2. Chức năng phải thực hiện một hành động.

3. Các hàm phải có tên mô tả.

4. Trích xuất mã trong phần nội dung if/else hoặc chuyển các câu lệnh thành các hàm được đặt tên rõ ràng.

5. Giới hạn số lượng đối số mà hàm nhận.

6. Nếu một hàm yêu cầu nhiều đối số cấu hình, hãy cân nhắc việc kết hợp chúng thành một biến tham số cấu hình duy nhất.

7. Các hàm phải thuần túy, có nghĩa là chúng không có tác dụng phụ và không sửa đổi các đối số đầu vào của chúng.

8. Hàm phải là một lệnh hoặc một truy vấn, nhưng không phải cả hai cùng một lúc (Tách truy vấn lệnh).

9. Tốt hơn là loại bỏ các lỗi và ngoại lệ khỏi mã hơn là để lại lỗi trong mã.

10. Trích xuất mã trùng lặp thành các hàm được đặt tên rõ ràng (Đừng lặp lại chính mình).

11. Kiểm tra đơn vị làm cho việc tái cấu trúc dễ dàng hơn.

Chương 4: Bình Luận

1. Nhận xét có thể không chính xác. Chúng có thể sai ngay từ đầu hoặc có thể ban đầu chính xác nhưng sau đó trở nên lỗi thời theo thời gian khi mã thay đổi.

2. Sử dụng các nhận xét để mô tả lý do tại sao nó được viết như vậy thay vì giải thích điều gì đang xảy ra.

3. Bạn thường có thể tránh nhận xét bằng cách sử dụng các biến được đặt tên rõ ràng và trích xuất các phần mã thành các hàm được đặt tên rõ ràng.

4. Tiền tố của các nhận xét TODO có tiền tố nhất quán để giúp bạn tìm thấy chúng dễ dàng hơn. Xem xét và dọn dẹp các nhận xét TODO của bạn theo định kỳ.

5. Đừng sử dụng Javadocs chỉ vì mục đích sử dụng chúng. Các nhận xét mô tả phương thức làm gì, đối số nào và kết quả trả về là gì, tốt nhất là dư thừa và tệ nhất là gây hiểu lầm.

6. Nhận xét nên bao gồm tất cả thông tin và bối cảnh có liên quan mà người đọc sẽ cần. Đừng lười biếng khi viết bình luận.

7. Nhận xét nhật ký và nhận xét tác giả tệp không cần thiết do kiểm soát phiên bản và đổ lỗi cho git.

8. Đừng bình luận về mã chết. Chỉ cần xóa nó. Nếu bạn cho rằng mình sẽ cần mã này trong tương lai thì đó chính là mục đích của việc kiểm soát phiên bản.

Chương 5: Định dạng

1. Với tư cách là một nhóm, hãy chọn một bộ quy tắc để định dạng mã của bạn, sau đó áp dụng các quy tắc đó một cách nhất quán. Bất kể bạn đồng ý với quy tắc nào, bạn cần phải đi đến thỏa thuận.

2. Sử dụng định dạng mã tự động và bộ phân tích mã. Đừng trông cậy vào người khác để tìm và sửa mọi lỗi định dạng theo cách thủ công. Điều này không hiệu quả, không hiệu quả và lãng phí thời gian khi xem lại mã.

3. Thêm khoảng trắng dọc giữa các dòng mã để phân tách các khối mã liên quan một cách trực quan. Tất cả những gì bạn cần là tạo một dòng mới giữa các nhóm.

4. Các tệp nhỏ dễ đọc, dễ hiểu và di chuyển hơn các tệp lớn.

5. Các biến phải được khai báo gần nơi chúng được sử dụng. Đối với các hàm nhỏ, phần này thường nằm ở đầu hàm.

6. Ngay cả đối với các hàm ngắn hoặc câu lệnh if, vẫn định dạng chúng chính xác thay vì viết chúng trên một dòng.

Chương 6: Đối tượng và cấu trúc dữ liệu

1. Chi tiết triển khai trong một đối tượng phải được ẩn đằng sau giao diện của đối tượng. Bằng cách cung cấp một giao diện để người tiêu dùng sử dụng một đối tượng, bạn giúp việc cấu trúc lại các chi tiết triển khai sau này trở nên dễ dàng hơn mà không gây ra các thay đổi đột phá. Sự trừu tượng làm cho việc tái cấu trúc dễ dàng hơn.

2. Bất kỳ đoạn mã nhất định nào cũng không được có kiến ​​thức về nội bộ của đối tượng mà nó hoạt động.

3. Khi làm việc với một đối tượng, bạn nên yêu cầu nó thực hiện một lệnh hoặc truy vấn, thay vì hỏi nó về nội bộ của nó.

Chương 7: Sửa lỗi

1. Việc xử lý lỗi không được can thiệp vào phần còn lại của mã trong mô-đun.

2. Tốt hơn là loại bỏ các lỗi và ngoại lệ khỏi mã hơn là để lại lỗi trong mã.

3. Viết các bài kiểm tra có lỗi để đảm bảo mã của bạn xác định được chúng và không bỏ sót chúng.

4. Thông báo lỗi phải có nhiều thông tin, với tất cả ngữ cảnh cần thiết mà ai đó có thể cần để khắc phục sự cố một cách hiệu quả.

5. Việc gói các API của bên thứ ba trong một lớp trừu tượng mỏng giúp việc thay thế thư viện này bằng thư viện khác trong tương lai trở nên dễ dàng hơn.

6. Việc gói các API của bên thứ ba trong một lớp trừu tượng mỏng giúp việc mô phỏng thư viện trong quá trình thử nghiệm dễ dàng hơn.

7. Sử dụng mẫu Trường hợp đặc biệt hoặc mẫu Đối tượng Null để xử lý hành vi đặc biệt, chẳng hạn như khi dữ liệu nhất định không tồn tại.

Chương 8: Ranh giới

1. Thư viện của bên thứ ba giúp tăng tốc độ phân phối sản phẩm bằng cách cho phép bạn thuê ngoài nhiều nhiệm vụ khác nhau.

2. Viết bài kiểm tra để đảm bảo bạn đang sử dụng thư viện của bên thứ ba một cách chính xác.

3. Sử dụng mẫu bộ điều hợp để thu hẹp khoảng cách giữa API của thư viện bên thứ ba và API mà bạn muốn có.

4. Việc gói các API của bên thứ ba trong một lớp trừu tượng mỏng giúp việc thay thế thư viện này bằng thư viện khác trong tương lai trở nên dễ dàng hơn. (Lặp lại từ Chương 7)

5. Việc gói các API của bên thứ ba trong một lớp trừu tượng mỏng giúp việc mô phỏng thư viện trong quá trình thử nghiệm dễ dàng hơn. (Lặp lại từ Chương 7)

6. Cố gắng không cung cấp cho ứng dụng của bạn quá nhiều thông tin về chi tiết của bất kỳ thư viện bên thứ ba nào.

7. Sẽ tốt hơn nếu phụ thuộc vào những gì bạn kiểm soát hơn là những gì bạn không kiểm soát.

Chương 9: Kiểm tra đơn vị

1. Mã kiểm tra phải rõ ràng như mã sản xuất (với một số ngoại lệ, thường liên quan đến bộ nhớ hoặc hiệu quả).

2. Khi mã sản xuất thay đổi thì mã kiểm tra cũng thay đổi.

3. Các thử nghiệm giúp giữ cho mã sản xuất của bạn linh hoạt và dễ bảo trì.

4. Các thử nghiệm cho phép bạn thực hiện các thay đổi, cho phép bạn tự tin tái cấu trúc mà không sợ bản thân không nhận thấy điều đó.

5. Cấu trúc các bài kiểm tra của bạn bằng cách sử dụng mẫu Sắp xếp-Hành động-Khẳng định (còn được gọi là mẫu Xây dựng-Vận hành-Kiểm tra, Thiết lập-Tập thể dục-Xác minh hoặc Đưa ra Khi nào Sau đó).

6. Sử dụng các hàm dành riêng cho miền để giúp bài kiểm tra dễ viết và đọc hơn.

7. Điểm một khái niệm cho mỗi bài kiểm tra.

8. Các bài kiểm tra phải nhanh chóng.

9. Các thử nghiệm phải độc lập.

10. Các thử nghiệm phải được lặp lại.

11. Các bài kiểm tra không nên yêu cầu xác nhận.

12. Các bài kiểm thử phải được viết kịp thời, ngay trước hoặc sau khi mã sản xuất được viết chứ không phải vài tháng sau đó.

13. Nếu các bài kiểm tra của bạn không tốt, chắc chắn sẽ có lỗi trong mã của bạn.

Chương 10: Lớp học

1. Các lớp học nên nhỏ.

2. Các lớp chỉ nên chịu trách nhiệm về một việc và chỉ nên có một lý do duy nhất để thay đổi (nguyên tắc trách nhiệm duy nhất).

3. Nếu bạn không thể nghĩ ra một cái tên rõ ràng cho lớp học thì có lẽ lớp đó quá lớn.

4. Công việc của bạn không kết thúc khi bạn có một đoạn mã để hoạt động. Bước tiếp theo sẽ là cấu trúc lại và làm sạch mã.

5. Việc sử dụng nhiều lớp nhỏ thay vì nhiều lớp lớn trong ứng dụng của bạn sẽ làm giảm lượng thông tin mà nhà phát triển phải hiểu khi thực hiện bất kỳ nhiệm vụ nhất định nào.

6. Việc có một bộ kiểm tra tốt cho phép bạn tự tin tái cấu trúc khi chia các lớp lớn thành các lớp nhỏ hơn.

7. Các lớp học phải được mở để mở rộng nhưng đóng lại để sửa đổi (nguyên tắc đóng mở).

8. Các giao diện và các lớp trừu tượng tạo ra các đường nối giúp việc kiểm tra dễ dàng hơn.

Chương 11: Hệ thống

1. Sử dụng tính năng chèn phụ thuộc để giúp các nhà phát triển linh hoạt chuyển bất kỳ đối tượng nào có giao diện phù hợp sang một lớp khác.

2. Sử dụng tính năng chèn phụ thuộc để tạo giao diện giữa các đối tượng trong ứng dụng của bạn nhằm giúp việc kiểm tra dễ dàng hơn.

3. Hệ thống phần mềm không giống như một tòa nhà cần được thiết kế trước. Chúng giống như những thành phố phát triển và mở rộng theo thời gian, thích ứng với nhu cầu hiện tại.

4. Trì hoãn việc đưa ra quyết định cho đến thời điểm quan trọng cuối cùng.

5. Sử dụng ngôn ngữ dành riêng cho miền để các chuyên gia và nhà phát triển miền sử dụng cùng một thuật ngữ.

6. Đừng quá phức tạp hóa hệ thống của bạn. Hãy sử dụng thứ đơn giản nhất mà hiệu quả.

Chương 12: Triển khai

1. Các hệ thống không thể kiểm tra sẽ không thể được xác minh và các hệ thống không thể xác minh sẽ không bao giờ được triển khai.

2. Việc viết các bài kiểm tra dẫn đến thiết kế tốt hơn vì mã dễ kiểm tra thường sử dụng tính năng chèn phụ thuộc, giao diện và tính trừu tượng.

3. Một bộ thử nghiệm tốt sẽ loại bỏ nỗi sợ làm hỏng ứng dụng của bạn trong khi tái cấu trúc.

4. Việc sao chép mã tạo ra nhiều rủi ro hơn vì có nhiều vị trí hơn trong mã có thể được thay đổi và thậm chí còn có nhiều vị trí có thể ẩn lỗi hơn.

5. Mã bạn viết bây giờ dễ hiểu hơn vì bạn đang tham gia sâu vào việc tìm hiểu nó. Không dễ để người khác nhanh chóng đạt được mức độ hiểu biết tương tự.

6. Hầu hết chi phí của một dự án phần mềm đều liên quan đến việc bảo trì dài hạn.

7. Các thử nghiệm đóng vai trò là tài liệu sống về cách ứng dụng của bạn nên (và thực hiện) hoạt động như thế nào.

8. Đừng di chuyển thêm nữa khi mã của bạn hoạt động. Hãy dành thời gian để làm cho nó rõ ràng và dễ hiểu hơn.

9. Người tiếp theo đọc mã của bạn trong tương lai gần rất có thể sẽ là bạn. Hãy tử tế với tương lai của bạn bằng cách viết mã dễ hiểu.

10. Chống lại giáo điều. Hãy theo đuổi chủ nghĩa thực dụng.

11. Phải mất hàng chục năm để trở thành một kỹ sư phần mềm thực sự giỏi. Bạn có thể tăng tốc quá trình học tập của mình bằng cách học hỏi từ các chuyên gia xung quanh và tìm hiểu các mẫu thiết kế thường được sử dụng.

Chương 13: Song song

1. Viết mã song song là khó khăn.

2. Đôi khi các lỗi và sự cố khó tái tạo thường là các sự cố tương tranh.

3. Việc kiểm tra không đảm bảo rằng ứng dụng của bạn sẽ không có lỗi nhưng nó sẽ giảm thiểu rủi ro.

4. Tìm hiểu về các vấn đề tương tranh phổ biến và các giải pháp khả thi.

Chương 14: Tinh chỉnh tuần tự

1. Mã sạch thường không bắt đầu bằng một bảng trống. Bạn viết một giải pháp thô trước rồi tái cấu trúc nó để làm cho nó sạch hơn.

2. Sẽ là một sai lầm nếu ngừng làm việc với mã khi nó đã bắt đầu hoạt động. Hãy dành thời gian để làm cho nó thậm chí còn tốt hơn sau khi nó đã hoạt động.

3. Tình trạng bất ổn đang gia tăng dần dần.

4. Nếu bạn thấy mình gặp khó khăn trong việc thêm các tính năng quá khó hoặc mất quá nhiều thời gian, hãy ngừng viết các tính năng và bắt đầu tái cấu trúc.

5. Thay đổi từng bước thường tốt hơn là xây dựng lại từ đầu.

6. Sử dụng Phát triển dựa trên thử nghiệm (TDD) để thực hiện một số lượng lớn các thay đổi rất nhỏ.

7. Thiết kế phần mềm tốt bao gồm việc tách các mối quan tâm trong mã của bạn và tách mã thành các mô-đun, lớp và tệp nhỏ hơn.

8. Dọn dẹp đống bừa bộn ngay sau khi dọn dẹp sẽ dễ dàng hơn là dọn dẹp sau đó.

Chương 15: Nội bộ JUnit

1. Tên biến phủ định hoặc biểu thức điều kiện khó hiểu hơn một chút so với tên biến tích cực.

2. Tái cấu trúc là một quá trình lặp đi lặp lại đầy thử nghiệm và sai sót.

3. Để lại cơ sở mã tốt hơn so với khi bạn tìm thấy nó (Quy tắc Hướng đạo sinh). (Lặp lại từ Chương 1)

Chương 16: Tái cấu trúc SerialDate

1. Đánh giá mã và phê bình mã của chúng tôi làm cho chúng tôi tốt hơn và chúng tôi nên hoan nghênh điều đó.

2. Đầu tiên hãy làm cho mã hoạt động, sau đó sửa nó.

3. Không phải mọi dòng mã đều cần được kiểm tra.

Chương 17: Mùi và chẩn đoán

1. Clean code không phải là một bộ quy tắc mà là một hệ thống các giá trị quyết định chất lượng công việc của bạn.

[Trong chương này, chú Bob liệt kê thêm 66 biến thể mã và phương pháp phỏng đoán của ông, nhiều biến thể trong số đó đã được đề cập trong phần còn lại của cuốn sách. Việc sao chép chúng ở đây về cơ bản sẽ là sao chép và dán tên của từng mục, vì vậy tôi đã hạn chế làm như vậy. Tôi khuyên bạn nên đọc cuốn sách này!]

Phần kết luận

Hãy kết thúc ở nơi chúng ta bắt đầu: Clean Code của Robert C. Martin là cuốn sách lập trình được khuyên dùng nhiều nhất mọi thời đại. Có lý do chính đáng cho việc này.