[Закрываются] конкретные признаки сверхразработки

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

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

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

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

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

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

Кроме этого, Джефф Стернал ответил просто звездным.

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

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

Отнеситесь ко всему с легкостью соль. Просто примите их критику, кивните, а потом выпейте с ними пива.

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

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

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

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

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

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

Написание собственного фреймворка

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

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

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

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

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

Это мой «быстрый тест», чтобы выяснить, имеет ли приложение тенденцию , требующие перестройки:

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

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

Скука

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

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

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

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

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

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

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

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

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

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