Eclipse: Tái cấu trúc hữu ích nhất

Question

Hiện tại, tôi sử dụng tính năng tái cấu trúc Eclipse. Một số kỹ thuật là rõ ràng hơn sau đó những người khác và một số tôi không bao giờ cố gắng.

Việc tái cấu trúc nào hữu ích nhất cho bạn và tại sao?

Lưu ý: Tôi tìm thấy trình bày này rất hữu ích, có lẽ bởi vì nó là ví dụ điều khiển do đó dễ hiểu:

"Refactoring for everyone - How and why to use Eclipse's automated refactoring features"

Edit: Bài viết này rất hữu ích cũng như (Cảm ơn jitter)

Explore refactoring functions in Eclipse JDT

Answer 1

Đó là một câu hỏi thú vị. Tôi biết những gì làm việc cho tôi và nó là thú vị để xem những gì người khác sử dụng.

Tôi quyết định thực hiện một cách tiếp cận khoa học hơn để xác định các lệnh tái cấu trúc được sử dụng phổ biến nhất. Eclipse có tính năng Usage Data Collector (UDC) được tích hợp sẵn. Dữ liệu là publicly available. Tôi lấy dữ liệu và trích xuất các đồ thị sau đây cho thấy các lệnh chỉnh sửa thường được sử dụng nhất (không có lệnh điều hướng).

alt text http://img.skitch.com/20091207-bmcng36rjy837sqmcx58b85age.gif

Tuy nhiên, tôi tin tưởng tuyệt đối vào "Save Actions" để định dạng và tổ chức nhập khẩu (đọc my article about it), vì vậy tôi sẽ không tính những. Tôi cũng sẽ xóa các hành động nhận xét. Hình ảnh trông giống như sau: alt text http://img.skitch.com/20091207-ieas1mk5114fwitucqkqxyw6t.gif

Answer 2

yêu thích của tôi:

1. Đổi tên
2. Kéo lên/Đẩy Xuống
3. Extract Method

Answer 3

Những gì tôi sử dụng nhiều nhất là Rename, Phương pháp Extract và thay đổi phương pháp Chữ ký, theo thứ tự đó.

Answer 4

Đổi tên - vì việc đưa ra những thứ có ý nghĩa là cách tốt nhất để viết mã tự viết. phím Shift +Alt +R

Extract phương pháp - bất cứ khi nào một phương pháp trở nên quá dài. phím Shift +Alt +M

Extract liên tục - bởi vì con số kỳ diệu là xấu. Shift + Alt + T (menu tái cấu trúc, không có phím tắt trực tiếp).

Biến giới thiệu/giới thiệu - để xóa lộn xộn khỏi các phương pháp. phím Shift +Alt +tôi (inline), phím Shift +Alt +L (giới thiệu)

Answer 5

tôi sử dụng:

1- Đổi tên - để sửa chữa phương pháp tốt hơn tên

2- Di chuyển - để sắp xếp gói của tôi theo những cách tốt hơn, như khi tôi bắt đầu dự án của tôi, nó quá nhỏ nên không cần gói io, nhưng bây giờ có.

3 Tạo Comments -khi tôi tạo ra một .class tránh tôi để copy lại giấy phép GPL, vv

4 Indentation đúng - để giữ mã của tôi có thể đọc được.

Answer 6

yêu thích (theo thứ tự sử dụng):

1. Rename (Alt-Shift-R, hoặc Ctrl-1 cho đổi tên nhanh hơn trong-file)
   biến đổi tên Tốt, phương pháp, vv. không có tác dụng phụ.
2. Trích xuất biến (Ctrl-1, Alt-Shift-L)
   Tốt để tách dòng nhanh 100 ký tự thành các bước riêng biệt.
3. Phương thức trích xuất (Alt-Shift-M)
   Tạo phương pháp trong một số mã mà không có bất kỳ tác dụng phụ nào.
4. Tuyên bố biến phân chia (Ctrl-1)
   Tốt khi bạn khởi tạo biến tại khai báo và bây giờ phát hiện ra rằng khởi tạo cần phải nằm trong một khối thử hoặc khối.
5. Chữ ký phương thức thay đổi (Alt-Shift-C)
   Con dao quân đội Thụy Sĩ tiện dụng của thao tác chữ ký phương pháp, bao gồm giá trị mặc định cho thông số mới.
6. Kéo Lên/Xuống Đẩy phương pháp kéo và biến vào một giao diện chung hoặc cha hoặc đẩy nó xuống một lớp con
7. Extract Interface/lớp cha
   Trích xuất một giao diện hoặc một lớp cha ra khỏi lớp hiện hành. Rất tiện dụng.

Answer 7

CTRL + 1 trên phần lót màu đỏ, tức là sửa nhanh.

Answer 8

Các cấu trúc lại phổ biến nhất đã được nêu và tôi hoàn toàn đồng ý với chúng.

Mã formatter (Nguồn, Format hoặc Ctrlphím ShiftF) là một trong những tính năng của IDE tôi sử dụng rất thường xuyên. Đúng vậy, nó không phải là refactoring, nhưng nó cải thiện code dễ đọc khi vẫn duy trì phong cách mã hóa của bạn: chỉ cần đi tới Preferences, Java, Mã Phong cách, Formatter và nói với Eclipse cách bạn muốn mã của bạn để tìm kiếm!

Tạo Getters and Setters cũng là tính năng tôi tìm thấy để tiết kiệm thời gian khi viết hạt Java.

Answer 9

yêu thích của tôi là:

1) Đổi tên - Nó hoạt động trên tên phương pháp, tên biến, tên lớp, fields-- thực sự bất cứ điều gì với một cái tên.
2) Chuyển đổi lớp ẩn danh thành lồng nhau - Giúp gỡ lỗi, cho phép bạn sử dụng lại logic (chẳng hạn như trình so sánh) mà bạn chỉ nghĩ rằng bạn sẽ sử dụng ở một nơi.
3) Chuyển đổi loại thành viên thành cấp cao nhất - Thường sau khi tạo một lớp ẩn danh thành một lớp lồng nhau, tôi phát hiện ra rằng lớp đó hữu ích ở nơi khác. Việc tái cấu trúc này là hoàn hảo.

Answer 10

Eclipse có lẽ là ít nhất cấu trúc lại cho tất cả các IDE phổ biến.Bạn có thể xem Netbeans hoặc IntelliJ (phiên bản cộng đồng là miễn phí). Ngược lại, Eclipse có thể là trình gỡ lỗi tốt nhất. ;)

Tôi sử dụng phép tái cấu trúc khi tôi viết mã tăng tốc khoảng 15% nên khả năng mã refactor của IntelliJ không biên dịch rất hữu ích cho tôi. Các IDE khác có thể hỗ trợ điều này ngay bây giờ (có ai biết không?) Tôi thấy thông minh hoàn chỉnh của IntelliJ khá thông minh hơn một chút.

Tôi đã thử kiểm tra lại một tệp từ bản in (được viết bằng nhật thực) và thấy rằng tôi đã sử dụng ít hơn 30% phím và ít hơn 50% di chuyển chuột khi nhập tệp bằng IntelliJ (so với Eclipse). ở giữa.

Answer 11

Tôi thích phương pháp Extract (Alt +phím Shift +M), và kể từ 3.6M1, bây giờ nó xử lý các lựa chọn có chứa tiếp tục báo cáo.

Để duy trì ngữ nghĩa của mã hiện có, lựa chọn cần bao gồm câu lệnh cuối cùng của vòng lặp. Trong phương pháp chiết xuất, tiếp tục báo cáo được thay đổi để trở lại:

Extract method refactoring with continue http://download.eclipse.org/eclipse/downloads/drops/S-3.6M1-200908061400/images/extract-method-continue.png

Đối với một lựa chọn mà có thể cần nhiều giá trị lợi nhuận trong phương pháp chiết xuất, Eclipse tại liệt kê các biến mâu thuẫn trong thông báo lỗi:

Extract method refactoring with an ambiguous return value error http://download.eclipse.org/eclipse/downloads/drops/S-3.6M1-200908061400/images/extract-method-multiple-return-values.png

Answer 12

Cũng đáng đọc nghiên cứu này: How do API evolve? A story of refactoring. bởi D. Dig và R. Johnson.

Các tác giả nhận thấy rằng 80% thay đổi là tái cấu trúc và phân loại chúng. Đây là tóm tắt:

Khung và thư viện thay đổi API của chúng. Việc di chuyển ứng dụng sang API mới rất tẻ nhạt và phá vỡ quy trình phát triển . Mặc dù một số công cụ và ý tưởng đã được đề xuất để giải quyết sự phát triển của API, hầu hết các cập nhật đều được thực hiện thủ công.Để tốt hơn hiểu các yêu cầu đối với các công cụ di chuyển , chúng tôi đã nghiên cứu API thay đổi của bốn khung và một thư viện . Chúng tôi phát hiện ra rằng các thay đổi phá vỡ các ứng dụng hiện tại không phải là ngẫu nhiên, nhưng có xu hướng để rơi vào các danh mục cụ thể. Hơn 80% những thay đổi này là cấu trúc lại. Điều này gợi ý rằng các công cụ di chuyển dựa trên cấu trúc lại phải được sử dụng để cập nhật các ứng dụng.

Answer 13

"Nó cũng đáng đọc nghiên cứu này: Làm thế nào để phát triển API Một câu chuyện của refactoring bởi D. Dig và R. Johnson

Các tác giả nhận thấy rằng 80% của những thay đổi được tái cấu trúc và phân loại?.. Dưới đây là tóm tắt ... "

80% thay đổi BREAKING được quan sát là tái cấu trúc. Bản thân các cấu trúc lại chỉ được hình thành từ 20 - 30% thay đổi API ..