Что такое "надстройка" применительно к программному обеспечению?

Ответ 1

Вопреки большинству ответов, я не считаю, что "в настоящее время ненужные функции" - чрезмерное проектирование; или это наименее проблематичная форма.

Как вы сказали, худший вид чрезмерной инженерии обычно совершается во имя будущей проверки и расширяемости - и достигается полная противоположность:

• Пустые слои абстракции, которые в лучшем случае не нужны и в худшем случае ограничивают вас узким, неэффективным использованием базового API.
• Код, заполненный обозначенными "точками расширения", такими как защищенные методы или компоненты, приобретенные с помощью абстрактных фабрик, - которые, как оказалось, не совсем то, что вам действительно нужно, когда вам нужно расширить функциональность.
• Сделать все настраиваемым, чтобы "избегать жесткого кодирования", с тем, что в файлах конфигурации есть больше (сложная, подверженная ошибкам) ​​логика приложения, чем в исходном коде.
• Сверх-обобщение: вместо реализации (технически неинтересного) функционального спецификатора разработчик создает (технически интересный) "механизм бизнес-правил", который "выполняет" сами спецификации, предоставляемые бизнес-пользователями. Конечным результатом является интерпретатор для частного (сценария или конкретного домена) языка, который обычно ужасно разработан, не имеет поддержки инструмента и настолько трудно использовать, что ни один бизнес-пользователь никогда не сможет с ним работать.

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

Ответ 2

Вопреки распространенному мнению, чрезмерное проектирование - это действительно явление, которое возникает, когда инженеры получают "высокомерие" и думают, что понимают пользователя.

Я сделал простую диаграмму, чтобы проиллюстрировать это:

Ответ 3

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

Ответ 4

Для меня чрезмерная инженерия включает все, что вам не нужно, и что вы не знаете, что вам нужно. Если вы поймете, что функция может быть приятной, если требования меняются определенным образом, тогда вы можете быть чрезмерно развитыми. В принципе, чрезмерное проектирование нарушает YAGNI.

Ответ 5

Это обсуждение в Joel on Software, которое начинается с

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

И, обсуждается с примерами.

Ответ 6

Проворный ответ на этот вопрос: каждый фрагмент кода, который не способствует запрошенной функциональности.

Ответ 7

Если вы тратите столько времени на размышления о возможных последствиях проблемы, в результате которой вы оказываете влияние на решение самой проблемы, вы можете быть чрезмерной.

Там тонкий баланс между "лучшими инженерными практиками" и "действительностью в реальном мире". В какой-то момент вы должны решить, что хотя конкретное решение может быть не таким "чистым" с технической точки зрения, каким оно может быть, оно выполнит эту работу.

Например:

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

Это все о соответствующем уровне усилий для этой задачи.

Ответ 8

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

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

Ответ 9

Для меня это все, что добавило бы больше жира в код. Мясо будет любым кодом, который будет выполнять работу в соответствии со спецификацией, и жир будет любым кодом, который раздувает код таким образом, что он просто добавит больше сложности. Возможно, программист ожидал будущего расширения функциональности; но все же он толстый.!

Ответ 10

Я думаю, что лучшие ответы на ваш вопрос можно найти в этом другом вопросе

Ответ 11

Мое грубое определение будет "Предоставлять функциональность, которая не нужна для удовлетворения требований спецификации"

Ответ 12

Я думаю, что они такие же, как Золотое покрытие и попадание Золотой молот:)

В принципе, вы можете сесть и потратить слишком много времени, пытаясь сделать идеальный дизайн, даже не написав код, чтобы узнать, как он работает. Любой гибкий метод подскажет вам не делать все, что нужно для вашего дизайна, и просто создавать куски дизайна, реализовывать его, повторять, переделывать, снова и т.д....

Ответ 13

Цитата отсюда: "... Реализуйте вещи, когда вам нужен на самом деле, никогда, когда вы просто предвидеть, что они вам нужны."

Ответ 14

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

Существует большая разница между надстройкой и созданием расширяемого аппликатора, который может быть повышен с изменением требований. Если я смогу придумать пример, я отредактирую сообщение.

Ответ 15

Over-engineering просто создает продукт с большей функциональностью, качеством, общностью, расширяемостью, документацией или любым другим аспектом, чем это требуется.

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

Ответ 16

Это относится к моему спорному программированию мнению "Самый простой подход всегда является лучшим подходом" .

Ответ 17

Когда ваш дизайн действительно делает вещи более сложными, а не упрощает их, вы перерабатываете.

Подробнее об этом:

http://www.codesimplicity.com/post/what-is-overengineering/

Ответ 18

Отказ от ответственности № 1: Я - крупный художник. Я не знаю кода. Я читал этот сайт все время. Это мой первый пост.

Забавно, что мой босс просто сказал, что я переработал новую программную продукцию, которую мы планируем наставничеством (HR-люди с целевым рынком). Поэтому я пришел сюда, чтобы найти этот термин.

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

Он сказал, что мы можем планировать будущие этапы улучшения продукта, особенно пользовательского интерфейса. У нас есть текущие клиенты, ожидающие "будущих улучшений", которых мы все еще не делаем. Они нуждаются в этом, хотя, действительно нуждаются в этом.

Я вхожу в отставку, поэтому я не отошел назад.

Но мое определение было бы............. убедившись, что оно только сделает как можно меньше, как можно дешевле, и все же будет приемлемым для того, что вы говорите. Кроме того, над инженерией.

Отказ от ответственности # 2: этот сайт помог мне приземлить мою следующую работу, внедряя более настраиваемое программное обеспечение.

Ответ 19

Красота программирования Agile заключается в том, что вам сложно перестроиться, если вы сделаете это правильно.