Wed 9 Aug 2006
Мысли об апгрейде инструментов
Posted by Alex Lebedev under менеджмент, процесс разработки
[2] Comments
Любая команда из полутора человек и более использует инструменты совместной разработки. Вот инструменты нашего проекта: CVS, CruiseControl.NET, TestTrack. Кроме того, есть еще множество специализированных инструментов разработки, которые должны быть стандартными во всей команде. Для нас это: NUnit, NAnt, Selenium-RC. Добавьте к этому списку еще и все внешние библиотеки, которые вы используете.
Весь этот зоопарк время от времени нужно апгрейдить. CVS нужно менять на Subversion чтобы отказаться, наконец, от ведения change log’ов модулей вручную. Надо апгрейдить NAnt до версии 0.85 rc4, которая корректно работает с NUnit. Надо переписывать старые функциональные тесты на Selenium-RC, а сам Selenium-RC – апгрейдить до следующей версии. TestTrack надо было апгрейдить еще 5 лет назад, но не получается – политика.
В последнее время я много думаю о том, как часто нужно апгрейдить инструменты и библиотеки, которые использует команда. Проходит несколько месяцев и половину того, что вы используете, надо обновлять. Как долго можно пользоваться устаревшим инструментами? Как часто можно вносить в работу дополнительную нестабильность, следствие изменения версий инструментов и библиотек?
Пока идеи следующие:
- Не обновлять ничего за несколько недель до выпуска очередного крупного релиза. Элементарное правило техники безопасности. На второстепенные вещи, не требующиеся для работы системы и не обязательные для выпуска релизов, это правило не распространяется.
- Обновлением занимается не штатный сотрудник, tech lead или назначенный менеджером человек, а тот, кто будет непосредственно пользоваться плодами обновления. Хорошо бы, если обновление инструментов будет завязано на решение конкретных запланированных задач. Бывает, что новая версия одного из инструментов сильно упрощает решение таких задач по сравнению с предыдущей версией. Такой момент идеален для апгрейда.
- По прошествии нескольких месяцев после выхода новой версии нужно подождать удобного момента и обновиться, даже если новые функции не нужны вам примо сейчас. В результате потом будет легче поддерживать совместимость между используемыми вами утилитами.
Небольшое уточнение. Эти размышления не затрагивают вопрос обновления платформы разработки. Кроме того, предполагается, что вы пользуетесь open source продуктами либо имеете возможность бесплатно апгрейдить свои коммерческие продукты. Процесс небесплатного обновления коммерческих продуктов выглядит совсем по-другому и выходит за рамки данных размышлений.
August 13th, 2006 at 12:45
По моему опыту, самое удачное время для обновления инструментария – это подготовка к новому проекту или, если проект длительный, подготовка к запуску разработки очередного релиза. Сам процесс обновления должет включать обучение новым возможностям тех кто будет пользоваться новыми инструментами. Дальше, возможно, рефакторинг с учетом новых возможностей.
August 13th, 2006 at 08:01
Согласен, это хороший консервативный подход к обновлению. Но если ограничиться только им, то можно упустить много возможностей сделать лучше и быстрее.
При традиционном подходе, решение о том, какие инструменты будут использовать разработчики, принимают не они сами, и часто даже не руководитель группы. Я вижу четыре недостатка у такой модели:
1. Человек, принимающий решения об инструментах, часто знает про них меньше чем разработчики. Очевидно, что его решения, как правило, будут хуже, чем решения разработчиков.
2. Разработчики не несут никакой ответственности за снижение качества своей работы, вызванное плохими инструментами. Э не только демонстрирует им, какого мнения руководство об их способности принимать важные решения, но и снижает общую заинтересованность в получении действительно хорошего результата.
3. Человек, выбирающий инструменты, как правило, не несет никакой ответственности за производительность труда разработчиков. А значит, и его интерес будет в том, чтобы в первую очередь достигнуть каких-то других, более значимых для него результатов – снизить риск личной ответственности, выбирая самое распространенное и стандартное решение, использовать солидные и красиво выглядящие на бумаге инструменты, чтобы улучшить свой имидж в глазах руководства, получить откат от продавца инструмента, в конце концов.