Сложный выбор

Каждый разработчик сталкивался с этой проблемой. Требуют починить баг или доработать продукт, но времени на качественное решение нет. Нужно было вчера, говорит менеджер. Вы перед трудным выбором: делать быстро и некачественно или на совесть, но долго.

Принять решение не так просто, как кажется. Воткнуть грубое решение и поскорей закрыть тикет? В отчете больше задач, проблема нейтрализована на ближайшее время.

Или заморочиться, провести исследование, прочитать книгу? Но менеджер не готов выделить часы, руководство давит. Мы должны двигаться, несется со всех сторон.

Поработать на выходных? Полно семейных дел, а два часа ничего не решат.

С опытом приходит понимание: позади этого выбора стоит другой, более важный выбор. Как я реагирую на проблемы? Как быть, когда что-то идет не так? И не только в работе, но и в жизни?

Только недавно я смог внятно выразить, что думаю по этому поводу.

На мой взгляд, хороший разработчик ценит качество продукта, который создает. Я заметил: пока проект в тонусе, с ним приятно работать. Даже сложные задачи приносят удовольствие, если код написан чисто и с пониманием. Модули и функции сгруппированы удобно. В сложных местах комментарии и док-стринги.

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

Пользователи слышат наплевательское отношение к коду. Может показаться, что сопли на бекенде спрятаны за интерфейсом, но это не так. Кривое поведение нет-нет, но прорвется сквозь щели. Пользователю покажут идиотскую ошибку, пришлют “[Object object]” в смс, оборвут сессию в важный момент.

От поспешного решения больше проблем, чем пользы. Да, какую-то дырку вы заткнули. Это прекрасно смотрится в отчетности. Повышает репутацию в команде: выручил, спас проект. Но это только видимая часть.

Невидимая состоит в том, что проект потихоньку поплыл. До катастрофы еще далеко, никто не заметит. Прямо сейчас ничего не случится. Проблемы встанут во весь рост потом. Вот хотя бы малая их часть.

1) Это ухудшает код, а плохой код значит плохой продукт. Код – это материал разработчика. За буквами на экране стоит его архитектура, ментальная модель. Ее нельзя ломать. Код подобен башне из кубиков. По мере роста она становится нестабильной. Башня не монолит, а набор блоков. Даже если класть кубики с хирургической точностью, она все равно упадет. Вопрос в том, успеет ли она подняться на нужную высоту. Нельзя вносить помехи в и без того хрупкую сущность.

2) Вы учите плохому новичков. К вам приходят молодые ребята, они чисты и впитывают все, что видят в проекте. Нельзя поощрять плохие практики, это дурно и с практической, и моральной стороны. Новички утащат костыли в соседний проект, потом в другой отдел. Плохая практика приживется в компании. Со временем она укрепится чужим авторитетом. На вопрос “почему так?” вам ответят “так писал сам Василий”. С полной уверенностью, что это исчерпывающий ответ.

3) Вы заметаете проблемы под ковер. Грубое решение все равно придется исправлять. Часто об этом не ставят в известность менеджеров и старших разработчиков. Иногда якобы по уважительной причине – они были в отпуске или болели. А выпиливать костыль еще труднее, чем добавить, поэтому легче махнуть рукой.

4) Замедление проекта. Проблему легче решить, когда в голове полный контекст о ней. Будет трудно вернуться к багу, который мигнул год назад. Разработчик, который знал все о нем, ушел. Комментарии в задаче скудные, воспроизвести не получается. Теперь, чтобы вновь наполнить голову контекстом, потребуется больше времени, чем когда проблема стояла в полный рост. Но никто не хочет этого делать. Задачу закрывают. Может, только каждый тысячный пользователь ловит этот баг, но им лень писать разработчикам. Сигнал не доходит до команды, всем наплевать.

5) Обман самого себя. Почему-то считают, что сейчас времени нет, но потом будет обязательно. Это доводит меня до белого каления. Почему вы решили, что потом время будет? Откуда оно возьмется?

Практика показывает, что если времени нет сейчас, то его не будет и через месяц, и через год. По крайне мере до тех пор, пока не изменится планирование.

6) Менеджмент не позволит. Если в проекте хоть как-то считают часы, то починить последствия вам не дадут. Проектному менеджеру платят за нововведения и продвижение продукта, но никогда — за оптимизации. Менеджер не лазит в код, он оценивает глазами и метриками. Если бага не видно, значит, его нет. И плевать, что разработчик патчит классы в рантайме.

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

Потом означает никогда.

Эта проблема справедлива даже для Гугла. Недавно они обновили почту, и по всему миру люди взвыли от тормозов. На что сотрудники Гугла, бывшие и анонимные, ответили. В компании не поощряется оптимизация кода, который уже работает. На результаты такой работы не смотрят при повышении. Там считают фичи, а не число запросов на сервер. Вот и объяснение тому, что почта тормозит.

Мы выяснили, что решение на скорую это отстой. И все же, как поступить при условии, когда вы линейный разработчик? Когда давит руководство, нет связей и возможности на что-то повлиять?

Я вижу две стратегии: краткосрочную и долгосрочную.

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

Цель краткосрочной стратегии в том, чтобы найти наименее болезненное решение. Акцент на том, что такое решение будет легче всего исправить. Мы оставляем задел на то, чтобы с наименьшими проблемами выкинуть этот код. Он должен быть написан с пониманием, его удалят. А не с мантрой “я же писал в два ночи, страдал, не трожьте, сволочи!!1”.

Бывали случаи, что краткосрочное решение оставалось надолго, поскольку выдавало достойный результат. Так бывает, когда разработчик на совесть подошел к проблеме, или ему повезло. Но вряд ли это ваш случай.

Чтобы найти достойное решение, обратитесь за помощью к людям. Важно грамотно составить вопрос: в чем проблема, как вы пытаетесь ее решить, что вы пытались сделать. Сообщите полный контекст, чтобы пресечь посторонние обсуждения и срач.

Скорее всего, опытные разработчики посоветуют вам как раз то, что вы не в силах обеспечить. Важно это оговорить: чуваки, меня не хватит на такой подход. Посоветуйте что-то полегче, а то решение я буду держать в уме.

Когда мне срочно нужна помощь, я пишу вопрос в черновике. Добавляю ссылки, куски кода, стараюсь предупредить очевидные вещи. Например, эту штуку я сделал именно так, потому что. Или этот метод не подошел из-за бага. Это здорово экономит время тех, кто отвечает. Обсуждение не размазывается по второстепенным темам.

Потом я раскидываю вопрос по нескольким чатам: рабочий, нерабочий, профильный канал в Телеграме, Слака. На грамотно составленный вопрос отвечают, как правило, за 5-10 минут.

Некоторые разработчики ищут решение молча, в муках, по ночам. Для меня это признак инфантильности и не профессионализма. Здесь кроется обман и лень, провал в навыках коммуникации.

Это была краткосрочная стратегия. Ее недостаток в том, что решение все же может оказаться недостаточно хорошим. Как мы помним, слабые решения — лишний груз в проекте. Это тот случай, когда остается признать – мы оказались бессильны перед задачей. Поможет долгосрочная стратегия.

Долгосрочная состоит в том, чтобы научиться делать и быстро, и качественно одновременно. Это совершенно другая планка. Если краткосрочная стратегия обусловлена соглашениями в команде, то долгосрочная – это скорее внутреннее. Это про личный рост и путь.

Следует запомнить проблемный случай и по возможности его разобрать. Не обязательно писать код на чистовик. Просто вспомнить проблему: каков был контекст, что сделали и как надо было сделать. Если позволяет время, накидать черновик хорошего решения. Почитать больше о предмете.

В школе это называется работа над ошибками. Делайте ее хотя бы мысленно.

Не позволяйте себе больше одного костыля на проблему. Это должно стать мантрой. Если вы встретили проблему в первый раз, решить ее костылем не так уж постыдно. Может быть, все будет не так плохо.

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

На верхнем уровне вырабатывается нетерпимость к плохой работе. Стратегии становятся неважны. Просто плохая работа не принимается ни под каким видом. Неважно: мало ли времени, зол ли заказчик или что-то другое. Мы так не работаем, точка. Давайте что-то менять: точнее планировать, обучать сотрудников, проводить семинары с разбором ошибок, да что угодно. Но никогда – гнать халтуру, обещая исправить ее потом.

Что в итоге? Вставлять костыли — можно. Костыль оправдан, если разработчик действительно обращался за помощью, и действительно не нашлось достойного решения. Вставлять второй такой же костыль — запрещено. Сама потребность в этом говорит, что пора нанимать людей или выделить время на обучение. Разносить костыли по проектам — недостойно.

Я хочу, чтобы в следующий раз вы, вставляя костыль в код, сначала подумали. Действительно ли я решаю проблему? Какие будут последствия и кто их решит? И когда?

Что бы сделал более опытный разработчик? Может быть, трагедии не будет, если потратить день и сделать все по уму?

Хотя бы один такой вопрос. Тогда статья написана не зря.