Clean Code
Trở thành một Lập trình viên tốt hơn
Nguyễn Khắc Nhật
| 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
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
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?
Những hình ảnh thường thấy
Bạn viết code như thế nào?
Quy trình thường thấy
Ban đầu
Quy trình thường thấy
Hệ thống đẹp
Quy trình thường thấy
Thêm tính năng mới
Quy trình thường thấy
Thêm một tính năng mới
Quy trình thường thấy
Thay đổi một tính năng
Thời gian trôi qua…
Kết quả thường thấy
Bạn có thấy quen thuộc không?
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?
Cách làm đúng
Ban đầu
Cách làm đúng
Hệ thống đẹp
Thêm tính năng mới
Cách làm đúng
Dọn dẹp sạch sẽ
Cách làm đúng
Cách làm đúng
Thêm tính năng mới
Cách làm đúng
Dọn dẹp sạch sẽ
Thời gian trôi qua…
Kết quả cần có
Kiến trúc sạch
Về năng suất thì sao?
`
Thời gian
Năng suất
`
Code bẩn
Code sạch
Clean Code là gì?
• Clean Code là tiêu chuẩn của code “tốt”
• Code như thế nào thì được coi là tốt?
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#
• Đơ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
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
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
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
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)
Một số ví dụ
Đặ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());
Đặ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;
}
Đặt tên đồng nhất khi có cùng ý nghĩa
• Không tốt:
• Tốt:
getUserInfo();
getClientData();
getCustomerRecord();
getUser();
Đặ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);
Đặ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()) {
//...
}
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";
}
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();
}
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);
DEMO
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
Tham gia các cộng đồng
Coding Dojo
Coderetreat
Clean code - Trở thành một lập trình viên tốt hơn

Clean code - Trở thành một lập trình viên tốt hơn

  • 1.
    Clean Code Trở thànhmộ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 đã baogiờ? • Đọ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 ảnhthường thấy
  • 11.
    Bạn viết codenhư thế nào?
  • 12.
    Quy trình thườngthấy Ban đầu
  • 13.
    Quy trình thườngthấy Hệ thống đẹp
  • 14.
    Quy trình thườngthấy Thêm tính năng mới
  • 15.
    Quy trình thườngthấy Thêm một tính năng mới
  • 16.
    Quy trình thườngthấy Thay đổi một tính năng
  • 17.
  • 18.
    Kết quả thườngthấy Bạn có thấy quen thuộc không?
  • 19.
    Kết quả thườngthấy Làm thế nào để code tiếp? Bạn có thấy quen thuộc không?
  • 20.
  • 21.
    Cách làm đúng Hệthống đẹp
  • 22.
    Thêm tính năngmới Cách làm đúng
  • 23.
    Dọn dẹp sạchsẽ Cách làm đúng
  • 24.
    Cách làm đúng Thêmtính năng mới
  • 25.
    Cách làm đúng Dọndẹp sạch sẽ
  • 26.
  • 27.
    Kết quả cầncó Kiến trúc sạch
  • 28.
    Về năng suấtthì sao? ` Thời gian Năng suất ` Code bẩn Code sạch
  • 29.
  • 30.
    • Clean Codelà tiêu chuẩn của code “tốt” • Code như thế nào thì được coi là tốt?
  • 31.
    Grady Booch Object OrientedAnalysis 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 • Đặttê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.
  • 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 đồngnhấ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ácngữ 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ầncó ý 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.
  • 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áccộng đồng
  • 49.
  • 50.