Как стать автором
Обновить

Страдать на работе — не обязательно

Время на прочтение 5 мин
Количество просмотров 17K
Всего голосов 24: ↑22 и ↓2 +20
Комментарии 14

Комментарии 14

Хотите сделать программиста счастливее — разрешите ему (или даже в принудительном порядке обяжите его) писать тесты (конечно, всё хорошо в меру).

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

С тестами не всё так очевидно.


Да, наличие достаточного количества хороших тестов однозначно делает разработчиков счастливее. А вот наличие хрупких тестов — наоборот. Недостаточное количество тестов, даже хороших, мало на что влияет, в т.ч. и на счастье разработчика.


Написание тестов… не буду говорить за всех, возможно есть фанаты этого дела, но я пока не встречал ни одного разработчика, который бы становился счастливее в момент написания тестов — включая меня самого, хотя я абсолютно добровольно пишу тесты примерно 30% времени. С этим, правда, можно бороться — разработка разных моков и специализированных DDL для сложных тестов это вполне полноценное и интересное программирование, которое сильно компенсирует нудность тестирования и может даже вывести средний баланс счастья при работе над тестами в плюс.


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

Что-то алгоритмически сложное намного приятнее отлаживать тестами, чем методом пристального взгляда. Оптимизации производить тоже намного спокойнее — если алгоритм ломается, сразу об этом узнаёшь и понимаешь, в каком месте причина. Наличие тестов экономит кучу времени и даёт реальную свободу для внесения изменений. (Впрочем, в остальном коде тесты я почти не пишу, хотя надо бы)

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

Интересно писать всякие хелперы для тестов, которые как раз и позволяют сделать сами тесты простыми, читабельными и нудными.

Интересно с помощью тестов проверять функционал, всяческие гипотезы и т.д. В этом режиме тесты просто не воспринимаются как какое-то отдельное написание кода, а скорее как работа над основной задачей.

Видел несложную программулину, автор которой был очень счастлив после покрытия тестами 70% кода. На этом основании она уехала в прод. Одна беда: программулина работала некорректно, а покрыты были всякие вспомогательные вещи типа чтения конфигов. Зато программист счастлив.

больше любили писать новый функционал, чем багфиксить legacу-код. А почему?

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

Как по мне, дело вовсе не в сложности. Основной недостаток багфиксинга в том, что он практически никак не повышает квалификацию, т.е. время, которое тратится на баги — это чистая потеря в плане профессионального развития. А времени они могут съедать очень много. Именно поэтому я предпочитаю тратить время на тесты — тоже не самое интересное занятие, но в результате эта стратегия позволяет мне бóльшую часть рабочего времени проводить не только с пользой для проекта, но и с пользой лично для себя, в плане профессионального роста, при этом на баги, в среднем, уходит максимум 5% моего времени. Кстати, ещё с этим помогает стратегия фиксить 99% багов в первую очередь, буквально в течении пары дней после их обнаружения — если не разрешать себе складировать баги в трекере на неопределённое время то резко повышается мотивация делать по-меньше багов, раз уж увернуться от их исправления возможности всё-равно нет.

которое тратится на баги — это чистая потеря в плане профессионального развития

А ничего, что зная как такой баг возник, можно впоследствии применять методы решения, чтобы таких багов не возникало? По мне так это неотъемлемая часть «развития».

К слову, из наблюдений:
Я смотрю, во фронтенде сейчас все внезапно стали «профессионально развиваться», штудируя один фреймворк за другим, вот только на выходе получаем баги вида: в ios прыгает кнопка, или fixed-элемент, cordova валится с эксепшеном (оказывается дело не в недостатке памяти на устройстве, а в рендере гребанных филдов на условных формах), а десктопные chrome/firefox показывает разные размеры элементов и т.д. и т.п. И ты впоследствии сидишь такой «че ваще происходит», а оказывается эти «профессионально развивающиеся» так «профессионально» накодировали, что логику переделывать надо.

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

время, которое тратится на баги — это чистая потеря в плане профессионального развития

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

Код писать можно так, чтобы в процессе ничему новому не учиться — это правда. Если кто-то не хочет развиваться — его сложно заставить. И выявление причины некоторых багов может открыть ранее неизвестные особенности поведения системы — это тоже правда.


Но я имел в виду немного другое: если желание развиваться есть, то написание практически любого кода предоставляет бесконечные возможности чему-то научиться в процессе, в то время как поиск багов такие возможности почти не предоставляет — узнать что-то действительно новое и полезное во время поиска и исправления бага удаётся крайне редко.


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

Если вас все устраивает в вашем коде это лишь означает, что он или слишком юн или никому не нужен. По мере взросления код начинает устраивать все меньше и меньше т.к. становится все страшнее и страшнее. При этом, парадоксально! все нужнее и нужнее. И в какой-то момент — «пора, мой друг, пора!». Дарить добро куда подальше. Желательно чтобы не догнали.
Насчёт багфиксинга немного не соглашусь. Да, бывают скучные, рутинные баги, которые чинятся на автомате; бывают мутные баги, где ничего не понятно, а заказчик уже одновременно истерит и тупит, не давая требуемой информации, или давая не то, или используя мозжечок вместо мозга (вместо файла — скриншот в doc'е, сливая гигабайтные дампы в несжатом виде через дохлый канал и т.д.). Но. Бывают такие, не побоюсь этого слова, красивые баги, когда всё совершенно непонятно, и неясно, в какую сторону вообще копать; и появляется одна идея (нет, не то), другая (опять мимо), и, наконец, третья (хм, а вот это интересно… Да ладно! Не может быть!), и тут на тебя нисходит просветление, и ты вдруг ясно понимаешь, как именно она появилась, и как всё работало раньше, и почему вдруг перестало работать — все кусочки паззла складываются воедино; и ты чинишь, запускаешь с замиранием сердца, и тут…
image
О да! Всё работает как часы! Особенно круто, когда вы искали этот баг в компании (хотя бы вдвоём), и именно тебе пришло в голову решение. О таких багах приятно рассказывать в кругу таких же ботаников, как ты, которые могут оценить всю глубину разверзшейся перед тобой задницы и всю красоту найденного решения.

Чинить баги тоже иногда интересно.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий