В этот раз речь пойдет о модульных тестах и инспекциях кода. Когда мы в нашей команде начали использовать две эти практики в своих проектах, драйва и радости от работы прибавилось на порядок. Упомянутым темам посвящено огромное количество теоретических и практических трудов, но сегодня речь пойдет именно о личной выгоде разработчика.
Сколько времени все мы проводим на работе? Как обычный человек, я провожу в офисе примерно треть своей жизни. А если добавить время, которое мы посвящаем мыслям о работе: дома или в отпуске, за кружкой пива с друзьями или на пикнике под шашлычок?..
Когда последний раз мы спрашивали себя:
— Что я ощущаю, когда иду на работу? Подавленность и депрессию или радость и вдохновение?
— Нравится ли мне то, что я делаю? и то, как я это делаю?
— Что я ощущаю, когда ухожу с работы? Удовлетворение и умиротворение или облегчение и истощение?
— Я хожу на работу по привычке или мне она нравится?
Очевидно, что всем хочется жить полной и гармоничной жизнью, наполненной радостью, удовлетворением, ощущением собственной полезности и силы, с ощущением самоуважения. Живем ли мы такой жизнью здесь и сейчас или откладываем ее на потом?
Не сломалось — не чини!
На одном из предыдущих мест работы мне довелось принимать участие в проекте, которому было уже больше 10 лет. Следов модульных тестов не было в помине, инспекции кода не проводились, каждый разработчик отвечал за свой кусок кода (так называемое личное владение кодом). Ухудшало ситуацию еще и отсутствие общего coding style на проекте, вплоть до того, что где-то использовались пробелы для отступа, а где-то табы. На тот момент про модульные тесты и инспекции кода я лично не знал ничего.
Приходилось ли вам существовать в таком проекте? Каковы воспоминания? А может кто-то выживает в таком проекте прямо сейчас? Б-р-р…
В общем, наш проект представлял собой рассадник багов. Девиз проекта был: не сломалось — не чини; не надо ничего улучшать. А как же внутреннее качество? Можно точно сказать — внутреннее качество проекта с каждым днем только ухудшалось. Ни о каком рефакторинге не могло быть и речи. Слабые попытки провести небольшой анализ с последующим исправлением наиболее критичных косяков заканчивались порождением новых, и иногда каверзных, багов. Знакома ли вам такая ситуация?
Неудивительно, что 80% своего времени я тратил на латание дыр и вникание в запутанную логику кода. Моя работа превратилась в бесконечную рутину и серость. Изо дня в день сплошная беспросветная тоска.
Можно ли назвать такой проект живым? Страх изменений превращал его в настоящего мертвеца. Как получать удовольствие от работы в такой ситуации? Из проекта исчезла искра, он перешел в стадию «дожительства»… а в какую стадию перешли люди на этом проекте?
Приятное ощущение занятости
При всем этом члены команды работали очень интенсивно. Но разве интенсивность обязательно означает эффективность? Сколько энергии и сил уходит на лечение багов, понимание плохого кода? Не тоскливо ли тратить время и силы на ненужную работу?
А как же личная гордость — гордость за то, что делаешь? На тот момент ощущения были удручающими: «Извините, так получилось, что это сделал я».
Если 20% своего времени тратить на полезные фичи и развитие проекта, а 80% — на лечение багов и понимание дурного кода, где взять время на самообразование и саморазвитие?..
В общем, как в пословице: «Хочу учиться, да баги не пускают...»
Надумал я сбежать от всего этого кошмара и пошел проходить интервью в одной очень известной отечественной компании, знакомой всем и каждому (далее просто компания Y). На собеседовании мне дали тестовое задание, с которым я отлично справился (себя не похвалишь — никто не похвалит). Дальше началось обсуждение.
— А как вы будете его тестировать?
— Ну, как… Вручную прогоню пользовательские случаи.
— Все вручную?
— Ну не все полностью, только основные пользовательские сценарии, остальное пускай проверяют тестировщики… В конце концов — я программист или специалист по качеству? (Чукча не читатель, чукча писатель.)
— А как вы будете лечить дефекты, которые найдут специалисты по качеству и клиенты?
— Ну, как-как? Запущу отладчик, найду причину, все поправлю — и отдам на проверку тестировщикам…
— Спасибо, мы вам позвоним…
Похоже на фантастику? Вовсе нет. Я даже помню лица тех парней, что меня собеседовали :) В итоге в компании Y я никогда не работал.
Что делать?
Самый простой путь решения проблемы — сбежать. Но станет ли выходом смена компании или проекта? Придешь на новое место, а там…
По сути ведь мы, программисты, не чужды многим «сейлзовым» ходам. Особенно, когда дело доходит до кода: плохие участки прикрываются фиговым листочком, а все внимание фокусируется на ярких и блестящих достоинствах. Видна только верхушка айсберга, процентов 20, не больше.
На собеседовании мне пропоют про те красивые 10—20%, а страшные 80—90% постараются опустить. Не пройдет и пары месяцев, как все вернется на круги своя… И снова рутина лечения багов и разгребания быдлокода. Шило на мыло.
На этот счет есть отличная притча:
— Мастер, как долго ждать перемен?
— Если ждать, то долго.
Стоит ли рассчитывать на какой-то новый результат, повторяя все время одни и те же действия? Я просто существую эту 1/3 своей жизни, которая происходит на работе, — или живу?
Выбор
Что я выбираю?
a) Жить интересно, развиваться, вдохновенно трудиться, писать элегантный код?
б) Ад на работе, недовольных заказчиков, затюканных коллег, жестких начальников?
Выбор, в общем-то, очевиден. Но прийти к этому не так уж и просто. Помочь программисту начать по-настоящему жить на работе могут инспекции кода и модульные тесты. Всего лишь две простые практики подготовят почву для постоянных улучшений.
Если выбор не делаю я — его сделает за меня кто-то другой: коллега, руководитель, менеджер, клиент, да мало ли кто. Главное, это будет ЧУЖОЙ выбор. Дай бог, если этот выбор окажется на светлой стороне, мой опыт показывает → 99.9% в ад :)
Начни с малого, введи инспекции кода в свой процесс разработки
Первый шаг — выбор инструмента. Это займет не больше недели, а что значит неделя в сравнении с третью жизни, которую мы проводим за чтением кода? Хочется ведь получать от этого процесса удовольствие, в том числе и эстетическое, не правда ли?
По моему опыту, все изменения начинаются с себя. Достаточно сказать себе: «Теперь весь код, который я заливаю в репозиторий, проверят мои коллеги». Звучит просто, но просто — не значит легко… Это как пробежать марафон. Казалось бы, начал бежать — и беги не останавливаясь 42 км. Но стоит поставить себя на место бегуна…
Наверняка будут конфликты — из-за стиля кодирования, используемых алгоритмов, библиотек, методик, подходов, паттернов, — но это только первые пару недель. Зато каждый разработчик начинает воспринимать код, как свой: «я его проверил, я его принял». Код начнет приносить удовольствие от работы с ним. Плюс я еще и «прокачаюсь» не только в умении писать код, но и в навыке делать критические замечания.
Следующим шагом можно вводить процесс разработки и написания модульных тестов
Первым делом хорошо бы выбрать готовый фреймворк для тестирования, благо их уже пруд пруди (http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks).
Следом в обязательном порядке настраиваем запуск модульных тестов на сервере. Сервер — это эталон аппаратно-программного окружения. Единственный критерий приемки кода и работающих тестов — прохождение тестов на сервере, а не на машинах разработчиков. Настроенный запуск модульных тестов на сервере сэкономит кучу времени.
Собственно, это все действия для подготовки инфраструктуры. Однако трудности еще ждут впереди, ведь подготовить к использованию этой практики гораздо сложнее.
Три самые страшные порока модульных тестов
1. Тесты прогоняются нерегулярно и не на эталонном сервере. Если тесты не прогоняются на сервере построения (у вас еще нет выделенного сервера построения?), то разработчики могут начать постепенно отключать тесты, которые «заваливаются». В результате получаются неработоспособные тесты, а мотивация их писать падает ниже плинтуса. Тесты «протухают».
2. Крупные тесты. Тесты должны быть маленькими, «слонов» сложно трансформировать — они превращаются из помощников в мучителей.
3. Тестирование ради тестирования. Какого-то универсального решения для подобной ситуации нет, но логичнее всего просто выбрать достаточную степень покрытия тестами своего проекта, прописать случаи, которые обязательно покрываются тестами. Кому-то будет, на самом деле, достаточно и 30%, а кому-то нужно и 70—90%. Это выбор команды.
Жизнь прорастает даже на камнях. Даже в самом страшном проекте могут прорасти ростки модульных тестов и зародиться инспекция кода. Именно мы сами и сеем семена качества своей жизни.
На унаследованном проекте можно начать с малого. Не знаю, как у вас, а у меня обычно безотказно проявляется принцип Парето: 20% кода выполняют 80% функционала. Мы фокусируем свое внимание в покрытии тестами именно на этих 20%. В своих проектах, применяя принцип 20/80, нашей команде удалось уменьшить количество багов в старом коде с ~30 в месяц до 2—4.
В результате мы забыли, что такое лечить баги, и это новое чувство было окрыляющим. Появилась возможность планировать свою работу, отдых, развитие, жизнь. Мы забыли про переработки и работу по выходным. Стали со спокойной душой уходить в отпуск. Я лично перестал шарахаться от телефонных звонков :)
При этом никто не поменял работу или проект. Мы просто перестроили работу так, как мы хотим ее видеть. Так, чтобы нам хотелось ею жить.
В заключение еще парочка вопросов к размышлению.
Когда мы, разработчики, закончим перекладывать вину на менеджеров, коллег, клиентов?
Когда перестанем откладывать жизнь? До следующего проекта, до следующей работы, до следующего… чего?
Все будет не так, как мы хотим, — но тогда, когда мы решимся.
Вот, собственно, и все. Желаю качественной жизни! Спасибо за внимание.
Автор: Александр Паздников, отдел исследований и контроля качества Positive Technologies.
Автор: ptsecurity
