Есть ли термин для чрезмерного осложнения ООП?

Год или два назад я увидел отличную статью об ООП (Java), в которой рассказывалось о прогрессировании простого конкретного регистратора из двух или трех строк кода, а также о теоретическом чрезмерном мышлении неопытного разработчика, который в основном сказал: « О, я должен добавьте это на случай, если мы когда-нибудь захотим этого! К концу статьи этот простой регистратор стал гигантским мусором, который первоначальный разработчик едва мог понять сам ...

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

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

Самый частый термин, который я слышал для описания таких конструкций, - это чрезмерная инженерия . Однако первоначальное значение этого слова не связано с разработкой программного обеспечения, и за пределами разработки программного обеспечения оно, вероятно, не так уж плохо.

На более общем уровне Джоэл Спольски дал дизайнерам, которые слишком усложняют архитектурные проекты, название « астронавты архитектуры ».

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

Да, сверхинжиниринг - самый простой термин для описания этого. Я видел сверхмощные, излишне сложные конструкции больше раз, чем помню за эти годы. Много лет назад, проходя курс Microsoft GWBasic, преподаватель неоднократно вбивал метод KISS (Keep it Simple Stupid). Сегодня это так же верно, как и тогда.

Поэтому я всегда помню KISS и всегда проектирую с твердыми принципами . Но с учетом вышесказанного все еще возможно переоценить дизайн с полностью продуманными принципами SOLID. Вы должны сбалансировать здравый смысл, прагматичный подход с желанием быть чистым и придерживаться общепринятых принципов ООП. Если у вас есть достаточно времени и вам нравится создавать сложные решения, вы можете в конечном итоге пойти по пути разработки двигателя для скейтборда, потому что вы думали, что он в конечном итоге превратится в автомобиль. К счастью, я был достаточно дисциплинирован, чтобы не делать этого на протяжении многих лет, но я видел это много раз.

Итак, чтобы подвести итог, чтобы предотвратить чрезмерное усложнение кода:

1) ПОЦЕЛУЙ (Пусть это будет просто глупо)

2) Следуйте принципам SOLID с практической точки зрения.

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

4) Рассмотреть реализацию решений при их проектировании. Вы не можете просто сказать: «О, это детали реализации», и предположить, что ваш дизайн практичен. Раньше я работал с архитектором, который делал это часто, и, увы, его проекты никогда не работали, и в результате я больше там не работаю.

5) Код, как будто вы тот, кто собирается поддерживать его.

Итак, у вас будет это собеседование, и вы намерены обмануть кандидата, чтобы он продемонстрировал то, что он знает о разработке программного обеспечения, а затем вы скажете: «Нет, вы, вероятно, хотите применить все, что вы знаете, в своем первом задании, иди дальше» Вы, позолоченный сверхинженерный создатель, не представляющий коммерческой ценности!

Я думаю, что было бы безопаснее представить конкретный пример и обсудить преимущества и недостатки применения определенных шаблонов. Чем вы будете запрашивать ответы типа «Зависит, хотите ли вы это быстро? Будет ли это все? Насколько сложна проблема? Какие шаблоны уже существуют?» и вы можете чему-то научиться сами. Это также позволило бы кандидату доказать свое чувство контекста, в то время как это было бы более открытым вопросом. Ожидание и получение конкретного ответа, в лучшем случае, вызовет у вас кого-то такого же серьезного беспокойства, как и у вас. Если вы не получите свой ответ, это может быть кандидат просто считает, что это просто.