Айтишная субстанция
В этом вашем айти я торчу всю сознательную жизнь — и даже этого мало, чтобы исчерпать гигантское болото существующих технологий. Трясина IT глубока и обширна; когда-то давно я мечтал испить эту чашу до дна, но макет оказался сильней. Оказалось, что нельзя быть крутым спецом сразу во всём, зато можно вывести принципы и правила, применимые в любой разработке, да и вне её, пожалуй, тоже.
Не бойся ошибаться, но работай над ошибками.
Нам со школы вбивают — иногда фигурально, но часто вполне буквально — недопустимость ошибки. Принёс "двойку" — а-та-та по жопе, и на два часа в угол. Ну или ещё какое наказание, мало как связанное с самой проблемой. Это пример — один, но не единственный, — того, как нас приучают бояться ошибок, скрывать их, отмазываться, оправдываться и даже иногда, проявляя эмпатию и солидарность, закрывать глаза на чужие косяки.
Первая парадигма, которую мне втолковали на моей первой серьёзной работе (привет мегафоновцам!) — косячат все. Как бы ответственно и серьёзно ты не подходил к выполняемой задаче, каким бы профессионалом ты не был — рано или поздно ты ошибёшься. Опыт и знания только уменьшают шанс получения ошибки, но она точно случится.
Однажды разработчик* написал скрипт, выполняющий нехитрую сортировку файлов по подкаталогам, исходя из имени файла. Разработчик был свеж умом — только что вышел из отпуска, за который успел отдохнуть душой и телом. Разработчик был опытен, он не одну сотню раз решал схожие задачи. Разработчик был компетентен, и знал, что не застрахован от ошибки, поэтому проверил скрипт на тестовом окружении, на котором всё отработало, как ожидалось. И даже этого ему было недостаточно, поскольку разработчик справедливо считал любые операции с незарезервированными данными критичными. Поэтому он попросил своего коллегу — тоже очень хорошего разработчика — сделать ревью этого небольшого и достаточно простого скрипта.
Коллега вернулся с одобрением, и разработчик, успокоившись, запустил скрипт на боевом сервере. Всё сработало, на первый взгляд, корректно.
А потом начались проблемы. Как обнаружилось при внимательнейшей вычитке, в одном месте скрипта автодополнение поставило $filename вместо $filepath, и любые коллизии в именах файлов приводили к их перезаписи. Разработчик проглядел опечатку, тестовый прогон не учитывал возможность коллизий, а делавший ревью коллега не очень хорошо посмотрел код, поскольку очень доверял коллеге.
Бессмысленно бояться ошибаться. Поэтому вторая парадигма, которую я вывел уже сам: не скрывай, не игнорируй, не ври, себе — прежде всего. Ошибся — признавай и иди исправлять.
Естественно, найдутся те, кто будет делать из тебя козла отпущения и пытаться наказать. Если это руководитель — это глупый руководитель, я бы подумал, стоит ли с таким работать, но это отдельная тема.
Докапывайся до причин.
В день релиза, за несколько часов до запуска клиентов на продакшен-сервер, всё становится плохо. Развёрнутое приложение выдаёт какие-то неправильные данные, хотя вот ещё пару часов назад всё выглядело идеально. Админы перепроверяют конфиги, разработчики пытаются воспроизвести проблему на тестовых серверах, продакт-менеджеры жрут валерьянку.
За пять минут до запуска происходит саморассос. Клиентов пускают на сервер, они там весело играются без всяких проблем. Продакт убирает валерьянку, достаёт коньяк, и остаток дня проходит под знаком радостного облегчения. Даже джуну Славику наливают, и он веселит коллег свежим анекдотом про курочку и снесённое напрочь яичко.
А через месяц боевой сервер снова уходит в несознанку, на этот раз — унося с собой все уже сохранённые пользовательские данные. Насовсем и навсегда.
Скажете: полноте, так не бывает! Отвечу: сам наблюдал как после саморассоса проблемы на неё забивают. Технарям лень, менеджмент не выделяет времени ("так заработало же!"), причина не установлена, никаких выводов не сделано.
Что нужно делать: отложить все остальные дела, и заниматься только поиском источника странного поведения.
Если интересны технические подробности рассказанного случая: в приложении была удобная функциональность "сброса к дефолту", написанная давно ушедшим разработчиком когда-то на старте проекта. Другой разработчик нашёл эту возможность, и добавил себе в конфиг её вызов раз в день — ему было удобно каждое утро начинать с чистого листа. Ближе к релизу он случайно закоммитил этот конфиг в мастер-ветку; техлид был дебилом не очень хорошо понимал VCS, считая, что конфиги можно хранить в репозитории. Из-за кранчей и общей усталости изменение прошло мимо ревью, и выкатилось на прод.
Это, конечно, всё равно бы заметили, если б не очень хорошо настроенное кеширование данных в Redis. С ним приложение почти ничего не тащило из БД; запись-то шла, и хотя каждое утро таблички чистились, данные оставались в промежуточном кеше
Ну а дальше понятно: то ли сработал триггер принудительного обновления кеша, то ли редис перезапустили без восстановления состояния — не суть важно. Ежедневные дампы БД всё-таки были — но пользы от них уже не было.
Не лезь в IT за деньгами (оно тебя сожрёт).
Ок, программирование — одна из немногих профессий, позволяющая чувствовать себя белым человеком. Важная сноска: белым человеком в этой стране, где какие-нибудь полторы тысячи ежемесячных долларов возносят вас в верхний квартиль финансового благополучия. Каждый раз, когда кто-то заводит речь о том, что программисты много зарабатывают, я ору: это не они много зарабатывают, это все остальные получают очень мало!
Но и это не будут лёгкие деньги. Образ хипстера-смузихлёба, за 300 килодолларов в секунды ненапряжно кодящего очередной стартап на новеньком макбуке — это фальшивая витрина профессии. В 100% случаев поначалу и в 90% случаев потом ваша работа будет похожа на работу золотаря, только лезть в говняную яму придётся не руками, а мозгами. Причём частенько, пока вы разгребаете эту яму, сверху будет литься непрерывный поток новых нечистот. И самая жопа в том, что пролетарий, после смены на заводе, переодевается из спецовки в треники, кладёт инструмент на полку и болт на работу. Он свободен. А айтишник всегда таскает с собой, если не ноутбук, то голову со всеми этими знаниями и абстракциями, и даже во сне его попускает не всегда. Это, безусловно, к любой думательной работе относится, но IT — наиболее очевидный и хайповый пример.
Если вам не заходит тяжёлая работа мозгами — лучше не лезьте, сами будете не рады потом.
Люби критику.
Один программист как-то написал очень клёвую утилиту, каких до него никто не делал. Он даже выложил её исходники на публику — потому что слышал, будто все крутые разработчики так делают.
Через некоторое время какой-то незнакомый человек прислал ему письмо: там он вежливо благодарил за полезную утилиту, предлагая исправления кода, представленные тут же.
Автор утилиты очень обиделся: как это так, мою крутую разработку кто-то вознамерился трогать своими немытыми руками!
А через полтора десятка лет этот же программист сам прислал список исправлений для проекта, разрабатываемого компанией молодых людей, считавших себя безумно крутыми разработчиками. И в ответ получил такую же обиду и хейт: какой выпендрёжник посмел тут обосрать наш прекрасный код? А ну иди сюда, я сам тебя обосру!
Как бы ты ни был крут и подготовлен, сколько бы сил и времени не вложил в своё развитие — всегда найдётся, кому макнуть тебя рылом в некомпетентность. Всегда есть человек, который взглянув на твой идеальный код, заявит, что такое дерьмище нельзя выпускать в продакшен; мало того — он ещё и напишет решение, которое действительно будет на порядок лучше. И сделано это будет не выпендрежа ради (хорошо, не только ради выпендрежа), а просто потому что ему это легко. Нет никакого смысла и рациональной причины обижаться и дуть щёки в ответ на критику: вас не унизили, а наоборот — приподняли над текущим уровнем. Скажите спасибо, извлеките опыт, это самое правильное, что вообще можно сделать.
Не работай в изменённом состоянии сознания.
Как-то, после бессонной ночи, опытный и уверенный в себе разработчик полез на удалённый сервер. Он прекрасно понимал, что писать код сейчас ему сложно — это же думать надо! — а вот поправить застарелый косяк с некорректными правами доступа на каталоги приложения он может не думая. Задачка, до которой просто не доходили руки, из тех, что выполняются с закрытыми глазами.
Запустив chown под рутом, разработчик увидел неожиданно большой вывод в терминале, и тут же нажал ctrl+c, отменяя выполнение. Но было уже поздно: он опечатался в пути исполнения, вместо каталога приложения задав команде путь от корня. Это практически порушило систему; чтобы всё продолжило хоть как-то работать, пришлось тут же выдать всем объектам 777, и потом уже муторно восстанавливать руками и скриптами.
Нельзя работать в изменённом состоянии сознания, невыспавшимся или выпившим. Вы можете решить, что всё в порядке, — но ваше сознание уже не способно на корректную самооценку. Поэтому просто "нет" — легко запомнить, невозможно забыть.
Мне наверняка возразят, припомнив т.н. "пик Балмера" — и я заранее принимаю возражение. С той оговоркой, что на продакшен пьяненьким лезть всё равно нельзя, а вот кодить начерно под лёгкой алкоголинкой бывает действительно увлекательно.
Дороже своего времени — только время коллег.
Обычный диалог в чате плохой команды:
— @username, мне нужно узнать, как сделать X, это твоя тема. [Через пять минут] — Ау, @username?! [проходит несколько часов] — Ещё надо? [Нет, я час ждал ответа, не дождался, потратил два часа на самостоятельное разбирательство, хотя ты мог дать мне нужные данные за пять минут, потерял контекст выполняемых задач, и, в общем, просрал время. И это не в первый раз так. Когда ты обратишься ко мне, я тоже не буду торопиться.] — Уже нет, спасибо... [все просирают дедлайн, получают втык, проект закрывается, стартап банкротится, Земля налетает на небесную ось]
Как должен выглядеть диалог в хорошей команде:
— @username, мне нужно узнать, как сделать X, это твоя тема. — Ок, смотри туда-то, там краткая дока для себя. Если нужны будут подробности — у меня окошко через два часа, можем созвон. — Отлично, спасибо! [проект выходит в срок, набирает аудиторию, Элон Маск пишет о нём в твиттере, стартап покупает Цукербергман за триллион долларов]
При работе в команде всегда цени время коллеги выше своего. Если к тебе кто-то обращается с разумной просьбой или обоснованным вопросом — он должен получить приоритет выше, чем твои дела. Помоги ему сразу, или же назначь время, когда сможешь помочь, чтобы тот распланировал своё время.
Если ты техлид или просто старший в команде — к тебе это относится десятикратно. Всегда будь доступен для помощи, это твоя первоочередная обязанность; как бы не было дорого твоё личное время, время команды ещё дороже. А прогер, знающий, что никогда не будет "буксовать" из-за недоступности лида, чувствует себя комфортнее, увереннее и благодарнее.
Будь учёным.
К сожалению, обучение на айтишника у нас сводится к вот этому:
ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ ПОСЛЕДНИЕ 9 КЛАССОВ. ВОТ БЕЙСИК, ОН РЕШАЕТ! @ ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ В ШКОЛЕ, ВОТ ПАСКАЛЬ, ОН РЕШАЕТ! @ ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ НА ПЕРВОМ КУРСЕ, ВОТ АСМ, ОН РЕШАЕТ! @ ЗАБУДЬТЕ ВСЕ ЧЕМУ ВАС УЧИЛИ, ВОТ ДИПЛОМ ПО СИШАРПУ, РЕШАЙТЕ. @ ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ В ВУЗЕ, ВОТ ПОХАПЕ, ЗДЕЛАЙТИ НАМ САЙТ ПОЖАЛСТА
Ни в каком ВУЗе, ни на каких платных курсах и даже ни на каких роликах с ютуба вас не научат хорошо программировать. Так, на полшишечки; а полное дерево знаний можно у себя вырастить только самостоятельно, много изучая и практикуя. Практикуя, практикуя, практикуя.
К счастью, у разработчиков сложилась своя, совершенно особая культура распространения и обмена знаниями и опытом, ближайший аналог которой — распространение знаний и опыта в научной среде. Но программисты сделали из этого целую идеологию open source. Во-первых, потому что могли, во вторых — потому что эта идеология очень хорошо отражает нашу профессиональную деформацию. Знать, изучать, улучшать, отдавать, демонстрируя свою крутость и принося пользу.
Это очень круто — да ещё и доступно без проблем. В то время, как тем же учёным буквально приходится платить журналам за рецензирование и публикацию их исследований, а другим учёным — оплачивать доступ к уже оплаченным публикациям, у нас на расстоянии одного запроса в гугл находится бесконечное множество материалов для изучения. Ты можешь взять исходники любимого фреймворка с гитхаба, впилить туда нужную фичу, и вжух** — ты в числе разработчиков. Не хватает умений для самостоятельного впиливания — оставляешь запрос на изменение, если фича нужна — может займётся кто-то другой. Или нет — никто никому ничего не должен.
Пользуйся этими преимуществами, изучай чужую работу, предлагай улучшения — такая практика лучше любой теории. Это повышает твою ценность, как специалиста.
Stay calm.
Когда к тебе прибегает белка-истеричка менеджер и начинает кричать, что всё плохо, сломалось и мы все погибнем, в 99% случаев это значит, что проблема не стоит выеденного яйца. И наоборот — в том единственном случае, когда случился какой-то настоящий ахтунг, твой гуманитарный друг решит, что нечего этих волосатых инопланетян беспокоить, они наверняка уже и сами знают.
Здесь не будет никаких историй или выводов, это просто наблюдение. Воспринимай ситуацию, как нечто само собой разумеющееся, оставайся спокоен и невозмутим.
Спорт необходим.
Через силу, через "не хочу", через годы, через расстоянья — занимайся своим организмом. Да, самое ценное — у тебя в голове; ты сидишь внутри черепушки, а вот эта несуразная конструкция из костей, кишок, мяса и разных жидкостей служит только для поддержания существования. Обслуживать эту периферию не хочется: можно ведь угнездиться в удобном кресле, тратя силы только на лёгкие движения кистями рук. Пиццу и колу тебе будут доставлять прямо к ротовому отверстию, удобно. Разве что, для гигиенических процедур придётся вставать; эх, когда уже научатся оцифровывать сознание?!
Вот пока не научились — биологический стафф, прилагаемый к мозгу, всё-таки надо обслуживать. Поддерживать его во вменяемом состоянии: мы, эволюционно, обезьяны, нам надо бегать, прыгать, вот это вот всё. Нам может не хотеться этого делать, но обезьянка в клетке быстро хиреет и тупеет. Так что седлайте велосипеды, прыгайте на турники, записывайтесь в спортзалы, ныряйте в бассейны, да хоть кубы в Beat Saber режьте. Ну надо!
Спорт, кроме прочего, переключает сознание, очищая мозг. Выше я писал, что разработчик всегда таскает свою работу с собой — и именно физическая нагрузка очень хорошо позволяет переключиться. Многие хорошие идеи и решения пришли мне после пары часов штанги или под финиш полумарафона: это неповторимое ощущение, когда в опустевшую голову прилетает письмо от боженьки*** с готовым ответом на задачку, которую ты полгода не мог осилить.
Комментируй это.
Миллионы раз сказанная, но от того не потерявшая актуальность, истина: комментируй свой код. Комментируй его так, будто читать его будет знающий твой адрес маньяк-убийца с топором.
Ведь вероятнее всего, читать эти комментарии будешь ты сам — когда уже напрочь забудешь и сам код, и даже для чего он нужен. Оставляй письмо самому себе, и сам себе скажешь за это "спасибо".
Конечно, с опытом ты дорастёшь до написания самодокументируемого кода, но вопрос "а для чего этот прекрасный код был нужен?" никуда не денется.
Можно было бы развернуть этот совет до "пиши документацию" — но, чувствую, это будет уже перебор. Тем не менее, если вы пишете доку и понятные примеры для стороннего разработчика — в программерском раю вам определённо забронировано лучшее местечко.
Не пызды многа. Пызды мала.****
Ежедневное дейли или какая-то летучка, или встреча. Полтора-два десятка человек сидят на пуфиках в опенспейсе, за столом в переговорке или вот даже в Зуме онлайн. И пока один рассказывает — скажем, докладывает продакту, чем занимался последний день, — остальные тупо просирают своё время.
Или представьте самое худшее, что может быть в команде разработчиков, — болтуна. Человека, не умеющего выцеплять конкретную и важную информацию. Обычно это звучит как-то так:
— Ну я делал фичу X, там надо было вот это так, но я решил сделать это так, и…
...Далее звучат минут всяких косвенных вещей, и заканчивается всё через полчаса подробностями о цвете поноса собаки, встреченной докладчиком на улице. Если вообще заканчивается.
И все сидят, слушают, не прерывают — потому что невежливо. И летучка растягивается на два часа; особенно это круто, если случается в середине рабочего дня, который, таким образом, оказывается просран — вернуться в контекст, из которого тебя вырвали, не так-то просто.
Или докладчик начинает на общей встрече разбирать вопрос, который только его касается. Какую-нибудь багу, с которой он может и должен подойти к более опытному коллеге отдельно. Да какого?!..
Это не дело. Для болтовни есть менеджеры, вот пусть они между собой собираются и меряются, у кого софт-скиллы длинней. А время господ разработчиков ценнее и важнее, берегите его.
Резюмируя: ощущаете, что на встрече происходит лишняя, ненужная вам болтология — вежливо интересуетесь необходимостью своего присутствия, предлагая всем заинтересованным обратиться персонально. И уходите. Сами же умейте говорить конкретно и по делу; сказали, вопросов нет, всем пока.
Делай бекапы!
Точно сделал? А если подумать? Автоматические? Инкрементные? На другую физическую машину? А лучше, конечно, на две. А восстановление проверил?
Вот казалось бы, сколько лет твердят: резервируй и перерезервируй… но сколько твердят, столько я и натыкаюсь на игнорирование этого правила. Последний раз — совсем недавно: бекапы боевой БД то ли не делались, то ли делались на другой раздел той же виртуалки; админский скрипт, удаляющий "бесхозные" инстансы чпокнул сервер (почему так получилось — отдельный разговор). Хоть какие-то данные пришлось выковыривать с dev-окружения, естественно, с потерями и искажениями, не говоря уж о простое сервиса. А ситуацию мог спасти трёхстрочный скрипт, раз в сутки архивирующий дамп, и отправляющий его да хоть по почте, если уж совсем больше некуда.
В миллиардный раз повторю — настраивайте правильные бекапы, резервирования мало не бывает!
Впрочем, если думаете, что повторяю зря, — правильно думаете: ребята из описанного кейса мало что вынесли, и нормального резерва так и не настроили. Но там случай с горбатым и могилой, что поделать.
Знай свой инструмент.
Очень болезненное наблюдение: мало кто умеет пользоваться тулзами и окружением, с которыми работают. Примеры очевидны: от запуска команд с sudo по умолчанию (т.е. человек убунтёнок не понимает идею разделения привилегий и ни разу не натыкался на патч Бармина) до использования VCS в качестве помойки.
Собственно, помойка в гите (сто тысяч серверных веток, мусорные commit message, ненужные ребейзы) — это погань, от которой лид команды должен отучивать разработчиков. А за форс пуши — уже и наказывать: как правило, форс пуш применяется неопытным разработчиком, как универсальное решение какой-то проблемы, с которой нормально справиться он не смог. Не порешал конфликты при мерже, например, испугался и перезатёр файлик локальным бекапом.
Беда тут в том, что с гитом работает вся команда, и один косяк может создать проблемы всем сразу.
Хуже ситуации с одним разработчиком, не умеющим в git, только когда в него не умеют все. И всем плевать. И конфиги хранятся в гите, и деплой делается ручками, и тысяча веток на сервере, и хардпуши сразу в мастер, и прочее, и прочее. Видел и вижу такое, к большому сожалению, очень часто.
Впрочем, часто встречаю некомпетентность и в других моментах, и примеров могу привести превеликое множество. Они могут показаться настолько тупыми, что вы решите, будто я их придумал; ах, если бы! Не далее, как вчера разработчик жаловался, что ему трудно отлаживать JS-скрипт в браузере через alert();.
Так что вы можете быть даже не очень хорошим программистом, не знать всех этих мудрёных алгоритмов, не понимать, как работают какие-нибудь хешмапы и где находятся пузырьки в одноимённой сортировке. Но если вы хотя бы знаете хоткеи своей IDE, а ещё лучше — прочтёте по ней справку и научитесь пользоваться автодополнением — у вас есть шанс отлично вписаться в сраную разработку, и успешно чего-то говнокодить, пока не придёте ко мне на собеседование, где я сломаю вам нос.
*) Здесь и везде под неким разработчиком был вовсе не какой-нибудь Альберт Эйнштейн, а, скорее всего, я. А иногда не я, но всегда это были какие-то реально существующие граждане.
**) Среднестатистический "вжух" занимает от нескольких часов до полугода, требуемых ментейнеру проекта на тестирование и принятие пулл-реквеста.
***) Боженька здесь приведён, как некий вымышленный персонаж, чей образ укреплён в коллективном сознании. А так нету никакого боженьки, уж писем от него точно никто не получал.
****) Народный пасловиц и пагаворка. Кныга маладова байца. Гиен-Аул: Нахнахыздат, 566 год Тарзана.