Hãy xem 1 cấu trúc dữ liệu được sử dụng trong code production thực tế: một “minute/hour counter”. Chúng tôi sẽ đưa ra cho bạn quá trình tự suy nghĩ tự nhiên của 1 kĩ sư có thể trải qua, đầu tiên thử giải quyết vấn đề và sao đó cải thiện hiệu năng của nó và thêm các chức năng. Quan trọng nhất, chúng ta sẽ cố gắng để code dễ đọc , sử dụng các nguyên tắc trong cuốn sách này. Chúng tôi có thể có một số lượt sai trên đường đi hoặc phạm sai lầm khác. Hãy xem nếu bạn có thể làm theo và bắt được chúng.

Trong chương này, chúng tôi sẽ chỉ cho bạn một số kĩ thuật đơn giản để viết các test sạch sẽ và hiệu quả.

Testing định nghĩa khác nhau với những người khác nhau. Trong chương này, chúng tôi sử dụng “test” có nghĩa là một vài code mà mục đích duy nhất của nó là kiểm tra hành vi của 1 phần (“real”) của code khác. Chúng tôi sẽ tập trung vào việc khía cạnh khả năng đọc của test và không nói sâu bạn nên viết test code trước khi viết code thực sự (“test-driven development”) hoặc khái cạnh về sự phát triển của test.

Trong 3 phần trước, chúng ta đã thảo luận về các phần rộng về các kĩ thuật làm cho code dễ hiểu. Trong phần này, chúng ta sẽ áp dụng các kĩ thuật đó vào 1 chủ đề được chọn.

Đầu tiên, chúng ta sẽ thảo luận về testing - làm sao viết test hiệu quả và có thể đọc được cùng 1 lúc.

Sau đó chúng ta sẽ đi quan tâm việc thiết kế và thực thi của cấu trúc dữ liệu mục đích đặc biệt (a “minute/hour counter”) để xem 1 ví dụ về hiệu năng, thiết kế tốt và tương tác với khả năng đọc code.

Chapter 14: Testing and Readability

Chapter 15: Designing and Implementing a “Minute/Hour Counter”

Biết khi nào không viết code có khả năng là kĩ năng quan trọng nhất 1 lập trình viên có thể học. Mỗi dòng code bạn viết là 1 dòng cần phải kiểm thử và bảo trì. Bằng cách sử dụng lại các thư viện hoặc loại bỏ các tính năng, bạn có thể tiết kiện thời gian và giữ codebase của bạn mỏng và có ý nghĩa.

KEY IDEA

The most readable code is no code at all.

You do not really understand something unless you can explain it to your grandmother.
— Albert Einstein

Code làm rất nhiều thứ 1 lúc rất khó hiểu. Một khối đơn của code có thể khởi tạo đối tượng mới, làm sạch dữ liệu, phân tích inputs và áp dụng logic, tất cả cùng 1 lúc. Nếu tất cả code đan xem với nhau, nó sẽ khó để hiểu hơn là mỗi “task” được bắt đầu và tự hoàn thành.

K E Y I D E A
Code should be organized so that it’s doing only one task at a time.

Nói cách khác, chương này đề cập đến vấn đề “phân mảnh” code của bạn. Theo dõi biểu đồ bên dưới để minh họa quá trình này: biểu đồ bên trái chỉ ra các đoạn mã khác nhau mà 1 phần của code đang làm và đoạn mã bên phải chỉ ra các đoạn code giống nhau sau khi nó được tổ chức làm 1 task 1 lúc.

Kĩ thuật là tất cả về việc chia nhỏ vấn đề lớn thành những vấn đề nhỏ hơn và đưa ra các giải pháp cho vấn đề đó lại với nhau. Áp dụng nguyên tắc này làm code dễ dàng đọc hơn.

Lời khuyên của chương này là chủ động xác định và trích xuất các bài toán con không liên quan. Điều đó có nghĩa:

1. Nhìn vào 1 hàm và khối code và tự hỏi “Mục đích ở mức high-level của đoạn code này?”
2. Với mỗi dòng code, hỏi “Nó có làm trực tiếp mục đích đó? Không thì nó đang giải quyết các vấn đề con không liên quan cần thiết để đáp ứng mục đích đó?”
3. Nếu đủ các dòng đang giải quyết các vấn đề con không liên quan, trích xuất code này vào trong các hàm tách biệt.

Trong phần 2, chúng ta đã thảo luận làm sao để thay đổi “vòng lặp và logic” trong chương trình của bạn để làm code có thể đọc. Chúng ta mô tả 1 vài kỹ thuật yêu cầu thay đổi cấu trúc của chương trình theo những cách nhỏ.

Trong phần này, chúng ta sẽ bàn luận về những thay đổi lớn hay bạn có thể làm với code ở mức function. Cụ thể, chúng ta sẽ khám phá các cách tổ chức lại code của bạn:

• Trích xuất “các vấn đề con không liên quan” cái mà không liên quan đến mục đích chính trong chương trình của bạn.
• Sắp xếp lại code của bạn để nó chỉ làm 1 task 1 lúc.
• Mô tả code của bạn bằng từ trước và sử dụng mô tả này để giúp bạn có hướng xử lý rõ ràng.

Cuối cùng, chúng ta sẽ thảo luận cách giải quyết bạn có thể xóa hoàn toàn code và tránh viết nó trong lần đầu tiên - cách tốt nhất để làm cho code dễ hiểu.

Chapter 10: Extracting Unrelated Subproblems

Chapter 11: One Task at a Time

Chapter 12: Turning Thoughts into Code

Chapter 13: Writing Less Code

Trong chương này, bạn sẽ thấy sẽ cẩu thả sử dụng biến trong lập trình làm khó hiểu hơn. Cụ thể, có 3 vấn đề cần tranh luận:

1. Khi có nhiều biến, sẽ khó hơn cho việc theo dõi tất cả.
2. Một phạm vi biến lớn hơn, bạn phải theo dõi nó lâu hơn.
3. Khi thường xuyên thay đổi biến, sẽ khó hơn để theo dõi giá trị hiện tại của nó.

Một con mực khổng lồ là loài động vật tuyệt vời và thông minh nhưng thiết kế body của nó gần hoàn hảo có 1 lổ hổng chết người: nó có 1 cái não mềm dẻo (donut-shaped brain) bọc trong thực quản. Do đó nếu nó nuốt quá nhiều thức ăn trong 1 lần, não của nó sẽ hư hại.

Điều này làm chúng ta phải làm gì với code? Well, code đến từ các “chunks” cái mà quá lớn, có thể có cùng hiệu ứng. Các nghiên cứu gần đây gợi ý rằng đa số chúng ta chỉ có thể nghĩ về 3 hoặc 4 “thứ” trong cùng 1 lúc. (Ref: Cowan, N. (2001). Con số kỳ diệu 4 trong trí nhớ ngắn hạn: Xem xét lại khả năng lưu trữ của não bộ. Behavioral and Brain Sciences, 24, 97–185.). Chỉ cần đặt đơn giản, 1 biểu thức lớn hơn trong code, đã rất khó hơn để hiểu.

K E Y I D E A
Break down your giant expressions into more digestible pieces.

Chia nhỏ những biểu thức khổng lồ của bạn thành những phần dễ hiểu hơn.