Code refactoring - tái cấu trúc mã nguồn và những kỹ thuật thông dụng

Tái cấu trúc mã nguồn là một phần không thể thiếu trong công việc của mọi developer. Nó đặc biệt quan trọng nếu bạn làm việc trong một môi trường linh hoạt. Trong bài viết này chúng ta hãy xem cái nhìn tổng quan về tái cấu trúc mã nguồn, cách hoạt động, khi nào cần, các kỹ thuật chính để tái cấu trúc và lợi ích của nó.

Code refactoring hay tái cấu trúc mã nguồn là gì?

Theo Martin Fowler, tác giả của hai cuốn sách về tái cấu trúc:

“Tái cấu trúc (refactoring) là quá trình thay đổi hệ thống phần mềm theo cách không làm thay đổi hành vi bên ngoài của code nhưng vẫn cải thiện cấu trúc bên trong của nó. Đó là một cách có kỷ luật để làm sạch code, giúp giảm thiểu cơ hội tạo ra lỗi. Về bản chất, khi bạn cấu trúc lại, bạn đang cải thiện thiết kế của mã sau khi nó đã được viết. “

Mục đích chính của việc tái cấu trúc mã nguồn là khá rõ ràng: làm cho mã sạch, gọn gàng, hiệu quả hơn và có thể bảo trì được. Quá trình này có nghĩa là một loại nâng cấp phần mềm cần thiết để cải thiện một số tính năng phi chức năng: khả năng bảo trì, hiệu suất, bảo mật và khả năng mở rộng.

Quá trình tái cấu trúc thường bao gồm một loạt các bước nhỏ được gọi là “tái cấu trúc vi mô”. Tại mỗi bước này, một thay đổi nhỏ đối với mã nguồn được thực hiện. Sự thay đổi đó làm cho mã đơn giản hơn và sạch hơn trong khi chức năng hệ thống vẫn như cũ.

Những lợi ích của việc tái cấu trúc mã nguồn

Như đã đề cập bên trên, việc tái cấu trúc mã nguồn không thay đổi hành vi bên ngoài của phần mềm. Chức năng của sản phẩm vẫn giữ nguyên và người dùng sẽ không thấy bất kỳ sự khác biệt nào.

Vậy tại sao code refactoring lại quan trọng? Có một số lý do giải thích tại sao việc tái cấu trúc mã nguồn lại quan trọng trong phát triển phần mềm:

Làm đơn giản hóa việc hỗ trợ và cập nhật code. Clean code dễ cập nhật và cải thiện hơn nhiều so với mã lộn xộn. Các lập trình viên có thể nhanh chóng viết ra chức năng mới, đồng thời cũng tiết kiệm ngân sách hỗ trợ vì việc bảo trì sẽ cần ít thời gian hơn.
Tiết kiệm thời gian và tiền bạc trong tương lai. Tái cấu trúc mã nguồn làm giảm khả năng xảy ra lỗi trong tương lai và đơn giản hóa việc triển khai chức năng phần mềm mới. Thay vì gỡ rối hoặc sửa lỗi, các nhà phát triển có thể nhanh chóng triển khai chức năng cần thiết ngay.

Giảm độ phức tạp để dễ hiểu hơn của code. Nếu có một nhân viên mới hoặc toàn bộ nhóm phát triển thay đổi hoàn toàn, những mới tham gia sẽ dễ dàng hiểu mã hơn và thực hiện các thay đổi cần thiết nhanh hơn.
Tăng khả năng bảo trì và khả năng mở rộng. Đôi khi, các lập trình viên chỉ đơn giản là tránh thực hiện các thay đổi đối với một số mã bẩn vì họ không hiểu rõ ràng những sửa đổi này sẽ dẫn đến hậu quả gì. Điều này cũng đúng với khả năng mở rộng. Loại bỏ trở ngại này là một lợi ích của việc tái cấu trúc mã.

Như vậy cả doanh nghiệp và các lập trình viên đều nhận được hai lợi ích chính: giảm thời gian và tiền bạc và có thể hiểu dễ dàng hơn về cách phần mềm hoạt động.

Khi nào cần đến code refactoring?

Không khó để biết thời điểm thích hợp để tái cấu trúc. Dưới đây là một số tình huống phổ biến để thực hiện việc tái cấu trúc mã:

Nợ kỹ thuật (Technical debt) được tích lũy. Nếu một số nhiệm vụ tương tự bắt đầu mất nhiều thời gian hơn để hoàn thành so với lúc khởi động dự án, nhưng mức độ phức tạp của chúng không thay đổi, thì đây là những triệu chứng rõ ràng của nợ kỹ thuật tích lũy. Điều đó có nghĩa là dự án ngày càng chứa nhiều đoạn mã phức tạp và khó hiểu, lỗi kiến trúc, và bản thân khả năng mở rộng của dự án cũng khó khăn.
Khi cần thiết mở rộng quy mô. Hãy giả định rằng sản phẩm hoạt động ổn, nhưng cần quá nhiều thời gian để thêm chức năng mới hoặc các vấn đề khác nhau bắt đầu xuất hiện do quá trình triển khai sản phẩm.

Khi ần thiết để làm cho mã dễ hiểu hơn. Phải mất nhiều năm để phát triển một số sản phẩm phần mềm và về mặt logic, nhân sự của nhóm thay đổi theo thời gian. Cấu trúc lại làm cho mọi mã dễ hiểu hơn đối với các thành viên mới trong nhóm.
Khi cần giảm chi phí nâng cấp và hỗ trợ. Qua lăng kính kinh doanh, điểm này là quan trọng nhất. Như đã đề cập trên, clean code và có cấu trúc tốt sẽ mất ít thời gian để cập nhật và bảo trì hơn.

Ngoài ra, nếu có thể, bạn có thể tái cấu trúc vi mô thường xuyên. Ví dụ: bạn có thể dành giờ cuối cùng trong ngày làm việc của mình cho hoạt động này vài lần một tuần.

Một số kỹ thuật chính trong code refactoring

Như đã đề cập trước đây, cách tốt nhất để cấu trúc lại là thực hiện theo từng bước nhỏ. Điều quan trọng là phải làm điều đó trước khi thêm bất kỳ chức năng hoặc tính năng mới nào vào giải pháp. Việc tái cấu trúc mã sẽ không thay đổi bất kỳ điều gì về cách sản phẩm hoạt động.

Có nhiều cách tiếp cận và kỹ thuật khác nhau để tái cấu trúc mã. Một số phổ biến nhất bao gồm:

1- Red-Green-Refactor

Một trong những kỹ thuật được sử dụng rộng rãi nhất để tái cấu trúc mã là quy trình RED / GREEN được sử dụng trong Agile test-driven development. Áp dụng phương pháp Red-Green-Refactor, các nhà phát triển chia cấu trúc lại thành ba bước riêng biệt:

RED: những gì (what) bạn muốn phát triển. Giai đoạn đầu tiên này là viết một bài kiểm tra. Vì tại thời điểm này, mã tương ứng hỗ trợ chức năng được kiểm tra không tồn tại, nên kiểm tra sẽ thất bại.
GREEN: cách (how) làm cho các bài kiểm tra của bạn vượt quan. Bước này là viết code & chức năng dự kiến sẽ tương ứng với thử nghiệm. Ở đây, người ta ít chú ý đến độ hoàn hảo của giải pháp. Trọng tâm chính tại thời điểm này là vượt qua bài kiểm tra và biến nó thành XANH!
REFACTOR: Thực hiện (how) các cải tiến. Giai đoạn này giành cho việc cấu trúc lại cả code và các bài test. Mục tiêu ở đây là chú ý đến các nội dung và tìm cách cải tiến.

2- Refactoring by Abtraction

Phân nhánh theo trừu tượng là một phương pháp được sử dụng chủ yếu khi cần thực hiện một lượng lớn việc tái cấu trúc. Tính trừu tượng liên quan đến kế thừa lớp, hệ thống phân cấp và trích xuất. Mục tiêu của trừu tượng hóa là giảm bớt sự trùng lặp không cần thiết trong mã phần mềm.

Một ví dụ về sự trừu tượng hóa là phương pháp Pull-Up/Push-Down. Đây là hai hình thức tái cấu trúc đối lập liên quan đến các lớp. Phương thức Pull-Up kéo các phần mã vào một lớp cha để loại bỏ sự trùng lặp mã. Push-Down lấy nó từ một lớp cha và chuyển nó xuống các lớp con.

3- Composing Methods

Đôi khi các developers có xu hướng viết code mở rộng quá phức tạp và khó đọc. Để giải cứu trong những tình huống như thế này, composing method được dùng để tái cấu trúc mã nguồn. Extraction và inline là hai trong số các kỹ thuật liên quan đến phương pháp tái cấu trúc này.

Extraction liên quan đến việc chia nhỏ code thành các phần nhỏ hơn để tìm và “trích xuất” sự phân mảnh. Sau đó, code bị phân mảnh được chuyển sang một phương thức riêng biệt và được thay thế bằng một lệnh gọi đến phương thức mới này. Ngoài phương thức, việc trích xuất có thể liên quan đến các lớp, giao diện và biến cục bộ.

Inline refactoring là một cách để giảm số lượng các phương thức không cần thiết trong khi đơn giản hóa code. Bằng cách tìm tất cả các lệnh gọi đến phương thức và thay thế chúng bằng nội dung của phương thức, phương thức sau đó có thể bị xóa.

4- Simplifying methods

Simplifying methods trong code refactoring có hai kỹ thuật:

Simplifying Conditional Expressions: Các câu lệnh điều kiện trong code có thể trở nên phức tạp theo thời gian. Đơn giản hóa các biểu thức điều kiện bằng cách sử dụng các kỹ thuật như hợp nhất các biểu thức điều kiện, phân tách điều kiện, thay thế điều kiện bằng tính đa hình, v.v.

Simplifying Method Calls: Điều này liên quan đến việc sửa đổi các tương tác giữa các lớp. Ví dụ: cập nhật các tham số hiện có và giới thiệu các tham số mới, thay thế các tham số bằng lời gọi phương thức, phương thức tham số hóa, v.v.

5 – Moving features between objects

Phương thức này chuyển các chức năng sang các lớp mới từ các lớp cũ có quá nhiều chức năng. Bạn có thể biết khi nào là thời điểm thích hợp để di chuyển giữa các lớp nếu bạn quan sát thấy lớp có quá nhiều chức năng được xác định trong đó hoặc nó không hoạt động nhiều. Sau đó, bạn có thể di chuyển các tính năng của lớp đó sang một lớp khác có nhiều không gian hơn và có thể sử dụng được hoặc xóa nó khỏi code.

6 – Preparatory refactoring

Preparatory refactoring (tái cấu trúc để chuẩn bị) là một hình thức thanh toán các khoản nợ kỹ thuật đã tích lũy theo thời gian. Như trong ví dụ của Martin Fowler, khi bạn bắt đầu phát triển một tính năng mới, bạn phát hiện ra rằng code bạn đang có không có cấu trúc tốt và việc thêm các tính năng mới vào code đó không phải là điều dễ dàng. Sau đó, bạn có thể cấu trúc lại code để dễ dàng đưa tính năng mới vào đó. Việc tái cấu trúc này trước khi phát triển thực tế được gọi là preparatory refactoring, nơi bạn chuẩn bị code của mình để phát triển tốt hơn.

Kết luận

Như đã đề cập, lợi ích chính của việc tái cấu trúc mã nguồn là làm sạch dirty coden, từ đó giảm nợ kỹ thuật. Clean code dễ đọc hơn, giúp cho cả các lập trình viên có thể làm việc trên mã nguồn đó trong tương lai một cách dễ dàng hơn. Code ít phức tạp hơn cũng có thể dẫn đến việc bảo trì được cải thiện, để kiến trúc bên trong biểu cảm hơn. Clean code cũng có nghĩa là các phần tử thiết kế và mô-đun mã có thể được sử dụng lại – nếu mã hoạt động tốt và sạch, nó có thể trở thành codebase ở những nơi khác.

Có nhiều kỹ thuật code refactoring: Red-Green-Refactor, refactoring by abtraction, composing method… Sử dụng kỹ thuật nào là tùy vào kỹ năng, team hay dự án của bạn.

Bài viết có tham khảo thông tin và sử dụng hình ảnh từ các nguồn:

1/ What Is Code Refactoring? Definition, Benefits and Best Practices

2/ What is Code Refactoring? How Refactoring Resolves Technical Debt

3/ Code Refactoring Best Practices: When (and When Not) to Do It

4/ What Is Code Refactoring, and When Should You Consider It?

Bạn có biết?

tham gia cộng đồng ITguru trên Linkedin, Facebook và các kênh mạng xã hội khác có thể giúp bạn nhanh chóng tìm được những chủ đề phát triển nghề nghiệp và cập nhật thông tin về việc làm IT mới nhất

Linkedin Page:
Facebook Group:
cơ hội việc làm IT : ITguru.vn