Инженерная культура, командная работа
Два понятия объединены вместо, чтобы сильно не дробить тему. К тому же, командная работа в принципе невозможна без привитой каждому участнику команды инженерной культуры. Сначала об инженерной культуре.
Понятие сложное, чтобы его свести в емкое определение. Сюда включено много внешне независимых понятий, которые сами по себе мало что значат, но объединенные вместе под словами "инженерная культура" становятся сильнейшим катализатором повышения уровня профессионализма.
Начну с общения. Инженерная культура подразумевает, что вы владеете терминологией, умеете ее правильно использовать в дискуссиях, а также свободно ориентируетесь в жаргонном сленге. Попробуйте себя проверить, поймете ли вы о чем говорится в следующих фразах:
- "… А ты создавай компонент в "ран-тайме" и присваивай ему "парентом" главную форму…"
- "…Подменяй в "квери" динамически условие "where", и прибей к нему план запроса…"
- "…Отпиши в трекер про эту багу, ковыряю ее на днях…"
- "…Слил код с cvs, просмотрел дифы и закоммитил…"
- "…Сегодня в "ньюсах" пробегала "инфа" о выходе нового релиза…"
Кстати, про релизы. Система нумерации версий ПО на сегодняшний день еще не устоялась. Если раньше продавали ПО, в имени которого фигурировал номер версии, то потом перешли на наименования по году выпуска, а номер версии стал внутренним атрибутом программы. Теперь уже и год выпуска уходит в прошлое- популярность набирает именование версии ПО просто красивым именем: "Виста", "Арканоид", "Центрино" и т.д. Но внутренние версии именуются все также: до точки ставится номер версии ПО, после точки- промежуточные варианты, связанные с внесением в ПО незначительных улучшений и устранением ошибок. В скобках также указывается номер билда. Номера билдов- это сквозная нумерация всех сборок программы, номер билда не сбрасывается в нуль при переходе к другой версии, он всегда только возрастает. Строго говоря, номер билда- это более точный идентификатор ПО, чем версия, т.к. в рамках одной версии может быть собрано несколько билдов с незначительными отличиями. Тем не менее, при обнаружении ошибок наиболее достоверный способ разработчику узнать, какие изменения привели к ошибке- это посмотреть номер именно билда, а не версии программы. Примеры версий программы:
- 1.01 (123)- версия (еще называемая мажорная версия) 1, в рамках этой версии- подверсия (минорная версия)- 01, билд- 123.
- 3.17 (1435) - версия 3, подверсия 17, билд- 1435.
Методологии программирования. С целью повышения продуктивности труда инженера и обеспечения стабильности выдаваемого им результата постоянно разрабатываются новые методики программирования. Существенного результата до сих пор не дала ни одна методика. Единственное, на чем все точно сошлись, так это на том, что каскадная разработка окончательно уступила место итерационному способу разработки ПО. Это случилось давно и нынешнее поколение молодых разработчиков уже нигде с ней (каскадной методикой разработки) не столкнется. А суть итерационного способа разработки сводится к тому, что сначала делаются крупные наброски, основной функционал, реализация которого требуется в первую очередь, и затем, круг за кругом функционал прорабатывается более детально с учетом замечаний заказчика, устраняя по пути обнаруженные ошибки. При такой методике зачастую оказывается, что проект далеко уходит от первоначальных планов, а для заказчика наиболее важным оказывается другое, чем то, что считалось в начале. Благодаря итерационному подходу подобные вещи выясняются наиболее быстро, а сама методика позволяет гибко адаптироваться к изменяющимся требованиям.
Выпуску программы предшествуют несколько этапов ее разработки. Различные методологии программирования тут расходятся, но основной, наиболее практикуемый вариант следующий:
- Обсуждение функционала. Это когда собирается группа и обсуждает, как надо сделать. Рисуют на доске, на листках, обсуждают после совещания в коридорах. Распределяются обязанности.
- Делается первый черновой вариант, густо "нашинкованный" заглушками. Вариант обсуждается, учитывается первый опыт, замечания и разработка идет на второй круг.
- Когда руководитель видит, что пора уже делать релиз, дается команда чуть притормозить коммиты в CVS нового функционала, а усиленно "довести до ума" функционал, который должен войти в релиз. Если вы не успели "довести до ума", то страшного ничего не будет, но вам добавиться лишняя работа т.к. наступит следующий этап.
- Создается ветка в CVS. С этого момента новый функционал в ветку не добавляется, а коммитится в HEAD. В ветке с готовящимся релизом сидят разработчики, усиленно дорабатывающие ПО. В HEAD'e продолжает работать небольшая часть разработчиков. С этого момента начинают выкладываться так называемые "снап-шоты". Это ночные сборки всего ПО, которое должно войти в релиз. В эти сборки сходят изменения, сделанные разработчиками за день.
- По мере готовности версии продукта, руководитель принимает решение о выпуске альфа-версии. Эта версия позволяет широкому кругу пользователей предварительно ознакомиться с ПО, а разработчикам получить обратный отклик ("фид-бэк") о ПО, а также список обнаруженных пользователями ошибок ("багов").
- Когда функционал программы сформирован, выпускается RC1 (release candidate 1), т.е. предварительная версия. В ней уже нового функционала внедряться не будет, идет только исправление ошибок.
- По мере снижения количества обнаруженных ошибок и их исправления выпускаются RC2, RC3. Крайне редко делают RC4. RC3 уже означает, что ПО в данной версии достигло зрелой стадии и пригодно к эксплуатации. Количество разработчиков, работающих над данной веткой продукта, уменьшается, т.к. для исправления ошибок их уже много не надо. Многие переходят на разработку следующей версии, как говорят "работать в HEAD'e". Такая вот несколько необычная ситуация- еще текущую версию не выпустили, уже работают на следующей. Легко может в производстве находится 1-2 версии ПО одновременно, и еще плюс экспериментальные разработки (это уже только в очень крупных компаниях уровня Microsoft).
- И вот, наступает долгожданный момент, и объявляется о выпуске релиза (release). Именно релиз начинает массово распространяться, рекламироваться, а разработчики расходятся по другим проектам. Выпуск сопровождается банкетом для всех разработчиков, в каждой фирме есть свои традиции выпуска релизов: вручение памятных знаков, "золотых" дисков с релизом ПО и т.п.
Участие в полном цикле разработке и выпуске релиза считается ценным опытом. Многие фирмы при приеме на работу весьма положительно смотрят на соискателей, имеющих подобный опыт.
Ночные сборки полезны сторонним разработчикам, которые будут использовать готовящийся продукт в своем ПО. Сторонние разработчики являются не просто опытными пользователям ПО, наиболее доверенным из них предоставляется доступ к части исходного кода программы. Имея доступ к низкоуровневым интерфейсам программы, они, что называется, видят ее изнутри, и могут свежим взглядом со стороны подсказать направления реализации тех или иных возможностей, указать на ошибки, и даже ошибки проектирования. Для общения с наиболее активными пользователями и сторонними разработчиками создаются специализированные форумы, нередко сторонние разработчики напрямую по e-mail обращаются к разработчикам выпускаемой версии ПО, встречаются на семинарах и конференциях, где неформально общаются и обсуждают готовящийся релиз. Сторонние разработчики стараются вместе с анонсом выпуска релиза вашего ПО, объявить о выпуске своего ПО, полностью поддерживающего функционал новой версии вашей программы.
Внутри команды обычно возникают специализации: у кого что лучше получается, тот тем и занимается. Кто-то берется за написание связи с базами данных, кто-то отвечает за сохранение в файл, соответственно, правит и найденные баги, которые относятся к его модулю. Принято не самому править баг, а сообщить о нем человеку, ответственному за модуль, где найден баг, чтобы он его исправил. Это связано с тем, что не занимаясь вплотную этим модулем, где обнаружен баг можно: во-первых, не учесть некоторых неявных зависимостей и, по незнанию, вообще завалить сборку; во-вторых, вы затратите на устранение бага больше времени, чем это займет у программиста, занимающегося этим модулем вплотную.
Совершенно нормально в команде попросить о помощи, если нет мысли как лучше реализовать функцию или помощь в поиске бага. Иногда, заработавшись, просто не замечаешь правильного решения, и взгляд со стороны очень помогает. Замечено, что иногда достаточно кому-то просто слух объяснить, проговорить постановку задачи или описание бага, и решение само собою всплывает.
Немаловажную роль в понятии инженерной культуры играет умение понятно, красиво оформить код и комментарии в нем. Внутри команды вырабатываются определенные правила оформления код. Придя в команду, смотрите как другие программисты в других модулях оформляют код и комментарии и подражайте им. Если вы программируете в уже существующем модуле, то, во-первых, придерживайтесь стиля оформления кода, принятого в этом модуле, а, во-вторых, не переформатируйте строки, написанные не вами. Второе требование имеет смысл еще и в другом плане. Системы контроля версий помечают за вами все измененные вами строки. Даже, если вы там только один пробельчик м-а-а-аленький такой поставили, то автором этой строки становитесь вы. И теперь багу, связанную с этим кодом, править вам, хотя вы и понятия об этом коде на самом деле не имеете. Кроме того, внимательно изучайте используемые приемы программирования в команде. Вы должны писать программы в одном стиле с остальными разработчиками, тогда код будет легче читаться и модули друг с другом проще будет связать между собой. Единство в оформлении кода, документировании кода и выборе способа решения задач- важный элемент командной работы.
Никакая учеба не способна научить инженерной культуре, это постигается только путем постоянной работы, ежедневным оттачиванием своего мастерства.
Заключение
Описанное в статье хорошо известно опытным IT-специалистам, и информация в статье для них будет тривиальной. Однако, начинающему специалисту о подобных вещах ни в одном университете не расскажут, и, кроме как "на собственных шишках", этому нигде не обучиться. Хотелось бы надеяться, что эта статья поможет молодому специалисту выбрать правильное направление для повышения уровня своего профессионализма.
(Конец)
