2008-10-21 28 views
8

Tôi đã thấy chủ đề này hiện diện nhiều hơn một lần. Tôi hy vọng rằng những người ở đây hiện đang ở trong tình huống tương tự hoặc đã từng trong quá khứ có thể đưa ra một số lời khuyên sâu sắc. Nó có thể hữu ích nếu bạn chia sẻ kinh nghiệm quá khứ của bạn là tốt.Logic nghiệp vụ xâm nhập UI trong ứng dụng winforms lớn

Vì vậy, có các cửa sổ khá lớn này tạo ra ứng dụng đã được phát triển qua nhiều năm. Mặc dù nhóm phát triển đã cố gắng tách logic nghiệp vụ khỏi giao diện người dùng, nhưng điều đó không xảy ra và có rất nhiều lĩnh vực của mã nơi logic kinh doanh được kết nối với giao diện người dùng. Trong thực tế tàn dư của những nỗ lực trước đó để áp dụng kiến ​​trúc MVP có thể được nhìn thấy ở rất nhiều nơi. Cũng có các bài kiểm tra đơn vị nhưng với mức độ bảo hiểm mã tương đối thấp. Có một số điểm nóng tuy nhiên - các khu vực mà mọi người đều biết đã nhận được phức tạp hơn mà họ nhất thiết cần phải được.

Rất nhiều lần lỗi có thể bị phát hiện trước đó chỉ được tìm thấy khi Người thử nghiệm lấy đèn đuốc của họ và thực sự bắt đầu tìm lỗi mà không may là quá muộn, tốn kém và nguy hiểm. Kỹ thuật, người kiểm tra và PM - tất cả nhận ra rằng một cái gì đó cần phải được thực hiện.

Cách nào là cách thiết thực nhất để giải quyết hoàn cảnh, hoặc cải thiện tình hình? Vì nó sẽ là một nhiệm vụ lâu dài, cách tốt nhất để đo lường tiến độ hướng tới mục tiêu là gì? Mục tiêu sẽ được xác định như thế nào trong các điều kiện khách quan để bắt đầu?

+0

BTW,> 100K LOC không lớn. > 1M LOC là rất lớn !! –

+0

Xóa số đề cập đến số để làm cho câu hỏi này liên quan đến nhiều người hơn :) – Sid

Trả lời

0

Có vẻ như một ứng dụng điển hình đối với tôi.

+0

Đó là một sự phản ánh đáng buồn của ngành công nghiệp mà điều này đã gây ra cho tôi một tiếng cười. – moffdub

5

Bạn cần phải nghiên cứu lại lớp kinh doanh và sau đó nối giao diện người dùng trở lại lớp kiến ​​trúc này.
Bạn giữ giao diện người dùng hiện tại và logic kinh doanh có sẵn trong khi thực hiện việc này và chuyển đổi sang một biểu mẫu mới cùng một lúc.

Điều này có nghĩa là cho phép bạn thêm tất cả các bài kiểm tra đơn vị và công cụ kiểm tra tự động mà bạn cần trong khi các hiệu ứng nhỏ. Bạn cũng có thể đảm bảo rằng các thành phần của bạn đang làm những gì họ cần để làm đúng.

Về cơ bản, đó là một chặng đường dài với lợi tức đầu tư hạn chế trong ngắn hạn nhưng với lợi ích tiềm năng lớn trong thời gian trung bình đến dài (thực sự là dài).

1

Có vẻ như bạn có một thách thức khá lớn trước bạn!

Trong điều kiện rộng nhất, tôi nghĩ bạn phải bắt đầu bằng cách làm việc với nhóm của bạn để xác định chính xác những gì bạn cho là chấp nhận được và những gì không thể chấp nhận được.

Theo kinh nghiệm của tôi, một mức độ logic kinh doanh nhất định (chẳng hạn như xác thực) phải nằm trong giao diện người dùng (mặc dù nó cũng phải được thực thi trong lớp nghiệp vụ).

Một khi bạn có một định nghĩa rõ ràng về những gì có thể chấp nhận được và những gì không, nó phải là một nhiệm vụ tương đối cơ khí (mặc dù khó khăn) để liệt kê các vi phạm trong dự án.

Điều đó sẽ cho bạn một dấu hiệu rõ ràng về quy mô của vấn đề - và thực sự là nơi duy nhất bạn có thể bắt đầu hợp lý nếu bạn định giải quyết nó theo bất kỳ cách nào có thể đo lường được.

2

"Logic nghiệp vụ xâm nhập giao diện người dùng" ... Tôi thích lựa chọn từ.

  • Đầu tiên và trước hết, hãy lấy mã vùng phủ sóng với các bài kiểm tra đơn vị.
  • Sau đó, xem lại cuốn sách Refactoring của Martin Fowler.
  • Áp dụng chuỗi dài Extract Class cấu trúc lại để tạo thành lớp tên miền. Sau mỗi lần, chạy lại các bài kiểm tra đơn vị của bạn để đảm bảo bạn có các thanh màu xanh lục.
  • Khi bạn hài lòng với mã mới, hãy xóa nội dung cũ.
  • Cuối cùng, bạn sẽ muốn Introduce Controller.

Tất nhiên, một phần khó khăn sẽ là đơn vị kiểm tra giao diện người dùng. Bạn có thể phải đầu tiên Extract Method trong giao diện người dùng để kiểm tra đơn vị các bit của logic nổi xung quanh trong đó, và sau đó làm theo các bước ở trên.

3

Sản phẩm có lợi nhuận như thế nào? Nhóm lớn bao nhiêu?

Những câu hỏi này sẽ là điểm bắt đầu của bạn để có giải pháp. Nhóm càng có nhiều lợi nhuận và càng lớn thì bạn sẽ có thể tái cấu trúc mã nhanh hơn thành một dạng mới hơn.

Nhưng với các dự án lớn thường có nhiều rủi ro với những thay đổi đối với mã. Phải có những khu vực "chỉ làm việc" mà chưa được xem xét trong nhiều năm. Bắt lỗi trong các lĩnh vực này sẽ là một thách thức lớn. Nó sẽ mất một lúc để có được bánh răng của bạn quay để thậm chí gỡ lỗi các khu vực này.

Mặc dù tôi phải nghiên cứu mã chi tiết. Khi bạn thực sự chắc chắn bạn biết nó lạnh, đưa ra một bài thuyết trình cho những người khác có kiến ​​thức trong cơ sở mã. Điều này sẽ chỉ ra lô mã tiếp theo mà bạn nghĩ bạn biết nhưng không. Khi mã bắt đầu đi sâu vào đầu bạn, hình ảnh rõ ràng và rõ ràng hơn về những gì cần thiết sẽ xuất hiện trong đầu bạn. Sau đó, bạn đã sẵn sàng lập kế hoạch cho bước đầu tiên. Làm cho nó một cái gì đó hợp lý và không cắn quá nhiều.

Trên tất cả, hãy học và vui chơi. Việc làm lại một dự án lớn có thể khá thú vị miễn là bạn có thái độ đúng đắn.

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