Làm cách nào để đi sâu vào mã không có một điểm nhập duy nhất?

Tôi làm việc trên các dự án Java doanh nghiệp không có một điểm nhập duy nhất từ ​​đó tôi có thể theo dõi luồng thực thi. Một số dự án có hàng trăm lớp và khi tôi được yêu cầu thêm một tính năng cho một dự án, tôi thường thấy mình không biết nên bắt đầu xem mã ở đâu.

Cách tốt nhất để đi sâu vào các dự án như vậy là để tôi có thể triển khai tính năng này một cách nhanh chóng mà không lãng phí thời gian.

Dự án có một bộ các bài kiểm tra đơn vị được duy trì tốt? Các bài kiểm tra đơn vị là tài liệu lập trình cho những gì mã làm.

Ngoài ra, bạn cần tìm hiểu đủ về kiến ​​trúc của ứng dụng để xác định các vị trí bạn cần chèn mã cho các tính năng mới của mình và ít nhiều bỏ qua phần còn lại. Bạn không cần phải biết toàn bộ cơ sở mã để làm điều này; nếu các dự án được kiến ​​trúc tốt, chức năng đã được đóng gói và tách rời đủ để bạn có thể tập trung vào các phần có liên quan. Nếu bạn may mắn, các dự án đã đi theo một kiến ​​trúc nổi tiếng sẽ đóng vai trò là bản đồ để bạn theo dõi.

Mã luôn có một hoặc nhiều điểm vào. Đối với các dự án MVC, điểm vào là một phương thức điều khiển dựa trên URL; phương thức này gần như chắc chắn sẽ truy cập vào kho lưu trữ dữ liệu và trả về một khung nhìn. Bắt đầu từ đó

Bắt đầu với tầng trung lưu (lớp logic nghiệp vụ).

Đó là một trong những nơi kiểm soát dành cho mọi hành động của người dùng hoặc kích hoạt sự kiện nếu đó là một ứng dụng không dựa trên giao diện người dùng. Nếu bạn đang ở chế độ gỡ lỗi, Bạn có thể theo dõi nó ở trên cùng và dưới cùng (rất có thể là lớp truy cập dữ liệu).

Đôi khi sẽ mất một chút nhưng đây là cách hiệu quả để nhảy vào các dự án không có giấy tờ.

Nếu dự án sử dụng bất kỳ khung công tác nào (struts-config.xml, ejb config xmls, spring config xmls) sẽ có một giao diện được xác định và bạn cũng có thể bắt đầu từ đó.

Luôn luôn có một điểm vào. Đối với các ứng dụng doanh nghiệp Java: các máy chủ, bộ lọc và trình nghe ngữ cảnh đứng đầu, chúng thường dẫn đến bootstrapping ứng dụng, ví dụ trình tải ngữ cảnh mùa xuân, sau đó dẫn vào bộ điều khiển, sau đó vào các thực thể và khung nhìn. Nó thực sự khá đơn giản, đặc biệt nếu một khung như lò xo, tấm thảm hoặc wicket được sử dụng. Khi bạn biết cách khung xử lý yêu cầu, bạn sẽ có thể xác định các điểm mở rộng bạn cần.

Tôi sẽ bắt đầu với một hệ thống phân cấp lớp. Nếu bạn có một công cụ tuyệt vời, nếu không, hãy tìm một công cụ có thể đảo ngược mã của bạn và tạo một công cụ cho bạn. Từ đó bạn có thể bắt đầu để xem mọi thứ có thể liên quan như thế nào. Một khi bạn có thể thấy mọi thứ có thể liên quan như thế nào, bạn ít nhất có thể nhắm mục tiêu vào các khu vực thay vì có một "hodgepodge" lớn của các lớp. Bạn có thể nhắm mục tiêu một khu vực mà bạn có thể thấy chúng được liên kết với nhau như thế nào (lớp này có phải là liên kết của vùng này không, đây có phải là tập hợp các lớp một mẫu thiết kế, v.v.). Cố gắng thêm một số thứ tự và cấu trúc xung quanh những gì bạn đang xem và sau đó chia nhỏ từng phần.

BIÊN TẬP:

Dưới đây là một số bài đăng từ ngăn xếp tràn ra ngoài các công cụ bạn có thể sử dụng trong nhật thực (hoặc dưới dạng các ứng dụng độc lập) để thiết kế ngược và tạo mô hình:

• /programming/51786/recommends-eclipse-plugins-to-generate-uml-from-java-code
• /programming/43344/is-there-some-tool-to-visualize-java- class-hierarchies-and-relations

"Làm thế nào để bạn ăn một con voi". "Một lần cắn một lần".

Điều này gần như không thể mở rộng dự án java của bạn nếu bạn không nhận được điểm vào và một tài liệu rõ ràng về những gì đã được thực hiện và tại sao.

FYI: Khi chúng tôi cung cấp một dự án cho khách hàng của chúng tôi, bây giờ chúng tôi tham gia một cách có hệ thống một mô hình UML cũng như tài liệu java và một tài liệu in. Chúng tôi tạo ra hàng trăm khung nhìn từ mô hình được hiển thị dưới dạng sơ đồ lớp. Chúng tôi thêm nhiều ý kiến ​​và giải thích kiến ​​trúc tĩnh cũng như các quy tắc và phương thức kinh doanh. Nếu khách hàng của chúng tôi muốn lấy mã của anh ấy và đưa nó cho một công ty khác, họ sẽ dễ dàng sửa đổi phần mềm hiện có không chỉ ở cấp triển khai mà còn ở cấp kiến ​​trúc. Sử dụng mạnh mẽ, đơn giản và tuyệt vời các chế độ xem UML động từ một mô hình duy nhất.

Phải nói rằng tôi biết rất ít nhà tích hợp quan tâm để cung cấp tất cả thông tin này bởi vì một khi khách hàng bị mắc kẹt thì tốt hơn là không để anh ta đi. Đưa ra mô hình đầy đủ và điều hướng UML động sẽ cho phép khách hàng độc lập và do đó điều này không tốt cho doanh thu kinh doanh. Tôi vẫn không hiểu tại sao các ngân hàng lớn, hoặc các công ty viễn thông lại ngây thơ đến mức bị mắc kẹt bởi các nhà tích hợp và không hỏi mô hình đầy đủ khi giao dự án? Mã java hoặc tài liệu in là không đủ. Các tài liệu in thường là một quá trình tự động. Nó không có giá trị thực sự để trích xuất thông tin từ mã để in hoặc cung cấp PDF.

Có những điểm vào LUÔN, bạn chỉ cần tìm chúng. Nếu đó là một ứng dụng hàng loạt theo lịch trình, có những nhiệm vụ được cấu hình ở đâu đó. Nếu đó là một ứng dụng web (sử dụng Spring) thì có ánh xạ và Bộ điều khiển. Nếu đó là một ứng dụng dịch vụ web, có các điểm cuối dịch vụ. Nếu đó là ứng dụng Xoay, có trình xử lý sự kiện hoặc somesuch. Và nếu đó là một ứng dụng dòng lệnh ol lông lớn, có một main()phương pháp.

Về "lặn nhanh" - tốt, mất bao lâu để tìm điểm vào là thực sự cá nhân. Nếu hệ thống được viết theo các mẫu đã thiết lập và bạn đã quen thuộc với các khung và các quy tắc và quy trình kinh doanh cơ bản - thì bạn sẽ có thể tìm ra chúng rất nhanh. Nếu không, nó có thể mất nhiều thời gian hơn. Nhưng không có "mánh khóe" phổ quát. Bạn tích lũy kinh nghiệm, bạn học cách nhận ra các mẫu và hiểu cách các khung được xây dựng và sắp xếp và bạn sẽ trở nên tốt hơn.

Về việc xử lý mã kế thừa:

• Cuốn sách từ Michael Feathers đưa ra một số thực tiễn tốt về cách tiếp cận phần mềm cũ.

Về lưu lượng thực hiện:

• Đó là một dự án mùa xuân, vì vậy mong đợi dòng điều khiển sẽ thực hiện các trò ảo thuật. Nó có thể thực hiện nhiều phương thức gọi bằng phản xạ hoặc thậm chí AOP. Cố gắng hiểu "dòng chảy thực thi" bằng cách sử dụng trình gỡ lỗi có thể gây ra sự thất vọng.
• Đó là một dự án mùa xuân, vì vậy cấu trúc của dự án khá đồng nhất. Tìm hiểu Spring (nếu bạn chưa có) để bạn hiểu các khái niệm về đậu và hệ thống dây điện. Điều này cho bạn biết những gì các lớp làm việc cùng nhau.

Về điểm vào:

• Hãy để tôi đoán: đó là một ứng dụng web. Hãy để tôi đoán lại: đó là sử dụng Spring MVC. Tìm hiểu cái này cũng vậy, để bạn biết cách tìm các lớp trình điều khiển cho các trang. Đây là những điểm vào ứng dụng của bạn. Có được gọi bằng phản xạ, vì vậy bạn sẽ không tìm thấy chúng bằng cách sử dụng phân tích tĩnh của mã nguồn.