Вы, кажется, почти в той точке, в которой я работал там, когда я начал там 1,5 года назад, с той лишь разницей, что вы начали играть с ветками, что на самом деле мы все еще не делаем на моей работе, но об этом позже в этом ответе.
В любом случае, вы перечисляете очень хороший набор инструментов, которые могут помочь небольшой компании, и они действительно прекрасно работают в качестве подтем, поэтому без лишних слов,
Системы контроля версий
Чаще всего небольшие компании в настоящее время используют CVS или SVN, и в этом нет ничего плохого, на самом деле я был бы очень обеспокоен, если бы вообще не использовался контроль версий. Тем не менее, вы должны использовать контроль версий right , просто один из них не сделает вашу жизнь проще. В настоящее время мы используем CVS и изучаем Mercurial , но мы обнаружили, что следующее работает как хороший набор соглашений при работе с CVS (и я подозреваю, что SVN тоже):
- Иметь отдельных пользователей для всех коммиттеров. Ценно знать, кто что совершил.
- Не разрешать пустые коммиты. Фактически, если возможно, настройте репозиторий так, чтобы он отклонял любые коммиты без комментариев и / или комментариев по умолчанию. Первоначальная фиксация для FooBarizer лучше, чем Пустое сообщение журнала
- Используйте теги для обозначения вех, прототипов, альфа-версий, бета-версий, релиз-кандидатов и финальных версий. Не используйте теги для экспериментальной работы или в качестве сносок / Post-It notes .
- Не используйте ветки, так как они действительно не работают, если вы продолжаете разрабатывать приложение. Это происходит главным образом потому, что в CVS и SVN ветвление просто не работает должным образом, и становится бесполезным упражнением поддерживать более двух живых ветвей ( головка и любая вторичная ветвь ) с течением времени.
Всегда помните, что для компании-разработчика программного обеспечения исходный код является вашим источником дохода и содержит всю ценность вашего бизнеса, поэтому относитесь к этому так. Также, если у вас есть дополнительные 70 минут, я очень рекомендую вам посмотреть через этот доклад , который Линус Торвальдс дал в Google о git и (d) VCS в целом, это действительно проницательно.
Автоматизированные сборки и среды непрерывной интеграции
Они примерно одинаковы на самом деле. Ежедневные сборки - это PR-шутка, мало похожая на состояние реального программного обеспечения, за исключением некоторого очень элементарного "Компилируется ли оно?" проблемы. Вы можете скомпилировать много ужасного шума кода, который ничего не делает, поддержание качества программного обеспечения не имеет ничего общего с получением кода для компиляции.
С другой стороны, модульные тесты являются отличным способом поддержания качества программного обеспечения, и я с некоторой личной гордостью могу сказать, что тщательное модульное тестирование помогает даже худшим из программистов улучшать свои показатели и выявлять глупые ошибки. На самом деле до сих пор было всего три ошибки, написанные мною написанным кодом, достигли производственной среды, и я бы сказал, что через 18 месяцев это чертовски хорошее достижение. В нашем новом производственном коде у нас обычно есть инструкция охват кода , равная + 80%, в основном + 90%, а в одном особом случае - до 98%. Эта часть очень интересна, и вам лучше использовать Google: TDD, BDD, модульные тесты, интеграционные тесты, приемочные тесты, xUnit, фиктивные объекты.
Это длинное предисловие, я знаю. Фактический смысл всего вышеперечисленного заключается в следующем: если вы хотите иметь автоматические сборки, они должны происходить каждый раз, когда кто-то фиксирует, и следить за тем, чтобы постоянно увеличивалось и улучшалось количество модульных тестов для производственного кода. Выберите систему непрерывной интеграции по вашему выбору (мы используем Hudson CI ), чтобы запустить все модульные тесты, связанные с проектом, и принимать сборки только в том случае, если все тесты пройдены. Не идите на компромиссы! Если модульные тесты показывают, что программное обеспечение не работает, исправьте его.
Кроме того, системы непрерывной интеграции предназначены не только для компиляции кода, но вместо этого их следует использовать для отслеживания состояния метрик программного проекта. Для Hudson CI я могу порекомендовать все эти плагины:
- Checkstyle - Проверяет, написан ли фактический исходный код заданным вами способом. Большая часть написания поддерживаемого кода заключается в использовании общих соглашений.
- Cobertura - Кодовые показатели покрытия, очень полезные для наблюдения за развитием покрытия с течением времени. Кроме того, следуя менталитету «источник - Бог», вы можете отказаться от билдов, если охват падает ниже определенного уровня.
- Task Scanner - Простой, но приятный: Сканирует для определенных тегов, таких как BUG, TODO, NOTE и т. Д. В вашем коде, и создает список из них для всех, чтобы прочитать. Простой способ отследить короткие заметки или известные ошибки, которые нужно исправить или что угодно, что вы можете придумать.
Структура проекта и управление зависимостями
Это спорный вопрос. В принципе, все согласны с тем, что наличие единой структуры - это замечательно, но поскольку есть несколько лагерей с различными требованиями, привычками и взглядами, которые они могут выдавать, они склонны не соглашаться. Например, люди Maven действительно верят, что есть только один способ - способ Maven - что-то делать, и это все, в то время как сторонники Ivy считают, что структура проекта не должна быть забита в ваше горло внешними сторонами, только необходимо правильно и единообразно управлять зависимостями. Только то, что это не осталось неясным, наша компания просто любит Плющ.
Так как мы не используем структуру проекта, навязанную внешними сторонами, я расскажу вам немного о том, как мы попали в то, что мы получили в нашу текущую структуру проекта.
Вначале мы использовали отдельные проекты для реального программного обеспечения и связанных тестов (обычно называемые Product и Product_TEST). Это очень близко к тому, что у вас есть, один огромный каталог для всего с зависимостями в виде JAR, непосредственно включенных в каталог. Что мы сделали, так это то, что мы извлекли оба проекта из CVS, а затем связали реальный проект с тестовым программным проектом в Eclipse как зависимость времени выполнения. Немного неуклюже, но это сработало.
Вскоре мы поняли, что эти дополнительные шаги совершенно бесполезны, поскольку, используя Ant - кстати, вы можете вызывать задачи Ant непосредственно в Hudson - мы могли бы сказать шагу сборки JAR / WAR игнорировать все по имени файла (скажем, все, что заканчивается Test или TestCase) или по исходной папке. Довольно скоро мы преобразовали наш программный проект для использования простой структуры двух корневых папок src и test. С тех пор мы не оглядывались назад. Единственная дискуссия, которую мы в настоящее время ведем, это то, что мы должны допустить, чтобы в нашей стандартной структуре проекта существовала третья папка с именем spikes, и это не очень жаркая дискуссия.
Это сработало очень хорошо и не требует никакой дополнительной поддержки или плагинов ни от одной из IDE, что является большим плюсом - причина номер два, по которой мы не выбрали Maven, видела, как M2Eclipse в основном взял на себя затмение. И поскольку вы, должно быть, задаетесь вопросом, причиной номер один для отказа от Maven была неуклюжесть самого Maven, бесконечное количество длинных XML-объявлений для конфигурации и связанная с этим кривая обучения считались слишком большими затратами на то, что мы получим от его использования.
Довольно интересно, что позднее комментирование с Ivy вместо Maven позволило нам плавно перейти к разработке Grails , которая использует имена папок и классов в качестве соглашений практически для всего при структурировании веб-приложения.
Кроме того, последнее замечание о Maven, хотя оно утверждает, что оно продвигает соглашение о конфигурации, если вы не хотите делать вещи точно так, как структура Maven говорит, что вы должны делать что-то, вы находитесь в мире боли для вышеупомянутые причины. Конечно, это ожидаемый побочный эффект наличия соглашений, но ни одно соглашение не должно быть окончательным, всегда должна быть хотя бы некоторая возможность для изменений, изменения правил или выбора подходящего из определенного набора.
Короче говоря, я считаю, что Maven - это базука, вы работаете в доме, и ваша конечная цель - освободить его от ошибок. Каждый из них хорош сам по себе и работает, даже если вы выберете любые два из них, но три вместе не работают.
Заключительные слова
Пока у вас менее 10 человек, ориентированных на код, вы обладаете всей гибкостью, необходимой для принятия важных решений. Когда вы выходите за рамки этого, вы должны жить с любым выбором, который вы сделали, независимо от того, насколько он хорош или плох. Не просто верьте вещам, которые вы слышите в Интернете, садитесь и строго проверяйте все - черт возьми, наш старший технический специалист даже написал свою дипломную работу бакалавра о веб-фреймворках Java, просто чтобы выяснить, какой из них нам следует использовать, - и действительно выяснить, что вы очень нужно. Не соглашайтесь ни на что, просто потому, что вам могут понадобиться некоторые функции, которые он предоставляет в отдаленном будущем, выберите те вещи, которые оказывают минимально возможное негативное влияние на всю компанию. Будучи 10-м человеком, нанятым в компанию, в которой я работаю, я могу подписать все в этом параграфе своей собственной кровью, в настоящее время у нас работает более 16 человек, и изменение некоторых соглашений на самом деле будет немного страшным.