Clean code - P2

Chương 3 - Functions

Chức năng là đơn vị tổ chức nên chương trình. Rất khó để hiểu những chức năng dài với các lệnh if lồng nhau, các vòng lặp for/while lồng ngồng, những khái niệm trừu tượng, các công thức tính toán khó hiểu và các chức năng khác được gọi lồng vào nữa. Trong khi chỉ cần chú ý một chút thì chúng ta lại có thể viết code tốt hơn.
Cuốn Clean code đưa ra một số tip dưới đây:

Small

Nguyên tắc đầu tiên của functions là chúng cần phải nhỏ. Nguyên tắc thứ hai là nhỏ hơn nữa. Không có công trình nào chứng minh là functions nhỏ thì tốt hơn, nhưng dựa vào kinh nghiệm của các lập trình viên trong nhiều thập kỷ đều đồng tình rằng những functions vài trăm dòng code thường gây ra sự khó chịu gớm ghiếc với người đọc code. Kinh nghiệm từ các sai lầm chỉ ra rằng functions nên được thiết kế nhỏ.

Blocks and Indenting
Những khối lệnh if/else, while, for nên tách ra thành các function nhỏ xử lý và đặt thành một lời gọi hàm. Với tên các function tường minh sẽ cho biết thông tin cụ thể nó làm gì, xử lý gì khi được gọi trong một hàm lớn.
Đôi khi những function nhỏ chỉ vài ba dòng code, nhưng nếu tách ra làm code rõ nghĩa hơn thì cũng nên tách.

Do one thing

Function chỉ nên thực hiện xử lý duy nhất một điều gì đấy. Nó nên thực hiện điều đó cho tốt.

Nghe có vẻ trừu tượng??? Vấn đề ở đây là cần phân biệt one thing và multi steps. Một function (one thing) không chỉ là một công đoạn mà gồm nhiều công đoạn khác nhau (multi steps)
Giả sử có một chức năng là tính toán tài khoản người dùng chơi chứng khoán tại thời điểm hiện tại. Khi đó sẽ cần tính số dư hiện tại, số tiền lãi lỗ hiện tại,...
Thì ở đây "one thing" chính là tính toán tài khoản người dùng tại thời điểm hiện tại, còn "multi steps" là các bước tính số dư hiện tại, số tiền lãi lỗ hiện tại,......
Mỗi step hay mỗi công đoạn này lại có thể là một function con (function con này sẽ là một step trong function lớn). Khi phân rã một khái niệm lớn thành các khải niệm nhỏ sẽ dễ hiểu, dễ theo dõi hơn.

One Level of Abstraction per Function

Đây là một khái niệm khó, tự nhận thấy mình mới hiểu ở một khía cạnh nhỏ. Vì vậy chưa thể giải thích cặn cẽ, mọi người có thể tham khảo thêm ở đây để hiểu thêm về SLA (single level abstraction):
http://principles-wiki.net/principles:single_level_of_abstraction https://crmbusiness.wordpress.com/2015/09/17/understanding-levels-of-abstraction/
Một ví dụ nhỏ:

public List<ResultDto> buildResult(Set<ResultEntity> resultSet) {
    List<ResultDto> result = new ArrayList<>();
    for (ResultEntity entity : resultSet) {
        ResultDto dto = new ResultDto();
        dto.setShoeSize(entity.getShoeSize());        
        dto.setNumberOfEarthWorms(entity.getNumberOfEarthWorms());
        dto.setAge(computeAge(entity.getBirthday()));
        result.add(dto);
    }
    return result;
}

Trong phương thức này sử dụng 2 mức trừu tượng. Đầu tiên là vòng lặp hoạt động trên toàn bộ tập kết quả, thứ hai là các phần tử trong trong tập kết quả chuyển đổi thành một đối tượng khác gọi là DTO. Ta có thể viết lại như sau:

public List<ResultDto> buildResult(Set<ResultEntity> resultSet) {
    List<ResultDto> result = new ArrayList<>();
    for (ResultEntity entity : resultSet) {
        result.add(toDto(entity));
    }
    return result;
}
 
private ResultDto toDto(ResultEntity entity) {
    ResultDto dto = new ResultDto();
    dto.setShoeSize(entity.getShoeSize());        
    dto.setNumberOfEarthWorms(entity.getNumberOfEarthWorms());
    dto.setAge(computeAge(entity.getBirthday()));
    return dto;
}

Việc tách ra một phương thức mới tên là 'toDto' chỉ có một mức trừu tượng là convert object, và mức trừu tượng này được gọi trong một phương thức khác rõ ràng đã giúp code clear hơn.

Use Descriptive Names

Dùng những từ ngữ dễ đọc, tường minh để đặt tên hàm và dùng những từ khóa để mô tả chức năng của nó làm gì. Một cái tên mô tả dài tốt hơn là một tên ngắn bí ẩn, không clear, và cũng tốt hơn là phải viết thêm một đoạn comment mô tả.

Function Arguments

Nhóm tác giả đưa ra ý kiến rằng một function không nên có quá 3 tham số. Khi nhiều tham số sẽ khó khăn hơn khi đứng ở góc độ kiểm thử. Sẽ rất khó khăn khi viết testcase phải đảm bảo tất cả tổ hợp các tham số đều hoạt động đúng.Nếu với môt, hai tham số thì là bình thường, nhưng nếu nhiều hơn hai tham số thì đó quả là vấn đề.

• Common monadic function (có hai hình thức phổ biến khi sử dụng một tham số)
  Một hàm lý luận trả về true hoặc false
  Một hàm lập luận, biến nó thành một cái gì khác và trả về cái được biến đổi.
  Một hình thức khác ít phổ biến hơn là hàm xử lý sự kiện, có một tham số đầu vào nhưng không có đối số đầu ra.
  

• Flag arguments
  Một hàm nhận vào tham số là một flag arguments là một hàm tồi, bời vì nó đã làm nhiều hơn một điều. Một là khi flag có giá trị true, một là khi flag có giá trị false. Nhóm tác giả cho rằng nên tách trường hợp này thành hai hàm.
  

• Arguments objects
  Để ý rằng khi một số hàm cần nhiều hơn 3 tham số, có khả năng là một số trong những tham số đó có thể gói gọn trọng một object riêng của chúng.
  

Circle makeCircle(double x, double y, double radius);
Circle makeCircle(Point center, double radius);

• Verbs and Keywords
  Mã hóa tên các tham số vào tên hàm, điều này giảm nhẹ vấn đề phải nhớ thứ tự các tham số. Ví dụ:
  

getCustomer(String customerId);  -> getCustomerById(String customerId);
assertEquals(Object expected, Object actual);  -> assertExpectedEqualsActual(Object expected, Object actual);

Command Query Separation

Hàm nên rõ ràng trong việc thực hiện một điều gì đó hoặc trả về một cái gì đó. Chằng hạn một hàm có chức nằng thay đổi trạng thái của đối tượng hoặc trả về thông tin của đối tượng là 2 việc khác nhau. Hàm làm cả lúc hai việc sẽ dẫn đến sự nhầm lẫn hoặc gây khó hiểu. Ví dụ

public boolean set(String attribute, String value);

Hàm này đặt giá trị của một thuộc tính và trả về true nếu thành công, false nếu thuộc tính không tồn tại.

if (set("username", "unclebob"))...

Vấn đề: Không biết hàm set này đang thực hiện theo cách nào

• Kiểm tra thuộc tính "username" đã tồn tại hay chưa
• Set thuộc tính "username" với giá trị "unclebob"... => Gây nhầm lẫn
  

Giải quyết vấn đề bằng cách đặt lại tên và phân tách các phần để sự mơ hồ không xảy ra:

if (attributeExists("username")) {
   setAttribute("username", "unclebob");
   ...
}

Sau khi viết lại, code trong đã rõ ràng và clear hơn.