Hôm nay mình xin giới thiệu một "kỹ thuật" khá quan trọng là Refactoring. Vậy nó là gì ?
- Theo mình hiểu thì Refactoring là tái cấu trúc, tổ chức lại mã nguồn mà không làm thay đổi hành vi của nó. Bạn có thể hình dung, phần mềm của mình là 1 căn phòng ngủ, refactoring có nghĩa là trang trí, thay đổi vị trí của các đồ dùng trong phòng ngủ để nó đẹp hơn, thoải mái hơn nhưng bản chất nó vẫn là phòng ngủ chứ không phải là phòng khách hay phòng bếp.
+ Vậy tại sao bạn nên refactoring?
- Nó giúp cải thiện cấu trúc thiết kế phần mềm của bạn.
- Giúp mã nguồn của bạn dễ hiểu hơn.
- Nó giúp bạn có thể tìm thấy nguyên nhân dẽ dàng hơn khi phần mềm của bạn dính lỗi.
- Ngoài ra nó giúp bạn viết phần mềm nhanh hơn.
+ Khi nào mình nên refactoring ?
- Khi bạn cần thêm một funciton.
- Khi bạn cần sửa một lỗi xuất hiện trong phần mềm.
- Và khi bạn review lại mã nguồn.
+ Khi nào bạn không nên refactoring ?
- Khi mã nguồn của bạn phải làm việc hầu như là chính xác trước khi bạn refactoring. Nếu mã nguồn của bạn chưa hoạt động chính xác hoặc chưa chạy được. Bạn không nên refactoring.
- Khi phần mềm của bạn đã đến deadline.
+ Một số vấn đề với refactoring :
- Khi bạn làm việc với database: Khi phần mềm của bạn làm việc với db, nó đã có một quan hệ chặt chẽ với db. Việc sử dụng refactoring làm bạn phải thay đổi cấu trúc của DB.
- Thay đổi interface : khi bạn đã public interface của bạn, việc tái cấu trúc lại nó cũng là một vấn đề.
- Khi bạn thay đổi thiết kế, việc refactoring gặp rất nhiều khó khăn, hầu như bạn phải đập và viết lại mới.
+ Vậy mã nguồn như thế nào là mã nguồn chưa tốt, cần refactoring ?
- Có rất nhiều cách nhận biết mã nguồn của bạn chưa tốt (bẩn hay "bóc mùi"), sau đây là một số cách nhận biết cơ bản :
- Duplicated Code : code của bạn có sự trùng lặp, khi có một đoạn mã với chức năng giống hệt được viết tại 2 nơi khác nhau.
- Long Method : phương thức của bạn quá dài - tính theo số dòng code.
- Large Class : Khi class của bạn chứa các phương thức và thuộc tính của như một class khác. Lấy một ví dụ : bạn có một class làm việc với DB nhưng class đó lại chứa những phương thức cũng như thuộc tính của class hiển thị View cho người dùng.
- Long Parameter List : Khi phương thức của bạn có quá nhiều tham số.
- Primitive Obsession : Khi bạn dùng các kiểu nguyên thủy để đại diện cho thực thể. Ví dụ bạn có một danh sách người chơi, bạn dùng các 1 mảng các con số như 1, 2, 3 để đại diện cho các người chơi, như vậy bạn đã mắc lỗi này.
- Switch Statements : Bạn nên cần thần khi làm việc với các câu lệnh switch. Bơi nó là nơi rất dẽ xuất hiện code "bẩn".
+ Hy vọng qua bài viết này bạn sẽ có cái nhìn khái quán về refactoring . Bài viết dựa trên slide của thầy Nguyễn Ngọc Tú . Download slide tại : http://www.mediafire.com/?7s55au5tp3kwfch
- Theo mình hiểu thì Refactoring là tái cấu trúc, tổ chức lại mã nguồn mà không làm thay đổi hành vi của nó. Bạn có thể hình dung, phần mềm của mình là 1 căn phòng ngủ, refactoring có nghĩa là trang trí, thay đổi vị trí của các đồ dùng trong phòng ngủ để nó đẹp hơn, thoải mái hơn nhưng bản chất nó vẫn là phòng ngủ chứ không phải là phòng khách hay phòng bếp.
+ Vậy tại sao bạn nên refactoring?
- Nó giúp cải thiện cấu trúc thiết kế phần mềm của bạn.
- Giúp mã nguồn của bạn dễ hiểu hơn.
- Nó giúp bạn có thể tìm thấy nguyên nhân dẽ dàng hơn khi phần mềm của bạn dính lỗi.
- Ngoài ra nó giúp bạn viết phần mềm nhanh hơn.
+ Khi nào mình nên refactoring ?
- Khi bạn cần thêm một funciton.
- Khi bạn cần sửa một lỗi xuất hiện trong phần mềm.
- Và khi bạn review lại mã nguồn.
+ Khi nào bạn không nên refactoring ?
- Khi mã nguồn của bạn phải làm việc hầu như là chính xác trước khi bạn refactoring. Nếu mã nguồn của bạn chưa hoạt động chính xác hoặc chưa chạy được. Bạn không nên refactoring.
- Khi phần mềm của bạn đã đến deadline.
+ Một số vấn đề với refactoring :
- Khi bạn làm việc với database: Khi phần mềm của bạn làm việc với db, nó đã có một quan hệ chặt chẽ với db. Việc sử dụng refactoring làm bạn phải thay đổi cấu trúc của DB.
- Thay đổi interface : khi bạn đã public interface của bạn, việc tái cấu trúc lại nó cũng là một vấn đề.
- Khi bạn thay đổi thiết kế, việc refactoring gặp rất nhiều khó khăn, hầu như bạn phải đập và viết lại mới.
+ Vậy mã nguồn như thế nào là mã nguồn chưa tốt, cần refactoring ?
- Có rất nhiều cách nhận biết mã nguồn của bạn chưa tốt (bẩn hay "bóc mùi"), sau đây là một số cách nhận biết cơ bản :
- Duplicated Code : code của bạn có sự trùng lặp, khi có một đoạn mã với chức năng giống hệt được viết tại 2 nơi khác nhau.
- Long Method : phương thức của bạn quá dài - tính theo số dòng code.
- Large Class : Khi class của bạn chứa các phương thức và thuộc tính của như một class khác. Lấy một ví dụ : bạn có một class làm việc với DB nhưng class đó lại chứa những phương thức cũng như thuộc tính của class hiển thị View cho người dùng.
- Long Parameter List : Khi phương thức của bạn có quá nhiều tham số.
- Primitive Obsession : Khi bạn dùng các kiểu nguyên thủy để đại diện cho thực thể. Ví dụ bạn có một danh sách người chơi, bạn dùng các 1 mảng các con số như 1, 2, 3 để đại diện cho các người chơi, như vậy bạn đã mắc lỗi này.
- Switch Statements : Bạn nên cần thần khi làm việc với các câu lệnh switch. Bơi nó là nơi rất dẽ xuất hiện code "bẩn".
+ Hy vọng qua bài viết này bạn sẽ có cái nhìn khái quán về refactoring . Bài viết dựa trên slide của thầy Nguyễn Ngọc Tú . Download slide tại : http://www.mediafire.com/?7s55au5tp3kwfch