litceysel.ru
добавить свой файл
  1 ... 5 6 7 8

60. Невероятно, но факт: тестеры – ваши друзья

Берк Хуфнагел (Burk Hufnagel)

Как бы они сами себя ни называли – «Контролем качества» или «Управлением качеством», – многие программисты зовут их «напастью». Мой опыт показывает, что у программистов часто враждебные отношения с теми, кто тестирует их программы. «Они слишком придираются» или «они хотят, чтобы все было идеально» – вот обычные жалобы. Знакомо, да?

Не знаю, по каким причинам, но у меня всегда был другой взгляд на тестеров. Может быть потому, что «тестером» на моей первой работе была секретарь фирмы. Маргарет была очень милой женщиной, которая вела делопроизводство и пыталась научить пару молодых программистов профессиональному поведению с клиентами. У нее также был дар обнаруживать любой баг, каким бы незаметным он ни был, в считанные секунды.

В то время я работал над программой, которую написал бухгалтер, считавший себя программистом. Естественно, с ней были большие проблемы. Когда мне казалось, что я исправил какой-то кусок, Маргарет пыталась поработать с ним, и слишком часто после нескольких нажатий на клавиши оказывалось, что он неправильно работает, но неким новым образом. Часто это вызывало отчаяние и неловкость, но она была настолько любезна, что мне никогда не приходило в голову обвинить ее в моем жалком положении. Наконец, наставал день, когда Маргарет могла без проблем запустить программу, ввести счет, распечатать его и выйти из программы. Я был в восторге. Более того, когда мы установили программу на машине клиента, все заработало правильно. Клиент не обнаружил никаких проблем, потому что сначала Маргарет помогла мне обнаружить их и исправить.

Вот почему я говорю, что тестеры – ваши друзья. Возможно, вы считаете, что тестеры роняют вашу репутацию, докладывая о тривиальных проблемах. Но когда клиент в восторге, потому что ему не досаждают все «мелочи», которые QC заставил вас исправить, тогда вы на высоте. Мысль понятна?

Представьте себе такую ситуацию: вы тестируете программное средство, использующее «сногсшибательные алгоритмы искусственного интеллекта» для нахождения и исправления ошибок параллельной обработки. Вы запускаете программу и обнаруживаете, что на заставке слово «интеллект» написано с ошибкой. Несколько дурное предзнаменование, но ведь это лишь опечатка, верно? Потом вы обнаруживаете, что экран настройки содержит флажки, когда там должны быть переключатели, а некоторые комбинации клавиш не работают. Все это мелочи, но по мере их накопления вы начинаете думать об авторах программы. Если они не могут справиться с простыми вещами, каковы шансы, что их ИИ действительно может найти и исправить такие замысловатые вещи, как проблемы параллельной обработки?


Возможно, это гении, которые настолько погрузились в задачи ИИ, что не обратили внимания на тривиальные проблемы, а в отсутствие «придирчивых тестеров», обнаруживающих проблемы, вам придется находить их самому. А в результате вы начинаете сомневаться в компетентности программистов.

Следовательно, как ни странно, эти тестеры, полные решимости найти все мелкие недостатки вашего кода, в действительности оказываются вашими друзьями.

61. Один двоичный модуль


Стив Фримен (Steve Freeman)

Я встречал несколько проектов, в которых при сборке переписывалась часть кода, чтобы для каждой целевой среды генерировался специальный двоичный модуль. Такая практика всегда чрезмерно усложняет вещи и создает риск появления несовместимых версий в каждой инсталляции. Как минимум, при этом собирается несколько почти идентичных экземпляров программы, каждый из которых предназначен для установки в соответствующей ему среде. Возникает слишком много движущихся частей, а значит, больше возможностей для ошибки.

Однажды я работал в команде, где после каждого изменения свойства нужно было сохранять код и проводить полный цикл сборки, поэтому тестеры находились в постоянной готовности на случай внесения малейшей поправки (при этом сборка осуществлялась также слишком долго). Работал я и в такой команде, где системные администраторы требовали отдельной полной сборки для поставляемого продукта (с помощью тех же самых скриптов), что означало отсутствие уверенности в том, что поставлялась та же версия, которая прошла тестирование. И так далее.

Правило должно быть простым: собирать единственный двоичный модуль, который можно точно идентифицировать и провести через все этапы конвейера выпуска продукта. Все специфические для среды детали должны храниться в самой среде. Это может быть, например, контейнер с компонентами, известный файл или заданный путь.

Если в вашей команде применяется сборка с манипулированием кодом или в коде хранятся настройки целевой среды, значит, проектирование было проведено недостаточно тщательно и не разделило те функции, которые являются неотъемлемой частью приложения, и те, которые относятся к специфике платформы. Или еще хуже: команда знает, как нужно поступить, но не считает внесение нужных изменений достаточно приоритетной задачей.


Бывают, конечно, исключения: иногда приходится делать сборку для целевых сред, существенно различающихся доступными ресурсами, но это не касается большинства из нас, пишущих приложения типа «вывод базы данных на экран и обратно».

Другой вариант – работа с унаследованным программным обеспечением, сразу навести порядок в котором слишком тяжело. В таких случаях нужно двигаться пошагово, но начать это делать нужно как можно скорей.

И еще одно: храните информацию о среде в виде версий. Нет ничего хуже, чем испорченная конфигурация среды, когда узнать, какие в нее были внесены изменения, невозможно. Версии информации о среде должны нумероваться отдельно от кода, так как они меняются с разной скоростью и по разным причинам. Некоторые команды используют для этого распределенные системы управления версиями (например, bazaar и git), поскольку в них проще сохранять в хранилище изменения, сделанные в рабочей среде – а они неизбежно случаются.

62. Правду скажет только код


Петер Зоммерлад (Peter Sommerlad)

В конечном счете, семантика программы определяется работающим кодом. Если он есть у вас только в двоичном виде, это не простое чтение! Однако исходный код может быть доступен, если это ваша собственная программа, типичная коммерческая разработка, проект open source или код на динамически интерпретируемом языке. При чтении исходного кода смысл программы должен быть очевиден. С уверенностью узнать, что делает программа, можно, только глядя в исходный код. Даже самое точное описание технических требований не скажет всей правды: в нем содержится не детальное описание того, что фактически делает программа, а описанные на высоком уровне пожелания составителя требований. Проектная документация может содержать описание планируемой разработки, но в ней могут отсутствовать нужные детали реализации. Эти документы могут устареть в сравнении с текущей реализацией или просто потеряться. А главное, их, возможно, никогда и не писали. Исходный код может быть единственным, что осталось.


Учтя все сказанное, задайте себе вопрос, насколько понятно ваш код может рассказать вам или другому программисту, что он делает.

Возможно, вы скажете, что ваши комментарии содержат все, что может потребоваться. Но учтите, что комментарии – это не работающий код. Они могут вводить в заблуждение так же, как любая другая документация. Есть традиционное мнение, что комментарии – это безусловно хорошее дело, поэтому некоторые программисты без всяких сомнений пишут обширные комментарии, даже повторяя и разъясняя в них пустяки, очевидные в самом коде. Это ошибочный способ сделать код понятным.

Если ваш код нуждается в комментариях, попробуйте переделать его так, чтобы надобность в них отпала. Длинные комментарии загромождают экран и даже могут быть скрыты вашей IDE. Если нужно пояснить сделанную модификацию, сделайте это не в коде, а с помощью сообщения в системе управления версиями.

Что можно сделать, чтобы ваш код действительно говорил правду и как можно яснее? Старайтесь выбирать хорошие имена. Организуйте свой код с учетом связной функциональности, что также облегчает выбор имен. Уменьшите связность вашего кода, чтобы достичь ортогональности. Напишите автоматизированные тесты, раскрывающие задуманное поведение, и проверьте интерфейсы. Безжалостно переделывайте код, если найдете простое, лучшее решение. Старайтесь, чтобы ваш код был как можно проще для чтения и понимания.

Относитесь к своему коду как к любому другому творческому тексту – стихотворению, эссе, открытому блогу или важному электронному письму. Тщательно формулируйте то, что хотите выразить, чтобы код делал то, для чего предназначен, и как можно проще сообщал, что он делает, – так, чтобы ваши намерения были ясны, когда их нельзя уже будет узнать у вас самого.

Помните, что полезным кодом пользуются гораздо дольше, чем предполагают его авторы. Те, кто будут сопровождать ваш код, останутся вам благодарны. А если вы сами занимаетесь сопровождением и код, с которым вы работаете, не спешит раскрыть свои тайны, применяйте вышеупомянутые принципы в упреждающем стиле. Придайте коду некоторое здравомыслие и сохраняйте собственную разумность.

63. Возьмите на себя руководство сборкой (и реорганизуйте ее)


Стив Берчук (Steve Berczuk)

Не столь редко бывает, что команды, в целом твердо соблюдающие дисциплину в отношении практики кодирования, пренебрежительно относятся к скриптам для сборки – либо считая их малозначительными, либо предполагая, что они настолько сложны, что требуют особых знаний, которыми располагают те, кто отвечает за выпуск продукта. Оставленные без внимания скрипты сборки, содержащие дублирование и ошибки, вызывают не меньшие проблемы, чем плохо поделенный на части код.

Одна из причин, по которым ответственные и грамотные разработчики рассматривают сборку как некую второстепенную работу, заключается в том, что скрипты для сборки часто пишут на ином языке, чем исходный код. Другая причина в том, что скрипты сборки – не настоящий «код». Такие оправдания противоречат тому обстоятельству, что большинство разработчиков с удовольствием изучает новые языки и что в результате сборки появляются исполняемые модули, которые разработчики и конечные пользователи могут тестировать и запускать. Код бесполезен, если из него не собирается исполняемый модуль, а сборка определяет компонентную архитектуру приложения. Сборка – важная часть процесса разработки, а установленные для процесса сборки правила могут упростить код и кодирование. Использование в скриптах сборки ошибочных идиом затрудняет их сопровождение и возможность совершенствования. Стоит потратить некоторое время, чтобы разобраться, как правильно выполнить модификацию. Если приложение собирается с неверными версиями зависимых объектов или конфигурация этапа сборки не верна, могут возникнуть ошибки.

Традиционно тестирование всегда возлагалось на группу «контроля качества». Сейчас мы понимаем, что тестирование в процессе кодирования – необходимое условие для получения предсказуемого результата. В этом ключе процессом сборки должна управлять команда разработчиков.

Понимание процесса сборки может упростить весь жизненный цикл разработки и сократить издержки. Простая сборка дает возможность новому разработчику быстро и легко включиться в работу. Автоматизация конфигурации в сборке может помочь получению согласующихся результатов, когда над проектом работает несколько человек, и избежать заявлений, что «у меня это работает». Многие инструменты сборки позволяют получать отчеты о качестве кода, дающие возможность заранее обнаружить потенциальные проблемы. Придумав, как самим управлять процессом сборки, вы облегчите жизнь себе и всем остальным участникам вашей команды. Вы сможете сосредоточиться на кодировании функций, что принесет пользу вашим ответственным участникам и сделает вашу работу более приятной.


Изучите процесс сборки в достаточной мере, чтобы знать, когда и как делать в нем модификации.

Скрипты сборки – это тоже код. Они слишком важны, чтобы доверить их кому-то другому, хотя бы по той причине, что приложение не закончено, пока оно не собрано. Задача программирования не завершена, пока не поставлено работающее программное обеспечение.

64. Программируйте парами и входите в поток


Гудни Хаукнес, Кари Россланд и Анн Катрин Гагнат (Gudny Hauknes, Kari Røssland, Ann Katrin Gagnat)

Представьте себе, что вы совершенно поглощены своей работой: сосредоточены, увлечены и заняты. Вы потеряли счет времени. Вы счастливы. Вы в состоянии потока. Трудно достичь и поддерживать состояние потока в команде разработчиков из-за многочисленных помех, отвлечений и прочих препятствий, которые легко могут его прервать.

Если вы уже участвовали в парном программировании, то, вероятно, знаете, как оно способствует достижению состояния потока. Если нет, то мы хотим поделиться своим опытом, чтобы побудить вас заняться им немедленно! Чтобы парное программирование было успешным, требуются некоторые усилия со стороны отдельных участников команды и всей команды в целом.

Действуя в команде, будьте снисходительны к разработчикам, у которых меньше опыта, чем у вас. Преодолейте свой страх перед более опытными разработчиками. Поймите, что люди различны между собой, и это большая ценность. Знайте сильные и слабые стороны как себя самого, так и других членов команды. Для вас может оказаться неожиданностью, как многому можно научиться у своих коллег.

Работая в команде, используйте парное программирование для распространения мастерства и знаний среди участников проекта. Задачи нужно решать парами и часто менять пары и задачи. Установите правило, в соответствии с которым должна происходить ротация. При необходимости откажитесь от этого правила или скорректируйте его. Наш опыт показывает, что не обязательно довести задачу до конца, а можно передать ее следующей паре. Прервать задачу, чтобы передать ее другой паре, может показаться нелогичным, но мы обнаружили, что это эффективно.


Есть много ситуаций, когда состояние потока может быть утрачено, но программирование в парах позволяет его сохранить:


  • Снижается роль «фактора грузовика». Это не совсем приятный мысленный эксперимент, но ответьте, сколько членов вашей команды должно попасть под грузовик, чтобы команда не смогла осуществить выпуск конечного продукта? Иными словами, насколько выпуск вашего конечного продукта зависит от определенных участников команды? Находятся ли знания в закрытом или в общем доступе? Если вы осуществляете ротацию заданий между парами, всегда найдется кто-то еще, обладающий знаниями, необходимыми для завершения работы. На состояние потока вашей команды «фактор грузовика» не повлияет.

  • Эффективно решаются проблемы. Если вы программируете в паре и сталкиваетесь со сложной проблемой, вам всегда есть с кем ее обсудить. В таком обсуждении скорее может найтись решение, чем если вы будете биться над ним в одиночестве. При ротации работы ваше решение будет повторно рассмотрено следующей парой, поэтому не столь важно, если ваше первоначальное решение окажется неоптимальным.

  • Плавно проходит интеграция. Если ваша текущая задача требует обращения к другому фрагменту кода, желательно, чтобы названия методов, документы и тесты были достаточно содержательны для быстрого понимания его работы. Если это не так, то работая в паре с разработчиком того фрагмента кода, вы сможете лучше и быстрее интегрировать его в свой код. Кроме того, вы можете обсудить с ним возможность изменения имен, документов и тестов.

  • Сокращаются отвлечения. Если кто-то обращается к вам с вопросом, или звонит телефон, или нужно срочно ответить на письмо, или нужно принять участие в совещании, ваш партнер по программированию может продолжить работу над кодом. Когда вы вернетесь, ваш напарник все еще будет в состоянии потока, и вы сможете быстро догнать его.
  • Новые участники команды быстро наращивают скорость своей работы. При парном программировании и надлежащей ротации пар и задач новички быстро знакомятся как с кодом, так и с другими членами команды.


Поток делает вас необычайно продуктивным. Но это состояние легко утрачивается. Старайтесь всеми силами войти в него, а потом удержать!

65. Используйте предметно-ориентированные типы вместо базовых


Эйнар Ландре (Einar Landre)

23 сентября 1999 года космический аппарат Mars Climate Orbiter стоимостью $327,6 был потерян при выходе на орбиту вокруг Марса из-за в программной ошибки на Земле. Ошибка была потом названа «смешением систем мер». Наземная станция использовала для измерения силы фунты, а космическая предполагала ньютоны, в результате чего наземная станция ошиблась в оценке мощности ускорителей аппарата в 4,45 раза.

Это один из многих примеров отказов программного обеспечения, которых можно было избежать благодаря более строгой и предметно-ориентированной типизации. Это также пример оснований для многих особенностей языка Ada, одной из главных задач разработки которого было создание встроенного отказоустойчивого программного обеспечения. В Ada применяется строгая типизация со статической проверкой как базовых, так и определенных пользователем типов:

type Velocity_In_Knots is new Float range 0.0 .. 500.00;

type Distance_In_Nautical_Miles is new Float range 0.0 .. 3000.00;

Velocity: Velocity_In_Knots;

Distance: Distance_In_Nautical_Miles;

Some_Number: Float;

Some_Number:= Distance + Velocity; -- Компилятор определит здесь ошибочное использование типов.

Разработчики в менее критичных областях также могут выиграть от более широкого применения предметно-ориентированной типизации, либо продолжать использовать базовые типы данных, предлагаемые языком и его библиотеками, такие как строки и числа с плавающей запятой. В Java, C++, Python и других современных языках существует такой абстрактный тип данных, как класс. Использование таких классов, как Velocity_In_Knots (скорость в узлах) и Distance_In_Nautical_Miles (расстояние в морских милях) значительно повышает качество кода:


  • Код легче читать, поскольку он описывает понятия предметной области, а не просто строки или числа

  • Код легче тестировать, потому что он инкапсулирует поведение, которое легко проверить.

  • Код облегчает повторное использование в разных приложениях или системах

Такой подход в равной мере пригоден для использования в языках как со статической, так и с динамической типизацией. Единственное различие в том, что в языках со статической типизацией разработчик получает некоторую помощь от компилятора, тогда как при работе с языками с динамической типизацией больше приходится полагаться на модульное тестирование. Могут различаться стили проверки, но не мотивация и стиль выражения.

Мораль: начинайте исследовать предметно-ориентированные типы с целью улучшения качества разрабатываемых программ.

66. Предотвращайте появление ошибок


Жиль Колборн (Giles Colborne)

Сообщения об ошибках – наиболее критичный вид взаимодействия между пользователем и системой. Они возникают, когда общение пользователя с системой близко к тому, чтобы прекратиться.

Проще всего считать, что ошибка возникает в результате ввода пользователем неверных данных. Но люди совершают ошибки предсказуемым и систематическим образом. Поэтому можно «отлаживать» взаимодействие между пользователем и системой так же, как взаимодействие между другими компонентами системы.

Допустим, например, что пользователь должен ввести дату в определенном диапазоне. Вместо того чтобы давать ему возможность ввести любую дату, лучше предоставить ему средство типа списка или календаря, которое покажет только допустимые даты. Это исключит всякую возможность ввода даты за пределами разрешенного диапазона.

Ошибки форматирования составляют еще одну распространенную проблему. Например, если пользователь видит текстовое поле для даты и вводит однозначно трактуемую дату, такую как «29 июля 2012», будет неправильным не принять его данные только потому, что они имеют не тот формат, который вы предпочитаете (например, "DD/MM/YYYY"). Еще хуже отклонить "29 / 07 / 2012" только из-за лишних пробелов – такие проблемы менее всего понятны пользователям, потому что им кажется, что формат даты правилен. Такая ошибка возникает, потому что проще отклонить данные, чем проанализировать три или четыре наиболее распространенных формата. Такие мелкие ошибки вызывают у пользователя растерянность, а в результате он не может сосредоточиться и делает новые ошибки. Лучше проявить уважение к привычкам пользователя при вводе данных, а не к данным.


Другой способ избежать ошибки форматирования – дать пользователю намек, например, с помощью метки, которая показывает нужный формат ("DD/MM/YYYY"). Другой способ намекнуть – разделить поле на три части по два, два и четыре символа.

Намеки – это не инструкции, а, скорее, подсказки, тогда как инструкции даются текстом. Намеки появляются в момент взаимодействия, а инструкции – до этого момента. Намеки дают контекст; инструкции диктуют поведение.

Обычно инструкции малоэффективны в предотвращении ошибок. Пользователи склонны считать, что интерфейсы должны действовать согласно их прежнему опыту («любому должно быть понятно, что такое 29 июля 2012!»). Поэтому инструкции не читают. Намеки подталкивают пользователей к тому, чтобы не сделать ошибки.

Еще один способ избежать ошибок – предлагать значения по умолчанию. Например, пользователи обычно вводят значения, соответствующие текущей дате, следующему дню, своему дню рождения, сроку окончания работы или дате, введенной в этой форме в предыдущий раз. В зависимости от контекста одна из этих дат может быть хорошим кандидатом на значение по умолчанию.

Какова бы ни была причина ошибки, система должна отнестись к ней терпимо. Этому можно содействовать, обеспечив возможность многоуровневой отмены всех выполненных операций – в особенности тех, которые могут удалить или модифицировать данные пользователя.

Регистрация действий и анализ операций возврата могут пролить свет на то, какие свойства интерфейса заставляют пользователей бессознательно совершать ошибки, такие как повторяющееся нажатие «неверной» кнопки. Такие ошибки часто вызываются вводящими в заблуждение подсказками или последовательностями действий, которые можно перепроектировать, чтобы предотвратить появление ошибок.

Какой бы подход вы ни избрали, большинство ошибок являются систематическими – результатом взаимного непонимания между пользователем и программным обеспечением. Выяснив, как пользователи думают, как интерпретируют данные, принимают решения и вводят данные, вы сможете с большим успехом отладить взаимодействие между вашими программами и их пользователями.

67. Профессиональный программист


Роберт Мартин (Robert C. Martin – «Uncle Bob»)

Что такое профессиональный программист?

Самая главная черта профессионального программиста – личная ответственность. Профессиональные программисты отвечают за свою карьеру, свои оценки, свои обязательства, свои ошибки и свое мастерство. Профессиональный программист не перекладывает эту ответственность на других.

  • Если вы профессионал, то отвечаете за свою карьеру. Вы ответственны за то, чтобы читать и учиться. Вы ответственны за знание современного уровня отрасли и технологий. Слишком часто программисты считают, что обучать их – задача работодателя. Извините, но это совершенное заблуждение. Как вы думаете, врачи ведут себя так же? А юристы? Нет, они учатся в свое свободное время и на собственные средства. Они проводят значительную часть свободного времени, читая журналы и документы. Они поддерживают свой профессиональный уровень. То же самое должны делать и мы. Отношения между вами и работодателем хорошо описаны в вашем контракте. Если коротко, то работодатель обязуется вам платить, а вы обязуетесь хорошо работать.

  • Профессионалы отвечают за код, который пишут. Они не выпускают код, если не уверены в его работе. Задумайтесь на минуту. Как вы можете считать себя профессионалом, если готовы выпустить код, в котором у вас нет уверенности? Профессиональные программисты не ждут, что QA что-то найдет в их коде, потому что они выпускают его не раньше, чем досконально протестируют. Конечно, QA что-нибудь обнаружит, потому что никто не идеален. Но как профессионалы мы должны стремиться к тому, чтобы QA не смог ничего найти.
  • Профессионалы – это игроки команды. Они отвечают за результат всей команды, а не только за свою работу. Они помогают другим, учат других, учатся сами у других и даже защищают других при необходимости. Когда один участник команды спотыкается, другие вступаются за него, зная, что когда-нибудь им самим понадобится поддержка со стороны.


  • Профессионалы не мирятся с длинными списками багов. Большой список ошибок – это противно. Системы, в базах данных ошибок которых хранятся тысячи пунктов – это трагедия безответственности. На самом деле, во многих проектах сама необходимость ведения базы данных ошибок служит признаком безответственности. Только очень большие системы могут иметь такие большие списки ошибок, что для контроля за ними требуются автоматические средства.

  • Профессионалы поддерживают порядок в делах. Они гордятся своим искусством. Их код понятен, хорошо структурирован и легок для чтения. Они следуют оговоренным стандартам и лучшим практикам. Они никогда не делают ничего впопыхах. Представьте себе, что вы можете наблюдать снаружи, как врач делает вам операцию на открытом сердце. У этого врача есть крайний (в буквальном смысле) срок. Он должен закончить операцию до того, как аппарат искусственного сердца повредит слишком много кровяных клеток. Как, по-вашему, он должен себя вести? Как типичный программист, делающий все в спешке и беспорядке? Может ли он решить, что вернется к этому потом и все исправит? Или все же он должен тщательно придерживаться правил своей науки, рассчитывать время и быть уверенным, что избранный им подход – лучший из тех, которые ему доступны? Чего вы хотите – беспорядка или профессионализма?

Профессионалы обладают чувством ответственности. Они отвечают за свою личную карьеру. Они отвечают за правильную работу своего кода. Они отвечают за уровень своего мастерства. Они не отказываются от своих принципов, когда на них давят сроки. На самом деле, когда давление растет, профессионалы еще крепче держатся за тот порядок, который считают правильным.

68. Все должно храниться в системе управления версиями


Диомидис Спинеллис (Diomidis Spinellis)

Храните все, что касается любых ваших проектов, в системе управления версиями. Необходимые для этого ресурсы имеются: бесплатные инструменты типа Subversion, Git, Mercurial и CVS, вдоволь дискового пространства, дешевые и мощные серверы, всюду доступная сеть и даже службы для размещения проектов. После установки ПО управления версиями все, что требуется для сохранения ваших трудов в его хранилище – это выполнить соответствующую команду в чистом каталоге, содержащем ваш код. А освоить нужно всего две новые основные операции: запись изменений в коде в хранилище и обновление вашей рабочей версии проекта до той, которая находится в хранилище.


После того как ваш проект помещен в систему управления версиями, можно без труда просмотреть его историю, узнать, кто написал каждый фрагмент кода и указать версию файла или проекта с помощью уникального идентификатора. Еще важнее, что вы можете смело модифицировать код – не нужно комментировать код на случай, если он потребуется в будущем, потому что старая версия надежно лежит в хранилище. Можно (и нужно) помечать окончательные версии символическими именами, чтобы потом быстро получить именно ту версию, которая работает у вашего клиента. Можно создавать отдельные ветви и разрабатывать их параллельно: в большинстве проектов есть активно разрабатываемая ветвь и одна или несколько ветвей более ранних версий, которые активно сопровождаются.

Система управления версиями минимизирует конфликты между разработчиками. Когда программисты работают над независимыми частями программного обеспечения, их интеграция проходит на ура. Когда они начинают мешать друг другу, система видит это и предлагает урегулировать конфликт. Дополнительные настройки системы позволяют оповещать всех разработчиков о каждой внесенной модификации, что дает всем равное представление о ходе развития проекта.

Организуя работу над проектом, не жадничайте: поместите под контроль версий все, что относится к проекту. Помимо исходного кода подключите документацию, инструментарий, скрипты для сборки, контрольные примеры, графику и даже библиотеки. Когда весь проект надежно помещен в хранилище (для которого регулярно делается резервная копия), возможный ущерб от потери диска или данных становится минимальным. Чтобы начать разработку на новой машине, нужно просто выписать проект из хранилища. Это упрощает распространение, сборку и тестирование кода на разных платформах: на любой машине единственная команда обновления гарантирует вам загрузку текущей версии программного обеспечения.

После того как вы оцените прелести работы с системой управления версиями, присмотритесь к следующим правилам, которые сделают еще более эффективной вашу работу и работу вашей команды:


  • Сохраняйте каждое логическое изменение в виде отдельной операции. Скинув одновременно множество модификаций в одной операции, вам будет трудно разделить их впоследствии. Это особенно важно, когда проводится рефакторинг или изменение стиля в рамках всего проекта, что может легко скрыть другие модификации.

  • Сопровождайте каждое изменение пояснительной запиской. Как минимум, кратко опишите, что вы изменили, но если вы хотите также сохранить основания для сделанных изменений, это самое лучшее место.

  • Наконец, не сохраняйте код, который срывает сборку проекта, иначе другие участники проекта будут весьма вами недовольны.

Жить с системой управления версиями слишком приятно, чтобы портить себе удовольствие ошибками, которых легко избежать.


1 http://martinfowler.com/eaaCatalog/lazyLoad.html

2http://www.processing.org/



<< предыдущая страница