Sử dụng các mẫu khác nhau cho các tính năng tương tự

10

Tôi là nhà phát triển duy nhất trong một dự án, giống như đối với bất kỳ dự án phần mềm nào, có thể được thực hiện bởi người khác trong tương lai.

Giả sử tôi đã sử dụng mẫu X để triển khai tính năng A. Sau khi phát triển và hoàn thiện tính năng này, tôi nhận ra rằng tôi có thể triển khai tính năng tương tự bằng cách sử dụng mẫu Y mà tôi vừa tìm hiểu. Nhưng tính năng A đang hoạt động tốt và việc tái cấu trúc từ X thành Y tốn nhiều thời gian và mang lại rất ít lợi ích.

Sau đó, đã đến lúc triển khai tính năng B. Nó tương tự như A, nhưng lần này tôi muốn nhân cơ hội này để chơi với mẫu Y. Tôi hài lòng về kết quả cuối cùng, tốt hơn so với khi thực hiện tính năng A, nhưng bây giờ mã của tôi sử dụng hai các mẫu khác nhau, X và Y, cho các tính năng tương tự.

Nhưng không có lý do thực sự để sử dụng các mẫu khác nhau, ngoại trừ thực tế là khi xây dựng tính năng AI không đủ kỹ năng để sử dụng cùng một mẫu như cho tính năng B.

Lưu ý rằng câu hỏi này không phải là về việc chọn đúng mẫu cho một vấn đề nhất định ; đó là về hai mẫu cùng tồn tại trong cơ sở mã để giải quyết các vấn đề tương tự, có thể giảm xuống còn một thời gian đủ để tái cấu trúc.

Là mã đó mùi?
Những bất lợi của việc giữ mã nguồn như thế này là gì?
Tôi có nên chỉ sử dụng một mẫu? tức là tái cấu trúc A để sử dụng Y hoặc tiếp tục sử dụng X khi viết B?
Làm thế nào, trong nguồn, tôi có thể truyền đạt rằng lý do tại sao có hai mẫu khác nhau cho các tính năng tương tự về cơ bản là không có lý do?
Tôi có lo lắng quá nhiều về những gì nhà phát triển tiếp theo nghĩ về mã của tôi không?

design-patterns refactoring documentation

— ris8_allo_zen0
nguồn

Có thể trùng lặp với việc chọn đúng mẫu thiết kế

— gnat

7

Nếu mẫu X và Y giải quyết cùng một vấn đề và không khách quan hơn, thì bạn nên quyết định chọn một mẫu và bám sát nó. Nếu có thể, bạn nên cố gắng giải quyết cùng một vấn đề theo cùng một cách nhất quán.

Bạn không phải lo lắng quá nhiều, thay vào đó là một mùi mã nghiêm trọng mà bạn chắc chắn nên xử lý và dọn dẹp.

Nhược điểm của việc có các giải pháp khác nhau cho cùng một vấn đề trong một cơ sở mã:

Sẽ mất gấp đôi thời gian để hiểu mã
Sẽ mất gấp đôi thời gian để sửa đổi mã khi bạn thay đổi một số hành vi liên quan đến mẫu
bạn sẽ có gấp đôi số lỗi
đồng nghiệp hiện tại và tương lai sẽ ghét bạn

— JacquesB
nguồn

2

Tôi đồng ý với câu trả lời của JacquesB . Tôi sẽ bổ sung, giải quyết các câu hỏi khác của bạn, rằng nếu ngay bây giờ bạn có hai mẫu cùng tồn tại và chưa có thời gian (chưa) để cấu trúc lại ứng dụng của bạn để sử dụng ứng dụng bạn thấy là tốt nhất, bạn nên đặt rằng trong các bình luận của bạn trong lớp "vi phạm" (lớp được tái cấu trúc). Bằng cách này, rõ ràng với nhà phát triển trong tương lai (bạn hoặc ai đó) rằng vẫn còn một số nợ phải trả.

Cuối cùng, nhược điểm chính của việc duy trì một cơ sở mã như thế này là sự phức tạp được thêm vào, nhưng không cần thiết. Bạn chắc chắn muốn tránh sự phức tạp không cần thiết bằng mọi giá!

— carlossierra
nguồn

Tôi muốn thấy điều này trong một số loại danh sách việc cần làm hoặc ít nhất là ngoài một ghi chú trong mã.

— JeffO

@JeffO Tôi đồng ý. Mặc dù chỉ dựa vào danh sách việc cần làm không phải là không có vấn đề gì thêm, vì hầu hết các lần này là cá nhân (không được chia sẻ), ngược lại với nhận xét bên trong cơ sở mã được chia sẻ. Nhưng một lần nữa, tôi đồng ý và có thể có một ý tưởng tốt để có cả hai (khi chúng chắc chắn không thể tránh được để bắt đầu).

— carlossierra

Đó là một điểm hay. Nó nên là một cái gì đó nhiều hơn một danh sách Todo đơn giản để bao gồm chia sẻ, cộng tác, giao tiếp và tất cả những thứ thú vị khác;

— JeffO

1

Đừng chơi trong codebase. Viết nguyên mẫu để bạn có thể tìm thấy những lợi thế và sự biến mất của một mẫu / thiết kế so với (các) mẫu khác.

Nó có thể chỉ ra rằng những gì trực giác cảm thấy có thể giảm đi, thực sự có thể phức tạp hơn so với việc có 2 mẫu khác nhau.

Dự kiến sẽ ném một cách nhiều mã được phát triển cho nguyên mẫu.

— Nam tước Robert
nguồn

1

Đây có phải là mùi mã hay không thực sự phụ thuộc vào vấn đề A và vấn đề B tương tự như thế nào. Câu trả lời của JacquesB dường như cho rằng chúng rất giống nhau và nếu bạn thay đổi vấn đề A (để sửa lỗi chẳng hạn), bạn cũng sẽ phải thay đổi vấn đề B cùng một lúc. JaqueB có thể đúng, nhưng cũng có thể là trường hợp A và B thay đổi độc lập vì chúng không giống nhau. Trong tình huống đó, bạn không thể có những nhược điểm được mô tả.

Dựa trên mô tả của bạn, nó nghe có vẻ hơi mùi mã (Sao chép) nhưng thật khó để biết mùi hôi thối như thế nào. Chẳng hạn, nếu A sử dụng Phương thức mẫu và B sử dụng Chiến lược, hai vấn đề có thể rất khác nhau mặc dù các mẫu phản chiếu đang được sử dụng. Tôi sẽ chờ đợi và xem cách tiếp cận. Trong trường hợp có vấn đề với C và nó giống như A và B, thì tôi đã cấu trúc lại A để phù hợp với B và sau đó tạo C sẽ rất đơn giản. Nếu có lỗi trong A, tôi cũng muốn cấu trúc lại nó để khớp với B, sau đó sửa lỗi. Trong trường hợp không có gì thay đổi thì nó không thành vấn đề?

Có nhiều cách để giải quyết các vấn đề tương tự trong một cơ sở mã là một thực tế của cuộc sống. Ngay cả trong trường hợp bạn là nhà phát triển duy nhất, bạn sẽ học những điều mới và có những hiểu biết mới, vì vậy các giải pháp của bạn sẽ thay đổi. Khi bạn nhận ra chính xác, bạn cần sửa chữa những khiếm khuyết này trong khi cung cấp giá trị. Thiết kế lại (đó là những gì bạn thực sự làm khi bạn thay đổi một mẫu) mã sẽ không bao giờ thay đổi nữa không cung cấp giá trị. Cách thực sự duy nhất để biết nó sẽ thay đổi là thực sự phải thực hiện thay đổi, đó là lý do tại sao tôi chờ đợi một vấn đề C.

— Eric Smith
nguồn

1

Không, bạn có thể có nhiều mẫu được sử dụng trong một cơ sở mã.

Tuy nhiên, nếu bạn đang triển khai một thành phần và bạn đang tiết lộ một cách sử dụng nó theo một mẫu, thì có lẽ tốt nhất là bạn nên sử dụng một thành phần. Ví dụ, giả sử tôi đang sử dụng mẫu trình xây dựng cho máy khách truy vấn REST của mình, nhưng sau đó tôi triển khai một trong các tài nguyên khác nhau. Điều đó sẽ gây nhầm lẫn cho mọi người.

— Ewan
nguồn