Các điểm chính của làm việc hiệu quả với mã di sản là gì? [đóng cửa]

Tôi đã thấy cuốn sách Làm việc hiệu quả với Mã di sản được đề xuất một vài lần. Những điểm chính của cuốn sách này là gì?

Có nhiều thứ để xử lý mã kế thừa hơn là thêm các bài kiểm tra đơn vị / tích hợp và sau đó tái cấu trúc không?

Vấn đề chính với mã kế thừa là nó không có bài kiểm tra. Vì vậy, bạn cần thêm một số (và sau đó nhiều hơn nữa ...).

Điều này tự nó sẽ mất rất nhiều công việc, như @mattnz lưu ý. Nhưng vấn đề đặc biệt của mã kế thừa là nó không bao giờ được thiết kế để có thể kiểm tra được . Vì vậy, thông thường, nó là một mớ hỗn độn mã spaghetti rất lớn, trong đó rất khó hoặc hết sức không thể cô lập các phần nhỏ để được kiểm tra đơn vị. Vì vậy, trước khi kiểm thử đơn vị, bạn cần cấu trúc lại mã để làm cho nó dễ kiểm tra hơn.

Tuy nhiên, để cấu trúc lại một cách an toàn, bạn phải có các bài kiểm tra đơn vị để xác minh rằng bạn chưa phá vỡ bất cứ điều gì với các thay đổi của mình ... Đây là cách bắt 22 mã kế thừa.

Cuốn sách hướng dẫn bạn cách thoát ra khỏi sự nắm bắt này bằng cách thực hiện các thay đổi tối thiểu, an toàn nhất đối với mã chỉ để kích hoạt các thử nghiệm đơn vị đầu tiên. Chúng không có nghĩa là làm cho thiết kế đẹp hơn - chỉ để cho phép thử nghiệm đơn vị. Trong thực tế, đôi khi chúng làm cho thiết kế xấu hơn hoặc phức tạp hơn. Tuy nhiên, chúng cho phép bạn viết bài kiểm tra - và một khi bạn có bài kiểm tra đơn vị, bạn có thể tự do làm cho thiết kế tốt hơn.

Có rất nhiều thủ thuật để làm cho mã có thể kiểm tra được - một số là rõ ràng, một số thì không. Có những phương pháp tôi sẽ không bao giờ nghĩ về bản thân mình, nếu không đọc cuốn sách. Nhưng điều thậm chí còn quan trọng hơn là Feathers giải thích chính xác điều gì làm cho một đơn vị mã có thể kiểm tra được. Bạn cần cắt giảm sự phụ thuộc và đưa ra các rào cản vào mã của mình, nhưng vì hai lý do riêng biệt:

• cảm biến - để kiểm tra và xác minh các tác động của việc thực thi một đoạn mã và
• phân tách - trước hết để có được đoạn mã cụ thể vào khai thác thử nghiệm.

Cắt giảm phụ thuộc một cách an toàn có thể là khó khăn. Giới thiệu giao diện, giả và Dependency Injection là sạch và đẹp như một mục tiêu, chỉ không nhất thiết phải an toàn để làm vào thời điểm này. Vì vậy, đôi khi chúng ta phải dùng đến phân lớp của lớp đang được kiểm tra để ghi đè một số phương thức mà thông thường sẽ bắt đầu một yêu cầu trực tiếp đến DB. Đôi khi, chúng ta thậm chí có thể cần phải thay thế một lớp / lọ phụ thuộc bằng một lớp giả trong môi trường thử nghiệm ...

Đối với tôi, khái niệm quan trọng nhất do Feathers mang lại là các đường nối . Đường may là một vị trí trong mã nơi bạn có thể thay đổi hành vi của chương trình mà không cần sửa đổi mã . Xây dựng các đường nối vào mã của bạn cho phép tách đoạn mã đang kiểm tra, nhưng nó cũng cho phép bạn cảm nhận hành vi của mã đang kiểm tra ngay cả khi khó thực hiện hoặc không thể thực hiện trực tiếp (ví dụ: vì cuộc gọi thực hiện thay đổi trong một đối tượng hoặc hệ thống con khác , có trạng thái không thể truy vấn trực tiếp từ bên trong phương thức thử nghiệm).

Kiến thức này cho phép bạn nhận thấy các hạt giống của khả năng kiểm tra trong đống mã khó nhất và tìm ra những thay đổi tối thiểu, ít gây rối nhất, an toàn nhất để đạt được điều đó. Nói cách khác, để tránh thực hiện các phép tái cấu trúc "rõ ràng" có nguy cơ phá mã mà bạn không nhận thấy - bởi vì bạn chưa có các bài kiểm tra đơn vị để phát hiện điều đó.

Cách nhanh chóng để có được những điểm chính của Làm việc hiệu quả với Mã kế thừa

• Đọc bản PDF 12 trang của Michael Feathers , được viết 2 năm trước cuốn sách.
• Nhìn vào bài thuyết trình của Michael Feathers: 68 slide
• Nghe một cuộc phỏng vấn podcast với Michael Feathers. Ví dụ: tập Hanselminutes dài 30 phút này .

Tôi làm việc trên cơ sở mã gồm hàng triệu dòng mã, một số có niên đại từ những năm 1980. Nó chỉ là phần mềm, vì vậy nó chỉ là vấn đề viết một vài bài kiểm tra đơn vị, vì vậy bạn có thể đi và chỉ cần cấu trúc lại nó, và làm cho nó tốt hơn nhiều.

Từ khóa ở đây chỉ là - đó là một từ có bốn chữ cái không thuộc về từ vựng của lập trình viên, chứ đừng nói đến một người đang làm việc trên các hệ thống cũ.

Bạn nghĩ mất bao lâu để viết một bài kiểm tra đơn vị, để kiểm tra nỗ lực phát triển trong một giờ? Để thảo luận, hãy nói một giờ nữa.

Bao nhiêu thời gian được đầu tư vào hệ thống di sản 20 triệu tuổi đó? Giả sử, 20 nhà phát triển trong 20 năm gấp 2000 giờ / năm (họ đã làm việc khá chăm chỉ). Bây giờ chúng ta hãy chọn một số - bạn có máy tính mới và công cụ mới, và bạn thông minh hơn rất nhiều so với những người đã viết đoạn $% ^^ này ngay từ đầu - giả sử bạn đáng giá 10 trong số đó. Bạn đã có 40 năm đàn ông, tốt, bạn có ...?

Vì vậy, câu trả lời cho câu hỏi của bạn là có nhiều hơn nữa. Ví dụ, thói quen đó là 1000 dòng (tôi có một vài dòng trên 5000), nó quá phức tạp và là một miếng mì spaghetti. Nó sẽ chỉ (một từ bốn chữ cái khác) sẽ mất một vài ngày để tính lại nó thành một vài thói quen 100 dòng và một vài người trợ giúp 20 dòng nữa, phải không? SAI LẦM. Ẩn trong 1000 dòng đó là 100 sửa lỗi, mỗi lỗi là một yêu cầu người dùng không có giấy tờ hoặc trường hợp cạnh khó hiểu. Đó là 1000 dòng vì thói quen 100 dòng ban đầu không thực hiện được công việc.

Bạn cần phải làm việc với tâm trí " nếu nó không bị hỏng, đừng sửa nó ". Khi nó bị hỏng, bạn cần phải rất cẩn thận khi sửa nó - vì bạn làm nó tốt hơn, rằng bạn không vô tình thay đổi thứ khác. Lưu ý rằng "đã phá vỡ" có thể bao gồm mã không thể xác định được, nhưng hoạt động chính xác, phụ thuộc vào hệ thống và việc sử dụng nó. Hãy hỏi "chuyện gì xảy ra nếu tôi làm hỏng việc này và làm cho nó tồi tệ hơn", bởi vì một ngày nào đó bạn sẽ làm được, và bạn sẽ phải nói với sếp của sếp tại sao bạn lại chọn làm điều đó.

Những hệ thống này luôn có thể được làm tốt hơn. Bạn sẽ có một ngân sách để làm việc, một dòng thời gian, bất cứ điều gì. Nếu bạn không - hãy đi và làm cho một. Ngừng làm cho nó tốt hơn khi tiền / thời gian đã hết. Thêm một tính năng, cho mình thời gian để làm cho nó tốt hơn một chút. Sửa một lỗi - một lần nữa, dành thêm một chút thời gian và làm cho nó tốt hơn. Không bao giờ cung cấp nó tồi tệ hơn so với khi bạn bắt đầu.

Có hai điểm chính để lấy đi từ cuốn sách.

1. Mã kế thừa là bất kỳ mã nào không có phạm vi kiểm tra.
2. Bất cứ khi nào bạn phải thay đổi mã kế thừa, bạn nên đảm bảo rằng nó có phạm vi bảo hiểm.

Như những người phản hồi khác đã chỉ ra, cố gắng cập nhật trước mã di sản hiện tại của bạn là một việc vặt . Thay vào đó, bất cứ khi nào bạn phải thay đổi mã kế thừa (đối với tính năng mới hoặc sửa lỗi), hãy dành thời gian để xóa trạng thái kế thừa của nó.

Trong một vỏ hạt đó là sự thật - thêm các bài kiểm tra và tái cấu trúc là tất cả những gì về nó.

Nhưng cuốn sách cung cấp cho bạn nhiều kỹ thuật khác nhau để làm như vậy với mã rất khó kiểm tra và cấu trúc lại một cách an toàn.