Чи є термін для надмірного ускладнення ООП?

Рік-два тому я побачив чудову статтю про OOP (Java), де показали простий простий конкретний реєстратор з двох-трьох рядків коду та теоретичні надмірні процеси роздумів недосвідченого розробника, які в основному сказали о, я повинен додайте це у випадку, якщо ми колись цього захочемо! На кінець статті цей простий лісоруб був величезним сміттям, яке оригінальний розробник навряд чи міг зрозуміти сам ...

Чи існує загальний термін для цього виду надмірних ускладнень? Ця стаття (яку я дуже бажаю, щоб я могла знову знайти) показує цю концепцію чудово для окремого випадку, але я натрапив на цілі проекти, де розробники, по суті, запрограмували себе у вузол через надмірне використання шаблонів, рамок, бібліотек і інші питання. По-своєму, це так само погано (або навіть гірше), ніж застарілі програми для спагетті VB6, які ми успадковуємо для заміни.

Те, що я насправді шукаю, - це зробити це під час співбесіди. Я хочу знати, чи хтось усвідомлює і усвідомлює, як легко впасти в це, не маючи архітектури / попереднього планування (і отримати падіння, чи здається, що вони мають правильний баланс), але це насправді не щось Я можу знайти багато інформації про.

Найчастіший термін, який я чув для опису таких конструкцій, - це переобладнання . Первісне значення цього слова, однак, не пов'язаний з розробкою програмного забезпечення, а також за межами розробки програмного забезпечення має , ймовірно , не такий поганий тон.

На більш загальному рівні Жоель Спольський дав дизайнерам, які надмірно ускладнювали архітектурні конструкції назву " архітектури космонавтів ".

Однак, особливо для інтерв'ю, я вважаю, що важливіше знати, як називається навпаки, вкладаючи лише речі, які фактично потрібні, і забути про нездоровий підхід «на всякий випадок» - це називається принципом YAGNI .

Так, перепрофілювання - це найпростіший термін, який можна описати. Я бачив переобладнані, непотрібно складні конструкції більше разів, ніж я пам'ятаю протягом багатьох років. Багато років тому під час проходження курсу Microsoft GWBasic інструктор неодноразово забивав метод KISS (Keep it Simple Stupid). Це так само правда сьогодні, як і тоді.

Тому я завжди пам’ятаю KISS і завжди розробляю з урахуванням принципів ТВОРЕНИХ. Але, маючи на увазі, все-таки можливо переобладнати конструкцію з принципами SOLID, які повністю враховуються. Ви повинні збалансувати здоровий глузд, прагматичний підхід із прагненням бути чистою та дотримуватися загальноприйнятних вказівок OOP. Якщо вам достатньо часу і якщо ви любите створювати хитромудрі рішення, ви можете закінчити шлях проектування двигуна для скейтборду, тому що ви думали, що він згодом перетвориться на автомобіль. На щастя, я був досить дисциплінований, щоб цього не робити протягом багатьох років, але бачив це вже не раз.

Отже, підсумовуючи, щоб не допустити перевиконання коду:

1) KISS (Нехай це буде просто дурно)

2) Дотримуйтесь принципів SOLID, враховуючи практичність.

3) Не намагайтеся проектувати для кожної подій. І іноді невеликі протікаючі абстракції - це не жахливі речі, якщо вони поодинокі, навмисні, і якщо зусилля щодо їх запобігання значно переважають наслідки їх утримання.

4) Розгляньте реалізацію рішень під час їх проектування. Ви не можете просто сказати: "о, це деталь реалізації", і припустити, що ваш дизайн практичний. Раніше я працював з архітектором, який робив це часто, і на жаль, його проекти ніколи не працювали, і як результат, я більше не працюю там.

5) Код, як ніби ви той, хто збирається його підтримувати.

Отже, ви збираєтесь пройти це інтерв'ю, і ви маєте намір обманути кандидата показати те, що він знає про інженерію програмного забезпечення, а потім ви скажете: "Ні, ви, мабуть, хочете застосувати все, що знаєте, у своєму першому завданні, рухайтесь далі , ти, золото, що створюєш непрофесійний творець, що не має цінності! Шо!

Я думаю, було б безпечніше представити конкретний приклад та обговорити плюси та мінуси застосування певних моделей. Чим би ви вимагали відповідей на кшталт "Це залежить, чи хочеш це швидко? Чи все це буде? Наскільки складна проблема? Які схеми вже існують?" і ви можете самі чогось навчитися. Це також дозволить кандидату довести своє почуття контексту, тоді як це було б більш відкритим питанням. Очікування та бажаючи конкретної відповіді, у кращому випадку, ви отримаєте когось із тим самим найбільшим занепокоєнням, як і ваш. Якщо ви не отримаєте своєї відповіді, кандидат може просто вважати це беззахисним.