Các dự án đào tạo về tái cấu trúc mã nguồn: cách cấu trúc công việc xử lý mã nguồn cũ nhằm dạy cách giảm thiểu nợ kỹ thuật.

Một nhóm được thừa hưởng một mô-đun tính phí mà không ai thực sự hiểu rõ. Nó không có các bài kiểm thử nào để bảo vệ hoạt động hiện tại. Một sprint được đề xuất để "dọn dẹp" nó, và kế hoạch là viết lại phần lõi theo một cấu trúc mới. Không ai có thể nói làm thế nào họ biết được phiên bản mới vẫn tính phí khách hàng một cách chính xác.

Đây là một tình huống minh họa, không phải là một sự cố đã được ghi nhận. Nó mô tả khoảng trống mà một dự án đào tạo về tái cấu trúc mã cần phải lấp đầy: các kỹ sư có thể thấy rằng mã nguồn lộn xộn, nhưng chưa thể lập kế hoạch cải tiến có giới hạn và chứng minh rằng hành vi của mã vẫn được giữ nguyên.

Hướng dẫn này dành cho các trưởng nhóm hỗ trợ kỹ thuật và các quản lý kỹ thuật. Nó bao gồm cách mô tả vấn đề hiệu năng, chẩn đoán các thiếu sót, chuẩn bị thiết kế và thực hành, giải quyết một trường hợp cụ thể và đánh giá xem kỹ năng có thể áp dụng vào công việc thực tế hay không. Nó cũng đề cập đến thiết kế đào tạo. Mã nguồn, các bài kiểm tra và quy tắc trong chương trình của bạn cần được các kỹ sư cấp cao trong chính hệ thống của bạn xác nhận.

Dự án đào tạo tái cấu trúc mã là gì?

Dự án đào tạo tái cấu trúc mã nguồn là một bài tập có cấu trúc trên mã nguồn cũ, với mục đích xây dựng năng lực cũng như cải thiện chất lượng mã. Người học lập kế hoạch cho một thay đổi nhỏ, có giới hạn, bảo vệ hành vi hiện có bằng các bài kiểm tra, cải thiện thiết kế từng bước nhỏ và chứng minh rằng không có gì bị lỗi. Mã nguồn trở nên tốt hơn, và quan trọng hơn, các kỹ sư thực hành khả năng phán đoán mà họ sẽ cần đối với các vấn đề nợ kỹ thuật thực tế.

sự kiện nhanh chóng

1. Mô tả vấn đề về hiệu năng

Hãy bắt đầu với nhiệm vụ: lập kế hoạch và xác nhận việc cải tiến mã nguồn cũ có phạm vi giới hạn. Từ "giới hạn" là từ quan trọng. Người học chọn một thay đổi đủ nhỏ để hoàn thành và có thể xác định rõ ràng những gì nằm trong và ngoài phạm vi.

Việc sử dụng thuật ngữ chính xác rất hữu ích. Martin Fowler mô tả quá trình tái cấu trúc như sau: một kỹ thuật được kiểm soát để cải thiện thiết kế của một cơ sở mã hiện có., bao gồm các biến đổi nhỏ, bảo toàn hành vi. Cụm từ “bảo toàn hành vi” là điều phân biệt việc tái cấu trúc với việc viết lại, và đó là điều mà quá trình đào tạo phải làm rõ. Chính phép ẩn dụ về nợ kỹ thuật mới là vấn đề. Thuật ngữ này do Ward Cunningham đặt ra.Và cuộc thảo luận của Fowler là một lời nhắc nhở hữu ích rằng nợ có thể được vay một cách có chủ đích và thận trọng, vì vậy không phải mọi học phần lộn xộn đều là một sai lầm cần phải sửa chữa.

Cuốn sách của Michael Feathers về mã nguồn cũ cũng có cùng quan điểm về thực tiễn. Mô tả của nhà xuất bản cho biết cuốn sách này dạy các nhà phát triển cách viết các bài kiểm thử để đảm bảo... Họ không vô tình thay đổi ứng dụng.và để kiểm soát phần mềm hiện có mà không cần viết lại hoàn toàn.

Hãy viết bản mô tả hiệu suất thành một câu duy nhất và nhờ quản lý kỹ thuật kiểm tra: “Với một mô-đun cũ và một mục tiêu đã định, kỹ sư đề xuất một thay đổi có giới hạn, thêm các bài kiểm tra để xác định chính xác hành vi hiện tại, thực hiện thay đổi từng bước nhỏ và chứng minh rằng hành vi đó được bảo toàn.”

2. Chẩn đoán những thiếu sót về kiến ​​thức và bối cảnh.

Trước khi bắt tay vào xây dựng bất cứ điều gì, hãy so sánh nhiệm vụ cần thực hiện với những hoạt động hiện tại của bạn và đánh giá chúng. Thông thường, ba câu hỏi sau sẽ giúp phân biệt khoảng trống trong đào tạo với những vấn đề khác:

1. Liệu phương pháp hiện tại có sử dụng đúng nhiệm vụ thực tế? Nếu khóa đào tạo chỉ trình bày các mẫu tái cấu trúc mã trong các slide, nhưng không ai thực sự thay đổi mã chưa được kiểm thử, thì không ai thực hành hành vi bảo vệ mã. Nếu bài kiểm tra đánh giá là bài trắc nghiệm về các "mùi" mã, thì nó chỉ đo lường khả năng ghi nhớ.
2. Yêu cầu về khả năng nhận thức là gì? Trong thang phân loại Bloom sửa đổi, việc đánh giá xem một thay đổi có an toàn hay không nằm ở cấp độ phân tích và đánh giá, còn việc thiết kế kế hoạch và các bài kiểm tra thuộc cấp độ sáng tạo. Việc ghép các hoạt động với các cấp độ này được đề cập trong hướng dẫn của chúng tôi. Phù hợp các hoạt động học tập với Phân loại Bloom..
3. Liệu có điều gì khác ngoài kỹ năng đang cản trở bạn? Kiểm tra nhân sự, công cụ và quy trình. Nếu việc xây dựng mất một giờ, sẽ không ai thường xuyên chạy thử nghiệm. Nếu công việc bảo trì không bao giờ được lên lịch, các kỹ sư sẽ chỉ chỉnh sửa lại mã nguồn một cách bí mật. Báo cáo các nguyên nhân không liên quan đến đào tạo cho những người có thể khắc phục chúng.

3. Thiết kế quá trình chuẩn bị và luyện tập có mục đích.

Khi bạn đã xác định được những thiếu sót nào mà đào tạo có thể khắc phục, hãy giao nhiệm vụ riêng biệt cho từng giai đoạn.

Sự chuẩn bị. Kiểm tra các điều kiện tiên quyết bằng một bài kiểm tra chẩn đoán ngắn: khung kiểm thử của bạn hoạt động như thế nào, kiểm thử đặc trưng là gì và nhóm của bạn xem xét và hợp nhất các bài kiểm thử ra sao. Tự học theo tốc độ riêng phù hợp với giai đoạn này. Bài kiểm tra ôn tập chỉ xác nhận các điều kiện tiên quyết.

Thực hành. Hãy sử dụng các dự án tái cấu trúc có hệ thống với hình dạng rõ ràng. Bắt đầu với một mẫu nhỏ, an toàn, sau đó chuyển sang một phần thực tế nhưng có giới hạn trong cơ sở mã của riêng bạn. Bài tập Gilded Rose là một điểm khởi đầu nổi tiếng cho bước đầu tiên. Tệp README của nó, được duy trì bởi Emily Bache, Khuyến nghị nên viết các bài kiểm thử trước khi thay đổi mã. và định hình bài tập như một quá trình thực hành việc thực hiện các bước nhỏ, chạy thử nghiệm thường xuyên và cải thiện thiết kế từng chút một. Một trình tự hợp lý cho mỗi dự án là: xác định mục tiêu và phạm vi, viết các bài kiểm tra ghi lại những gì mã hiện tại đang làm, thay đổi từng thứ một, chạy thử nghiệm sau mỗi bước và ghi lại những gì bạn đã học được.

Phản hồi. Hãy liên kết phản hồi với các quyết định, chứ không phải với tổng điểm. Câu "Bạn đã trích xuất được logic giảm giá, nhưng các bài kiểm tra của bạn chỉ bao gồm trường hợp thành công, vì vậy bạn không thể nhận thấy sự thay đổi làm tròn" sẽ hữu ích hơn là "3 trên 5".

Giảng viên trực tiếp hướng dẫn hay ôn tập không đồng bộ? Phản hồi trực tiếp mang lại giá trị cao nhất khi lựa chọn không rõ ràng, ví dụ như nên dừng lại và bổ sung bài kiểm tra còn thiếu hay tiếp tục. Đánh giá không đồng bộ là đủ khi người học so sánh kế hoạch và bài kiểm tra của họ với phiên bản được chuyên gia chú thích. Nhiều nhóm sử dụng cả hai: chuẩn bị theo tốc độ cá nhân trước, sau đó là buổi hướng dẫn về các trường hợp khó.

4. Hãy cùng nhau tìm hiểu một ví dụ thực tế.

Ví dụ minh họa. Người quản lý kỹ thuật nên xác nhận trường hợp và tiêu chí trả lời trước khi sử dụng.

Trường hợp. Một hàm cũ tính toán tổng giá trị đơn hàng, bao gồm chiết khấu, thuế và phí vận chuyển. Hàm này chưa được kiểm thử. Một nhóm đề xuất tái cấu trúc toàn bộ mô-đun thanh toán để làm cho nó "sạch sẽ" hơn.

Nhiệm vụ. Người học giải thích những việc họ sẽ làm, nêu ra bằng chứng họ sẽ thu thập và cho biết họ cần thêm thông tin hoặc hỗ trợ gì.

Lần thử đầu tiên. “Tôi sẽ chia mô-đun thành ba dịch vụ và chuyển logic sang đó, sau đó kiểm tra lại số liệu ở môi trường thử nghiệm.” Người học đã chọn một thay đổi lớn và một bước kiểm tra thủ công muộn. Không có cách nào để biết liệu phiên bản cũ và phiên bản mới có khớp nhau ở các trường hợp ngoại lệ hay không.

Phản hồi và thử lại. Người đánh giá hỏi chức năng này hoạt động như thế nào trong trường hợp giỏ hàng trống, giảm giá khiến tổng số tiền âm và trường hợp làm tròn. Bài tập lại yêu cầu người học thu hẹp phạm vi xuống một hành vi cụ thể và giải thích cách họ chứng minh rằng hành vi đó không thay đổi.

Một nỗ lực mạnh mẽ hơn. “Tôi sẽ giữ nguyên cấu trúc module hiện tại. Tôi sẽ ghi lại giá trị mà hàm tính tổng đơn hàng trả về hiện tại cho một tập hợp các đầu vào, bao gồm cả các trường hợp ngoại lệ, để làm bài kiểm tra. Sau đó, tôi sẽ tách phần tính toán chiết khấu thành một hàm riêng, chạy các bài kiểm tra sau bước đó và dừng lại. Tôi sẽ lưu ý rằng quy tắc vận chuyển có những hành vi mà tôi không hiểu và sẽ hỏi ý kiến ​​đồng nghiệp trước khi động đến nó.” Hãy lưu ý rằng câu trả lời này giới hạn phạm vi thay đổi, ưu tiên bảo vệ hành vi trước và nêu rõ những gì chưa biết.

Tại sao mỗi câu trả lời lại có thể chấp nhận được hoặc chưa đầy đủ. Hãy đánh giá từng phương án dựa trên các tiêu chí đã được phê duyệt, chứ không phải dựa trên sở thích cá nhân của người đánh giá. Phương án đầu tiên có thể là một hướng đi dài hạn hợp lý nhưng chưa hoàn thiện, vì nó không có bằng chứng về việc duy trì hành vi đã đề ra. Phương án tốt hơn là phương án nhỏ, có thể kiểm chứng và trung thực về sự không chắc chắn.

5. Đánh giá năng lực và lập kế hoạch chuyển giao

Bằng chứng về năng lực là khả năng thực hiện trên một trường hợp mã nguồn cũ mới mà người học chưa từng gặp. Chấm điểm phân tích rủi ro và bằng chứng cho thấy hành vi đã được duy trì. Một bảng tiêu chí đơn giản sử dụng thang điểm từ 0 đến 2 cho mỗi tiêu chí:

Thang điểm: 0 là không có hoặc không được hỗ trợ, 1 là một phần với những thiếu sót liên quan, và 2 là đầy đủ và được chứng minh dựa trên các tiêu chí đã thống nhất. Xác định riêng các lỗi nghiêm trọng, chẳng hạn như thay đổi hành vi mà không có thử nghiệm nào có thể phát hiện ra, để điểm tổng thể không che giấu được lỗi nào. Bảng đánh giá này chỉ là một đề xuất, không phải là tiêu chuẩn sẵn sàng đã được xác nhận: hãy điều chỉnh nó với người quản lý kỹ thuật và thử nghiệm thí điểm. Hướng dẫn của chúng tôi về Thiết kế bài tập tương tác với phản hồi hữu ích Hướng dẫn cách viết phản hồi liên quan đến các quyết định.

Lên kế hoạch chuyển giao một cách cẩn trọng. Sau bài tập, hãy giao cho mỗi kỹ sư một vấn đề nhỏ, thực tế để giải quyết với người đánh giá, hoặc tiến hành một buổi đánh giá ngắn về một thay đổi gần đây đã gây ra lỗi. Kiểm tra việc chuyển giao sau khi đã được tiếp xúc với công việc thực tế một cách thích hợp, chứ không phải ngay sau buổi hội thảo.

Trong trường hợp phương thức giao hàng tương tác giúp ích

Các định dạng tương tác rất hữu ích khi mọi người cần cam kết trước khi xem toàn bộ nhóm. Trong một phiên trực tiếp, người điều phối có thể hiển thị một đoạn mã cũ ngắn, yêu cầu mỗi kỹ sư đưa ra thay đổi đầu tiên mà họ sẽ thực hiện và cách họ sẽ chứng minh tính an toàn của nó, sau đó tiết lộ các thay đổi trước khi thảo luận. Cùng một câu hỏi này cũng có thể được thực hiện theo hình thức tự học để chuẩn bị. AhaSlides hỗ trợ học tập tương tác và chuyển đổi giữa hình thức trực tiếp và tự học. Đây là một công cụ trình bày và học tập, không phải là nơi để chạy hoặc phân tích mã, vì vậy hãy thực hiện việc tái cấu trúc trong môi trường của riêng bạn. Kiểm tra bất kỳ chức năng soạn thảo, phản hồi hoặc báo cáo cụ thể nào mà bạn dự định sử dụng so với quy trình làm việc của riêng bạn. Để được hướng dẫn về việc lựa chọn định dạng, hãy xem bài viết của chúng tôi về... Khi nào nên sử dụng phương pháp học tập thích ứng, tương tác và trực tiếp?.

Đo lường những gì đã thay đổi

Xác định trước những tiêu chí nào sẽ chứng minh các kỹ sư có thể hoàn thành nhiệm vụ. So sánh chất lượng phân tích rủi ro và bằng chứng về hành vi được duy trì trong một trường hợp chưa từng thấy, so với một tiêu chuẩn cơ bản. Xác định đối tượng tham gia, mẫu số và thời gian. Nếu kết quả được cải thiện, hãy kiểm tra những thay đổi khác trong cùng kỳ, chẳng hạn như công cụ kiểm thử mới, tốc độ biên dịch nhanh hơn hoặc thay đổi quyền sở hữu, trước khi ghi nhận hiệu quả của khóa đào tạo.

Những ràng buộc có thể vẫn còn

• Đến lúc bảo trì rồi. Nếu công việc xử lý nợ không bao giờ được lên kế hoạch, các kỹ sư được đào tạo vẫn không có nơi nào để sử dụng kỹ năng của họ.
• Công cụ thử nghiệm. Nếu không có bộ dụng cụ kiểm tra hữu dụng hoặc quy trình lắp ráp nhanh, việc thực hiện từng bước nhỏ và kiểm tra thường xuyên sẽ rất khó duy trì.
• Phạm vi bao phủ vụ việc. Một trường hợp điển hình cho thấy một vài loại rủi ro. Điểm số không phản ánh chính xác khả năng đánh giá của kỹ sư nói chung.
• Đánh giá khi nào không nên tái cấu trúc mã. Một số đoạn mã tốt hơn hết nên được giữ nguyên, thay thế hoặc loại bỏ, và quyết định đó không chỉ phụ thuộc vào kỹ năng.
• Chuyển khoản. Hiệu suất trong một bài tập lập trình (kata) không giống với hiệu suất trong một module sản xuất dưới áp lực giao hàng.

Hãy nêu rõ những vấn đề này với nhà tài trợ từ sớm và lên kế hoạch khắc phục riêng biệt. Đào tạo giúp cải thiện khả năng lập kế hoạch và chứng minh của kỹ sư. Nó không tạo ra thời gian hay công cụ cần thiết.

Các câu hỏi thường gặp

Dự án đào tạo tái cấu trúc mã là gì?

Đó là phương pháp thực hành có cấu trúc trên mã nguồn cũ, trong đó các kỹ sư lên kế hoạch cho một thay đổi nhỏ, bảo vệ hành vi hiện có bằng các bài kiểm tra, thay đổi thiết kế từng bước nhỏ và chứng minh rằng không có gì bị hỏng.

Liệu việc viết lại toàn bộ mã có phải là cách tốt để tìm hiểu về nợ kỹ thuật?

Thông thường là không. Việc viết lại toàn bộ mã nguồn rất lớn, khó kiểm tra và che khuất kỹ năng bạn muốn xây dựng. Một thay đổi có giới hạn kèm theo các bài kiểm tra nắm bắt hành vi hiện tại sẽ giúp làm rõ lý do.

Làm thế nào để đánh giá xem các kỹ sư có thể thực hiện việc tái cấu trúc mã một cách an toàn hay không?

Hãy đưa ra một trường hợp mã nguồn cũ mới và chấm điểm phân tích rủi ro cũng như bằng chứng cho thấy hành vi đó được duy trì theo các tiêu chí đã thống nhất. Bài kiểm tra về các mẫu tái cấu trúc chỉ nhằm xác nhận các điều kiện tiên quyết.

Bạn có cần mã nguồn mẫu để phục vụ cho việc đào tạo không?

Bạn cần một nơi an toàn để thực hành. Nhiều nhóm bắt đầu với một bài tập lập trình công khai (public kata) rồi chuyển sang một phần mã nguồn được giới hạn của riêng họ. Quản lý kỹ thuật của bạn nên xác nhận xem mã nguồn đó có phù hợp hay không.

Bắt đầu từ đâu

Hãy chọn một thay đổi nhỏ, lặp đi lặp lại trong mã nguồn của bạn. Viết báo cáo hiệu năng, nhờ quản lý kỹ thuật xác nhận trường hợp này và các bài kiểm tra chứng minh hành vi được duy trì, đồng thời soạn thảo một bảng đánh giá ba tiêu chí với thang điểm từ 0 đến 2 và danh sách các lỗi nghiêm trọng. Thử nghiệm với một nhóm nhỏ trước khi triển khai rộng rãi.

Để xem cách thức thực hiện bài tập ra quyết định tái cấu trúc mã nguồn trực tiếp với nhóm của bạn và có thể tái sử dụng theo tốc độ riêng sau đó, hãy khám phá AhaSlides.