Trao đổi về chủ đề Clean Code tại CodeGym. Thế nào là một mã nguồn tốt? Làm thế nào để hệ giữ được hệ thống sạch?

1. Clean Code
Trở thành một Lập trình viên tốt hơn
Nguyễn Khắc Nhật

2. | Agile | Scrum | Kanban | Lean | Java | Scala | Typescript | NodeJS | Bobril | Angular
• Giảng viên
• Lập trình viên
• Chuyên gia Agile, Scrum, Kanban
• Đồng tác giả sách “Cẩm nang Scrum”
• Đồng sáng lập Học viện Agile
• Đồng sáng lập CodeGym

3. Bạn đã bao giờ?
• Đọc lại những dòng code của mình và tự hỏi:
• Đứa nào code vậy? Đoạn này nghĩa là thế nào đây?
• Code chỗ này nhưng lại phát sinh bug ở chỗ kia?
• Càng code thì hệ thống càng chậm?
• Thậm chí đến một lúc nó còn không chạy được
• Đọc mã nguồn của các hệ thống mã nguồn mở và không hiểu gì?
• Phải viết thêm nhiều câu chú thích trong code của mình?
• Bởi vì nếu không thì không ai hiểu chúng đang làm gì
• Cố gắng viết mã nguồn ngắn nhất có thể, bởi vì như thế mới là xịn?
• Mà không biết rằng chúng rất khó hiểu

4. Bạn có đang?
• Tự hào về những dòng code mà mình viết ra?
• Hay là chỉ muốn giấu diếm chúng, không muốn ai nhìn thấy?
• Cố gắng dành thời gian để trau chuốt những dòng code?
• Hay là code cho chúng chạy được là tốt rồi?
• Viết code một cách bài bản?
• Hay theo chiến thuật code-and-fix?

5. Những hình ảnh thường thấy

11. Bạn viết code như thế nào?

12. Quy trình thường thấy
Ban đầu

13. Quy trình thường thấy
Hệ thống đẹp

14. Quy trình thường thấy
Thêm tính năng mới

15. Quy trình thường thấy
Thêm một tính năng mới

16. Quy trình thường thấy
Thay đổi một tính năng

17. Thời gian trôi qua…

18. Kết quả thường thấy
Bạn có thấy quen thuộc không?

19. Kết quả thường thấy
Làm thế
nào để
code tiếp?
Bạn có thấy quen thuộc không?

20. Cách làm đúng
Ban đầu

21. Cách làm đúng
Hệ thống đẹp

22. Thêm tính năng mới
Cách làm đúng

23. Dọn dẹp sạch sẽ
Cách làm đúng

24. Cách làm đúng
Thêm tính năng mới

25. Cách làm đúng
Dọn dẹp sạch sẽ

26. Thời gian trôi qua…

27. Kết quả cần có
Kiến trúc sạch

28. Về năng suất thì sao?
`
Thời gian
Năng suất
`
Code bẩn
Code sạch

29. Clean Code là gì?

30. • Clean Code là tiêu chuẩn của code “tốt”
• Code như thế nào thì được coi là tốt?

31. Grady Booch
Object Oriented Analysis
Dave Thomas
OTI, Eclipse
Michael Feathers
Working effectively with Legacy Code
Ron Jeffries
Extreme Programming Installed
Extreme Programing Adventures in C#

32. • Đơn giản
• Trực tiếp
• Dễ đọc hiểu
• Có ít phụ thuộc
• Không có code lặp
• Chạy tất cả các bài kiểm thử
• Không làm mờ đi ý định của người viết
• Giống một bài văn hay
• Giống như là được viết ra bởi một người rất có tâm
Clean Code

33. Smell Code
• Đặt tên vô nghĩa
• Phương thức quá dài
• Lớp quá dài
• Phương thức xử lý quá nhiều việc
• Phương thức có quá nhiều tham số
• Lạm dụng quá nhiều ghi chú (comment) trong mã nguồn
• Mã nguồn bị trùng lặp
• Sử dụng các giá trị magic

34. Clean Code ở đâu?
Định danh Hàm Ghi chú
Định dạng
Đối tượng & Lớp
Xử lý lỗi Kiểm thử
Kiến trúc

35. Clean Code thì được gì?
• Cộng tác dễ dàng hơn
• Debug dễ dàng hơn
• Ít rủi ro hơn
• Năng suất hơn
• Đi được đường dài hơn
• Hạnh phúc hơn

36. Làm sao để có Clean Code?
• Phải nắm tiêu chuẩn
• Phải biết mục đích
• Phải làm việc với tinh thần phục vụ
• Khác với làm cho xong việc
• Phải học các pattern (nhận diện code thối)
• Phải học các dọn dẹp code (refactor)

37. Một số ví dụ

38. Đặt tên có ý nghĩa và đọc được (1)
• Không tốt:
• Tốt:
String yyyymmdstr = new SimpleDateFormat("YYYY/MM/DD").format(new Date());
String currentDate = new SimpleDateFormat("YYYY/MM/DD").format(new Date());

39. Đặt tên có ý nghĩa và đọc được (2)
• Không tốt • Tốt
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}

40. Đặt tên đồng nhất khi có cùng ý nghĩa
• Không tốt:
• Tốt:
getUserInfo();
getClientData();
getCustomerRecord();
getUser();

41. Đặt tên để tìm kiếm được
• Không tốt:
• Tốt:
setTimeout(blastOff, 86400000);
public static final int MILLISECONDS_IN_A_DAY = 86400000;
setTimeout(blastOff, MILLISECONDS_IN_A_DAY);

42. Đặt tên để tự giải thích ý nghĩa
• Không tốt:
• Tốt:
Application application = new Application();
//...
if(application.getStatus() == "paid") {
//...
}
Application application = new Application();
//...
if(application.isPaid()) {
//...
}

43. Không thêm các ngữ cảnh thừa
• Không tốt: • Tốt:
class Car {
public String carMake = "Honda";
public String carModel = "Accord";
public String carColor = "Blue";
}
void paintCar(Car car) {
car.carColor = "Red";
}
class Car {
public String make = "Honda";
public String model = "Accord";
public String color = "Blue";
}
void paintCar(Car car) {
car.color = "Red";
}

44. Mỗi hàm chỉ nên làm một việc
• Không tốt: • Tốt:
public void emailClients(List<Client> clients) {
for (Client client : clients) {
Client clientRecord = repository.findOne(client.getId());
if (clientRecord.isActive()){
email(client);
}
}
}
public void emailClients(List<Client> clients) {
for (Client client : clients) {
if (isActiveClient(client)) {
email(client);
}
}
}
private boolean isActiveClient(Client client) {
Client clientRecord = repository.findOne(client.getId());
return clientRecord.isActive();
}

45. Tên hàm cần có ý nghĩa
• Không tốt: • Tốt:
private void addToDate(Date date, int month){
//..
}
Date date = new Date();
addToDate(date, 1);
private void addMonthToDate(Date date, int month){
//..
}
Date date = new Date();
addMonthToDate(1, date);

46. DEMO

47. Bộ các kỹ thuật liên quan
• Clean Code
• Tiêu chuẩn chất lượng
• Code Refactoring
• Cách để có được Clean Code
• Automation Test
• Đảm bảo an toàn khi refactor
• Design Pattern
• Tiêu chuẩn chất lượng cao hơn

48. Tham gia các cộng đồng

49. Coding Dojo

50. Coderetreat