Có một thuật ngữ cho sự phức tạp quá mức của OOP?

Một hoặc hai năm trước tôi đã thấy một bài viết xuất sắc về OOP (Java), trong đó cho thấy sự tiến triển của một trình ghi nhật ký cụ thể đơn giản gồm hai hoặc ba dòng mã, và một quá trình suy nghĩ quá mức về mặt lý thuyết của nhà phát triển thiếu kinh nghiệm về cơ bản đã nói rằng , tôi nên nói thêm điều này trong trường hợp chúng ta muốn điều đó Đến cuối bài viết, bộ ghi chép đơn giản này là một đống rác khổng lồ mà nhà phát triển ban đầu khó có thể hiểu chính mình ...

Có một thuật ngữ chung cho loại biến chứng quá mức này? Bài báo đó (mà tôi rất mong muốn tôi có thể tìm lại) cho thấy khái niệm tuyệt vời cho một trường hợp bị cô lập, nhưng tôi đã bắt gặp toàn bộ các dự án nơi các nhà phát triển đã tự lập trình thành một nút thắt bằng cách sử dụng quá mức các mẫu, khung, thư viện và các vấn đề khác. Theo cách riêng của mình, điều này là xấu (hoặc thậm chí tệ hơn) so với các ứng dụng spaghetti VB6 cũ mà chúng tôi thừa kế để thay thế.

Điều tôi thực sự tìm kiếm là đưa vấn đề này lên khi phỏng vấn. Tôi muốn biết liệu ai đó có nhận thức và ý thức được việc rơi vào tình trạng này dễ dàng như thế nào khi thiếu kiến ​​trúc / quy hoạch trước (và cảm thấy liệu họ có cân bằng chính xác không), nhưng đó không thực sự là một điều gì đó Tôi có thể tìm thấy rất nhiều thông tin trên.

Thuật ngữ thường xuyên nhất tôi nghe để mô tả các thiết kế như vậy là quá mức . Các ý nghĩa gốc của từ đó, tuy nhiên, không liên quan đến phát triển phần mềm, và bên ngoài phát triển phần mềm nó có lẽ không phải là một giai điệu xấu như vậy.

Ở cấp độ tổng quát hơn, Joel Spolsky đã đặt cho các nhà thiết kế những người thiết kế kiến ​​trúc quá mức với cái tên " phi hành gia kiến ​​trúc ".

Tuy nhiên, đặc biệt đối với một cuộc phỏng vấn, tôi nghĩ điều quan trọng hơn là phải biết những gì ngược lại, chỉ đưa những thứ vào một thiết kế thực sự cần thiết và quên đi cách tiếp cận "chỉ trong trường hợp" không lành mạnh - đây được gọi là nguyên tắc YAGNI .

Vâng, áp đảo là thuật ngữ đơn giản nhất để mô tả điều này. Tôi đã thấy các thiết kế quá phức tạp, phức tạp không cần thiết nhiều lần hơn tôi có thể nhớ trong những năm qua. Nhiều năm trước, khi tham gia khóa học Microsoft GWBasic, người hướng dẫn đã liên tục thực hiện phương pháp KISS (Giữ cho nó đơn giản ngu ngốc). Điều này đúng như ngày hôm nay.

Vì vậy, tôi luôn ghi nhớ KISS và luôn thiết kế với các Nguyên tắc RẮN trong tâm trí. Nhưng với điều đó đã được nói, vẫn có thể áp đảo một thiết kế với các nguyên tắc RẮN được xem xét đầy đủ. Bạn phải cân bằng một cách tiếp cận thông thường, thực dụng với mong muốn được thuần khiết và tuân thủ các nguyên tắc OOP thường được chấp nhận. Nếu có đủ thời gian và nếu bạn thích tạo ra các giải pháp phức tạp, bạn có thể đi xuống con đường thiết kế một động cơ cho ván trượt vì bạn nghĩ rằng cuối cùng nó sẽ được biến thành một chiếc xe hơi. May mắn thay, tôi đã đủ kỷ luật để không làm điều này trong những năm qua, nhưng tôi đã thấy nó nhiều lần.

Vì vậy, để tóm tắt, để ngăn chặn quá mức mã hóa:

1) KISS (Giữ cho nó đơn giản ngu ngốc)

2) Thực hiện theo các nguyên tắc RẮN với tính thực tiễn trong tâm trí.

3) Đừng cố gắng thiết kế cho mọi tình huống. Và đôi khi nhỏ, trừu tượng rò rỉ không phải là những điều khủng khiếp, nếu chúng bị cô lập, có chủ ý và nếu nỗ lực ngăn chặn chúng vượt xa những tác động của việc giữ chúng.

4) Xem xét việc thực hiện các giải pháp trong khi thiết kế chúng. Bạn không thể chỉ nói, "ồ, đó là một chi tiết triển khai" và cho rằng thiết kế của bạn là thực tế. Tôi đã từng làm việc với một kiến ​​trúc sư đã làm việc này thường xuyên, và than ôi, các thiết kế của anh ta không bao giờ hoạt động, và kết quả là, tôi không làm việc ở đó nữa.

5) Mã như thể bạn là người sẽ duy trì nó.

Vì vậy, bạn sẽ có cuộc phỏng vấn này và bạn có ý định lừa ứng viên hiển thị những gì anh ta biết về công nghệ phần mềm và sau đó bạn sẽ nói "Nah, có lẽ bạn muốn áp dụng tất cả những gì bạn biết trong bài tập đầu tiên của mình, hãy chuyển ngay bây giờ , bạn mạ vàng quá kỹ thuật tạo ra giá trị phi kinh doanh! Shoo! "

Tôi nghĩ sẽ an toàn hơn nếu trình bày một ví dụ cụ thể và loại bỏ các ưu và nhược điểm của việc áp dụng các mẫu nhất định. Hơn bạn sẽ được mời chào cho các câu trả lời như "Nó phụ thuộc, bạn có muốn nó nhanh không? Đây có phải là tất cả không? Vấn đề phức tạp đến mức nào? Những mô hình nào đã được áp dụng?" và bạn có thể tự học một cái gì đó. Điều này cũng sẽ cho phép ứng viên chứng minh ý thức về bối cảnh của mình trong khi đó sẽ là một câu hỏi cởi mở hơn. Chờ đợi và muốn có một câu trả lời cụ thể sẽ giúp bạn có được mối quan tâm lớn nhất giống như bạn. Nếu bạn không nhận được câu trả lời của mình, đó có thể là ứng cử viên chỉ coi đó là một người không có trí tuệ.