Refactoring Code - Day 2 - Các nguyên lý cơ bản trong refactoring

Hôm nay mình tiếp tục đọc phần II của cuốn sách “Priciples in Refactoring”. Phần này có lẽ là phần quan trọng nhất của cuốn sách nên mình sẽ đọc và nghiền ngẫm từ từ từng mục một. Dưới đây là những ghi chép ngẫu hứng tóm tắt lại 2 mục con của phần II:

Định nghĩa của Refactoring

  1. Refactoring là thay đổi cấu trúc bên trong của phần mềm làm cho nó “dễ hiểu hơn” và “rẻ hơn” cho việc thay đổi mà không thay đổi hành vi có thể quan sát được => End-user sẽ không thể cảm nhận có sự thay đổi bên trong phần mềm.

  2. Refactoring giống với Performance Optimization là thay đổi cấu trúc bên trong mà không thay đổi hành vi quan sát được. Nhưng lại khác nhau về mục đích: Performance Optimization thường làm code khó hiểu hơn để đổi lại hiệu năng khi cần thiết.

Tại sao phải dùng Refactoring?!

  1. Cải thiện thiết kế phần mềm. Refactoring thường xuyên sẽ giúp code giữ nguyên được hình dáng của thiết kế. Không những thế nó giúp làm tinh gọn những thiết kế nghèo nàn bằng cách giảm đi sẽ lặp đi lặp lại để đảm bảo rằng code chỉ thể hiện đúng 1 và chỉ 1 hành vi duy nhất của nó. Đó là bản chất của một thiết kế tốt.

  2. Làm cho phần mềm dễ hiểu hơn. Dù muốn hay không thì dự án phần mềm sẽ luôn xuất hiện thêm kể thứ 3 ngoài bạn và khách hàng, đó là những lập trình viên khác trong tương lai. Vì thế việc máy tính phải xử lý thêm vài vòng tính toán làm nó chậm đi cũng không quan trọng bằng vấn đề một thay đổi phải mất hàng tháng mà lẽ ra chỉ mất hàng giờ hết người lập trình viên hiểu rõ code của bạn. Ngoài ra, hãy dùng code để diễn tả ý tưởng của bạn, biến code trở thành công cụ ghi chép chủ đạo chứ không phải ghi nhớ trong trí nhớ hoặc viết vào một nơi khác.

  3. Giúp bạn tìm ra bugs dễ hơn. Một khi đã hiểu rõ code một cách rõ ràng, bạn sẽ phần nào đó xoá bở bớt những giả tưởng mơ hồ về hệ thống, từ đó có thể tìm ra lỗi dễ dàng hơn.

  4. Giúp bạn lập trình nhanh hơn (trong tương lai). Một thiết kế hệ thống tốt là thiết yếu cho việc phát triển nhanh hệ thống. Refactoring giúp cải thiện thiết kế hệ thống, giúp bạn đi theo đúng thiết kế => nó sẽ làm tăng tốc độ phát triển hệ thống lên là điều tất yếu!

Hôm nay mình chỉ đọc đến đây thôi vì phần này quan trọng mình không muốn sẽ bị quá tải về kiến thức, “giục tốc bất đạt” mà ;) có thể bạn sẽ thấy mình lặp ý trong các bài liên tục, cái này mình sẽ tổng hợp lại sau khi lĩnh hội xong cuốn sách :)


Nếu bạn muốn mua và tìm đọc cuốn sách thì nhấn vào đây

Ref:

  • Cover photo from Google Search

Refactoring Code - Day 1 - Cơ bản về refactoring

Hôm rài qua nha ông anh chôm (mượn) được cuốn sách kinh điển gối đầu giường của dân Dev. Cuốn sách này là “REFACTORING” của Martin Fowler bản năm 1999 hướng dẫn trên ngôn ngữ Java (có bản 2018 mới trên cũng trên nền Java… nhưng thêm chữ Script 😁 - JavaScript, nhưng theo mình cảm nhận thì nó không tường minh như là trên Java). Và đây là bìa cuốn sách:

Refactoring Book Cover 1999

Hôm nay mình đọc được hết phần 1 gồm 52 trang đầu của sách và cảm nhận được mình học được rất nhiều từ phần này, sau đây là những ghi chép ngẫu hứng tóm tắt lại phần I của mình:

  1. Refactoring bản chất là thay đổi cấu trúc code bên trong nhưng không thay đổi hành vi bên ngoài của code. (Nôm na là bạn học nhiều sẽ thông minh ra nhưng cơ thể bên ngoài vẫn phải vậy) => Vì thế đòi hỏi việc đầu tiên và quan trọng nhất trước khi refactoring là phải có một bộ test tốt.

  2. Nhịp điệu chính (thần chú bạn luôn nên nhớ) khi làm refactoring là thay đổi nhỏ -> test -> thay đổi nhỏ -> test -> thay đổi nhỏ -> … -> hoàn thành -> commit

  3. Code tốt là code tự nó giải thích được bản thân nó là gì, làm gì và chạy ra sao. Và chìa khoá trong việc này là cách đặt tên biến và phương thức. (nếu mọi thứ chưa tường minh thì mới dùng comments) => Đừng ngại trong việc đổi tên nếu nó làm code tường minh, rõ ràng hơn.

  4. Nên giải thoát cho các biến tạm thời không cần thiết, vì nó có thể bị lãng quên và dễ nảy sinh ra vấn đề sau này. => Có thể áp dụng chiến thuật “Replace Temp with Query”

  5. Đừng ngại refactoring sẽ làm chậm chương trình cho tới khi bạn có số liệu profiler chính xác. Và lúc đó thì chuyện tối ưu cũng sẽ dễ hơn là tối ưu trên một đống hỗn tạp phải không?! => Khi refactoring thì tính rõ ràng được ưu tiên hơn hiệu suất.

  6. Ưu tiên tách business logic ra khỏi giao diện để nâng cao tính tái sử dụng.

  7. Và cuối cùng nhưng không kém quan trọng là mục tiêu chính của refactoring:

    • Làm code tinh gọn hơn
    • Rõ ràng hơn, minh bạch hơn (No magic)
    • Dễ test hơn
    • Sẵn sàng cho những thay đổi trong tương lai hơn

PHẦN NÀY TỚI ĐÂY LÀ HẾT RÙI !!


Nếu bạn muốn mua và tìm đọc cuốn sách thì nhấn vào đây

Ref:

  • Cover photo from Google Search
  • “Refactoring - Improving Design Existing Code” book cover from Amazon