Насправді, варіацій цих процесів стільки, скільки існує у багатьох компаній. Значення: кожна компанія має дещо інші конвенції, ніж інші, але є деякі загальні найкращі практики, які зазвичай використовуються в більшості місць.
Кращі практики, які завжди корисні
- Весь вихідний код проекту та все, що потрібно для його створення, знаходиться під контролем версій (також званий вихідним контролем). Будь-хто повинен мати можливість побудувати весь проект одним клацанням миші.
Крім того, непотрібні файли (об'єктні файли або скомпільовані двійкові файли) не слід додавати до сховища, оскільки їх можна відновити досить просто, і це просто витратить місце в репо.
- Кожен розробник повинен оновити та зафіксувати кілька разів на день контроль версій. Здебільшого, коли вони закінчили завдання, над яким працюють, і протестували його досить, щоб вони знали, що воно не містить тривіальних помилок.
- Знову ж таки: будь-хто повинен мати можливість побудувати проект одним клацанням миші. Це важливо і полегшує тестування для всіх. Велика перевага, якщо це можуть зробити і непрограмісти (наприклад, бос). (Це викликає у них відчуття можливості побачити, над чим саме працює команда.)
- Кожен розробник повинен протестувати нову функцію або виправлення помилок, які вони додають, перш ніж зафіксувати їх у сховищі.
- Налаштуйте сервер, який регулярно (через заздалегідь визначені інтервали) оновлює себе зі сховища і намагається побудувати все у всьому проекті . Якщо це не вдається, він надсилає команді електронні листи разом із останніми комітами до контролю версій (з якого коміту не вдалося створити), щоб допомогти налагодити проблему.
Ця практика називається безперервною інтеграцією, а збірки також називаються нічними збірками .
(Це не означає, що розробники не повинні будувати та тестувати код на власних машинах. Як уже згадувалося вище, вони повинні це робити.)
- Очевидно, всі повинні бути знайомі з основним дизайном / архітектурою проекту, тому, якщо щось потрібно, різним членам команди не потрібно винаходити колесо. Написання багаторазового коду - це добре.
- Потрібна якась комунікація між членами команди. Кожен повинен хоч трохи усвідомлювати, що роблять інші. Чим більше, тим краще. Ось чому щоденний стенд корисний у командах SCRUM.
- Модульне тестування - це дуже хороша практика, яка робить тестування основних функціональних можливостей вашого коду автоматично.
- Програмне забезпечення для відстеження помилок (яке іноді називають програмним забезпеченням для відстеження часу ) є дуже хорошим засобом відстеження того, які помилки існують і які завдання мають різні члени команди. Це також добре для тестування: альфа / бета-тестери вашого проекту можуть таким чином спілкуватися з командою розробників.
Ці прості речі гарантують, що проект не вийде з-під контролю, і всі працюють над однією версією коду. Процес інтеграції континуусів допомагає, коли щось йде дуже погано.
Це також заважає людям фіксувати речі, які не збираються, до основного сховища.
Якщо ви хочете включити нову функцію, яка займе кілька днів, а вона заблокує іншим людям можливість створювати (і тестувати) проект, використовуйте функцію гілок вашого контролю версій.
Якщо цього недостатньо, ви також можете налаштувати його на автоматизоване тестування, якщо це можливо з відповідним проектом.
Ще кілька думок
Наведений вище список може бути дуже важким на перший погляд. Я рекомендую вам дотримуватися його за необхідності : починайте з контролю версій та відстежувача помилок, а потім налаштуйте сервер безперервної інтеграції, якщо вам це потрібно. (Якщо це великий проект, він вам дуже скоро знадобиться.) Почніть писати модульні тести для найважливіших частин. Якщо цього недостатньо, то пишіть їх більше.
Кілька корисних посилань:
Постійна інтеграція , Щоденні збірки - це ваші друзі , Контроль версій , Тестування модулів
Приклади:
Для контролю версій я сьогодні використовую Git для своїх особистих проектів. Subversion також популярний, і, наприклад, VisualSVN досить просто налаштувати, якщо ви використовуєте сервер Windows. Для клієнта TortoiseSVN найкраще працює для багатьох людей. Ось порівняння між Git та SVN.
Щодо програмного забезпечення для відстеження помилок, Jira та Bugzilla дуже популярні. Ми також використовували Mantis на попередньому робочому місці.
Для програм постійної інтеграції існує Teamcity для одного (також CruiseControl та його аналог .NET є помітними).
Відповідь на ваше запитання "хто вирішує основний дизайн проекту?"
Звичайно, це був би головний розробник.
У компаніях провідним розробником є особа, яка розмовляє з фінансовими / маркетинговими людьми проекту та приймає рішення щодо суперечності відповідно до фінансових можливостей компанії, запланованих особливостей, вимог користувачів та часу, який доступний.
Це складне завдання, і, як правило, у ньому задіяно більше одного народу. Іноді членів команди також просять взяти участь або провести мозковий штурм щодо проекту цілого проекту або окремих частин.
