Если вы не поняли что-то из сказанного, это нормально. На первых порах git вызывает немало затруднений. К тому, как работает эта система, нужно привыкнуть. Но будьте уверены: git и другие подобные системы – это будущее управления исходным кодом.
IDE/редактор
Мы, разработчики, проводим большую часть времени за чтением и редактированием кода. Инструменты, используемые нами для этих целей, значительно изменились за прошедшие годы. Некоторые из них обладают неимоверной мощью, а некоторые почти не изменились с 1970-х годов.
vi
Казалось бы, эпоха использования vi как основного редактора для разработки давно прошла. В наши дни появились инструменты, значительно превосходящие vi по своим возможностям, и другие простые текстовые редакторы того же типа. Однако в последнее время наблюдается заметный всплеск популярности vi, который объясняется его простотой, удобством использования, скоростью и гибкостью. Хотя vi и уступает Emacs или Eclipse по широте возможностей, он остается быстрым и мощным редактором.
При этом я уже не являюсь опытным пользователем vi. Когда-то меня называли «богом» vi, но это время давно прошло. Я использую vi время от времени, когда мне нужно быстро отредактировать текстовый файл. Я недавно использовал его для быстрого изменения исходного файла Java в удаленном режиме. Но объем полноценного кода, написанного мной в vi за последние 10 лет, ничтожно мал.
Emacs
Emacs до сих пор остается одним из самых мощных редакторов и, вероятно, останется им еще несколько ближайших десятилетий. Его мощь обеспечивается внутренней моделью на базе lisp. В категории инструментов редактирования общего назначения ни один другой редактор даже отдаленно не может с ним конкурировать. С другой стороны, я думаю, что Emacs не может полноценно конкурировать со специализированными интегрированными средами разработки (IDE), которые сейчас заняли лидирующее положение. Редактирование кода не относится к задачам редактирования общего назначения.
В 1990-е годы я был фанатом Emacs. Я просто не рассматривал другие варианты. Тогдашние редакторы с управлением мышью были смешными игрушками, к которым ни один разработчик не мог относиться серьезно. Но в начале 2000-х я познакомился с IntelliJ – моим фаворитом среди IDE, и уже не оглядывался назад.
Eclipse/IntelliJ
Я – пользователь IntelliJ. Я люблю эту систему. Я использую ее для написания кода на Java, Ruby, Clojure, Scala, Javascript и многих других языках. Она была написана программистами, которые понимают, что нужно программисту при написании кода. За прошедшие годы IntelliJ почти никогда не подводила меня, а впечатления почти всегда оставались положительными.
Среда Eclipse по своей мощи и масштабу сравнима с IntelliJ. Эти две среды качественно превосходят Emacs по возможностям редактирования Java-кода. В этой категории существуют и другие IDE, но я не упоминаю их здесь, потому что у меня нет непосредственного опыта их использования.
Эти интегрированные среды отличаются от таких инструментов, как Emacs, прежде всего чрезвычайно мощными возможностями манипулирования кодом. Например, IntelliJ позволяет извлечь суперкласс из класса всего одной командой. Вы можете переименовывать переменные, извлекать методы, преобразовывать наследование в композицию… и это далеко не полный список.
С этими инструментами редактирование кода переходит с уровня строк и символов на уровень более сложных манипуляций. Разработчик думает не о нескольких следующих символах и строках, которые он собирается ввести, а о следующих преобразованиях. Короче говоря, модель программирования в этих новых системах значительно изменяется и становится более производительной.
Конечно, за широту возможностей приходится платить. Освоение интегрированных сред требует немалого времени и усилий, и фаза начальной подготовки проекта становится довольно заметной. Кроме того, эти инструменты весьма требовательны – для их работы необходимы значительные вычислительные мощности.
TextMate
Редактор TextMate мощен и нетребователен к ресурсам. Правда, он не умеет выполнять потрясающие манипуляции, на которые способны IntelliJ и Eclipse. У него нет мощного lisp-ядра и библиотеки Emacs. Он не обладает скоростью и гибкостью vi. С другой стороны, его можно быстро освоить, а выполняемые операции интуитивно понятны.
Я использую TextMate время от времени, особенно для спонтанного программирования на C++. В крупном проекте я бы использовал Emacs, но для небольших задач на C++ мне просто лень с ним возиться.
Отслеживание задач
Сейчас я использую Pivotal Tracker. Эта система проста и элегантна, она хорошо интегрируется с гибкими/итеративными методологиями и позволяет всем заинтересованным сторонам и разработчикам быстро общаться друг с другом. Я очень доволен ей.
В очень мелких проектах я иногда использую Lighthouse. Эта система очень проста и удобна в настройке и использовании, но по широте возможностей она и близко не подходит к Tracker.
Также в некоторых случаях я просто использую вики. Такое решение хорошо подходит для внутренних проектов. Вики позволяет применить любую организационную схему на ваше усмотрение, никто не заставляет вас использовать конкретный процесс или жесткую структуру. Этот вариант тоже чрезвычайно прост для понимания и использования.
Иногда лучшей системой отслеживания задач оказывается настенная доска с набором карточек. Доска делится на столбцы (например, «Нужно сделать», «В работе» и «Готово»). Разработчики просто переносят карточки из одного столбца в другой по мере работы над задачами. Пожалуй, это одна из самых распространенных систем отслеживания задач в современных группах, использующих гибкие методологии.
Я рекомендую своим клиентам начать с подобной «ручной» системы, прежде чем приобретать специализированные программы. Освоив ручную систему, клиент получает знания, которые позволят ему сделать разумный выбор – иногда в пользу той же доски с карточками.
Счетчики дефектов
Группе разработчиков определенно необходим список текущих задач. К их числу относятся как задания на реализацию новых возможностей и функций, так и исправления ошибок. Для группы разумного размера (от 5 до 12 разработчиков) такой список должен содержать от несколько десятков до сотен позиций. Не тысяч! Если в вашей системе тысячи ошибок, с ней что-то не так. Если ваш список насчитывает тысячи задач и/или функций, с ней что-то не так. В общем случае список должен быть относительно небольшим, поэтому для работы с ним должно быть достаточно такого несложного инструмента, как вики, Lighthouse или Tracker.
На рынке имеются коммерческие программы, которые выглядят неплохо. Я видел, как мои клиенты пользуются ими, но пока не имел возможности поработать лично. Не имею ничего против таких инструментов – при условии, что список задач остается небольшим и легко управляемым. Когда средства отслеживания задач вынуждены работать со списками из тысяч позиций, само слово «отслеживание» теряет смысл. Список текущих задач превращается в «свалку текущих задач» (и часто пахнет соответствующим образом).
Непрерывная сборка
В последнее время для обеспечения непрерывной сборки я использую Jenkins. Система нетребовательна, проста, а работа с ней не требует длительной подготовки. Вы загружаете программу, запускаете ее, проводите несложную настройку конфигурации – а дальше все работает. Очень удобно.
Мой подход к непрерывной сборке прост: свяжите ее с системой управления исходным кодом. Каждый раз, когда в базе регистрируется измененный код, должна выполняться непрерывная сборка, отчет о результатах которой выдается группе.
Группа просто обязана следить за тем, чтобы сборка всегда проходила успешно. Если сборка не проходит, это должно стать тревожным сигналом, а группа должна немедленно собраться для решения проблемы. Ни при каких условиях недействующая сборка не должна существовать более суток.
В проекте FitNesse я требую, чтобы каждый разработчик выполнял сценарий непрерывной сборки перед регистрацией своих изменений. Сборка занимает менее 5 минут, так что она необременительна. Если в ходе сборки обнаруживаются проблемы, разработчики устраняют их до регистрации. Таким образом, автоматическая сборка редко сталкивается с какими-либо проблемами. Чаще всего проблемы при автоматической сборке возникают из-за настроек рабочей среды, поскольку моя среда автоматической сборки значительно отличается от сред разработчиков.
Инструменты модульного тестирования
Для каждого языка существуют свои специализированные средства модульного тестирования. Лично я использую JUnit для Java, rspec для Ruby, NUnit для. Net, Midje для Clojure и CppUTest для C и C++.
