Кейт — хороший программист и отличный спикер. Сам доклад поднимает много интересного о программировании на С++ и программировании вообще (стоит посмотреть). Но больше всего меня зацепила одна высказанная ею (буквально вскользь) мысль. Кейт удалось очень кратко и по делу обозначить мотивацию программистов. Звучала она так: «Программист во время работы стремится максимизировать своё счастье». Это звучит банально, но ведь так оно и есть.
Мы можем говорить, что болеем за проект, заказчика, компанию, человечество и мир во всём мире (и это даже может быть правдой). Но давайте будем честны. Мы люди и, как все люди, в первую очередь стремимся максимизировать своё счастье — глобально во всей жизни, стратегически в карьере, тактически в текущем проекте и мелочно здесь и сейчас, при написании вот этой функции, вот этой строки кода. Да, мы это делаем и было бы хорошо разобраться, что делает нас более счастливыми, а что — менее. Это позволит нам лучше понимать коллег, подчинённых да и самих себя.
Сразу хочу вынести за скобки вопросы оплаты труда, условий работы, начальства, коллектива и прочего. Если вы работаете там, где работаете — то всё это вас примерно устраивает. Давайте сфокусируемся на том, что делает нас счастливыми и несчастными при непосредственной работе над кодом.
Тесты
Все проекты с тестами счастливы одинаково, каждый проект без тестов несчастен по-своему. Я могу с уверенностью сказать, что программисты в проектах с хорошим тестовым покрытием в среднем более счастливы, чем в проектах без тестов вообще. Я даже видел, как программисты, которым начальство не согласовывало написание полноценных тестов, писали их втайне (иногда даже во внерабочее время). Почему это происходило? Написанный тест делает программиста счастливее. Само его существование — уже признак того, что хоть что-то в вашем проекте делается согласно лучшим практикам индустрии (даже если остальное нет). Успешно завершившийся тест показывает красивую зелёную галочку, хвалит программиста (а ведь его, может быть, никто больше и не похвалит). Успешное завершение 100% тестов даёт какую-то устойчивую почву под ногами, когда уже во что-то можно верить — это добавляет нам уверенности в сегодняшнем и завтрашнем дне, делает счастливее. И даже проваленный тест выполняет свою работу — сообщает нам, что мы не зря его написали, хвалит нас за предусмотрительность. Хотите сделать программиста счастливее — разрешите ему (или даже в принудительном порядке обяжите его) писать тесты (конечно, всё хорошо в меру).
Багфиксинг и разработка нового функционала
«Я вам не скажу за всю Одессу», но большинство встреченных мною в жизни программистов больше любили писать новый функционал, чем багфиксить legacу-код. А почему? А потому, что прикосновение к багу — это прикосновение к чужому несчастью. Что-то у кого-то пошло не так и это было настолько важно, что он не поленился донести своё горе аж до разработчика. Придётся входить в его положение, пытаться воспроизвести. А дальше ведь либо получится воспроизвести — и будет удар по самолюбию из-за допущенного бага, либо не получится и придётся (о боже, нет!) контактировать с живым человеком, обнаружившим проблему, и пытаться раздобыть больше информации. Всё это нельзя назвать приятным.
В то же время написание нового функционала — это потенциальное прикосновение к счастью. Мы пока ещё ничего не сломали, ни в чём не виноваты. Мы пишем новый код, чтобы решать новые задачи. Возможно, это удастся. Возможно, мы получим заслуженную похвалу (премию, повышение). Это уже ближе к верхним уровням пирамиды потребностей человека по Маслоу.
Какой отсюда вывод? Работа программиста должна быть сбалансирована, в ней не должно быть одного багфиксинга. Каждому программисту нужно время от времени поручать разработку новых фич. Да, от багфиксинга никуда не деться, но мы хотя бы можем попробовать достичь «примерно нулевого» баланса счастья и несчастья в этом вопросе.
Рефакторинг
Работать с хорошим кодом — приятно. К сожалению, хороший код не падает с неба. Его даже невозможно взять и написать с первого раза. Мы должны сделать хороший код из плохого, поскольку его больше не из чего сделать. Здесь программисты делают выбор: каждый день, приходя на работу, продолжать страдать и работать с плохим кодом или же всё-таки взять и постараться сделать из него хороший. Во втором случае часто приходится воевать с руководством, которое не понимает, на что можно было потратить вот эти N часов времени, если новых фич в продукте не добавилось и старых багов тоже исправлено не было. Да, приходится воевать. К счастью, в этой войне у нас есть аргументы: лаконичный и красивый код менее подвержен ошибкам, его поддержка занимает меньше времени (и стоит меньше денег), он лучше поддаётся изменениям при появлении новых бизнес-требований и т.д. Кроме того, эта война, как правило, не продолжительна: она заканчивается каким-то компромиссом вроде «нет, месяц на рефакторинг я не дам, но давайте будем выделять на него 2 часа в неделю по пятницам». Окей, уже хорошо. Мы только что добыли себе кусочек счастья. Да, его ещё нужно будет построить собственными руками, но это уже стало возможным.
Использование современных библиотек и инструментов
Многим, наверное, известна боль от необходимости работать в проекте, застрявшем по какой-то причине на компиляторе (фреймворке, библиотеке) многолетней давности. Нам объясняют, что вот по таким-то и таким-то причинам нельзя перейти на новую версию вот здесь и вот сейчас, но когда-нибудь, наверное, если получится… Что тут можно поделать? Ну, во-первых, нужно признаться самим себе в том, что обстоятельства сложились не в нашу пользу и ситуация делает нас несчастнее, чем мы могли бы быть. Во-вторых, эту же мысль можно озвучить и начальству (или заказчику). Вряд ли кто-то будет с этим спорить. И вот в этот момент можно попробовать себе что-то выторговать: например, время на те самые тесты, новый функционал и рефакторинг. (Можно и прибавку к зарплате, но в начале статьи я пообещал оставить это за скобками).
Кстати, потраченное на столь полезные задачи время на самом деле может не только сделать вас чуть счастливее здесь и сейчас, но и устранить те самые «страшные» причины, по которым невозможно было перейти на использование более новых инструментов. Реальная ситуация из моей жизни:
— Мы не уверены, что переход на новую библиотеку не принесёт нам новых проблем…Через 2 недели — новая библиотека в продакшене.
— А вот я написал 200 тестов на код, использующий эту библиотеку, давайте попробуем перейти и запустим их.
— Хм, ну давай.
Можно, наверное, продолжать исследовать и другие аспекты. Но общая мысль одна: некоторые задачи и обстоятельства делают программиста счастливее, другие — несчастнее. Если вторых будет больше, чем первых — настроение и продуктивность программиста будет падать, рано или поздно это приведёт к проблемам в проекте или к его уходу из команды. Поэтому и сам программист, и его руководитель должны задумываться не только о «глобальном благе» проекта, компании или пользователя, но и том, как при этом оставаться относительно счастливым разработчику. А иначе в чём смысл?
Комментарии (12)
rzerda
26.11.2018 19:04Видел несложную программулину, автор которой был очень счастлив после покрытия тестами 70% кода. На этом основании она уехала в прод. Одна беда: программулина работала некорректно, а покрыты были всякие вспомогательные вещи типа чтения конфигов. Зато программист счастлив.
больше любили писать новый функционал, чем багфиксить legacу-код. А почему?
Потому что в среднем баги ловить сложнее, чем писать код, их содержащий. Плюс за отлов багов не премируют, а за фичи — пожалуйста.powerman
26.11.2018 20:25Потому что в среднем баги ловить сложнее, чем писать код, их содержащий.
Как по мне, дело вовсе не в сложности. Основной недостаток багфиксинга в том, что он практически никак не повышает квалификацию, т.е. время, которое тратится на баги — это чистая потеря в плане профессионального развития. А времени они могут съедать очень много. Именно поэтому я предпочитаю тратить время на тесты — тоже не самое интересное занятие, но в результате эта стратегия позволяет мне бoльшую часть рабочего времени проводить не только с пользой для проекта, но и с пользой лично для себя, в плане профессионального роста, при этом на баги, в среднем, уходит максимум 5% моего времени. Кстати, ещё с этим помогает стратегия фиксить 99% багов в первую очередь, буквально в течении пары дней после их обнаружения — если не разрешать себе складировать баги в трекере на неопределённое время то резко повышается мотивация делать по-меньше багов, раз уж увернуться от их исправления возможности всё-равно нет.
theuser
27.11.2018 17:10которое тратится на баги — это чистая потеря в плане профессионального развития
А ничего, что зная как такой баг возник, можно впоследствии применять методы решения, чтобы таких багов не возникало? По мне так это неотъемлемая часть «развития».
К слову, из наблюдений:
Я смотрю, во фронтенде сейчас все внезапно стали «профессионально развиваться», штудируя один фреймворк за другим, вот только на выходе получаем баги вида: в ios прыгает кнопка, или fixed-элемент, cordova валится с эксепшеном (оказывается дело не в недостатке памяти на устройстве, а в рендере гребанных филдов на условных формах), а десктопные chrome/firefox показывает разные размеры элементов и т.д. и т.п. И ты впоследствии сидишь такой «че ваще происходит», а оказывается эти «профессионально развивающиеся» так «профессионально» накодировали, что логику переделывать надо.powerman
27.11.2018 17:22Конечно. Пока речь идёт о подходе, при котором каждый найденный баг рассматривается как исключение, а не норма. Для этого необходимо, помимо исправления самого бага, проверить весь проект на предмет аналогичных багов и исправить их все одновременно, плюс проанализировать причины возникновения бага и попытаться изменить процессы разработки так, чтобы такого рода баги в будущем не появлялись. Я именно так и стараюсь работать. Тем не менее, изменить процессы чтобы исключить такую категорию багов удаётся не всегда, поиск бага может занять дни, а реальной пользы от выяснения его причины часто может и не быть.
ianzag
27.11.2018 21:42Если вас все устраивает в вашем коде это лишь означает, что он или слишком юн или никому не нужен. По мере взросления код начинает устраивать все меньше и меньше т.к. становится все страшнее и страшнее. При этом, парадоксально! все нужнее и нужнее. И в какой-то момент — «пора, мой друг, пора!». Дарить добро куда подальше. Желательно чтобы не догнали.
hdfan2
27.11.2018 20:23Насчёт багфиксинга немного не соглашусь. Да, бывают скучные, рутинные баги, которые чинятся на автомате; бывают мутные баги, где ничего не понятно, а заказчик уже одновременно истерит и тупит, не давая требуемой информации, или давая не то, или используя мозжечок вместо мозга (вместо файла — скриншот в doc'е, сливая гигабайтные дампы в несжатом виде через дохлый канал и т.д.). Но. Бывают такие, не побоюсь этого слова, красивые баги, когда всё совершенно непонятно, и неясно, в какую сторону вообще копать; и появляется одна идея (нет, не то), другая (опять мимо), и, наконец, третья (хм, а вот это интересно… Да ладно! Не может быть!), и тут на тебя нисходит просветление, и ты вдруг ясно понимаешь, как именно она появилась, и как всё работало раньше, и почему вдруг перестало работать — все кусочки паззла складываются воедино; и ты чинишь, запускаешь с замиранием сердца, и тут…
О да! Всё работает как часы! Особенно круто, когда вы искали этот баг в компании (хотя бы вдвоём), и именно тебе пришло в голову решение. О таких багах приятно рассказывать в кругу таких же ботаников, как ты, которые могут оценить всю глубину разверзшейся перед тобой задницы и всю красоту найденного решения.
Чинить баги тоже иногда интересно.
maxzh83
Знаю несколько примеров, когда в проект брали человека исключительно с одной целью — обеспечить определенный процент покрытия тестами. Процент был спущен заказчиком сверху и логике несильно поддавался. Нужно ли говорить, в какой эйфории находился этот человек?
powerman
С тестами не всё так очевидно.
Да, наличие достаточного количества хороших тестов однозначно делает разработчиков счастливее. А вот наличие хрупких тестов — наоборот. Недостаточное количество тестов, даже хороших, мало на что влияет, в т.ч. и на счастье разработчика.
Написание тестов… не буду говорить за всех, возможно есть фанаты этого дела, но я пока не встречал ни одного разработчика, который бы становился счастливее в момент написания тестов — включая меня самого, хотя я абсолютно добровольно пишу тесты примерно 30% времени. С этим, правда, можно бороться — разработка разных моков и специализированных DDL для сложных тестов это вполне полноценное и интересное программирование, которое сильно компенсирует нудность тестирования и может даже вывести средний баланс счастья при работе над тестами в плюс.
В общем, при обсуждении счастья от работы, тесты — это граничная тема. Если писать тесты качественно, развлекая себя в процессе написанием вспомогательной обвязки для тестов, и заниматься этим не более половины рабочего времени — то да, это добавит счастья. Если же этот баланс не соблюдается, то это добавит чего угодно, но только не счастья.
lgorSL
Что-то алгоритмически сложное намного приятнее отлаживать тестами, чем методом пристального взгляда. Оптимизации производить тоже намного спокойнее — если алгоритм ломается, сразу об этом узнаёшь и понимаешь, в каком месте причина. Наличие тестов экономит кучу времени и даёт реальную свободу для внесения изменений. (Впрочем, в остальном коде тесты я почти не пишу, хотя надо бы)
Antervis
если писать тесты интересно, значит, вы делаете это не так — они должны быть простыми как три копейки а значит, нудными в написании. Ибо чем тесты сложнее, тем выше шанс, что ошибка в них спрячет ошибку в проде.
powerman
Интересно писать всякие хелперы для тестов, которые как раз и позволяют сделать сами тесты простыми, читабельными и нудными.
Gorthauer87
Интересно с помощью тестов проверять функционал, всяческие гипотезы и т.д. В этом режиме тесты просто не воспринимаются как какое-то отдельное написание кода, а скорее как работа над основной задачей.