phương pháp Refactoring trong cơ sở mã hiện với số lượng lớn các thông số

Question

Tôi đã thừa hưởng một cơ sở mã hiện nơi "tính năng" như sau:

• lớp nguyên khối khổng lồ với (theo nghĩa đen) 100 của các biến thành viên và các phương pháp đi một cho các trang (màn hình)
• các phương pháp công khai và riêng tư với số lượng đối số lớn.

Tôi đang cố gắng dọn dẹp và cấu trúc lại mã, để nó tốt hơn một chút so với cách tôi tìm thấy. Vì vậy, câu hỏi của tôi

• là giá trị (hoặc bạn) phương pháp tái cấu trúc với 10 hoặc nhiều đối số để chúng dễ đọc hơn?
• có phương pháp hay nhất về phương pháp nên dài bao lâu? Bạn thường giữ chúng bao lâu?
• là các lớp nguyên khối có hại không?

Answer 1

là giá trị (hoặc bạn) phương pháp tái cấu trúc với 10 hoặc nhiều đối số để chúng dễ đọc hơn?

Có, nó rất đáng giá. Nó thường quan trọng hơn đối với các phương thức tái cấu trúc không phải là "hợp lý" so với các phương thức đã tốt, ngắn và có một danh sách đối số nhỏ.

Thông thường, nếu bạn có nhiều đối số, đó là do phương thức thực hiện quá nhiều - rất có thể, nó phải là một lớp của riêng nó, không phải là phương thức.

Điều đó đang được nói, trong những trường hợp cần nhiều tham số, tốt nhất là đóng gói các tham số vào một lớp đơn lẻ (ví dụ: SpecificAlgorithmOptions) và chuyển một thể hiện của lớp đó. Bằng cách này, bạn có thể cung cấp mặc định rõ ràng, và nó rất rõ ràng phương pháp nào là cần thiết so với tùy chọn (dựa trên những gì được yêu cầu để xây dựng lớp tùy chọn).

có phương pháp hay nhất nào về phương pháp nên dài? Bạn thường giữ chúng bao lâu?

Phương pháp nên càng ngắn càng tốt. Nó nên có một mục đích, và được sử dụng cho một nhiệm vụ, khi có thể. Nếu nó có thể chia nó thành các phương thức riêng biệt, trong đó mỗi phương thức là một "nhiệm vụ" thực sự, định tính, thì làm như vậy khi tái cấu trúc.

là các lớp nguyên khối không tốt?

Có.

Answer 2

nếu mã đang hoạt động và không cần chạm vào nó, tôi sẽ không tái cấu trúc. tôi chỉ refactor trường hợp rất có vấn đề nếu tôi anyway phải chạm vào chúng (hoặc để mở rộng chúng cho chức năng hoặc sửa lỗi). Tôi ủng hộ cách thực dụng: Chỉ (trong 95%) cảm ứng, những gì bạn thay đổi.

Vài suy nghĩ đầu tiên về vấn đề cụ thể của bạn (mặc dù chi tiết rất khó mà không biết mã):

• đầu đến biến dụ nhóm, các nhóm này sau đó sẽ là mục tiêu để làm 'chiết xuất lớp'
• khi đã nhóm các biến này, bạn hy vọng có thể nhóm một số phương thức, cũng được di chuyển khi thực hiện 'trích xuất lớp'
• thường có nhiều phương pháp không sử dụng bất kỳ trường nào. làm cho chúng tĩnh (chúng có nhiều khả năng là các phương thức trợ giúp, có thể được trích xuất tới các lớp trợ giúp)
• trong trường hợp các trường cá thể không liên quan được trộn lẫn theo nhiều phương pháp, tải các phương thức 'extract method'
• càng nhiều càng tốt, bởi vì bạn rất có thể không có kiểm tra tại chỗ và tự động hóa là an toàn hơn.

Về câu hỏi cụ thể khác của bạn.

là giá trị nó (hay bạn) phương pháp cấu trúc lại với 10 hay các đối số để chúng dễ đọc hơn?

dứt khoát. 10 thông số là quá nhiều để nắm bắt cho con người chúng ta. rất có thể phương pháp này đang làm quá nhiều.

có phương pháp hay nhất nào về phương pháp nên dài? Bạn thường giữ chúng bao lâu?

tùy theo ... tùy chọn. tôi đã nói một số điều về điều này thread (mặc dù câu hỏi là PHP). tôi vẫn sẽ áp dụng các số/chỉ số này cho bất kỳ ngôn ngữ nào.

là các lớp nguyên khối không tốt?

tùy theo ý bạn là gì với nguyên khối. nếu bạn ngụ ý nhiều biến mẫu, phương thức vô tận, rất nhiều phức tạp nếu có/khác, vâng.

cũng có một cái nhìn tại một viên ngọc thực (đối với tôi là phải có cho mỗi nhà phát triển): working effectively with legacy code

Answer 3

Giả sử mã đang hoạt động tôi sẽ đề nghị bạn suy nghĩ về những câu hỏi đầu tiên:

• là mã được ghi chép đầy đủ?
• bạn có hiểu mã không?
• tần suất các tính năng mới được thêm vào?
• tần suất các lỗi được báo cáo và sửa lỗi?
• khó sửa đổi và sửa mã?
• tuổi thọ của mã là gì?
• bạn còn bao nhiêu phiên bản của trình biên dịch (nếu có)?
• là hệ điều hành mà nó chạy trên dự kiến ​​sẽ thay đổi trong suốt cuộc đời của nó?

Nếu hệ thống sẽ được thay thế sau năm năm, được ghi lại tốt, sẽ có ít thay đổi và lỗi dễ sửa chữa - để riêng nó bất kể kích cỡ của lớp và số tham số. Nếu bạn được xác định để refactor làm cho một danh sách các đề xuất tái cấu trúc của bạn theo thứ tự lợi ích tối đa với những thay đổi tối thiểu và tấn công nó từng bước.