Способы предотвратить сверхразработку? [закрытый]

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

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

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

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

С уважением

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Timeboxing - это так просто, как сказать - я потрачу N часов на исследование технологии, чтобы сделать эту работу лучше.

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

Похоже, вы работаете самостоятельно, что затрудняет рецензирование. Я работаю в Scrum-магазине. Часть процесса требует, чтобы мы обсудили все исправления и функции, а затем получили согласие (согласие) с другими инженерами перед написанием строчки кода. Это похоже на «Отмерь дважды, отрежь один раз». Мы тратим около половины своего времени на исследования и планирование, и это того стоит.

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

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

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

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

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

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

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

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

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

• Повторить ...

Практикуйте ЯГНИ (она вам не понадобится), и ваша продуктивность может повыситься. Возможно, много.

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

Выпустить раньше, выпускать часто

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

Отличный вопрос. Вот что я обнаружил, и сделать это непросто:

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

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

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

Сохраняйте простоту, глупость

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

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

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

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

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

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

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

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

Да.

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

1. Создайте самый маленький и простой элемент, который решит проблему.

2. Изучите альтернативы.

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

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

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

1. заставить его работать
2. сделать его лучше
3. истекло время

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

Сроки.

Есть несколько способов, которые приходят на ум:

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

Еще пара вещей, на которые следует обратить внимание:

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

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

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

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

Честно ответьте на оба вопроса Duck и продолжайте разработку на основе вашего ответа.

Кстати, вам следует возможно, спросите Утки, не возражает ли он все время, которое вы тратите на Stack Overflow.

Честно ответьте на оба вопроса Duck и продолжайте разработку на основе вашего ответа.

Кстати, вам следует возможно, спросите Утки, не возражает ли он все время, которое вы тратите на Stack Overflow.

Честно ответьте на оба вопроса Duck и продолжайте разработку на основе вашего ответа.

Кстати, вам следует вероятно, спросите Утки, не возражает ли он все время, которое вы тратите на Stack Overflow.

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

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

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