Конкретные симптомы чрезмерной инженерии

Ответ 1

Каковы общие симптомы над-инжиниринг?

Код, который решает проблемы, которые у вас отсутствуют.

Ответ 2

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

Ответ 3

Скука

Скука является хорошим предшественником переработанного кода. Я признаю, что когда я получил свою первую работу, я чувствовал себя настолько недоиспользуемым. Мне было просто скучно. И когда мне стало скучно, я написал код. Не только любой код - СОБЫТИЯ КОДА.

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

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

Если вы пишете свои собственные фреймворки и код DSL, отключайте менее стимулирующие часы на работе, просто остановитесь. Время лучше потратить на чтение Wards Wiki или написать книгу с открытым исходным кодом, или вы можете просто попросить руководство для большей работы.

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

Написание собственной Framework

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

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

Он написал свою собственную схему инъекций зависимостей, свою собственную ORM, единую систему тестирования (которая, по необъяснимому, выглядела и действовала очень похоже на NUnit - почему он не использовал NUnit?), рамки для создания factory objects (a factory factory" Я бы назвал это).

Помните, что код был действительно замечательным, но в чем смысл?

Написание лучшей базовой библиотеки

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

Кроме всего прочего, они писали:

• Рамка активного каталога для проверки подлинности форм в веб-формах ASP.NET - необъяснимо, потому что эта функция встроена в ASP.NET.
• Темы и скины с горячей заменой для сайтов - также необъяснимы, поскольку код был менее функциональным, чем встроенные темы ASP.NET, и требовал на 1000% больше раздувания.
• Они необъяснимо написали свои собственные типизированные наборы данных и адаптеры данных. Эти объекты обеспечивали меньшую функциональность, чем типизированные наборы данных, которые VS будет автогенерировать для вас, одновременно требуя более шаблонного кода, чем объекты домена NHibernate.

Либо они не очень хорошо знакомы с каркасом, либо думают, что его печально недостаточно.

Есть только очень немногие примеры, которые я могу придумать, где обновленная библиотека лучше оригинала (см. Jane Street Core Library, C5 Generic Collections для .NET, реальный валютный класс), но есть вероятность, что вы не будете писать лучшую стандартную библиотеку.

Ответ 7

Избегайте использования YAGNI, DRY и KISS приходят на ум, глядя на вещи, которые чрезмерно спроектированы. Если есть много частей, которые, кажется, частично завершены, и многие части кода, которые, похоже, имеют: "Что, если это произойдет? Что, если это произойдет?" чувствую, что это будет другой момент. Игнорирование хороших принципов дизайна OO или SOLID принципы было бы другим отметить. Если вы думаете, что написали идеальный код, это было бы еще одним признаком неприятностей, так как очень редко кто-то пишет что-то, что не может быть улучшено так или иначе.

ИМО, будьте осторожны, что некоторые люди могут чрезмерно критиковать вашу работу как часть любой базы кода, могут привлекать людей, любящих вещи определенным образом, например. именования соглашений о методах, тестах и ​​переменных. Это так, как есть. Теперь вам нужно выяснить, как обращаться с людьми в siutations, например conflict или убеждение/влияние, где есть инструменты, которые могут помочь.

Ответ 8

ИМХО Большинство комментариев, которые вы получили о своем приложении, на самом деле не касаются чрезмерной инженерии, потому что чрезмерная инженерия касается не технологии. Это о архитектуре. Новые технологии можно изучать и понимать в разумные сроки. Понимание чрезмерно спроектированного приложения обычно намного сложнее, а иногда даже невозможно. Это делает ошибки 2, 4 и 5 неверными. Первый момент не является действительно действительным, потому что вам явно заплатили за то, что он написал приложение, и если он работает, у вас здесь нет проблем.

Это мой "быстрый тест", чтобы выяснить, слишком ли сложное приложение :

• Обертка для "всего": Обертки полезны, но легко переусердствовать. Убедитесь, что вы только обертываете вещи, которые действительно нужно обернуть. (Я в основном обернул свою собственную обертку один раз. Я знаю, о чем говорю;-).)
• Переосмысление колеса: Классика. Это очень распространено, и вы уже упомянули об этом. Вы реализовали какую-то функциональность, потому что вам нужно было это сделать? Что делает ваша фреймворк делать то, что нет в других доступных библиотеках?
• "Чувствует" чрезмерно спроектированный: Это самый важный момент, но также самый трудный момент для просмотра. Взгляните на свой код и посмотрите, какие части чувствуют себя слишком сложными. Спросите себя, если есть более простой способ его реализации и почему вы так не выбрали. Если у вас нет хорошего ответа, эта часть, вероятно, слишком переработана.

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

Ответ 9

Когда компьютер коллег пролетает мимо вашей головы, потому что они провели последние 6 часов, пытаясь и не сумев сделать диалоговое окно freaking, используя вашу смешную структуру, вот и довольно конкретный симптом.

Ответ 10

Ты не астронавт архитектуры. LINQ довольно простой и простой и полезный, для одного. То же самое касается .NET 3.5.

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

Возьмите все с солью. Просто примите их критику, кивните, и имейте пиво с ними впоследствии.

Если они попросят вас изменить его, то ваш комментарий будет "jeez.. Я знаю, что я сделал это неправильно, но он работает, и это будет слишком много проблем, чтобы изменить".

Ответ 11

Плагины, которые обеспечивают встроенную функциональность вашего приложения

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

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

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

Ответ 12

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

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

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

Ответ 13

На более общем и высоком уровне подход

I feel that when there a gap between the complexity of the problem and
the complexity of the solution, then you have a clear case of overengineering. 

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

Ответ 14

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

Ребята, с которыми вы разговаривали, могут иметь хорошие предложения, но это не значит, что вам нужно взять все, что они говорят, как Евангелие. Например, использование последней версии .NET в новом проекте не поражает меня, как о чем-то беспокоиться. Неужели они действительно жалуются на это?

Ответ 15

половина из них - старики (я в их лиге), придерживающиеся проверенного и истинного парового двигателя, который они знали. другая половина верна, но на самом деле не говорит вам ничего нового.

кроме этого, ответ Джеффа Стерна - звездный.

Ответ 16

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

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

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

Мне еще предстоит отменить абсолютные правила для вызова...

Я подозреваю, что я склонен к чрезмерной инженерии, поэтому я сделал эту картинку обои для ПК

Ответ 17

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

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

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

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

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