Lợi nhuận:
- Khả năng thiết lập mạng lưới an toàn thử nghiệm để nắm bắt hành vi hiện tại trước khi tái cấu trúc
- Khả năng yêu cầu AI thực hiện các chuyển đổi nhỏ, một bước, duy trì hành vi và xác thực từng bước
- Khả năng xác định và ưu tiên nợ kỹ thuật trong bối cảnh kinh doanh
Tái cấu trúc đang cải thiện cấu trúc bên trong của mã mà không thay đổi hành vi bên ngoài của nó: làm cho nó dễ đọc hơn, đơn giản hơn, dễ bảo trì hơn. Mặt khác, nợ kỹ thuật là một thỏa hiệp về thiết kế được thực hiện nhằm mục đích giải quyết nhanh chóng và được hoàn trả "kèm lãi suất" theo thời gian - mọi góc bạn cắt hôm nay sẽ quay trở lại dưới dạng chậm lại hoặc lỗi vào ngày mai. Trí tuệ nhân tạo là một trợ thủ đắc lực giúp tăng tốc các nhiệm vụ tái cấu trúc máy móc và lặp đi lặp lại; Nhưng có một quy tắc vàng về tái cấu trúc và chỉ riêng AI không thể đảm bảo điều đó: hành vi không được thay đổi.
Trong phần này, chúng ta tìm hiểu cách tái cấu trúc an toàn bằng AI: các bước nhỏ và có thể đảo ngược, bảo vệ bằng các thử nghiệm, phát hiện mùi mã và ưu tiên nợ kỹ thuật. Điểm quan trọng là ở đây: chính các bài kiểm tra đã vượt qua chứ không phải lời nói của AI mới chứng minh rằng hành vi đó được duy trì.
Nguyên tắc vàng của tái cấu trúc: Hành vi không đổi
Điều khiến việc tái cấu trúc trở nên nguy hiểm là việc vô tình thay đổi hành vi trong khi nói "Tôi đang tiến bộ". Bỏ trường hợp đặc biệt khi đơn giản hóa một điều kiện, phá vỡ trật tự khi chuyển đổi vòng lặp, thiếu tác dụng phụ khi tách một hàm—tất cả đều tạo ra mã "trông rõ ràng" nhưng bị hỏng.
Đó là lý do tại sao thử nghiệm là điều kiện tiên quyết để tái cấu trúc: trước khi thay đổi, bạn phải có các thử nghiệm nắm bắt hành vi hiện có. Những thử nghiệm này là một “mạng lưới an toàn”; Nếu bạn vô tình làm hỏng thứ gì đó trong quá trình tái cấu trúc, chúng sẽ phá vỡ và cảnh báo bạn. Nếu bạn không có bài kiểm tra, trước tiên hãy viết bài kiểm tra để khắc phục hành vi hiện có (như chúng ta đã học ở bài 5) — đây là lúc AI bắt đầu.
Thận trọng: Tái cấu trúc được hỗ trợ bởi AI mà không có testnet là một trong những nguồn lỗi nguy hiểm nhất. Thật dễ dàng để nói "Tôi đã giữ nguyên hành vi"; Bằng chứng là các bài kiểm tra giống nhau đều vượt qua trước và sau khi thay đổi.
Từng bước: Quy trình tái cấu trúc an toàn
- Thiết lập mạng lưới an toàn. Hãy để có những bài kiểm tra nắm bắt hành vi hiện tại của mã mà bạn sẽ cấu trúc lại; Nếu không, hãy viết chúng ra trước (và xem chúng hoàn thành).
- Đặt tên cho mùi. Bạn đang cải thiện điều gì và tại sao? "Hàm này thực hiện 3 việc", "logic tương tự lặp lại ở 4 vị trí", "tên gây hiểu lầm".
- Yêu cầu các bước nhỏ, một bước. Yêu cầu AI thực hiện một phép chuyển đổi duy nhất (ví dụ: chỉ “chia hàm này làm đôi”) chứ không viết lại toàn bộ tệp.
- Chạy thử nghiệm. Sau mỗi bước. Nếu xanh thì tiếp tục, nếu đỏ thì rút về.
- Đọc Khác biệt. Xác nhận từng dòng một rằng thay đổi thực sự là bảo toàn hành vi; Có thể có sự trượt logic khi nói AI "chỉ là cấu trúc".
- Kết hợp thành từng phần nhỏ. PR tái cấu trúc một lần lớn vừa có rủi ro vừa không thể xem xét được.
Ba hộp nhỏ
Trường hợp 1 - Chức năng 220 dòng được phân chia an toàn. Một nhóm có chức năng xử lý đơn hàng gồm 220 dòng. 14 bài kiểm tra đầu tiên được viết (với sự trợ giúp của AI) nhằm nắm bắt hành vi hiện tại, tất cả đều vượt qua. Sau đó, chức năng này được AI chia thành 5 chức năng nhỏ hơn từng bước; Các thử nghiệm đã được chạy sau mỗi bước. Hai bài kiểm tra đã bị phá vỡ trong một bước - AI đã bỏ lỡ kết quả trả về trong một trường hợp khó khăn. Các cuộc kiểm tra đã phát hiện ra điều này ngay lập tức và sửa nó. Nếu không có mạng, lỗi có thể lan sang cả quá trình sản xuất.
Trường hợp 2 - Thảm họa không có testnet. Một nhà phát triển khác đã "dọn dẹp" mô-đun tính toán ngày tháng chưa có thử nghiệm với AI. Mã trông đẹp hơn, nhưng nó tính toán năm nhuận không chính xác; Lỗi xuất hiện hai tuần sau đó do khách hàng phàn nàn. Sự mất mát vượt xa thời gian tiết kiệm được từ việc tái cấu trúc. Bài học: tái cấu trúc mà không kiểm thử là một canh bạc.
Trường hợp 3 - Ưu tiên nợ kỹ thuật. Một nhóm đã cung cấp cho AI một lượng tồn đọng khoảng 30 điểm “có thể cải thiện” và yêu cầu mỗi người ghi điểm trên trục “tần suất thay đổi × rủi ro × nỗ lực”. Trong bảng kết quả, một mô-đun xấu, hiếm khi được chạm vào thực sự có mức độ ưu tiên thấp, trong khi mô-đun có độ phức tạp trung bình thay đổi thường xuyên lại có mức độ ưu tiên cao. Nhóm đã hướng năng lượng của mình đến đúng nơi.
Bốn mẫu có thể sao chép
Phát hiện mùi mã và ưu tiên:
Danh sách ứng cử viên tái cấu trúc "có mùi" trong mã này: hàm dài, lặp lại (DRYViolation), tên gây hiểu lầm, điều kiện lồng nhau sâu, tác dụng phụ ẩn, số ma thuật. Đối với từng: vị trí, lý do xảy ra sự cố, bước nhỏ được đề xuất, rủi ro ước tính (thấp/trung bình/cao). ĐỪNG THAY ĐỔI mã, chỉ cần lập kế hoạch.{{code}}
Chuyển đổi một bước, duy trì hành vi:
CHỈ làm điều này: {{chuyển đổi đơn lẻ, ví dụ: Chia hàm này thành 3 hàm được đặt tên nhỏ hơn}}. THAY ĐỔI hành vi hiển thị, chữ ký và giá trị trả về. Viết bằng 1 câu lý do tại sao mọi thứ bạn thay đổi vẫn giữ nguyên hành vi.{{code}}
Mạng lưới an toàn trước khi tái cấu trúc (kiểm tra đặc tính):
Viết các bài kiểm tra nắm bắt hành vi HIỆN TẠI của chức năng này (đúng hay không); mục tiêu là nắm bắt xem hành vi có thay đổi trong quá trình tái cấu trúc hay không. Bao gồm các mục + cạnh điển hình. Viết kỳ vọng dựa trên kết quả đầu ra hiện tại của hàm.{{function}}
Tạo hồ sơ nợ kỹ thuật (tồn đọng):
Đổ danh sách mùi sau đây vào bảng ưu tiên: chất, khu vực bị ảnh hưởng, tần suất thay đổi (hiểu biết của tôi: {{...}}), rủi ro, nỗ lực ước tính, mức độ ưu tiên được đề xuất. Đặt tác động cao + nỗ lực thấp lên hàng đầu. {{danh sách mùi}}
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: "Hãy dọn sạch mã này và làm cho nó tốt hơn."
Strong: "Chia hàm 90 dòng này thành 3 hàm nhỏ hơn với một trách nhiệm duy nhất mà không thay đổi hành vi và chữ ký bên ngoài của nó. Giữ các tác dụng phụ (viết DB) theo thứ tự hiện tại. Tôi có các bài kiểm tra, hành vi phải giữ nguyên. Hãy đưa ra điểm khác biệt và giải thích bằng một câu tại sao mỗi phần tách là bảo toàn hành vi. [code]"
Phiên bản mạnh mẽ; Nó yêu cầu một chuyển đổi cụ thể duy nhất, áp đặt rõ ràng ràng buộc về hành vi và chữ ký, đồng thời yêu cầu sự biện minh. Những yêu cầu mơ hồ như “làm tốt hơn” sẽ dẫn đến những thay đổi không kiểm soát được và đầy rủi ro.
Kiểu tái cấu trúc
Độ tin cậy của AI
Điều kiện tiên quyết
đổi tên
cao
Phạm vi có đúng không?
Phân chia chức năng
trung bình cao
Testnet là phải
Chia sẻ lặp lại
trung bình
Sự khác biệt về hành vi có thể được ẩn giấu
Thay đổi thuật toán/cấu trúc
thấp
Thử nghiệm mở rộng + xác nhận của con người
sắp xếp lại kiến trúc
thấp
Do con người lãnh đạo, được hỗ trợ bởi AI
Quản lý nợ kỹ thuật, không phải xử lý lại
Nợ kỹ thuật không hoàn toàn xấu; Đôi khi việc vay mượn có ý thức (để đáp ứng việc giao hàng) là quyết định đúng đắn. Mục tiêu không phải là loại bỏ nợ mà là làm cho nó trở nên rõ ràng và có thể quản lý được. AI rất nhanh trong việc phát hiện và ưu tiên nợ, nhưng việc quyết định “nợ nào nên trả và khoản nào nên bỏ” đòi hỏi bối cảnh kinh doanh: mô-đun này thay đổi thường xuyên như thế nào, nó ảnh hưởng đến bao nhiêu người, rủi ro là gì? Quyết định này được đưa ra bởi nhóm biết cơ sở mã và sản phẩm; AI chỉ làm rõ các lựa chọn.
Mẹo: Giữ PR tái cấu trúc của bạn tách biệt với PR liên quan đến thay đổi hành vi. Có thể nói "PR này chỉ là tái cấu trúc, hành vi vẫn như cũ" giúp việc điều tra dễ dàng hơn và cho phép bạn nhanh chóng thu hẹp nguyên nhân nếu có vấn đề phát sinh.
Những lỗi thường gặp
- Tái cấu trúc mà không cần testnet. Bạn không còn gì để chứng minh rằng hành vi đó được bảo tồn.
- Nó có nghĩa là "xóa toàn bộ tập tin". Những thay đổi lớn, không kiểm soát được sẽ che giấu lỗi và không thể kiểm tra được.
- Chấp nhận Diff mà không cần đọc nó. AI có thể đã thiếu logic khi nói "chỉ là cấu trúc".
- Tái cấu trúc khó hiểu với thay đổi hành vi. Thực hiện cả hai trong cùng một PR khiến việc theo dõi nguyên nhân gốc rễ là không thể.
- Đang cố gắng khắc phục mọi mùi. Mã xấu mà hiếm khi thay đổi thường có mức độ ưu tiên thấp; Phân bổ năng lượng đến nơi thường xuyên thay đổi.
Tóm lại
Quy tắc tái cấu trúc duy nhất là hành vi không đổi và bằng chứng cho điều này là các thử nghiệm. AI có khả năng phát hiện mùi mã rất mạnh, chuyển đổi một bước và ưu tiên nợ kỹ thuật; nhưng bạn phải thiết lập mạng lưới an toàn, chạy thử nghiệm và đọc điểm khác biệt sau mỗi bước. Thực hiện các bước nhỏ, có thể đảo ngược; phân biệt tái cấu trúc với thay đổi hành vi; và để nhóm biết bối cảnh kinh doanh quyết định khoản nợ nào sẽ phải trả.
Nhiệm vụ ứng dụng
Chọn một hàm từ cơ sở mã mà bạn thấy dài hoặc phức tạp. Đầu tiên hãy in các bài kiểm tra nắm bắt hành vi hiện tại của nó bằng mẫu "mạng an toàn" và xem liệu tất cả chúng có vượt qua hay không. Sau đó, hãy tái cấu trúc hàm theo một cách duy nhất (ví dụ: chia làm đôi) với mẫu "chuyển đổi duy trì hành vi một bước" và chạy lại thử nghiệm. Nếu bài kiểm tra bị hỏng, hãy tìm hiểu lý do; Nếu nó hoàn toàn không bị hỏng, hãy đọc từng dòng khác nhau để xác nhận rằng hành vi đó thực sự được bảo tồn.
danh sách kiểm tra
- [ ] Tôi biết rằng việc tái cấu trúc sẽ không thay đổi hành vi và đã có những thử nghiệm để chứng minh điều đó.
- [ ] Tôi đang thiết lập một mạng lưới an toàn để nắm bắt hành vi hiện tại trước khi tái cấu trúc.
- [ ] Tôi muốn những chuyển đổi nhỏ, một bước từ AI, chứ không phải những chuyển đổi lớn chỉ diễn ra một lần.
- [ ] Sau mỗi bước, tôi chạy thử nghiệm và đọc phần khác biệt.
- [ ] Tôi tiếp tục tái cấu trúc PR tách biệt với PR thay đổi hành vi.
- [ ] Tôi ưu tiên nợ kỹ thuật với bối cảnh kinh doanh, không cố gắng loại bỏ một cách mù quáng.