Инфраструктура для программного проекта [закрыто]
-
01-07-2019 - |
Вопрос
Скоро я возглавлю новый проект.И я размышлял над тем, какова базовая инфраструктура для программного проекта.Это то, что, я думаю, должно быть в каждом проекте:
-Соглашения о стиле кодирования
-Соглашения об именовании
-Стандартная структура каталогов проекта (например, стандартная компоновка каталога maven и т.д.)
-Управление проектами и отслеживание проблем (например, trac, redmine и т.д.)
-Сервер непрерывной интеграции (например, hudson, круиз-контроль и т.д.)
Я не уверен, что я что-то упустил.Кто-нибудь хотел бы добавить?
Нет правильного решения
Другие советы
В качестве предварительного ответа ознакомьтесь с тестом Джоэла:http://www.joelonsoftware.com/articles/fog0000000043.html
Просто закуска:
- Используете ли вы систему управления версиями?
- Можете ли вы выполнить сборку за один шаг?
- Делаете ли вы ежедневные сборки?
- У вас есть база данных ошибок?
- Исправляете ли вы ошибки перед написанием нового кода?
- У вас есть актуальное расписание?
- У вас есть спецификация?
- Есть ли у программистов спокойные условия работы?
- Используете ли вы лучшие инструменты, которые можно купить за деньги?
- У вас есть тестировщики?
- Пишут ли новые кандидаты код во время собеседования?
- Проводите ли вы тестирование юзабилити коридора?
- система контроля версий (напр.subversion, cvs, git)
В дополнение к вашему я поставлю:
- Стратегия модульного тестирования
- Стратегия интеграционного тестирования
- Определенный Процесс
- Стратегия выпуска (доставки) (например, этапы, рабочие пакеты и так далее)
- Стратегия ветвления системы управления версиями
- Как насчет документации - как (комментарии в коде, высокоуровневые спецификации), когда, количество, кто
- Как вы будете тестировать - модульное / приемочное / пользовательское тестирование
- управление версиями кода, какой-нибудь SVN / Git (или он включен в trac?)
- роли и обязанности команды - должны быть указаны в ocntext вашего проекта
Управление знаниями имеет решающее значение.Поскольку вы уже планируете использовать wiki (например, Trac или Красный Рудник) вы могли бы использовать его и для KM.
Функциональное тестирование является обязательной частью любого проекта.Модульное тестирование - это здорово, и оно хорошо работает для гибких проектов, но функциональное тестирование все еще необходимо.Вам нужен хотя бы базовый План тестирования.Если вы планируете иметь несколько проектов или подпроектов, неплохо было бы использовать документ о стратегии тестирования или вики-страницу.Тестовые случаи, примеры приемочных тестов и т.д. Могут основываться на ваших пользовательских историях или их эквивалентах, но они все равно должны существовать в той или иной форме.
Я бы тоже включил в это дело файлообменный сервер.Я думал, что контроль версий настолько прост, что я даже не потрудился включить его в список.Но это хорошая точка контроля версий.
План управления конфигурацией.У вас должен быть документированный подход к вашим рабочим потокам разработки, к тому, как вы будете объединяться между ними и т.д.