Способы предотвращения чрезмерной инженерии?

Ответ 1

Примите идею XP... YAGNI. (Вам это не понадобится)

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

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

Ответ 2

сжатые сроки.

Ответ 3

• заставить его работать.
• сделать это лучше
• закончилось время

В этом порядке.

Ответ 4

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

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

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

Ответ 5

Да.

Чтобы предотвратить чрезмерное проектирование, сделайте это.

• Постройте самую маленькую, самую простую вещь, которая решает проблему.

• Исследуйте альтернативы.

Ответ 6

По моему опыту, самый простой способ избежать чрезмерной инженерии - это опыт. В то время как greenhorns будут бесконечно бороться со своими сомнениями и опасениями, старший разработчик просто сделает это. И они поймут это правильно (второй раз, если не первый).

Второй самый простой способ - уверенность. Здесь есть опасность, хотя: без опыта уверенность может быть чрезвычайно опасной.

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

Ответ 7

Отличный вопрос. Вот что я нашел, и это не все легко сделать:

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

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

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

Ответ 8

Release Early, Release часто

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

Ответ 9

Практика YAGNI (вам это не понадобится), и ваша производительность может возрасти. Возможно, много.

Возможно, вы захотите прочитать "Программист каналов" , однако примите во внимание ваше мнение.

Ответ 10

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

Конструкции будут представлены в UML для облегчения анализа.

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

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

Ответ 11

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

Чтение об идеях, стоящих за этим, может помочь вам меньше беспокоиться о перфекционизме: http://c2.com/cgi/wiki?EmergentDesign

Вот как я научился это делать:

• Научитесь сначала писать тест для некоторых простых функций.
• Затем напишите код, который удовлетворяет тесту.
• Ищите элементы повторения или вещи, которые вы можете упростить. ПЕРЕД тем, как вы пытаетесь упростить/разблокировать код, убедитесь, что ВСЕ проходит тест, поэтому у вас есть базовый уровень для рефакторинга.
• После рефакторинга снова запустите все тесты - чтобы убедиться, что вы не изменили никаких поведений, которые вас волнуют.
• Проверьте его.

• Повторить... до завершения...

• Это проще сделать, когда вы общаетесь с кем-то еще... желательно тем, кто уже знает, как делать XP.

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

Другими словами, изучите XP; -)

Ответ 12

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

Ответ 13

Использовать часть CMMI; измерьте себя.

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

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

Ответ 14

На ум приходит несколько способов:

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

Несколько других замечаний:

• Избегайте избиения себя за выполнение своей работы. Прошлое будет оставаться в прошлом, независимо от того, что вы делаете.
• Идеальный код для приложения - это миф. Враг хорошего плана - мечта идеального.
• Хотя некоторый анализ хорош, используйте умеренность, чтобы предотвратить "анализ паралича"

Ответ 15

Вам нужны две вещи: Timeboxing и Peer Review

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

Peer Review означает, что вы обсуждаете проблему с другими заинтересованными инженерами.

Звучит так, как будто вы работаете самостоятельно, что делает Peer Review сложным. Я работаю в магазине Scrum. Часть процесса требует, чтобы мы обсуждали все исправления и функции, а затем покупали (соглашаться) с другими инженерами перед написанием строки кода. Это работает так же, как "Мера дважды, вырезать один раз". Мы тратим около половины нашего времени на исследования и планирование, и это стоит инвестиций.

Ответ 16

Держите его простым, глупым

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

http://en.wikipedia.org/wiki/KISS_principle

Ответ 17

Похоже, у вас нет менеджера проектов.

Вам нужно украсть методы из известной Rubber Duck Debugging и применить их к управлению проектами. Представьте, что Rubber Duck - ваш менеджер проектов, представляющий основного клиента, и объясните ему, что вы хотите использовать X-часы для изучения новой технологии или новой архитектуры. Теперь притворимся, что Rubber Duck спрашивает вас, считаете ли вы, что новые функции будут стоить X * Y денег клиента, где Y - ваша почасовая зарплата плюс стоимость вашего стола и льгот. Затем Rubber Duck спрашивает вас, считаете ли вы, что новая функция стоит отложить доставку X-часов.

Ответьте на оба вопроса "Утка" честно и приступите к разработке на основе вашего ответа.

Наверное, вам, вероятно, следует спросить утку, если он все время будет тратить на переполнение стека.

Ответ 18

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

Ответ 19

Преждевременная оптимизация и обработка того, что ifs может определенно быть проблемой.

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

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

Ответ 20

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

Ответ 21

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

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

Ответ 22

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

Ответ 23

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

Привет

Ответ 24

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

Скажем, я пишу утилиту, которую только когда-либо буду использовать, и я буду использовать ее редко или даже только один раз. Если у меня есть выбор между кодированием такой утилиты в оболочке Bourne или Perl за десять минут, которая выполняется на ночь, и три часа, чтобы написать оптимизированную версию, используя сложные и сложные алгоритмы на С++, которые работают за одну минуту... электричество дешевле моего времени.

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

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

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

Теперь, многие десятки проектов и, возможно, миллионы строк кода, есть много дизайнерских решений, которые я могу сделать почти инстинктивно. Например: "Если вы работаете на С++ и сталкиваетесь с проблемой, которую может решить какой-то шаблон STL, и вы не ограничены, чтобы не использовать STL, то это путь. Это потому, что современные реализации STL очень оптимизированы, и любое улучшение, которое вы могли бы получить от написания собственного кода, просто не стоило бы усилий".

Кроме того, я могу просто взглянуть на ситуацию и сказать: "10% проекта, где у нас могут возникнуть проблемы, здесь, и здесь, и здесь, чтобы нам нужно было сконцентрировать наши исследования и дизайн а остальные 90%, пусть просто заработают, но мы сможем это сделать". И это работает очень хорошо.

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

Ответ 25

Время бокса - это то, что мы делаем.

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

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

Ответ 26

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

Тем не менее, этот метод действительно ДЕЙСТВИТЕЛЬНО требует создания чистого, хорошо написанного, легко понятного кода и требует, чтобы вы использовали аксессоры во всем мире. Если вы этого не сделаете, у вас будет кошмар рефакторинга.

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

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

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

Ответ 27

Существует один верный принцип: сначала сделайте все, а затем будьте умны. Вы должны достичь первой цели, второй - нет.

Ответ 28

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

• получить историю пользователей
• использовать прецеденты из истории пользователя
• напишите unit test для первой функции первого варианта использования
• реализовать функцию
• рефакторинг при необходимости используйте SRP, чтобы разделить слишком большие классы.
• перейти к следующей функции
• перейти к следующему варианту использования
• После того, как вы закончите, вы можете добавить API (например, REST) ​​и базу данных (например, PgSQL) в ваше приложение (эта часть зависит от того, какую модель разработки вы следуете).

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

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