Подтвердить что ты не робот

Каков ваш или ваш процесс программирования компании?

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

Некоторые вопросы, на которые нужно ответить:

  • Как пользователи сообщают вам об ошибках/функциях? Какое программное обеспечение вы используете для отслеживания их?
  • Как запросы ошибок/функций превращаются в "работу"? Планируете ли вы эту работу? У вас есть расписание?
  • У вас есть спецификации и следуйте им? Насколько они детализированы?
  • Есть ли у вас технический лидер? Какова их роль? Они сами программируют или просто архитектуру/наставничество?
  • Вы unit test? Как это вам помогло? Что бы вы сказали, ваше освещение?
  • Вы просматриваете код? При работе в сжатые сроки страдает ли читаемость кода? Планируете ли вы вернуться позже и очистить его?
  • Вы документируете? Сколько комментариев вы или ваша компания чувствовали себя комфортно? (Описание класса, каждого метода и внутренних методов? Или просто сложные части кода?)
  • Как выглядит ваш поток SCM? Используете ли вы ветки функций, теги? Как выглядит ваш "багажник" или "мастер"? Это где происходит новая разработка или самая стабильная часть вашей базы кода?
4b9b3361

ОТВЕТЫ

Ответ 1

Для моей (небольшой) компании:

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

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

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

  • Спецификации не являются святыми и не принадлежат кому-либо конкретному человеку. Записывая спецификацию в демократическую среду контроля над источниками, мы поощряем постоянное экспериментирование и пересмотр - до тех пор, пока она задокументирована, поэтому мы не говорим "WTF"? позже.
    В недавней игре iPhone (еще не опубликована) мы закончили с почти 500 веткими, которые позже перевели почти на 20 различных функций, огромное количество упрощений концепций ( "Tap to Cancel" на индикаторе выполнения вместо отдельной кнопки), ряд отвергнутых идей и 3 новых проекта. Великая вещь каждая идея была задокументирована, поэтому было легко представить, как идея может изменить продукт.

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

  • Мы используем DOxygen для создания нашей документации. На самом деле у нас нет автогенерации, встроенной в наш процесс сборки, но мы работаем над этим.

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

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

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

Итак, в основном, наш поток обычно выглядит примерно так:

  • Спецификация документа для ПК + планирование " Ментальное тестирование" Шаг 1
  • Просмотр кода + модульные тесты " Тестирование пользователя" Шаг 1 или 2
  • Контроллер бумаги и спецификация модели + планирование " Ментальное тестирование" Шаг 2 или 3
  • Модель и код контроллера + тесты устройств " Тестирование пользователя" Шаг 3 или 4
  • Разветвленная идея "Спецификация" Кодирование (без модульных тестов) " Ментальное тестирование" Отклонение
  • Разветвленная идея "Спецификация" Кодирование (без модульных тестов) " Ментальное тестирование" Принятие "Единичные тесты" Магистральный) Шаг 2 или 4
  • Известные ошибки "Отслеживание ошибок" Восстановление ошибок "Шаг 2 или 4
  • Готовый продукт "Отчеты об ошибках" Шаг 2 или 4

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

Ответ 2

Я не знаю, почему этот вопрос был проголосован. Я думаю, это отличный вопрос. Это одна вещь для поиска в Google, и читать некоторые случайные сайты, которые много раз пытаются продать вам что-то, а не быть объективными. И еще одна вещь, чтобы спросить SO толпу, которые разработчики/ИТ-Mangers, чтобы поделиться своим опытом, и что работает или не работает для своих команд.

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

Более подробно о ваших вопросах. Здесь основное резюме методов, которые работают для меня (многие из них - здравый смысл):

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

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

  • Прежде чем приступать к какой-либо новой разработке, напишите письменный документ о том, что система сможет сделать (и что он не сделает). Примите во внимание это, но будьте гибкими для потребностей бизнеса. Насколько подробный документ должен быть? Достаточно подробный, чтобы все понимали, на что способна конечная система.

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

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

  • Unit test, где это имеет смысл. Но НЕ обманывайтесь об этом. 100% -ый охват кода!= Нет ошибок, и программное обеспечение работает правильно в соответствии со спецификациями.

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

  • Прокомментируйте свой код особенно сложно для чтения/понимания частей, но не вносите его в роман.

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

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

Ответ 3

  • Мы используем Trac в качестве нашей системы отслеживания ошибок/функций.
  • Билеты Trac проверяются, изменяются на работоспособные единицы и затем назначаются на веху.
  • Трейковые билеты - это наши спецификации, содержащие в основном очень редкую информацию, о которой нужно поговорить во время этапа.
  • Нет, но наша команда разработчиков состоит только из двух участников.
  • Да, мы тестируем, и да, TDD нам очень помог. Охват составляет около 70 процентов (Cobertura).
  • Нет, мы реорганизуем, когда это необходимо (при изменении кода)
  • Мы документируем только общедоступные методы и классы, наш максимальный счетчик строк равен 40, поэтому методы обычно настолько малы, чтобы быть самоописательными (если есть такая вещь; -)
  • svn с trunk, rc и стабильными ветвями
    • trunk - разработка новых функций, исправление старых функций
    • rc - для тестирования дома исправления сбрасываются с магистрали
    • stable - только исправление ошибок сливается с магистрали или rc

Ответ 4

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

http://agilemanifesto.org/

http://www.extremeprogramming.org/

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

В ореховой оболочке:

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