Viết hàm sao cho tốt (P2)

Tiếp theo P1

2. Nguyên tắc 2: nghĩ trước khi làm

Khi bắt tay vào implement cho một hàm (xa hơn là một chức năng nào đó), đừng vội code, hãy phân tích kỹ từng việc sẽ làm của hàm.

Đôi khi với những chức năng phức tạp, chúng ta nên vẽ ra luồng xử lý chính cho thật rõ ràng.

Điều này sẽ giúp bạn tránh được nhứng sai sót trong quá trình coding. Do đó hãy phân tích cẩn thận, đối chiếu với yêu cầu và có thể thảo luận với tester (QC, QA) để xác nhận việc hiểu của mình là đúng, đồng thời giúp cả team có cái nhìn thống nhất về việc sẽ làm.

Có nhiều công cụ hỗ trợ việc này, bao gồm có phí lẫn miễn phí, online và offline như:

Hãy làm tốt việc này, nó sẽ giúp bạn phát triển hơn về sau.

Trong quá trình implementation, hãy tạo các dòng comment trước những block code, giải thích việc bạn sắp làm trong mấy dòng code tiếp theo. Việc này rất có lợi cho những người sau này có nhu cầu sửa chữa, cập nhật. Trên thực tế, ngay chính bản thân tác giả dòng code đó chưa chắc nhớ nỗi những thứ mình đã làm trước đó 1-2 tuần.

void DoActionA(T param)
{
    // TO DO
    // Step 1: validate the param
    // Step 2: process X
    // Step 3: process the result of X
    ....
}

3. Nguyên tắc 3: cố gắng tái sử dụng những hàm có sẵn.

Khi bạn muốn thực hiện một chức năng mới, hãy tìm xem trong chức năng này có phần nào đã được thực hiện trong các chức năng hiện có của hệ thống hay không. Trong trường hợp đã có một phần nào đó đã có trước đây, hãy sử dụng nó thay vì viết mới.

Hãy xem lại phần P1 của chủ đề này, trong nguyên tắc thứ nhất mà chúng tôi đưa ra ví dụ.

Giả sử ban đầu anh A viết hàm CheckPrime bằng cách viết riêng một hàm kiểm tra nguyên tố (IsPrime). Khi anh A (hoặc anh B) viết CountPrime, anh có thể tái sử dụng hàm IsPrime mà không cần viết lại. (Bạn có thấy việc tách nhỏ hàm lợi hại chưa? 😀 )

Có 3 lợi ích
  • GIảm thiểu công sức bỏ ra cho cả việc code lẫn test. Ví dụ như trên, chúng ta không cần code hay test lại việc kiểm tra nguyên tố, mà chỉ tập trung vào việc đếm số nguyên tố trong dãy số đầu vào.
  • Bớt sai sót. Làm càng nhiều sai càng nhiều, cho nên tái sử dụng thì ít sai hơn là viết mới.
  • Tránh trùng lắp code (dupplicate). Việc này ảnh hưởng việc đánh giá chất lượng code của dự án.

(còn tiếp P3)

1 bình luận về “Viết hàm sao cho tốt (P2)”

Viết một bình luận