Liệu nó có ý nghĩa để viết các bài kiểm tra cho mã kế thừa khi không có thời gian cho việc tái cấu trúc hoàn chỉnh?

Tôi thường cố gắng làm theo lời khuyên của cuốn sách Làm việc hiệu quả với Legacy Cod e . Tôi phá vỡ các phụ thuộc, di chuyển các phần của mã sang @VisibleForTesting public staticcác phương thức và đến các lớp mới để làm cho mã (hoặc ít nhất là một phần của nó) có thể kiểm tra được. Và tôi viết các bài kiểm tra để đảm bảo rằng tôi không phá vỡ bất cứ điều gì khi tôi sửa đổi hoặc thêm các chức năng mới.

Một đồng nghiệp nói rằng tôi không nên làm điều này. Lý luận của mình:

• Mã ban đầu có thể không hoạt động đúng ở vị trí đầu tiên. Và viết các bài kiểm tra cho nó làm cho việc sửa lỗi và sửa đổi trong tương lai khó hơn vì các nhà phát triển cũng phải hiểu và sửa đổi các bài kiểm tra.
• Nếu đó là mã GUI với một số logic (ví dụ: ~ 12 dòng, 2-3 khối / nếu khác), một thử nghiệm không đáng để gặp rắc rối vì mã này quá tầm thường để bắt đầu.
• Các mẫu xấu tương tự cũng có thể tồn tại trong các phần khác của codebase (mà tôi chưa thấy, tôi khá mới); sẽ dễ dàng hơn để làm sạch tất cả chúng trong một lần tái cấu trúc lớn. Trích xuất logic có thể làm suy yếu khả năng này trong tương lai.

Tôi có nên tránh trích xuất các phần có thể kiểm tra và viết bài kiểm tra nếu chúng tôi không có thời gian để tái cấu trúc hoàn toàn không? Có bất lợi nào cho việc này mà tôi nên xem xét?

Đây là ấn tượng không khoa học cá nhân của tôi: cả ba lý do nghe có vẻ như ảo tưởng nhận thức rộng rãi nhưng sai lầm.

1. Chắc chắn, mã hiện tại có thể sai. Nó cũng có thể đúng. Vì toàn bộ ứng dụng dường như có giá trị đối với bạn (nếu không, bạn chỉ cần loại bỏ nó), trong trường hợp không có thông tin cụ thể hơn, bạn nên cho rằng nó chủ yếu là đúng. "Bài kiểm tra viết làm cho mọi thứ khó khăn hơn vì có nhiều mã liên quan hơn" là một thái độ đơn giản và rất sai lầm.
2. Bằng mọi cách, hãy dành những nỗ lực tái cấu trúc, thử nghiệm và cải tiến của bạn ở những nơi họ thêm giá trị nhất với ít nỗ lực nhất. Các chương trình con GUI định dạng giá trị thường không phải là ưu tiên hàng đầu. Nhưng không thử nghiệm cái gì đó vì "nó đơn giản" cũng là một thái độ rất sai lầm. Hầu như tất cả các lỗi nghiêm trọng đều được cam kết bởi vì mọi người nghĩ rằng họ hiểu điều gì đó tốt hơn thực tế.
3. "Chúng tôi sẽ làm tất cả trong một cú hích lớn trong tương lai" là một suy nghĩ tốt. Thông thường các swoop lớn vẫn vững vàng trong tương lai, trong khi hiện tại không có gì xảy ra. Tôi, tôi chắc chắn về niềm tin "chậm và ổn định sẽ thắng cuộc đua".

Một vài suy nghĩ:

Khi bạn tái cấu trúc mã kế thừa, sẽ không có vấn đề gì nếu một số thử nghiệm bạn viết xảy ra trái với thông số kỹ thuật lý tưởng. Vấn đề là họ kiểm tra hành vi hiện tại của chương trình . Tái cấu trúc là về việc thực hiện các bước chức năng nhỏ để làm cho mã sạch hơn; bạn không muốn tham gia sửa lỗi trong khi tái cấu trúc. Ngoài ra, nếu bạn phát hiện ra một lỗi trắng trợn, nó sẽ không bị mất. Bạn luôn có thể viết một bài kiểm tra hồi quy cho nó và tạm thời vô hiệu hóa nó, hoặc chèn một tác vụ sửa lỗi trong hồ sơ tồn đọng của bạn để sau này. Một việc tại một thời gian.

Tôi đồng ý rằng mã GUI thuần túy rất khó kiểm tra và có lẽ không phù hợp để tái cấu trúc kiểu " Làm việc hiệu quả ... ". Tuy nhiên, điều này không có nghĩa là bạn không nên trích xuất hành vi không có gì để làm trong lớp GUI và kiểm tra mã được trích xuất. Và "12 dòng, 2-3 nếu / khối khác" không phải là nhỏ. Tất cả các mã với ít nhất một chút logic điều kiện nên được kiểm tra.

Theo kinh nghiệm của tôi, tái cấu trúc lớn không dễ dàng và chúng hiếm khi hoạt động. Nếu bạn không đặt ra cho mình những mục tiêu nhỏ bé, chính xác, sẽ có nguy cơ cao bạn bắt tay vào làm lại không bao giờ kết thúc, kéo tóc, nơi cuối cùng bạn sẽ không bao giờ đặt chân lên. Thay đổi càng lớn, bạn càng có nguy cơ phá vỡ một thứ gì đó và bạn sẽ càng gặp nhiều rắc rối hơn khi tìm ra nơi bạn thất bại.

Làm cho mọi thứ tiến triển tốt hơn với các phép tái cấu trúc nhỏ không phải là "làm suy yếu các khả năng trong tương lai", nó cho phép chúng - củng cố mặt bằng đầm lầy nơi ứng dụng của bạn nằm. Bạn chắc chắn nên làm điều đó.

Đồng thời: "Mã ban đầu có thể không hoạt động chính xác" - điều đó không có nghĩa là bạn chỉ cần thay đổi hành vi của mã mà không lo lắng về tác động. Các mã khác có thể dựa vào những gì dường như là hành vi bị hỏng hoặc tác dụng phụ của việc triển khai hiện tại. Kiểm tra phạm vi bảo hiểm của ứng dụng hiện tại phải giúp tái cấu trúc dễ dàng hơn sau này, bởi vì nó sẽ giúp bạn tìm ra khi bạn vô tình làm hỏng thứ gì đó. Bạn nên kiểm tra những phần quan trọng nhất trước.

Câu trả lời của Kilian bao gồm các khía cạnh quan trọng nhất, nhưng tôi muốn mở rộng ở điểm 1 và 3.

Nếu một nhà phát triển muốn thay đổi mã (refactor, mở rộng, gỡ lỗi), cô ấy phải hiểu nó. Cô ấy phải đảm bảo những thay đổi của mình ảnh hưởng đến chính xác hành vi mà cô ấy muốn (không có gì trong trường hợp tái cấu trúc), và không có gì khác.

Nếu có bài kiểm tra, thì cô cũng phải hiểu các bài kiểm tra, chắc chắn. Đồng thời, các bài kiểm tra sẽ giúp cô hiểu mã chính và các bài kiểm tra dễ hiểu hơn nhiều so với mã chức năng (trừ khi chúng là các bài kiểm tra tồi). Và các thử nghiệm giúp hiển thị những gì đã thay đổi trong hành vi của mã cũ. Ngay cả khi mã gốc là sai và kiểm tra kiểm tra hành vi sai đó, đó vẫn là một lợi thế.

Tuy nhiên, điều này đòi hỏi các bài kiểm tra được ghi lại dưới dạng kiểm tra hành vi có sẵn, không phải là một đặc điểm kỹ thuật.

Một số suy nghĩ về điểm 3 cũng vậy: ngoài thực tế là "cú hích lớn" hiếm khi thực sự xảy ra, còn có một điều khác: nó thực sự không dễ dàng hơn. Để dễ dàng hơn, một số điều kiện sẽ phải áp dụng:

• Các antipotype được tái cấu trúc cần phải được tìm thấy dễ dàng. Có phải tất cả các singletons của bạn được đặt tên XYZSingleton? Là getter dụ của họ luôn luôn được gọi getInstance()? Và làm thế nào để bạn tìm thấy thứ bậc quá sâu của bạn? Làm thế nào để bạn tìm kiếm các đối tượng thần của bạn? Chúng yêu cầu phân tích số liệu mã và sau đó kiểm tra thủ công các số liệu. Hoặc bạn chỉ vấp ngã khi họ làm việc, như bạn đã làm.
• Việc tái cấu trúc cần phải là cơ khí. Trong hầu hết các trường hợp, phần khó của tái cấu trúc là hiểu rõ mã hiện có đủ để biết cách thay đổi nó. Singletons một lần nữa: nếu singleton biến mất, làm thế nào để bạn có được thông tin cần thiết cho người dùng của nó? Nó thường có nghĩa là hiểu sơ đồ địa phương để bạn biết nơi lấy thông tin từ đó. Bây giờ thì còn gì dễ dàng hơn: tìm kiếm mười singletons trong ứng dụng của bạn, hiểu cách sử dụng của từng loại (điều này dẫn đến việc cần phải hiểu 60% của codebase) và trích xuất chúng? Hoặc lấy mã mà bạn đã hiểu (bởi vì bạn đang làm việc với nó ngay bây giờ) và trích xuất các singletons đang được sử dụng ở đó? Nếu việc tái cấu trúc không quá máy móc đến mức nó đòi hỏi ít hoặc không có kiến ​​thức về mã xung quanh, thì sẽ không được sử dụng để tạo ra nó.
• Việc tái cấu trúc cần phải được tự động hóa. Điều này là hơi dựa trên ý kiến, nhưng ở đây đi. Một chút tái cấu trúc là niềm vui và thỏa mãn. Rất nhiều tái cấu trúc là tẻ nhạt và nhàm chán. Để lại đoạn mã bạn vừa làm việc ở trạng thái tốt hơn mang lại cho bạn cảm giác tốt đẹp, ấm áp, trước khi bạn chuyển sang những thứ thú vị hơn. Cố gắng cấu trúc lại toàn bộ cơ sở mã sẽ khiến bạn thất vọng và tức giận với các lập trình viên ngốc đã viết nó. Nếu bạn muốn thực hiện tái cấu trúc swoop lớn, thì nó cần được tự động hóa phần lớn để giảm thiểu sự thất vọng. Theo một cách nào đó, đây là sự kết hợp của hai điểm đầu tiên: bạn chỉ có thể tự động tái cấu trúc nếu bạn có thể tự động tìm mã xấu (nghĩa là dễ dàng tìm thấy) và tự động thay đổi mã (tức là cơ học).
• Cải thiện dần dần làm cho một trường hợp kinh doanh tốt hơn. Tái cấu trúc swoop lớn là vô cùng đột phá. Nếu bạn cấu trúc lại một đoạn mã, bạn sẽ luôn gặp phải xung đột hợp nhất với những người khác đang làm việc với nó, bởi vì bạn chỉ cần chia phương thức mà họ đang thay đổi thành năm phần. Khi bạn cấu trúc lại một đoạn mã có kích thước hợp lý, bạn sẽ xảy ra xung đột với một vài người (1-2 khi chia tách siêu tuyến 600 dòng, 2-4 khi phá vỡ đối tượng thần, 5 khi tách đơn vị từ mô-đun ), nhưng dù sao bạn cũng đã có những xung đột đó vì các chỉnh sửa chính của bạn. Khi bạn thực hiện tái cấu trúc toàn bộ cơ sở mã, bạn sẽ xung đột với tất cả mọi người. Chưa kể rằng nó liên kết với một vài nhà phát triển trong nhiều ngày. Cải tiến dần dần làm cho mỗi sửa đổi mã mất nhiều thời gian hơn. Điều này làm cho nó dễ dự đoán hơn và không có khoảng thời gian có thể nhìn thấy như vậy khi không có gì xảy ra ngoại trừ việc dọn dẹp.

Có một văn hóa ở một số công ty nơi họ tỏ ra thận trọng cho phép các nhà phát triển bất cứ lúc nào để tăng cường mã không trực tiếp cung cấp giá trị bổ sung, ví dụ như chức năng mới.

Có lẽ tôi đang giảng về việc chuyển đổi ở đây, nhưng đó rõ ràng là nền kinh tế sai lầm. Làm sạch và súc tích mã lợi ích cho các nhà phát triển tiếp theo. Nó chỉ là hoàn vốn không rõ ràng ngay lập tức.

Cá nhân tôi đăng ký Nguyên tắc Hướng đạo nam nhưng những người khác (như bạn đã thấy) thì không.

Điều đó nói rằng, phần mềm bị entropy và xây dựng nợ kỹ thuật. Các nhà phát triển trước đây không có thời gian (hoặc có lẽ chỉ lười biếng hoặc thiếu kinh nghiệm) có thể đã triển khai các giải pháp lỗi tối ưu phụ so với các giải pháp được thiết kế tốt. Mặc dù có thể mong muốn cấu trúc lại những thứ này, nhưng bạn có nguy cơ đưa ra các lỗi mới cho mã làm việc (cho người dùng bằng cách nào).

Một số thay đổi có rủi ro thấp hơn những thay đổi khác. Ví dụ, nơi tôi làm việc có xu hướng có rất nhiều mã trùng lặp có thể được đưa vào chương trình con một cách an toàn với tác động tối thiểu.

Cuối cùng, bạn phải thực hiện một cuộc gọi phán xét về việc bạn thực hiện tái cấu trúc bao xa nhưng có giá trị không thể phủ nhận khi thêm các bài kiểm tra tự động nếu chúng chưa tồn tại.

Theo kinh nghiệm của tôi, một bài kiểm tra đặc tính của một số loại hoạt động tốt. Nó cung cấp cho bạn phạm vi kiểm tra rộng nhưng không cụ thể tương đối nhanh chóng, nhưng có thể khó thực hiện cho các ứng dụng GUI.

Sau đó tôi sẽ viết các bài kiểm tra đơn vị cho các phần mà bạn muốn thay đổi và làm như vậy mỗi khi bạn muốn thực hiện thay đổi do đó tăng phạm vi kiểm tra đơn vị của bạn theo thời gian.

Cách tiếp cận này cung cấp cho bạn một ý tưởng tốt nếu các thay đổi đang ảnh hưởng đến các bộ phận khác của hệ thống và hãy để bạn vào vị trí để thực hiện bất kỳ thay đổi cần thiết nào sớm hơn.

Re: "Mã ban đầu có thể không hoạt động đúng":

Các xét nghiệm không được viết bằng đá. Họ có thể được thay đổi. Và nếu bạn đã kiểm tra một tính năng sai, nó sẽ dễ dàng viết lại bài kiểm tra chính xác hơn. Rốt cuộc, chỉ có kết quả mong đợi của chức năng được kiểm tra nên đã thay đổi.

Vâng, vâng. Trả lời như một kỹ sư kiểm thử phần mềm. Đầu tiên bạn nên kiểm tra mọi thứ bạn từng làm. Bởi vì nếu bạn không, bạn không biết liệu nó có hoạt động hay không. Điều này có vẻ rõ ràng đối với chúng tôi nhưng tôi có những đồng nghiệp nhìn nhận nó khác đi. Ngay cả khi dự án của bạn là một dự án nhỏ có thể không bao giờ được giao, bạn phải nhìn trực diện người dùng và nói rằng bạn biết nó hoạt động vì bạn đã thử nghiệm nó.

Mã không tầm thường luôn chứa các lỗi (trích dẫn một anh chàng từ uni; và nếu không có lỗi trong đó, thì đó là chuyện nhỏ) và công việc của chúng tôi là tìm ra chúng trước khi khách hàng làm. Mã di sản có lỗi di sản. Nếu mã ban đầu không hoạt động theo cách nó cần, bạn muốn biết về nó, tin tôi đi. Lỗi là ổn nếu bạn biết về chúng, đừng ngại tìm chúng, đó là những gì ghi chú phát hành dành cho.

Nếu tôi nhớ không nhầm thì cuốn sách Tái cấu trúc nói rằng hãy kiểm tra liên tục bằng mọi cách. Vì vậy, đó là một phần của quá trình.

Làm bảo hiểm kiểm tra tự động.

Hãy coi chừng suy nghĩ mơ ước, cả của riêng bạn và của khách hàng và ông chủ của bạn. Tôi rất muốn tin rằng những thay đổi của tôi sẽ đúng ngay lần đầu tiên và tôi sẽ chỉ phải kiểm tra một lần, tôi đã học được cách đối xử với suy nghĩ đó giống như cách tôi đối xử với các email lừa đảo của Nigeria. Vâng, chủ yếu là; Tôi chưa bao giờ đi email lừa đảo nhưng gần đây (khi hét lên) tôi đã từ bỏ việc không sử dụng các thực tiễn tốt nhất. Đó là một kinh nghiệm đau đớn kéo dài (nhiều). Không bao giờ lặp lại!

Tôi có một câu trích dẫn yêu thích từ truyện tranh web Freefall: "Bạn đã bao giờ làm việc trong một lĩnh vực phức tạp mà người giám sát chỉ có một ý tưởng sơ bộ về các chi tiết kỹ thuật? ... Sau đó, bạn biết cách chắc chắn nhất để khiến người giám sát của bạn thất bại là làm theo mọi mệnh lệnh của anh ta mà không cần hỏi. "

Có lẽ thích hợp để giới hạn thời gian bạn đầu tư.

Nếu bạn đang xử lý một lượng lớn mã kế thừa hiện chưa được thử nghiệm, việc nhận được bảo hiểm thử nghiệm ngay bây giờ thay vì chờ đợi một bản viết lại lớn giả định trong tương lai là bước đi đúng đắn. Bắt đầu bằng cách viết bài kiểm tra đơn vị là không.

Nếu không có kiểm tra tự động, sau khi thực hiện bất kỳ thay đổi nào đối với mã, bạn cần thực hiện một số kết thúc thủ công để kết thúc kiểm tra ứng dụng để đảm bảo nó hoạt động. Bắt đầu bằng cách viết các bài kiểm tra tích hợp cấp cao để thay thế điều đó. Nếu ứng dụng của bạn đọc các tệp trong, xác thực chúng, xử lý dữ liệu theo cách thức nào đó và hiển thị kết quả mà bạn muốn kiểm tra nắm bắt tất cả điều đó.

Lý tưởng nhất là bạn sẽ có dữ liệu từ một kế hoạch kiểm tra thủ công hoặc có thể lấy một mẫu dữ liệu sản xuất thực tế để sử dụng. Nếu không, vì ứng dụng đang trong quá trình sản xuất, trong hầu hết các trường hợp, nó đang hoạt động như vậy, vì vậy chỉ cần tạo ra dữ liệu sẽ đạt được tất cả các điểm cao và cho rằng đầu ra là chính xác cho đến bây giờ. Không tệ hơn việc thực hiện một chức năng nhỏ, giả sử nó đang thực hiện tên của nó hoặc bất kỳ nhận xét nào cho thấy nó nên được thực hiện và viết các bài kiểm tra giả định rằng nó hoạt động chính xác.

IntegrationTestCase1()
{
    var input = ReadDataFile("path\to\test\data\case1in.ext");
    bool validInput = ValidateData(input);
    Assert.IsTrue(validInput);

    var processedData = ProcessData(input);
    Assert.AreEqual(0, processedData.Errors.Count);

    bool writeError = WriteFile(processedData, "temp\file.ext");
    Assert.IsFalse(writeError);

    bool filesAreEqual = CompareFiles("temp\file.ext", "path\to\test\data\case1out.ext");
    Assert.IsTrue(filesAreEqual);
}

Khi bạn đã có đủ các bài kiểm tra cấp cao này được viết để ghi lại các ứng dụng hoạt động bình thường và hầu hết các trường hợp lỗi phổ biến, lượng thời gian bạn sẽ cần dành để đập bàn phím để thử và bắt lỗi từ mã đang làm gì đó ngoài việc bạn nghĩ rằng nó đáng lẽ phải làm sẽ giảm đáng kể làm cho việc tái cấu trúc trong tương lai (hoặc thậm chí là viết lại lớn) dễ dàng hơn nhiều.

Khi bạn có thể mở rộng phạm vi kiểm tra đơn vị, bạn có thể giảm bớt hoặc thậm chí rút lại hầu hết các kiểm tra tích hợp. Nếu ứng dụng đọc / ghi tệp của ứng dụng hoặc truy cập DB, kiểm tra các phần đó một cách cô lập và chế nhạo chúng hoặc bắt đầu kiểm tra bằng cách tạo cấu trúc dữ liệu đọc từ tệp / cơ sở dữ liệu là một nơi rõ ràng để bắt đầu. Trên thực tế, việc tạo ra cơ sở hạ tầng thử nghiệm sẽ mất nhiều thời gian hơn so với việc viết một tập các thử nghiệm nhanh và bẩn; và mỗi khi bạn chạy một bộ thử nghiệm tích hợp trong 2 phút thay vì dành 30 phút để kiểm tra thủ công một phần của những gì các thử nghiệm tích hợp bao gồm bạn đã kiếm được một chiến thắng lớn.