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

сроки.

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

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

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

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

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

да.

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

1. построить самую маленькую, простую вещь, которая решает эту проблему.

2. исследовать альтернативы.

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

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

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

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

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

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

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

Выпускать Рано, Выпускать Часто

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

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

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

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

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

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

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

• повторить... до сделанный...

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

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

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

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

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

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

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

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

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

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

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

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

• сосредоточьтесь на том, что было задано, и, где это возможно, сделайте требования максимально ясными. Первые могут рассматриваться как пассивно-агрессивные для некоторых, поскольку выполнение именно того, что было предложено, не обязательно является обычной практикой.
• оставайтесь в данный момент, избегайте играть в игру "что, если", ЯГНИ.
• Time-box работа так, что это не черная дыра всасывает все время доступны.

пару из других вещей, чтобы заметить:

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

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

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

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

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

Будь проще, глупый

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в отношении

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. наслаждайтесь пользователей
2. используйте случаи из истории пользователя
3. написать модульный тест для первой функции первого варианта использования
4. реализовать функцию
5. рефакторинг при необходимости используйте SRP разделить слишком большие классы
6. перейти к следующей функции
7. переход к следующему использованию дело
8. после того, как вы закончите, вы можете добавить API (например, REST) и базу данных (например, PgSQL) в свое приложение (эта часть зависит от того, какой модели разработки вы следуете)

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

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