Clean code (P1)

Bài đăng này đã không được cập nhật trong 2 năm

Chủ đề lần này mình sẽ giới thiệu cho mọi người một cuốn sách rất hay giành cho developer là “Clean code – A handbook of Agile software craftsmanship ”.

Bạn đọc cuốn sách này thứ nhất bạn là một lập trình viên, thứ hai bạn muốn trở thành một lập trình viên tốt hơn. Rất tốt, chúng ta cần những lập trình viên tốt hơn.

Clearn code là sách hướng dẫn các cho các developder “code sạch”. Theo định nghĩa của sách “code sạch” là code dễ đọc, dễ hiểu, dễ sửa và dễ bảo trì.

Có người cho rằng chỉ cần viêt code có thể chạy được là OK và nghĩ rằng đoạn code mình viết thì mình sẽ nhớ được là mình làm như thế nào, hay với nguyên nhân khách quan làm cho kịp deadline, sau này có thời gian thì chỉnh sửa sau (sau này với developer là không bao giờ ). Bạn thử tưởng tượng với một đoạn code bạn viết trong vòng 2 hoặc 3 tháng bạn quay lại chỉnh sửa bạn còn nhớ bạn viêt gì không? Hay lúc đó bạn chỉ thấy một đống code lởm với những dòng không rõ nghĩa. Đó là một trong hậu quả của việc code không sạch.

Bài học rút ra từ cuốn sách:

Tầm quan trọng của việc viết “code sạch”.
Cách đặt tên biến, tên hàm. Tên biến tên hàm phải nói rõ tác dụng của hàm và biến.
Độ dài của hàm, các parameter truyền vào.
Tại sao không nên lạm dụng comment. Comment không phải không tốt nhưng có người viết code không sạch thì comment để làm gì. Sách khuyên ta nên viết code tự comment, tức là đoạn code dễ hiểu tới mức đọc là biết code làm gì, comment chỉ nên dùng để giải thích những đoạn không thể giải thích qua code.
Hướng dẫn cách viết và dùng unittest.
Giải quyết các vấn đề liên quan đến xung đột.
Một số ví dụ về refactor code (biến code lởm thành code sạch nhờ biện phám refactor).
Một số dấu hiệu nhận biết code smell (bạn có thể đọc và dựa theo dấu hiệu này tìm những đoạn code lởm trong project của bạn).

1. Tổng quan về việc viết “code sạch”.

There will be code – sẽ mãi phải viết code

Tác giả phủ định một giả thuyết rằng, tương lai không cần lập trình viên nữa mà mọi người có thể dùng app để tự tạo app mình cần (tương tự như kiểu kéo thả giao diện).
Tóm lại tương lai vẫn cần phải code, dù chúng ta có thể tạo ra những ngôn ngữ lập trình cực kỳ gần gũi với con người hay có những tool giúp chuyển những yêu cầu thành những đoạn mã thì vẫn luôn cần những chỗ chính xác tuyệt đối chỉ có thể tạo ra bằng việc viết code (so there will always be code ).

Bad code

Trong phần này tác giả đề cập vấn đề có cần thiết viết clearn code không hay chỉ bad code là đủ rồi.
Kent Beck người sáng tạo ra Test Driven Development đã nói: “... this book is based on a rather fragile premise: that good code matters...” - liệu mã tốt có quan trọng thật không.Tác giả khẳng định mã tốt là một trong những điều quan trọng nhất của lập trình.
Đã có rất nhiều project phát triển một thời gian các chức năng chạy tạm ổn, nhưng khi các yêu cầu thêm mới và update nhiều lên thì các dòng mã tăng lên và rất khó đọc đến nỗi người tạo ra project phải phát điên lên và đập hệ thống đi. Đó là hậu quả nghiêm trọng của việc viết code bẩn.
Chắc chắn bạn đi làm một thời gian bạn sẽ nhiều lần “cộc đầu” vào mã bẩn. Chính xác là bạn phải đọc hiểu đoạn code đó, mà càng đọc bạn càng không hiểu gì và đành chấp nhận chết đuối trong mã bẩn đó.

What is clear code

Một câu chuyện có thật xảy ra vào thập niên 80, vào thời điểm đó một ứng dụng tên là Killer rất nổi tiếng và được nhiều người sử dụng.
Sau khi sản phẩm được phát hành rộng rãi thì xuất hiện những bug từ những version đầu tiên cho tới version tiếp theo nhưng vẫn không được khắc phục làm cho Killer chạy không ổn định. Sau đó sản phẩm bị hủy hoại và công ty phát hành Killer cũng đóng cửa.
Hai mươi năm sau người phát hành Killer mới lên tiếng về sự thất bại đó. Họ nói rằng thời điểm phát hành Killer ra thị trường thì sản phẩm là một mớ code lộn xộn không thể bảo trì được, càng lúc càng thêm vào nhiều chức năng làm cho code ngày trở nên phình to và không quản lý được nữa. Sai lầm của họ là viết code bẩn.

Thế nào là clear code? Có rất nhiều chuyên gia nói về vấn đề này.**

Bjnarne Stroustrup tác giả cuốn sách “The C++ Programming Language” đưa ra quan điểm của mình: Ông muốn code của mình phải hiệu quả và đẹp. Tất cả các hàm business logic phải rõ ràng và bugs dễ dàng tìm thấy. Code phải dễ dàng bảo trì, các ngoại lệ phải được bắt một cách rõ ràng. Phải tối ưu hóa các performance, tránh viết code quá phức tạp gây khó khăn cho người khác.
Grady Booch tách giả cuốn sách “Object oriented analysic and design with Applications” đưa ra quan điểm của mình: viết code đơn giản, code phải dễ đọc và dễ hiểu cho người khác. Code phải có ý nghĩa và dễ quản lý.

2. Meaningful names

Name are everywhere in software. Có tên biến, tên hàm, tên đối, tên class và tên package. Dưới đây là một số quy tắc đặt tên:

2.1 Use intention – revealing names: đặt tên biến có ý nghĩa

Ví dụ 1:

Bad code:

int d; //elapsed time in days int ds;


-	Biến d có thể là bất cứ cái gì, chúng ta không hiểu được mục đích của tác giả

-	Tác giả sử dụng comment để nói lên mục đích của biến ds thay vì sử dụng trong code

**Good code**

- ```PHP
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

Tên biến nói rõ mục đích sử dụng biến.

Ví dụ 2:

Bad code

public List<int[]> getThem() { List<int[]> list1 = new ArrayList<int[]>(); for (int[] x : theList) if (x[0] == 4) list1.add(x); return list1; }

Mặc dù đoạn code trên không có những biểu thức phức tạp, khoảng cách và thụt vào đầu dòng là hợp lý nhưng vẫn gây khó hiểu cho người sử dụng đoạn code. Đoạn mã ngầm đòi hỏi chúng ta phải trả lời các câu hỏi sau:

-	List thuộc loại nào?

-	Ý nghĩa của chỉ mục 0 trong List là gì?

-	Giá trị 4 là gì?

-	Sử dụng kết quả trả về như thế nào?

**Good code**

- ```PHP
public List<int[]> getFlaggedCells() {
 	List<int[]> flaggedCells = new ArrayList<int[]>();
 		for (int[] cell : gameBoard)
 			if (cell[STATUS_VALUE] == FLAGGED)
 				flaggedCells.add(cell);
 			return flaggedCells;
 }

2.2 Avoid Disinformation

Người lập trình cần tránh đặt tên biến vô nghĩa, gây khó hiểu cho người dừng. Ví dụ khai báo int x, y, z là không nên, khi đọc tên biến người dùng không biết được ý nghĩa của biến là gì.
Hãy coi chừng các tên biến dài và gần gần giống nhau, nếu bạn không tinh mắt có thể hiểu nhầm các biến đó. Bạn rất dễ bị nhầm giữa hai tên một module XYZControllerForEfficientHandlingOfStrings và XYZControllerForEfficientStorageOfStrings tên một biến nào đó sử dụng đâu đó trong mã code.
Một ví thật sự khủng khiếp khi bạn sử dụng L và O (chữ cái viết hoa) để đặt tên biến. Vấn đề khi nhìn tên biến và hằng số 0 và 1 gần như hoàn toàn giống nhau.

int a = l; if ( O == l ) a = O1; else l = 01;


- Người đọc có thể nghĩ đó là chủ ý của người viết, nhưng điều này là không phải. Trong trường hợp này tác giả đưa ra giải pháp sử dụng một phông chữ khác để thấy rõ sự khác biệt.

Còn rất nhiều phần hay sẽ được cập nhật và trình bày ở phần tiếp theo.

Link tham khảo: https://cleansourcecode.files.wordpress.com/2013/10/clean-code.pdf

PHP

Mục lục