Thực hiện code refactoring như thế nào? Vấn đề này thậm chí là quá nhiều cho cả một cuốn sách. Những cách thức đơn giản nhất bạn có thể tham khảo tại http://refactoring.com của huyền thoại Martin Fowler. Tại đây bạn có thể tham khảo những kỹ thuật đơn giản nhất và dấu hiệu nhận biết một đoạn code có thể được refactor; từ chuyện đơn giản nhất như chuyển 2 đoạn code giống nhau thành một hàm đến sự liên kết giữa các đối tượng nhằm đảm bảo tính hướng đối tượng của chương trình. Trang web này thực sự hữu ích với những hệ thống thiết kế theo tư tưởng hướng đối tượng (phù hợp với đa số những mã nguồn hiện giờ), nhưng cũng rất tốt với những tư tưởng lập trình khác. Một chú ý hay là, đôi khi bạn thấy hướng dẫn refactor một đoạn code từ A sang B và nơi khác lại hướng dẫn refactor đoạn code từ B sang A. Điều này không mâu thuẫn, bởi “A hay B tốt hơn?” thì chỉ chính bạn mới có câu trả lời xác đáng trong ngữ cảnh của source code hiện tại. Tuy vậy, vẫn sẽ có những chuẩn chung để một đoạn code được coi là “tốt” hay “dở”; ví dụ, đặt tên biến là a là điều không chấp nhận được trong phát triển phần mềm (nơi duy nhât tôi thấy cách đặt tên biến này phát huy tác dụng là trong những cuộc thi lập trình với source code ngắn và thời gian ganh đua tính bằng mili giây). Và hãy nhớ rằng, code refactoring không làm thay đổi hành vi của chức năng hay hệ thống; do đó, kết quả của việc kiểm thử phải không đổi.
Bạn đang đọc: Code Refactor Là Gì ? Định Nghĩa Và Giải Thích Ý Nghĩa
Khi nào thực hiện code refactoring? Về lý thuyết, hãy thực hiện code refactoring bất cứ khi nào có thể. Trước khi commit, mỗi lập trình viên cần đọc lại những đoạn code mình đã viết và xem có thể cải tiến được không. Sau một thời gian, nhóm phát triển cần cùng nhau nhìn lại xem có thể cải tiến ở những điểm nào và cùng thực hiện code refactoring. Tuy nhiên, vấn đề không đơn giản như vậy.
Điều gì ngăn cản code refactoring? Đây là một câu hỏi rất thú vị. Tôi đã gặp rất nhiều nhóm thực hành Agile nhưng không bao giờ thực hiện code refactoring, với những lý do chính như sau:
Trình độ kém. Khi nhóm phát triển không có hiểu biết sâu sắc về OOP thì đương nhiên những đoạn code ban đầu viết ra sẽ rất “dở”, nhưng quan trọng là họ hoàn toàn không biết rằng nó “dở”. Việc này càng nguy hại nếu không thực hiện code refactoring bởi nhóm sẽ mãi duy trì năng lực hiện có.Chấp nhận.Trình độ kém. Khi nhóm tăng trưởng không có hiểu biết thâm thúy về OOP thì đương nhiên những đoạn code khởi đầu viết ra sẽ rất “ dở ”, nhưng quan trọng là họ trọn vẹn không biết rằng nó “ dở ”. Việc này càng nguy cơ tiềm ẩn nếu không thực thi code refactoring bởi nhóm sẽ mãi duy trì năng lượng hiện có. Chấp nhận .
Xem thêm: Site Đào Bitcoin Free For Bityard】, Làm Thế Nào Để Đào Bitcoin
Xem thêm: Downtown Là Gì? Uptown Là Gì? Phân Biệt Downtown Và Uptown Nguồn Gốc Và Ý Nghĩa Của Từ Downtown
Sau một thời gian dài, nhóm phát triển nhận ra có rất nhiều đoạn code “dở” nhưng nhóm vẫn chấp nhận bởi số lượng code “dở” là quá nhiều và có tư tưởng chấp nhận “sống chung với lũ”, hoặc nghĩ tới việc viết lại toàn bộ hệ thống.Không có thời gian. Đây là lý do khá xác đáng; bởi như tôi nói ở trên, khách hàng hoàn toàn không nhận được lợi ích trực tiếp từ code refactoring, nên khó thuyết phục họ trả tiền cho nhóm phát triển thực hiện code refactoring. Tuy vậy, việc lắp ổ điện thứ 11 mất 10 giờ, thay vì 2 giờ cho ổ điện thứ 1, thì cũng là tiền của khách hàng mà thôi (và điều này có thể nảy sinh nghi ngờ từ khách hàng rằng năng lực hoặc thái độ làm việc của nhóm đã kém đi).Sau một thời hạn dài, nhóm tăng trưởng nhận ra có rất nhiều đoạn code “ dở ” nhưng nhóm vẫn đồng ý bởi số lượng code “ dở ” là quá nhiều và có tư tưởng gật đầu “ sống chung với lũ ”, hoặc nghĩ tới việc viết lại hàng loạt mạng lưới hệ thống. Không có thời hạn. Đây là nguyên do khá xác đáng ; bởi như tôi nói ở trên, người mua trọn vẹn không nhận được quyền lợi trực tiếp từ code refactoring, nên khó thuyết phục họ trả tiền cho nhóm tăng trưởng thực thi code refactoring. Tuy vậy, việc lắp ổ điện thứ 11 mất 10 giờ, thay vì 2 giờ cho ổ điện thứ 1, thì cũng là tiền của người mua mà thôi ( và điều này hoàn toàn có thể phát sinh hoài nghi từ người mua rằng năng lượng hoặc thái độ thao tác của nhóm đã kém đi ) .Tuy vậy, những nguyên do này sẽ đẩy cả nhóm tăng trưởng vào một vòng luẩn quẩn không hồi kết : trình độ kém và sức ép thời hạn đưa ra những đoạn code “ dở ”, không triển khai code refactoring khiến trình độ không được cải tổ, sau một thời hạn đành đồng ý, khiến sức ép thời hạn càng lớn, không hề triển khai code refactoring, và trình độ không được cải tổ … Và dự án Bất Động Sản, từ đam mê bỗng thành gánh nặng với nhóm tăng trưởng, khiến động lực thao tác không còn đúng .
Vậy giải pháp là gì? Từ góc độ một lập trình viên, tôi cho rằng việc không thực hiện code refactoring là trách nhiệm của lập trình viên; do họ không đủ đam mê và trách nhiệm cần thiết với “đứa con tinh thần” của mình; không khác một nhà văn viết ra những tác phẩm rẻ tiền. Tuy vậy, người “lãnh đạo” trong dự án Agile cũng phải có trách nhiệm tạo ra những “khoảng lặng” về những chức năng cần bổ sung để nhóm phát triển thực hiện code refactoring. Việc này diễn ra càng đều đặn, trình độ và năng suất của lập trình viên càng cao bởi code refactoring chính là một cách nâng cao tay nghề và hiểu biết sâu sắc dựa trên những best practice cải tiến họ tốt hơn. 1 ngày dành cho code refactoring hôm nay có thể giảm bớt 10 ngày phát triển buồn tẻ sau này.
Xem thêm: flattering tiếng Anh là gì?
Giải pháp cho source code đã quá “cũ”? Khi chúng ta “động đâu cũng thấy vấn đề” trong source code, chấp nhận hoặc làm lại từ đầu thường là giải pháp; tuy vậy, cả 2 giải pháp này đều rất tốn kém. Code refactoring có thể là một giải pháp:
Sử dụng công cụ phân tích source code (tôi sẽ đề cập ở những bài viết sau) để tìm ra những đoạn code “dở”Nhóm phát triển cùng quét nhanh qua mã nguồn để đánh giá và tìm thêm những vấn đềƯớc lượng tổng thời gian cần cho code refactoringĐịnh nghĩa và lên kế hoạch việc kiểm thử. Việc này rất quan trọng vì code refactoring phải đảm bảo không thay đổi hành vi của chức năng và hệ thống. Lúc này automation test được ưu tiên bởi khối lượng kiểm thử nhiều. Không nên (thậm chí là nghiêm cấm) thực hiện code refactoring nếu không có kế hoạch kiểm thử tốt.Lên kế hoạch và thực hiện dần, từng phần. Thật tuyệt vời nếu chúng ta có toàn bộ thời gian để thực hiện; nếu không, hãy thực hiện từng phần song song với quá trình phát triển tiếp. Và hãy kiên nhẫn, chúng ta không thể thấy kết quả chỉ sau 1 vài ngày.Sử dụng công cụ nghiên cứu và phân tích source code ( tôi sẽ đề cập ở những bài viết sau ) để tìm ra những đoạn code “ dở ” Nhóm tăng trưởng cùng quét nhanh qua mã nguồn để nhìn nhận và tìm thêm những vấn đềƯớc lượng tổng thời hạn cần cho code refactoringĐịnh nghĩa và lên kế hoạch việc kiểm thử. Việc này rất quan trọng vì code refactoring phải bảo vệ không biến hóa hành vi của công dụng và mạng lưới hệ thống. Lúc này automation test được ưu tiên bởi khối lượng kiểm thử nhiều. Không nên ( thậm chí còn là nghiêm cấm ) thực thi code refactoring nếu không có kế hoạch kiểm thử tốt. Lên kế hoạch và thực thi dần, từng phần. Thật tuyệt vời nếu tất cả chúng ta có hàng loạt thời hạn để triển khai ; nếu không, hãy triển khai từng phần song song với quy trình tăng trưởng tiếp. Và hãy kiên trì, tất cả chúng ta không hề thấy tác dụng chỉ sau 1 vài ngày .Thât ra, code refactoring là việc làm rất đơn thuần, đến mức người ta thuận tiện bỏ lỡ code refactoring để nghĩ tới architect refactoring hay structure refactoring. Nhưng theo tôi, khi triển khai code refactoring tốt, những design pattern sẽ dần được hình thành và từ đó kiến trúc mới cũng sẽ được hình thành. Rất ít khi tất cả chúng ta cần tới architect refactoring ; và tôi cũng không tham vọng ra mắt những điều này sớm .
Source: https://mindovermetal.org
Category: Wiki là gì
