2010-09-17 26 views
5

Gần đây tôi đã đọc cuốn sách của Michael C. Feathers Working effectively with legacy code và đi qua điểm mà ông đã đề cập đến một cách để kiểm tra sự an toàn của các công cụ tái cấu trúc tự động.Có công cụ tái cấu trúc an toàn nào cho .net (hoặc ít nhất là C#) không?

Câu hỏi của tôi là: Có công cụ tái cấu trúc an toàn nào cho nền tảng .net không?; điều đó có nghĩa là các công cụ chỉ cho phép tái cấu trúc thực và ví dụ: không cho phép tái cấu trúc inline variable trên biến số temp trong ví dụ sau hoặc ít nhất là cảnh báo rằng tôi đang thay đổi logic.

class Program 
{ 
    private static int _x; 

    static void Main() 
    { 
     int temp = Test(); 
     for (int i = 0; i < 10; ++i) 
     { 
      Console.WriteLine(temp); 
     } 
     Console.ReadKey(); 
    } 


    private static int Test() 
    { 
     return ++_x; 
    } 
} 

Tôi đã thử nghiệm ví dụ này trên các công cụ refactoring ResharperCoderush + Refactor pro với các phiên bản mới nhất và cả thất bại kiểm tra và cho phép sắp xếp để:

class Program 
{ 
    private static int _x; 

    static void Main() 
    { 
     for (int i = 0; i < 10; ++i) 
     { 
      Console.WriteLine(Test()); 
     } 
     Console.ReadKey(); 
    } 

    private static int Test() 
    { 
     return ++_x; 
    } 
} 
+0

Bạn có ví dụ về công cụ * sẽ * thực hiện theo cách bạn muốn, ngay cả đối với ngôn ngữ khác không? –

+1

Thực ra tôi muốn rằng công cụ sẽ không cung cấp việc tái cấu trúc cụ thể này hoặc hiển thị một số loại cảnh báo rằng điều này sẽ thay đổi logic của mã. Bởi vì việc tái cấu trúc không được thay đổi logic, hãy xem định nghĩa tại wikipedia: http://en.wikipedia.org/wiki/Refactoring. – RoXX

Trả lời

5

Để thực sự an toàn với quá trình tái cấu trúc tự động là rất khó.

Khi lần đầu tiên giới thiệu các phép tái cấu trúc trong Visual C#, chúng tôi tự hỏi câu hỏi này: chúng ta có cần phải hoàn thành mọi thứ đúng lúc hay chúng ta cho phép chúng mắc lỗi trong một số trường hợp?

Để được quyền tất cả thời gian sẽ đòi hỏi rất nhiều nỗ lực lập trình, có nghĩa là chúng tôi chỉ nhận được một vài phép tái cấu trúc trong hộp. Nó cũng sẽ làm cho các phép tái cấu trúc chậm lại, vì chúng mất nhiều thời gian để xác nhận.

Cho phép họ phạm sai lầm sẽ khiến họ vô dụng đối với bất kỳ đội nào không có phạm vi kiểm tra tự động tuyệt vời. Các nhóm TDD có các bài kiểm tra tốt, nhưng đó chỉ là một phần của cơ sở người dùng Visual Studio. Chúng tôi không muốn tạo ra các tính năng mà chúng tôi phải nói với mọi người không nên sử dụng!

Đội TDD sẽ gặp lỗi nhanh chóng, nhưng họ sẽ học nhanh như không tin tưởng các công cụ tái cấu trúc của chúng tôi. Họ ngần ngại sử dụng chúng, và tìm kiếm các giải pháp khác phần lớn thời gian (tìm và thay thế thay cho Đổi tên).

Ngoài ra, với tư cách là nhóm C#, chúng tôi đã ở vị trí tốt để thực hiện tái cấu trúc độ trung thực cao. Chúng tôi đã có một lợi thế độc đáo, với các nhà thiết kế ngôn ngữ C# và đội biên dịch ngay dưới hành lang. Chúng tôi biết chúng ta nên chơi với thế mạnh của mình.

Vì vậy, chúng tôi quyết định thực hiện các phép tái cấu trúc chất lượng thấp hơn, thay vì nhiều phép tái cấu trúc không đáng tin cậy. Hôm nay có rất 6.

Visual Studio Refactorings

Nhìn lại, tôi muốn chúng tôi đã chỉ làm Rename, Phương pháp chiết xuất, và giới thiệu Biến địa phương. Hai cái cuối cùng gần như giống nhau, thực hiện khôn ngoan. 3 tham số refactorings (có sử dụng để được một 7, thúc đẩy biến địa phương để tham số, nhưng nó đã được cắt giảm trong VS2010) là một tấn công việc để có được quyền, và có lẽ không có giá trị nó.

Đề xuất của tôi là làm TDD, cung cấp cho bạn một bộ sưu tập lớn các bài kiểm tra để bạn có thể cấu trúc lại an toàn, cho dù bạn sử dụng công cụ hoặc thực hiện thủ công.

10

Refactoring vốn đã nguy hiểm. Chỉ dựa vào một công cụ để làm cho mã của bạn an toàn là không khôn ngoan.

Chúng tôi sử dụng Resharper nhưng không có mạng lưới an toàn của các bài kiểm tra đơn vị toàn diện. Tôi không biết về bất kỳ công cụ C# nào tốt hơn trong không gian này.

+1

Tôi đồng ý rằng bạn nên luôn có các xét nghiệm đơn vị để bao gồm việc tái cấu trúc, nhưng thực tế nếu bạn có một công cụ chỉ cho phép tái cấu trúc an toàn, bạn có thể áp dụng một số phép cấu trúc lại cơ bản trước khi thêm các thử nghiệm đơn vị vào mã kế thừa hoặc để làm cho mã có thể kiểm tra được, điều này sẽ làm cho bạn hiệu quả hơn. – RoXX

+2

Tái cấu trúc * không nên * vốn có rủi ro từ quan điểm chức năng. Điều này chỉ để cho thấy rằng các công cụ không đủ mạnh để thực hiện việc kiểm tra, do đó, các công cụ xây dựng cung cấp cho họ mà không cần kiểm tra cần thiết. Người mua hãy cẩn thận. (Đừng làm cho tôi sai: nó là * cứng * để thực hiện tất cả các kiểm tra cần thiết: bạn cần những gì số tiền để kết thúc trước đầy đủ của một trình biên dịch). –

2

"an toàn" là khá chủ quan ....

Trong khi hai công cụ khiến không được coi là "an toàn" dựa trên thử nghiệm này trong tâm trí của bạn cả trong những công cụ cực kỳ hữu ích. Không có công cụ nào là hoàn hảo. Nếu có một tình huống mà họ làm một cái gì đó bạn không thích hoặc tránh làm việc đó hoặc tạo ra một công việc xung quanh.

5

Tôi không đồng ý rằng "kiểm tra" của bạn hiển thị lỗi.

BẠN đã thay đổi logic, chứ không phải công cụ. Bạn đã thay đổi mã sao cho một phương thức sẽ được gọi lặp đi lặp lại thay vì một lần.

Các công cụ chỉ làm những gì bạn bảo họ làm.

+0

Yup. Đây là lý do tại sao bạn nên kiểm tra mã của bạn sau mỗi lần tái cấu trúc để bạn * biết * khi bạn thay đổi logic. – strager

+0

Tôi sẽ chấp nhận tuyên bố OPs nếu công cụ thực sự giới thiệu lỗi, chẳng hạn như sử dụng phép đảo ngược nếu tuyên bố tái cấu trúc dẫn đến kết quả logic khác. –

+2

Thực ra tôi đã sử dụng TOOL để áp dụng tái cấu trúc, mà không phải là tái cấu trúc. Định nghĩa của tái cấu trúc đang thay đổi mã mà không sửa đổi hành vi của nó, nhưng công cụ đã thay đổi một số hành vi để nó không nên gọi chức năng này tái cấu trúc. Tất nhiên việc kiểm tra đơn vị để trang trải điều này luôn tốt nhất, nhưng thực ra bạn sẽ hiệu quả hơn nếu bạn có thể áp dụng các phép tái cấu trúc tự động này mà không phải lo lắng về việc phá vỡ chức năng hiện tại – RoXX

0

Tôi nghĩ rằng Refactor an toàn có thể là công cụ cho trường hợp của bạn. Mặc dù nó dành cho Java, các khái niệm của nó có thể áp dụng cho các ngôn ngữ OO khác.

http://www.dsc.ufcg.edu.br/~spg/saferefactor/

Các vấn đề liên quan