Khi nào nên loại bỏ sự phức tạp?

Giới thiệu sớm sự phức tạp bằng cách thực hiện các mẫu thiết kế trước khi chúng là cần thiết không phải là thực hành tốt.

Nhưng nếu bạn tuân theo tất cả (hoặc thậm chí hầu hết) các nguyên tắc RẮN và sử dụng các mẫu thiết kế chung, bạn sẽ đưa ra một số phức tạp vì các tính năng và yêu cầu được thêm hoặc thay đổi để giữ cho thiết kế của bạn duy trì và linh hoạt khi cần.

Tuy nhiên, một khi sự phức tạp đó được giới thiệu và hoạt động như một nhà vô địch khi bạn loại bỏ nó?

Thí dụ. Tôi có một ứng dụng được viết cho một khách hàng. Khi ban đầu được tạo ra ở đó một số cách để tăng lương cho nhân viên. Tôi đã sử dụng mô hình chiến lược và nhà máy để giữ cho toàn bộ quá trình tốt đẹp và sạch sẽ. Theo thời gian các phương thức nâng nhất định trong đó được thêm hoặc xóa bởi chủ sở hữu ứng dụng.

Thời gian trôi qua và chủ sở hữu mới tiếp quản. Chủ sở hữu mới này là mũi cứng, giữ mọi thứ đơn giản và chỉ có một cách duy nhất để tăng lương.

Sự phức tạp cần thiết của mẫu chiến lược không còn cần thiết nữa. Nếu tôi mã hóa điều này từ các yêu cầu như hiện tại thì tôi sẽ không giới thiệu sự phức tạp thêm này (nhưng đảm bảo rằng tôi có thể giới thiệu nó với ít hoặc không có công việc nếu cần.

Vì vậy, tôi có loại bỏ việc thực hiện chiến lược bây giờ không? Tôi không nghĩ chủ sở hữu mới này sẽ thay đổi cách tăng giá. Nhưng chính ứng dụng đã chứng minh rằng điều này có thể xảy ra.

Tất nhiên đây chỉ là một ví dụ trong một ứng dụng mà chủ sở hữu mới tiếp quản và đã đơn giản hóa nhiều quy trình. Tôi có thể loại bỏ hàng tá lớp, giao diện và nhà máy và làm cho toàn bộ ứng dụng đơn giản hơn nhiều. Lưu ý rằng việc triển khai hiện tại chỉ hoạt động tốt và chủ sở hữu hài lòng với nó (và ngạc nhiên và thậm chí còn vui hơn khi tôi có thể thực hiện các thay đổi của cô ấy rất nhanh vì sự phức tạp được thảo luận).

Tôi thừa nhận rằng một phần nhỏ của sự nghi ngờ này là vì rất có thể chủ sở hữu mới sẽ không sử dụng tôi nữa. Tôi thực sự không quan tâm rằng ai đó sẽ đảm nhận việc này vì nó không phải là một công cụ tạo thu nhập lớn.

Nhưng tôi quan tâm đến 2 điều (liên quan)

1. Tôi quan tâm một chút rằng người bảo trì mới sẽ phải suy nghĩ kỹ hơn một chút khi cố gắng hiểu mã. Sự phức tạp là sự phức tạp và tôi không muốn chọc giận kẻ tâm thần đến sau tôi.

2. Nhưng thậm chí nhiều hơn tôi lo lắng về một đối thủ cạnh tranh nhìn thấy sự phức tạp này và nghĩ rằng tôi chỉ thực hiện các mẫu thiết kế để làm việc hàng giờ. Sau đó lan truyền tin đồn này để làm tổn thương doanh nghiệp khác của tôi. (Tôi đã nghe điều này được đề cập.)

Vì thế...

Nói chung, cần loại bỏ sự phức tạp trước đây mặc dù nó hoạt động và đã có một nhu cầu được chứng minh trong lịch sử về sự phức tạp nhưng bạn không có dấu hiệu nào cho thấy nó sẽ cần thiết trong tương lai?

Ngay cả khi câu hỏi trên thường được trả lời là "không", liệu có nên loại bỏ sự phức tạp "không cần thiết" này nếu giao dự án cho đối thủ cạnh tranh (hoặc người lạ) không?

Theo một số cách, tôi nghĩ rằng đây phần lớn là một quyết định kinh doanh và không nhất thiết phải dựa trên chính mã. Một số điều cần xem xét:

• Bạn có được trả tiền để thực hiện các thay đổi?
• Liệu mã hiện đang hoạt động như mong đợi?
• Có bất kỳ vấn đề bảo mật hoặc hiệu suất với mã như là?
• Liệu số nợ kỹ thuật có cao hơn chi phí sửa chữa nó không?
• Điều gì thực sự có khả năng xảy ra nếu bạn để lại mã như vậy?
• Các vấn đề trong tương lai có thể tăng lên có hoặc không có tái cấu trúc là gì?
• Bao nhiêu trách nhiệm là mã cho bạn và doanh nghiệp của bạn?

Bạn đang ở vị trí tốt nhất để trả lời những câu hỏi đó. Tuy nhiên, dựa trên mô tả của bạn, tôi không biết liệu tôi có phiền tái cấu trúc và đơn giản hóa mọi thứ không vì nó có vẻ đáng để bạn dành thời gian. Nếu nó hiện đang hoạt động, khách hàng rất vui và bạn không muốn được trả tiền cho việc cập nhật mọi thứ, sau đó hãy để nó hoạt động và hoạt động trên một hoạt động tạo doanh thu.

Tóm lại, thực hiện phân tích lợi ích chi phí và đánh giá rủi ro của cả hai con đường và thực hiện quá trình hành động an toàn nhất, hiệu quả nhất và có lợi nhất.

Không xóa mã này và thay thế nó bằng một cái gì đó đơn giản để dễ dàng mã hóa một tính năng mà khách hàng cần xem xét và trả tiền?

Bạn có thể có một cái gì đó hữu ích mà một nhà phát triển khác có thể học hỏi, nhưng khả năng tìm thấy ứng dụng của khách hàng khác để cắm nó vào, không có khả năng.

Tin đồn về mã của đối thủ cạnh tranh không phải là thứ bạn có thể ngăn chặn. Họ sẽ trông thật ngu ngốc khi cố gắng tuyển dụng khách hàng một cách tiêu cực.

Một câu nói phổ biến là: "Nếu nó không bị hỏng, đừng sửa nó".

Có một số lý do đằng sau quy tắc này. Một số trong số đó có thể là "đơn giản hóa" sẽ có nguy cơ đưa ra các lỗi mới, khác biệt và có thể lớn hơn, có thể mất một khoảng thời gian phát triển xa các nỗ lực có giá trị khác và có thể là sự thay đổi hoàn toàn cho một số cơ hội kinh doanh bất ngờ trong tương lai. phát sinh.

Nếu có đủ giá trị kinh doanh để mã này có thể mang theo và dễ bảo trì hơn, thì hãy quyết định xem giá trị đó có thực sự đủ để xem xét mã hiện tại "bị hỏng" hay không. Cũng có thể, nếu có một kế hoạch mở rộng kinh doanh lớn, hoặc bạn nghi ngờ một lỗi tiềm ẩn ẩn trong sự phức tạp có thể làm giảm hoạt động kinh doanh.

Trước hết, nếu ứng dụng đã được chủ sở hữu mới tiếp quản một lần, nó có thể xảy ra lần nữa. Và chủ sở hữu tiếp theo có thể lại bắt đầu sử dụng sự phức tạp đó không được hưởng lợi từ lúc này.

Ngoài ra, những thay đổi không hề nhỏ đối với mã làm việc luôn gây ra rủi ro, do đó (như những người khác lưu ý) khách hàng nên đồng ý (và trả tiền) cho chúng. Nếu độ phức tạp "thêm" hiện tại không gây ra bất kỳ nhược điểm đáng chú ý nào, có thể đo lường được (chẳng hạn như các vấn đề về hiệu suất), không có lý do mạnh mẽ nào để loại bỏ nó.

(Tiềm năng) những khách hàng (không) thuê bạn chỉ dựa trên tin đồn của đối thủ cạnh tranh là IMHO không có giá trị nào, trừ khi bạn đang có nhu cầu thu nhập tuyệt vọng. Bạn có lý do chính đáng và hợp lý tại sao bạn triển khai ứng dụng theo cách bạn đã làm và bất kỳ khách hàng nghiêm túc nào cũng có thể hiểu điều đó. Một người không - hoặc thậm chí không buồn hỏi bạn về - có thể sẽ gây ra cho bạn nhiều rắc rối hơn trên đường đi so với giá trị của công việc.

Nói chung, cần loại bỏ sự phức tạp trước đây mặc dù nó hoạt động và đã có một nhu cầu được chứng minh trong lịch sử về sự phức tạp nhưng bạn không có dấu hiệu nào cho thấy nó sẽ cần thiết trong tương lai?

Không.

Ngay cả khi câu hỏi trên thường được trả lời là "không", liệu có nên loại bỏ sự phức tạp "không cần thiết" này nếu giao dự án cho đối thủ cạnh tranh (hoặc người lạ)

Không. Tại sao phải lãng phí thời gian của bạn để sửa chữa các công việc ưu tiên thấp như thế này? Không có hại cho mã ở đó.

Đối với câu hỏi của bạn: Khi nào nên loại bỏ sự phức tạp?

Tôi nghĩ là, nếu nó không bị hỏng, đừng sửa nó .

Để có thể loại bỏ sự phức tạp, điều sau đây phải đúng:

1. Các phần bị loại bỏ phải độc lập với chương trình. Nếu có bất kỳ sự phụ thuộc nào từ chương trình xung quanh vào mã được đề cập, chỉ cần loại bỏ sự phức tạp sẽ không hoạt động
2. Thật không may, nếu nó có vẻ phức tạp, thì rất có thể các phần đó không độc lập và các phần phụ thuộc sẽ phá vỡ chương trình của bạn khi bạn xóa phần đó
3. Loại bỏ tất cả các phụ thuộc sẽ mất thời gian, do đó thời gian cần được xem xét khi bạn ước tính nếu hoạt động có đáng nỗ lực
4. Hầu hết thời gian không đáng để bỏ công sức, nhưng bạn sẽ quyết định không làm cho bất kỳ mã mới nào sử dụng mã cũ

Tôi nghĩ rằng có một cái gì đó lớn hơn tại nơi làm việc ở đây ... Khả năng mở rộng

Những gì bạn đang nói về được gọi là Khả năng mở rộng . Việc mã hóa có phức tạp hay không không quan trọng, liệu ứng dụng có thể phát triển dựa trên các quy tắc kinh doanh mới hay thay đổi quy tắc kinh doanh hay không. Điều gì xảy ra nếu chủ sở hữu tiếp theo muốn một cái gì đó hoàn toàn khác.

Vì vậy, tôi nói giữ mã và tài liệu nó. Đây là một tính năng về cách ứng dụng có thể được sử dụng.

Nói chung, cần loại bỏ sự phức tạp trước đây mặc dù nó hoạt động và đã có một nhu cầu được chứng minh trong lịch sử về sự phức tạp nhưng bạn không có dấu hiệu nào cho thấy nó sẽ cần thiết trong tương lai?

Có một nỗ lực và rủi ro để loại bỏ sự phức tạp. Nếu đó là cao hơn nỗ lực thêm và rủi ro duy trì mã quá phức tạp, thì bạn giữ nó. Nếu không, bạn loại bỏ nó. Tuy nhiên, thật khó để ước tính những rủi ro đó.

Tôi sẽ nói thêm rằng bạn có thể giảm thiểu rủi ro bảo trì khó khăn hơn bằng cách ghi lại lý do tại sao bạn sử dụng Chiến lược mẫu thiết kế ở vị trí đầu tiên, trong mã. Cá nhân tôi tin rằng bất kỳ mẫu thiết kế nào cũng có thể truy nguyên theo yêu cầu rõ ràng (chức năng hoặc không chức năng).

Ngay cả khi câu hỏi trên thường được trả lời là "không", liệu có nên loại bỏ sự phức tạp "không cần thiết" này nếu giao dự án cho đối thủ cạnh tranh (hoặc người lạ) không?

Kịch bản của bạn về việc bị loại bỏ bởi cạnh tranh trong giờ đệm chính xác là lý do tại sao bạn nên ghi lại sự phức tạp. Nếu bạn ghi lại và chứng minh (với một yêu cầu cụ thể của khách hàng) việc sử dụng bất kỳ mẫu nào, thì bạn sẽ được bảo vệ. Nếu bạn không thể biện minh cho một mẫu với yêu cầu của khách hàng, thì nó có vẻ như quá mức hoặc viêm mẫu.

Nếu các yêu cầu thay đổi, thì bạn có thể biện minh cho việc rời bỏ nó vì rủi ro là bạn có thể phá vỡ mã (hoặc số lượng công việc để phẫu thuật loại bỏ mẫu).

Tôi nghĩ thật tốt khi phân biệt giữa độ phức tạp ngẫu nhiên và độ phức tạp thiết yếu , vì các mẫu thường liên quan đến cả hai.

Đó là, yêu cầu của bạn để hỗ trợ các thuật toán khác nhau để quyết định tăng là một sự phức tạp thiết yếu (một phần của vấn đề cần giải quyết). Việc duy trì mã của bạn được thực hiện dễ dàng hơn bởi mẫu Chiến lược, nhưng mã hóa cứng nếu / sau đó thay thế cho Chiến lược sẽ vẫn hoạt động. Tôi đã thực hiện các bài tập trong các khóa học thạc sĩ của mình, nơi sinh viên tìm thấy cơ hội để áp dụng Chiến lược trong các dự án nguồn mở. Độ phức tạp không nhất thiết phải tốt hơn / tệ hơn khi áp dụng Chiến lược (vì đó là độ phức tạp thiết yếu ). Đôi khi có thể khó hiểu hơn về Chiến lược, bởi vì mã được chia thành nhiều lớp với tính đa hình, thay vì một khối lớn nếu / sau đó / khác.

Lý tưởng nhất, một mô hình hoạt động khi những lợi ích mà nó cung cấp lớn hơn chi phí cho những nhược điểm của nó. Một lần nữa, định lượng những điều này là khó khăn. Thường thì một mẫu làm cho nhà phát triển hài lòng (không chỉ vì nó làm cho việc thêm một chiến lược nâng cao mới dễ dàng hơn, mà còn cho nó các nhà phát triển ấm áp để biết rằng một mẫu đã được áp dụng). Thật khó để cho khách hàng thấy nó mang lại lợi ích cho họ như thế nào.

Khách hàng không quan tâm hoặc thậm chí không hiểu các chi tiết. Trong trường hợp chủ sở hữu mới áp dụng KISS trong các quy trình của mình, đó là việc cô ấy giảm bớt sự phức tạp thiết yếu , điều này cũng sẽ ảnh hưởng đến giải pháp phần mềm.