Pull to refresh

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

Reading time 6 min
Views 25K
В этот раз речь пойдет о модульных тестах и инспекциях кода. Когда мы в нашей команде начали использовать две эти практики в своих проектах, драйва и радости от работы прибавилось на порядок. Упомянутым темам посвящено огромное количество теоретических и практических трудов, но сегодня речь пойдет именно о личной выгоде разработчика.

Сколько времени все мы проводим на работе? Как обычный человек, я провожу в офисе примерно треть своей жизни. А если добавить время, которое мы посвящаем мыслям о работе: дома или в отпуске, за кружкой пива с друзьями или на пикнике под шашлычок?..

Когда последний раз мы спрашивали себя:
— Что я ощущаю, когда иду на работу? Подавленность и депрессию или радость и вдохновение?
— Нравится ли мне то, что я делаю? и то, как я это делаю?
— Что я ощущаю, когда ухожу с работы? Удовлетворение и умиротворение или облегчение и истощение?
— Я хожу на работу по привычке или мне она нравится?

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

Не сломалось — не чини!


На одном из предыдущих мест работы мне довелось принимать участие в проекте, которому было уже больше 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.
Tags:
Hubs:
+49
Comments 20
Comments Comments 20

Articles

Information

Website
www.ptsecurity.com
Registered
Founded
2002
Employees
1,001–5,000 employees
Location
Россия