Cách tiếp cận tốt nhất trong việc kiểm toán một ứng dụng web java/j2ee lớn là gì

Question

Tôi phải kiểm tra một ứng dụng web Java/J2ee lớn đã phát triển qua một số năm. Nó được viết bởi một công ty khác, không phải là công ty tôi đang làm việc. Trong trạng thái hiện tại của nó đã trở nên khó phát triển và duy trì, các chức năng mới khó thêm và thường dẫn đến các lỗi mà đôi khi hiển thị trong sản xuất . Dường như có một số mã sao chép/dán đã dẫn đến sao chép mã. Ứng dụng hiện tại là một số loại hình mua sắm trực tuyến với một số nội dung giống như cms ở đây và ở đó. Nó chủ yếu là Struts và một số mùa xuân trong các phần mới của mã, có thể một số ejbs ném vào cho biện pháp tốt. Có một số bài kiểm tra đơn vị có sẵn, nhưng không có nhiều bài kiểm tra. Đây là những điều tôi đã được nói, tôi chưa thấy mã thực sự.

Công ty của tôi sẽ đề xuất viết lại các phần của ứng dụng này để giảm bớt sự phức tạp của , cải thiện chất lượng và mô đun, và giúp thêm các chức năng mới một cách dễ dàng. Trước khi thực hiện bất kỳ cam kết nào, họ muốn có một số đánh giá cao về chất lượng của mã hiện có và để xác định số lượng nó có thể được sử dụng lại, theo thứ tự để có nhiều hơn dự đoán về những gì sẽ có xong - viết lại toàn bộ hoặc một phần viết lại.

Bắt là tôi sẽ phải làm điều này trong một thời gian rất ngắn (một vài ngày) vì vậy tôi là cố gắng tìm ra kế hoạch cho những gì có thể được thực hiện trong một thời gian ngắn như vậy. Những gì tôi đang thiking là:

• check out "cơ bản" thứ - ngoại lệ xử lý, khai thác gỗ
• séc ra mức độ layering (lượt xem, điều khiển, lớp dao)
• đo độ che phủ thực tế của đơn vị kiểm tra
• có thể chạy một số Checkstyle, FindBugs và PMD so với các dự án
• ...

Vậy câu hỏi thực tế là những điều sh khác Tôi có tính đến/kiểm tra/đo lường/etc không?

Tôi không chắc chắn những gì loại số liệu mà tôi có thể nhận ra điều này và nếu nó thực sự có nghĩa là gì đó, tôi có cảm giác rằng những gì công tác quản lý là yêu cầu là loại phương pháp sai , vì vậy câu hỏi thứ hai sẽ là: có ai có ý tưởng tốt hơn không?

Tôi sẽ đánh giá cao bất kỳ ý tưởng, đề xuất, nhận xét về điều này.

Edit: Tôi sẽ có thêm hai máy dò mã chết để trộn: UCD và DCD

Answer 1

Tôi có hai ứng dụng web có cài đặt tương tự như bạn. Tôi đã ngừng sử dụng FindBugs và Checkstyle khi họ cho thấy hơn 10.000 điểm có vấn đề. Các ứng dụng đã sử dụng truy cập dữ liệu cấp JDBC, JSP để trình bày và một khung tùy chỉnh để gửi đi yêu cầu. May mắn cho tôi, những cài đặt cấp thấp này cho phép tôi thực hiện các phần mở rộng và sửa lỗi ở mức độ khó trung bình. Trong dự án 3 năm, chỉ có khoảng 20% ​​mã gốc vẫn giữ nguyên. Sớm hay muộn mọi thứ khác cần phải được thay đổi, thay thế hoặc loại bỏ (và cuối cùng tôi đã có thể sử dụng FindBugs và Checkstyle).

Chúng tôi cũng phải đối mặt với tình trạng khó xử của việc viết lại hoàn toàn. Tuy nhiên, có một số yếu tố chống lại nó:

• Không chắc chắn khách hàng sẽ trả tiền để viết lại hoàn toàn.
• Việc thiếu tài liệu kỹ thuật và chức năng khiến việc ghi đè hoàn toàn trở nên nguy hiểm.
• Manhours để hiểu đầy đủ ứng dụng hoàn chỉnh quá cao. Khách hàng muốn thay đổi được yêu cầu sớm hơn.
• Những người dùng đã tùy chỉnh cách trình bày và hành vi trang. Có vẻ như khó thuyết phục người dùng sử dụng giao diện mới cho các chức năng cũ.
• Nếu chúng tôi viết lại hoàn toàn, chúng tôi cần cung cấp tài liệu hoàn chỉnh. Để cập nhật, chúng tôi chỉ cần ghi lại phần của mình.
• Thật khó để thuyết phục quản lý (riêng và của khách hàng) viết lại nếu chương trình hoạt động (nhiều hơn hoặc ít hơn)
• Công ty có quy tắc PMD riêng và mã không vượt qua. Nó đã được đơn giản hơn để tranh luận rằng nó là đủ các bộ phận mới vượt qua bài kiểm tra.

Nó tóm tắt những gì bạn muốn thực sự làm.

Bạn có muốn viết lại, bất chấp sự phức tạp không?

• Đặt trọng tâm vào các lỗi mã. Biểu đồ tròn lớn với nhiều màu đỏ là thuyết phục.
• Giải thích các thuộc tính của chương trình và cách chúng không phù hợp với tầm nhìn của công ty.
• Hiển thị các tùy chọn nâng cao vượt quá các yêu cầu hiện tại và mô tả cách phiên bản hiện tại không đạt đến thử thách.
• Thực hiện các cuộc phỏng vấn với người dùng thực. Họ có thể chỉ ra các vấn đề quan trọng với phiên bản hiện tại.
• Là rẻ tiền nhưng là một ước tính tốt. Bạn có thể trì hoãn một số chi phí cho đến giai đoạn bảo trì.

Bạn không muốn viết lại?

• Đặt trọng tâm vào chi phí, đặc biệt là nhu cầu của khách hàng để kiểm tra lại mọi thứ.
• Chỉ ra sự cố tiềm ẩn của chức năng vi phạm.
• Yêu cầu người viết tài liệu toàn thời gian.

Nếu bạn muốn nếm thử mã, hãy thử thêm Hello World! chức năng/màn hình cho ứng dụng. Điều đó cho biết mức độ khó và tốc độ của bạn có thể thực hiện những điều mới.

Answer 2

Tôi thích danh sách của bạn khá nhiều. Tôi nghĩ bạn có một kế hoạch tấn công tuyệt vời để bắt đầu.

Tôi muốn xem xét để chuẩn hóa trên Spring hoặc EJB 3.0 nhưng không phải cả hai.

Tôi chưa đọc nó, nhưng tôi tự hỏi nếu cuốn sách của Michael Feathers "Working Effectively With Legacy Code" có ý tưởng hay không?

UPDATE:

lẽ bạn có thể giúp điều bằng cách đặt chúng trên một tự động xây dựng và tích hợp liên tục - Cruise Control, Hudson, hoặc Đội bóng thành phố. Nếu bạn phải làm bất kỳ refactoring nó sẽ giúp đỡ.

Answer 3

Bạn đang tập trung vào khả năng bảo trì và khả năng mở rộng được phát hiện.

Tôi sẽ thêm xem xét thời gian cần thiết để khởi động lại dự án. Họ có sử dụng kiểm soát nguồn không? Họ có môi trường riêng biệt để tích hợp và thử nghiệm chấp nhận của người dùng không? Có một máy chủ xây dựng?

Khi bạn phải chi tiêu hai tháng trước khi cải tiến đầu tiên, một người nào đó cần quản lý kỳ vọng của khách hàng trả trước.

Answer 4

Trong thực tế, họ sẽ không trả tiền cho một viết lại đầy đủ, bởi vì:

• Đó là suy thoái kinh tế, chi phí của bạn viết lại nó từ đầu sẽ cao

• Họ có thể cố gắng để bán công ty càng sớm càng tốt

• việc quản lý không hiểu gì về phát triển phần mềm

lần đầu tiên tôi sẽ đi với một số sự kiện đơn giản:

• Sử dụng một công cụ để hiển thị các SLOC của dự án
• Run as bạn lên kế hoạch FindBugs và cuối cùng PMD, chỉ để ước tính các khuyết tật
• Thực hiện hồ sơ nhanh chóng phiên
• Kiểm tra các lớp khác nhau
• Xem (kết nối Streams, Hibernate hay JDBC, vv) nếu nguồn lực thường đóng
• Xem nếu công nghệ được sử dụng khi họ không áp dụng (EJB, Web Services, vv)
• Xem cách họ xử lý các trường hợp ngoại lệ và đăng nhập
• Xem nếu có quá nhiều hoặc không đủ trừu tượng
• Xem nếu bạn có thể thêm một số lớp cơ sở để giảm việc lặp lại code

Cố gắng vẽ một biểu đồ nhanh về kiến trúc của ứng dụng, nếu chúng không cung cấp cho bạn một tài liệu về nó.

Thu thập một số số liệu thống kê và một số sự kiện, viết báo cáo và gửi báo cáo cho công ty. Họ sẽ muốn giảm thiểu chi phí và họ sẽ yêu cầu bạn tránh sửa mã không bị hỏng. Bạn bắt đầu với các thống kê, sau đó đến các sự kiện và một đề xuất với thời gian/tỷ lệ phần trăm gần đúng của mã bị ảnh hưởng/giá cả.

Thông thường các ứng dụng Struts cũ là một pita để duy trì, đã được thực hiện điều đó. Nếu nó không phải là một phần công việc của bạn, tôi sẽ nói để nó đi. Nếu bạn gặp các trang "độc lập" không liên quan đến nhiều mẫu và có thể thay đổi nhiều, đề xuất viết lại chúng bằng một số công nghệ khác.