Истории разработчиков

На собеседованиях часто поднимается вопрос о самом крупном профессиональном провале. Несколько раз я и сама просила кандидатов рассказать об этом, когда проводила интервью. Люблю такие истории - это хороший повод для дискуссии, через них проявляются ценности человека, а бонусом можно узнать что-то новое и повеселиться.

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

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

Продукт включал в себя приложения Android/iOS, фронт и бэк. Я писала мобилки, двое моих коллег занимались фронтом и бэком соответственно.

Сервис делался для другой страны. Для выхода в продакшен был жесткий дедлайн - пресс-конференция, на которой представители заказчика - общественные деятели этой страны - планировали представлять продукт публике.

Утро перед пресс-конференцией. Заблаговременно выпущены релизы в AppStore и Google Play, фронт и бэк задеплоены. Боевая база данных потихоньку набирает пользователей - наша команда, тестировщики, представители заказчика и случайные люди, которые сами нашли продукт, хотя реклама еще не давалась.

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

Согласовав с заказчиком маневр, мы очистили базу. Началась пресс-конференция, а вместе с ней начали появляться первые регистрации.

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

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

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

Поясню подробнее на примере.

Вася создал учетную запись. База данных присвоила Васе id под номером 1, сервер взял этот id, сгенерировал из него токен и отдал Васе. Вася сохранил токен и ходит с ним на сервер за приватными данными. Теперь мы очистили базу. Аккаунта Васи больше не существует, но токен на его устройстве всё ещё хранится. В сервисе регистрируется первый новый пользователь Аня. База теперь уже Ане выдает id под номером 1, сервер генерирует из этого id такой же токен. В результате у Васи хранится токен Ани, и Вася может делать запросы от имени ничего не подозревающей Ани.

На момент реализации проекта мы знали о том, что можно использовать uuid вместо целочисленных id, что токен должен содержать срок действия и рефреш, но посчитали эти нюансы избыточными.

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

За годы работы в IT я убедилась - любой практический опыт, а тем более опыт ошибок, со временем перерастает в профессиональное чутье. А теоретические знания без практики быстро меркнут, поэтому важно действовать и не бояться оступиться. Люди ошибаются, это нормально. Не нормально - не анализировать свои ошибки.

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

Не бойся ошибаться, но работай над ошибками.

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

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

Однажды разработчик написал скрипт, выполняющий нехитрую сортировку файлов по подкаталогам, исходя из имени файла. Разработчик был свеж умом только что вышел из отпуска, за который успел отдохнуть душой и телом. Разработчик был опытен, он не одну сотню раз решал схожие задачи. Разработчик был компетентен, и знал, что не застрахован от ошибки, поэтому проверил скрипт на тестовом окружении, на котором всё отработало, как ожидалось. И даже этого ему было недостаточно, поскольку разработчик справедливо считал любые операции с незарезервированными данными критичными. Поэтому он попросил своего коллегу тоже очень хорошего разработчика сделать ревью этого небольшого и достаточно простого скрипта. Коллега вернулся с одобрением, и разработчик, успокоившись, запустил скрипт на боевом сервере. Всё сработало, на первый взгляд, корректно. А потом начались проблемы. Как обнаружилось при внимательнейшей вычитке, в одном месте скрипта автодополнение поставило $filename вместо $filepath, и любые коллизии в именах файлов приводили к их перезаписи. Разработчик проглядел опечатку, тестовый прогон не учитывал возможность коллизий, а ревьювер не очень хорошо посмотрел код, поскольку не считал себя умнее коллеги.

Бессмысленно бояться ошибаться. Поэтому вторая парадигма, которая следует из первой: не скрывай, не игнорируй, не ври, себе прежде всего. Ошибся признавай и иди исправлять. Естественно, найдутся те, кто будет делать из тебя козла отпущения и пытаться наказать. Если это руководитель это негодный руководитель, я бы подумал, стоит ли с таким работать, но это отдельная тема.

Докапывайся до причин.

В день релиза, за несколько часов до запуска клиентов на продакшен-сервер, всё становится плохо. Развёрнутое приложение выдаёт какие-то неправильные данные, хотя вот ещё пару часов назад всё выглядело идеально. Админы перепроверяют конфиги, разработчики пытаются воспроизвести проблему на тестовых серверах, продакт-менеджеры жрут валерьянку. За пять минут до запуска происходит саморассос. Клиентов пускают на сервер, они там весело играются без всяких очевидных проблем. Продакт убирает валерьянку, достаёт коньяк, и остаток дня проходит под знаком радостного расслабления. Даже джуну Славику наливают, и он веселит коллег свежим анекдотом про курочку и снесённое напрочь яичко.
А через месяц боевой сервер снова уходит в несознанку, на этот раз унося с собой все уже сохранённые пользовательские данные. Насовсем и навсегда.

Скажете: полноте, так не бывает! Отвечу: а вы сами не наблюдали, как после саморассоса проблемы на неё забивают? Технарям лень, менеджмент не выделяет времени (так заработало же!), причина не установлена, никаких выводов не сделано.
Что нужно делать: отложить все остальные дела, и заниматься только поиском источника странного поведения.

Технические подробности примера выше таковы: в приложении была удобная функциональность сброса к дефолту, написанная когда-то на старте проекта уже ушедшим разработчиком. Другой разработчик нашёл эту возможность, и добавил себе в конфиг её вызов раз в день ему было удобно каждое утро начинать с чистого листа. Ближе к релизу он случайно закоммитил этот конфиг в мастер-ветку; техлид был не на своём месте, и не очень хорошо понимал VCS, считая, что конфиги можно хранить в репозитории. Из-за кранчей и общей усталости изменение прошло мимо ревью, и выкатилось на прод.
Это, конечно, всё равно бы заметили, если б не очень хорошо настроенное кеширование данных в Redis. С ним приложение почти ничего не тащило из БД; запись-то шла, и хотя каждое утро таблички чистились, данные оставались в промежуточном кеше

Ну а дальше понятно: то ли сработал триггер принудительного обновления кеша, то ли Redis перезапустили без восстановления состояния не суть важно. Ежедневные дампы БД всё-таки были но пользы от них уже не было.

Не лезь в IT за деньгами (оно тебя сожрёт).

Ок, программирование одна из немногих профессий, позволяющая чувствовать себя белым человеком. Важная сноска: белым человеком в этой стране, где какие-нибудь полторы тысячи ежемесячных долларов возносят вас в верхний квартиль финансового благополучия. Каждый раз, когда кто-то заводит речь о том, что программисты много зарабатывают, я ору: это не они много зарабатывают, это все остальные получают очень мало!
Но даже это не будут лёгкие деньги. Образ хипстера-смузихлёба, за 300 килодолларов в секунду ненапряжно кодящего очередной стартап на новеньком макбуке фальшивая витрина профессии. В 100% случаев поначалу и в 90% случаев потом ваша работа будет похожа на работу золотаря, только лезть в вонючую яму придётся не руками, а мозгами. Причём частенько, пока вы разгребаете эту яму, сверху будет литься непрерывный поток новых нечистот. И самая мякотка в том, что пролетарий после смены на заводе переодевается из спецовки в треники, кладёт инструмент на полку и болт на работу. Он свободен. А айтишник всегда таскает с собой, если не ноутбук, то голову со всеми этими знаниями и абстракциями, и даже во сне его попускает не всегда.
Это, безусловно, к любой думательной работе относится, но IT наиболее очевидный и хайповый пример.

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

Люби критику.

Один начинающий программист как-то написал очень клёвую утилиту, каких до него никто не делал. Он даже выложил её исходники на публику потому что слышал, будто все крутые разработчики так делают. Через некоторое время какой-то незнакомый человек прислал ему письмо: там он вежливо благодарил за полезную утилиту, предлагая тут же свои исправления кода. Начинающий программист очень обиделся: как это так, мою крутую разработку кто-то вознамерился трогать своими немытыми руками?!
А через полтора десятка лет этот же программист сам прислал список исправлений для проекта, разрабатываемого компанией молодых людей, считавших себя безумно крутыми разработчиками. И в ответ получил такую же обиду и хейт: какой выпендрёжник посмел тут охаять наш прекрасный код своими правками?

Сколь крутым бы ты себя не считал, насколько бы ты ни был подготовлен на самом деле, и какой бы опыт не был у тебя за плечами, всегда найдётся, кому макнуть тебя рылом в некомпетентность. Всегда есть человек, который взглянув на твой идеальный код, заявит, что такой мусор нельзя выпускать в продакшен; мало того он ещё и предложит решение, которое действительно будет на порядок лучше. И сделано это будет не выпендрежа ради (хорошо, не только ради выпендрежа), а просто потому что он это может. Нет никакого смысла и рациональной причины обижаться и дуть щёки в ответ на критику: вас не унизили, а наоборот приподняли над текущим уровнем. Скажите спасибо, извлеките опыт, это самое правильное, что вообще можно сделать.

Ребятам из истории понадобился где-то год на осознание. Всё происходило, как по учебнику: новые фичи внедрялись всё с большими задержками, количество сбоев росло, а производительность падала. Упав в яму страданий Даннинга-Крюгера, они уже сами попросили помощи у более опытного товарища, и он им помог, чем мог. Ведь и тут смысла обижаться нет все мы через это проходили.

Не работай в изменённом состоянии сознания.

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

Запустив chown под рутом, разработчик увидел неожиданно большой вывод в терминале, и тут же нажал ctrl+c, отменяя выполнение. Но было уже поздно: он опечатался в пути исполнения, вместо каталога приложения задав команде путь от корня. Это практически порушило систему; чтобы всё продолжило хоть как-то работать, пришлось тут же выдать всем объектам 777, и потом уже муторно восстанавливать руками и скриптами.

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

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

Дороже своего времени только время коллег.

Обычный диалог в чате плохой команды:

@username, мне нужно узнать, как сделать X, это твоя тема.
[Через пять минут]
Ау, @username?!
[проходит несколько часов, перемежаемых кидаемыми в чат смешнявками из тематических каналов]
Хай! Ещё надо?
[Нет, я час ждал ответа, не дождался, потратил два часа на самостоятельное разбирательство, хотя ты мог дать мне нужные данные за пять минут, потерял контекст выполняемых задач, и, в общем, профукал день. И это не в первый раз так. Когда ты обратишься ко мне, я тоже не буду торопиться!]
Уже нет, спасибо...

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

Как должен выглядеть диалог в хорошей команде:

@username, мне нужно узнать, как сделать X, это твоя тема.
Ок, смотри туда-то, там краткая дока для себя. Если нужны будут подробности у меня окошко через два часа, можем созвон.
Отлично, спасибо!

Проект выходит в срок, набирает аудиторию, Элон Маск пишет о нём в твиттере, стартап покупает Цукербергман за миллиард долларов, разработчики покупают себе золотые макбуки и начинают писать на них новый стартап.

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

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

Будь учёным.

К сожалению, обучение на айтишника обычно сводится к вот этому:

Ни в каком ВУЗе, ни на каких платных курсах и даже ни на каких роликах с ютуба вас не научат хорошо программировать. Максимум на полшишечки; а полноценное дерево знаний можно у себя в голове вырастить только самостоятельно, изучая и практикуя. Практикуя, практикуя, практикуя.

К счастью, у разработчиков сложилась своя, совершенно особая культура распространения и обмена знаниями и опытом, ближайший аналог которой распространение знаний и опыта в научной среде. Но программисты сделали из этого целую идеологию open source. Во-первых, потому что могли, во вторых потому что эта идеология очень хорошо отражает нашу профессиональную деформацию. Знать, изучать, улучшать, отдавать, демонстрируя свою крутость и принося пользу.
Это очень круто да ещё и доступно без проблем. В то время, как тем же учёным буквально приходится платить журналам за рецензирование и публикацию их исследований, а другим учёным оплачивать доступ к уже оплаченным публикациям, у нас на расстоянии одного запроса в гугл находится бесконечное множество материалов для изучения. Ты можешь взять исходники любимого фреймворка с гитхаба, впилить туда нужную фичу, и вжух ты в числе разработчиков, добавляй строчку в резюме. Не хватает умений для самостоятельного впиливания оставляешь запрос на изменение, если фича нужна может займётся кто-то другой. Или нет никто никому ничего не должен.

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

Stay calm.

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

Таков вечный закон жизни. Прими его, как нечто само собой разумеющееся, оставайся спокоен и невозмутим.
И озаботься мониторингом, конечно.

Спорт необходим.

Через силу, через не хочу, через годы, через расстоянья занимайся своим организмом. Да, самое ценное у тебя в голове; ты сидишь внутри черепушки, а вот эта несуразная конструкция из костей, кишок, мяса и разных жидкостей служит только для поддержания существования. Обслуживать эту периферию не хочется: можно ведь угнездиться в удобном кресле, тратя силы только на лёгкие движения кистями рук. Пиццу и колу тебе могут доставлять курьером прямо к ротовому отверстию, удобно. Разве что, для гигиенических процедур придётся вставать; эх, когда уже научатся оцифровывать сознание?!

Вот пока не научились биологический стафф, прилагаемый к мозгу, всё-таки надо обслуживать. Поддерживать его во вменяемом состоянии: мы, эволюционно, обезьяны, нам необходимо бегать, прыгать, вот это вот всё. Нам может не хотеться этого делать, но обезьянка в клетке быстро хиреет и тупеет. Так что седлайте велосипеды, прыгайте на турники, записывайтесь в спортзалы, ныряйте в бассейны, да хоть кубы в Beat Saber режьте. Ну надо!

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

Комментируй это.

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

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

Не треплись много, треплись мало.

Ежедневное дейли, какая-то летучка, или встреча. Полтора-два десятка человек сидят на пуфиках в опенспейсе, за столом в переговорке или же в Zoom онлайн. И пока один рассказывает скажем, докладывает продакту, чем занимался последний день, остальные тупо тратят своё время.

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

Ну я делал фичу X, там надо было вот это так, но я решил сделать это так, и

...Далее звучат минут всяких косвенных вещей, и заканчивается всё через полчаса подробностями о цвете шерсти собаки, встреченной докладчиком на улице. Если вообще заканчивается.

И все сидят, слушают, не прерывают потому что невежливо. И летучка растягивается на два часа; особенно это круто, если случается в середине рабочего дня, который, таким образом, оказывается потерян вернуться в контекст, из которого тебя вырвали, не так-то просто. Или докладчик начинает на общей встрече разбирать вопрос, который только его касается. Какую-нибудь багу, с которой он может и должен подойти к более опытному коллеге отдельно. Да какого?!..
Это не дело. Для болтовни есть менеджеры, вот пусть они между собой собираются и меряются, у кого софт-скиллы длинней. А время господ разработчиков ценнее и важнее, берегите его.

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

Делай бекапы!

Точно сделал? А если подумать? Автоматические? Инкрементные? На другую физическую машину? А лучше, конечно, на две. А восстановление проверил?

Вот казалось бы, сколько лет твердят: резервируй и перерезервируй но сколько твердят, столько я и натыкаюсь на игнорирование этого правила. Последний раз совсем недавно: бекапы боевой БД то ли не делались, то ли делались на другой раздел той же виртуалки; админский скрипт, удаляющий бесхозные инстансы чпокнул сервер (почему так получилось отдельный разговор). Хоть какие-то данные пришлось выковыривать с dev-окружения, естественно, с потерями и искажениями, не говоря уж о простое сервиса. А ситуацию мог спасти трёхстрочный скрипт, раз в сутки архивирующий дамп, и отправляющий его да хоть по почте, если уж совсем больше некуда.

В миллиардный раз повторю настраивайте правильные бекапы, резервирования мало не бывает! Впрочем, если думаете, что повторяю зря, правильно думаете: ребята из описанного кейса мало что вынесли, и нормального резерва так и не настроили. Более того: пока я оформлял эту статью, ситуация в той команде повторилась буквально на сто процентов; в нашей реальности молния бьёт в одно место и два и двадцать раз.

Знай свой инструмент.

Очень болезненное наблюдение: мало кто умеет пользоваться тулзами и окружением, с которыми работают. Примеры очевидны: от запуска команд с sudo по умолчанию (т.е. пользователь не понимает идею разделения привилегий и ни разу не натыкался на патч Бармина) до использования VCS в качестве помойки.

Собственно, помойка в гите (сто тысяч устаревших серверных веток, мусорные commit message, не относящиеся к делу файлы) это погань, от которой лид команды должен отучивать разработчиков. А за форс пуши уже и наказывать: как правило, форс пуш применяется неопытным разработчиком, как универсальное решение какой-то проблемы, с которой нормально справиться он не смог. Не порешал конфликты при мерже, например, испугался и перезатёр файлик локальным бекапом (он-то по старинке версионируется каталогами!). Беда тут в том, что с гитом работает вся команда, и один косяк может создать проблемы всем сразу.
Хуже ситуации с одним разработчиком, не умеющим в git, только когда в него не умеют все. И всем плевать. И конфиги хранятся в гите, и деплой делается ручками, и тысяча веток на сервере, и хардпуши сразу в мастер, и прочее, и прочее. Видел и вижу такое, к большому сожалению, очень часто.

Впрочем, часто встречаю некомпетентность и в других моментах, и примеров могу привести превеликое множество. Они могут показаться настолько тупыми, что вы решите, будто я их придумал; ах, если бы! Вот, пока я писал эту статью, командный разработчик пожаловался, что ему трудно отлаживать JS-скрипт в браузере через alert();.

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