Памятка рекрутеру

Совершенно не считаю рекрутеров бесполезными людьми, они полезные, нередко адекватные и разумные (в той же пропорции, в которой адекватность встречается в социуме), но раз за разом умудряются совершать одни и те же ошибки, что потихоньку выбешивает. Дайте ссылку на это эссе знакомому IT-рекрутеру, пусть проникнется.

Во-первых, не надо мне звонить. НЕ НАДО. ЗВОНИТЬ НЕ НАДО, БЛИН ВАШУ. Разговор голосом в отношениях «разработчик vs рекрутер» — это финальная стадия отношений, не стартовая. Во время вашего звонка я могу быть фиг знает где, услышать фиг знает что (если вообще захочу), вы всё равно весь текст вакансии мне не расскажете (а если расскажете, я треть не услышу) и т.д. Внезапно звонящий рекрутер звучит как стопицотый телефонный спамер, вносимый в чёрный список, не более. Если у вас есть мой номер телефона, у вас должен быть и email. Как вы, блин, вообще представляете себе процесс? Оу, звонит незнакомая девушка, тарабанит два-три предложения, а я «уря! хотеть к вам сходить прям сейчас вечером нет сейчас хотеть берите аааа»? Нет, правда?
Во-вторых, читайте резюме. Рекрутер, предлагающий мне вакансию фронта, изумляет до невозможности. Рекрутер, спрашивающий, какой у меня стаж и опыт, тоже. Рекрутер из Екатеринбурга, удивлённый «ой, а вы не в Е.?», удивил взаимно. Вы потратите пять минут на человеко-кандидата, но избежите кучи нелепостей, после которых у разработчика подозрения, что всё у них так, потому нафиг надо.
В-третьих, почта. Офигенное изобретение человечества, позволяющее рекрутеру дать мне 1) много нужной информации, 2) возможность вдумчиво исследовать вакансию. Погуглю контору. Посмотрю на карте офис. Прикину требования к себе. Вдруг у меня знакомые есть в конторе, им напишу, спрошу. Вот только после этого процесса что-то внятное отвечу. Не потому, что я сноб и зануда (хоть я сноб и зануда). Потому, что вакансий много, рекрутеров много, у меня есть выбор. Если рекрутер не осиливает в этот выбор доложить свой лист текста, для меня это точно не трагедия, просто я не нужен этому рекрутеру, а этот рекрутер мне.
В-четвёртых, общение, личность, социализация, всё такое. Пункт со звёздочкой, да. Письма из шаблона убогие («Уважаемый(я) Сергей», ага). Рекрутер, общающийся не со мною, но с анонимным ресурсом, от найма которого рекрутер получит копеечку, скучен и ничем не выделяется на общем фоне. С таким же успехом могу HeadHunter полистать. Особенно несчастно выглядит на фоне рекрутеров, с которыми сложились товарищеские отношения. Разница в том, что они начинали не шаблоном. Попробуйте написать простое человеческое письмо. Не надо стихами, не надо клоунады. Простое человеческое. Можно даже без полной вакансии сразу. Устроит «Сергей, привет. Знаю, что не в поиске работы, но не считаю лишним обменяться контактами, если вы не против. Вы всё так же джавист, специализацию не сменили?» и т.п. Я общительный и отвечу. А рекрутер мне ответит. А я. Но вот именно с человеческим общением у рекрутеров не складывается, сплошной равнодушный поток.

А так-то ребята и девчата нужную работу делают, аки пчёлки, цветочки опыляющие.

Главный рефакторинг

Посмотрел вчера на код после джуниора, сделал всего один рефакторинг и тут же удалил 380 строк. Задумался, вспоминая последние 10..15 рефакторингов, что делал. По сути все они были одним и тем же: убийство копипасты. Нет, иногда копипаста не плохо. Иногда она даже нужна и является элементом архитектуры. Но часто она всё-таки фу и бяка. И один из skill’ов, что разработчик должен натачивать в себе с первого же молочного зуба — чутьё на плохую копипасту и практику её уничтожения. Если этого нет, нет и хорошего разработчика, даже не надейтесь.

Более культурно это нынче называется DRY (Don’t repeat yourself) и за последние лет двадцать каждый уважающий себя учебник рекомендует следовать этому принципу (ещё до того, как его сформулировали).
Например, [Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts. Refactoring. Addison-Wesley, 1999]: «Number one in the stink parade is duplicated code. If you see the same code structure in more than one place, you can be sure that your program will be better if you find a way to unify them».
Например, [Steve McConnell. Code Complete. Microsoft Press, 2004]: «Duplicated code almost always represents a failure to fully factor the design in the first place». (на деле у него примерно такой же текст уже в 1998 году был.
Например, [Robert C. Martin. Clean Code. Prentice Hall, 2008]: «Every time you see duplication in the code, it represents a missed opportunity for abstraction. .. Find and eliminate duplication wherever you can».

Почему это важно? Даже вот не с позиции абстракций и прочего, но сугубо прагматично кодерски.
Во-первых, вы мешаете JIT’у и прочим оптимизациям. Если исходник в одном месте и часто вызывается, у него гораздо больше шансов на автоматическую оптимизацию, чем у того же исходника в двадцати местах с размазанными вызовами.
Во-вторых, вы мешаете коллегам изучать код не только увеличенным объёмом текста и пустыми ожиданиями «раз оно двоится, может, не просто так», но и тем, что в IDE не получится тыцнуть в один метод и найти его использование.
В-третьих, вы очевидно мешаете исправлять этот код. Я и в самом деле сегодня вынужден был заменить 20+ копипаст. Предположим, правил бы багу. Мне пришлось бы править её в 20+ местах, после чего генератор копипасты был бы упомянут в разных позах и разных занятиях. Не говоря уж о том, что в случае баги я мог бы в одном-двух местах её и не исправить, пропустив. В общем, беда.
В-четвёртых, вы мешаете делать рефакторинг. Довольно часто бывает так, что после выноса копипасты становится очевидным следующий шаг. А потом ещё один. Рефакторинг похож на падающие доминошки, после одной каки чистятся ещё десять и в конце красивый компактный понятный код. А когда перед глазами портянки, сложно сразу уцепить возможность улучшения.

В общем, дорогие джуниоры, учитесь это самое. Даже если у вас в телах if’а повторы, уже повод почесать репку. Чешите репку чаще, оно полезно.

Лучшие ошибки софта VII

Довольно смешная (не смешная для авторов, конечно) ошибка произошла несколько лет назад. Игра Aliens: Colonial Marines вышла в феврале 2013 года и быстро получила шквал критики. Ну очень сырой продукт выпустили. Нещадно бажило всё, от графики до AI. И вот спустя четыре с хвостиком года обнаружился символ, исправление которого привело к наизаметнейшему улучшению поведения монстров. Достаточно было заменить ошибочное «Teather» на верное «Tether». Тестирование? Не, не слышал.

Автомобильная индустрия вовсю напичкивает машины сложным софтом, потому очередная проблема не удивляет. Но масштаб последствий интересный. Итак, Fiat Chrysler Automobiles NV отзывает около 4.8M автомобилей в США по причине баги в круиз-контроле. Вернее, с ним-то всё хорошо. Просто при схождении звёзд в 15 моделях этот контроль потом не выключить, да ещё и замыкание происходит. В общем, веселье, если ты не за рулём.

Затрудняюсь оценить ущерб, но ошибка классическая, хоть в учебники. В 1978 году с помощью NASA начали исследовать озоновые дыры над Антарктикой. Датчики собирают данные, софт анализирует, дыры находятся. Уря-уря. Пока в 1985 году совсем другие ребята не обнаружили, что огромная дырень прошла мимо программы исследований просто потому, что в код влепили ограничение на верхние границы. Мол, если значение такое-то, то оно шибко толсто, так не бывает, явно ошибка датчиков. Оказалось, бывает и не такое.

На дне у Ларнаки с 1980 года лежит большой и красивый кораблик MS Zenobia. А лежит он там потому, что в софте, управляющем закачкой балластной воды, выстрелила бага, закачавшая слишком много воды слишком не вовремя. Жертв нет. Как и Зенобии. Зато дайверам раздолье, внесено в карты годных мест.

Долго колебался, добавлять эту историю или нет. Решил добавить, т.к. можно считать примером того, с какой стороны в софт может прилететь проблема и как легко всё испортить, не учитывая все векторы «атаки». На юге Финляндии 12 апреля 1997 года поезда не ходили целый час. Всё потому, что на клавиатуру упала скрепка. Упала под пробел и, как понимаю, накрыла контакты. Дальше я не понял причины (машина запрашивала логин три дня и переполнила винт?), но в итоге сигналы на железке были переведены автоматикой в «стоп». Ну всё и остановилось. В общем, учитывайте и такие случаи, да.

Книга: Getting Started with SQL

lrg (1)
Thomas Nield.
Getting Started with SQL: A Hands-On Approach for Beginners.
O’Reilly, 2016.
Есть особая категория книг — помогающие переступить порог входа. Обычно в них нет откровений, нет сакральности, просто текст, который написан так доступно и так деликатно к измождённому учёбой мозгу, что после прочтения уже не страшно, можно идти дальше.
Вот эта такая. Всего 100+ страниц, базой SQLite, рассматривается самый ходовой набор SQL. Совсем немножко захвачена тема дизайна схемы базы данных, но тем, кто вообще никогда, и так норм.
Книга годная, советую тем, кто впервые сталкивается с SQL и хочет оперативно подхватить основы.

Инфраструктура стартапа

// По другому поводу написал конспект современной инфраструктуры, но получилось достаточно цельно, потому и за эссе сойдёт.
Развитие инфраструктуры идёт в сторону «делать больше, платить меньше». В общем, как и везде на рынке технологий. Небольшие компании не могут позволить себе сотни тысяч долларов ежемесячно, да и большие давно стараются ужаться в подобных расходах (один лишь GitHub на 1K пользователей в год начинается от 15М рублей), потому прогресс идёт вполне ожидаемым путём.
Под инфраструктурой далее подразумеваю всё, что обеспечивает процесс разработки и эксплуатации продукта, а не части самого продукта. Потому, например, Nginx в тренде, но это не инфраструктура.
Упомянутые названия считаю современным [хайповым] трендом. Иначе говоря, если собрать в небольшую толпу десятка два 20..30-летних разработчиков, из толпы будет доноситься то, что опишу ниже. Безусловно, существуют организации, живущие на другом софте, но речь не про них.
Каталог ниже также можно рассматривать, как первый набросок для первых обсуждений в начинающем стартапе. О, у нас есть N копеек и два человека, что мы можем из этого соорудить, чтобы продержаться десять лет до первого миллиона копеек? Если с этой позиции смотреть, так нынешний софт в какой-то мере представляет собою конструктор Лего. Кубики умеют работать друг с другом, редко являются обязательными, конструкцию по мере нужды можно наращивать и даже местами заменять с адекватной миграцией данных, ежели руки прямые. Я как-то прикидывал, нынче при действительно прямых руках можно чуть ли не всю инфраструктуру размазать за $150 в месяц. Не на сто человек, да, но мелкий коллектив вполне. Хорошие времена.

Нулевой круг: хостинг особо упомяну.
В тренде аутсорсинг и облачность. Соответственно, массово выбирают тех, кто на нормальном уровне за нормальные деньги предоставляет все те услуги, которые предоставлялись бы собственной серверной с отрядом админов, железячников, ноков и завхозов. Влёт можно назвать [в порядке убывания универсальности] Amazon AWS, Microsoft Azure, Google Cloud Platform. Это очень разные платформы со своей спецификой каждая, потому равными назвать не могу. Просто разные. Если нужно «в два клика» что-нибудь захостить, есть DigitalOcean. Сервисов на порядок (если не два) меньше, чем у того же AWS, но с задачей справляется.

Первый круг: VCS и Issue tracker.
VCS. Исходный код и прочее надо где-то хранить и обеспечить общину возможностью совместной работы с ним. Совместная работа нынче подразумевает активную вовлечённость, социальность, частично геймификацию, интеграцию со всем на свете. В тренде GitHub, GitLab, Bitbucket. Все три решения сделаны поверх git.
Issue tracker. Весело, молодо и задорно жить без тикетов или обходиться цветными бумажками на доске, но рано или поздно, а команда из этих штанишек вырастает. Задачи надо где-то описывать, обсуждать, отслеживать статус, строить графы зависимостей, получать срезы состояния и прочее. Тут устроить зоопарк проще, т.к. каждый год кто-нибудь пытается повторить успех JIRA (ведущий ледокол рынка трекеров, с каждым релизом бьющий рекорды неудобства). В спину ей дышат Bugzilla (для совсем олдскульных), YouTrack. С ощутимой натяжкой можно упомянуть Trello, но они всё-таки про другое. Но если далеко от системы карточек на доске уходить не хочется, то и Trello сойдёт.

Второй круг: общение, мониторинг и логи.
Общение. Команды часто распределённые (особенно если вы стартап и вам дешевле нанять двух senior’ов из Мордовии, чем одного московского middle), потому тема «где нам обсуждать работу?» поднимется быстро. Важной характеристикой решения является возможность видео на команду. Тут тоже бардак, т.к. долго не было единого продукта, решающего все задачи разработки (закрытые групповые каналы, архив, конференции, plugin’абильность, модные боты и т.п.). Потому у вас сейчас два варианта: устраивать конструктор из Skype / Jabber (ссылка на протокол) / Telegram или использовать Slack. Особняком варианты для knowledge base — что-то для хранения коллективных знаний. Тут у каждого своё, хоть одну из сотни Wiki поднимай, хоть один из вариантов по подписке, хоть закрытый репозиторий на GitHub. «Моделей» слишком много на любой вкус.
Мониторинг. В какой-то важный для команды момент количество тихо упавших сервисов начнёт действовать на нервы, после чего срочно вспоминают о нужде мониторинга живости машин и софта на них. Тут тоже не особо много боевых альтернатив. Частые метрики снимаются либо в Prometheus, либо в Influx. Событийный мониторинг есть смысл делать через всё тот же Zabbix. Приятные глазу графики как смотрели, так и будем смотреть в Grafana. А всякие стектрейсы и прочие ошибки можно отправлять в Sentry.
Логи. Весь софт пишет мегагигабайты логов, об которые ушатаешься ходить на каждую машину и грепать файл за файлом. Потому человечество придумало ELK stack (Elasticsearch, Logstash, Kibana). Держать в инфраструктуре эту триаду — та ещё головная боль, но иметь возможность удобно оперировать логами с кластеров… бесценно.

Последний круг: Continuous integration, Continuous delivery и остальное.
Темпы современной жизни диктуют темпы и разработке. Продукты надо делать быстро. Скорость часто бьёт по качеству, потому элементы CI/CD включают в себя также и максимальное исключение человеческого фактора — автоматизация проверок кода, автоматизация сборок, выкаток. В этой области раздолье и зоопарк полный. На деле же основной проблемой будет совсем не софт, но внедрение разработчикам в головы нужды в CI. Например, там тесты писать надо, а это же таааак скуууучно.
В этом же разделе решения, которые могут примениться раньше, могут позже, могут прямо-явно не относиться к CI/CD, но здорово его облегчают. В общем, список того, чем занимаются, когда хотят сделать всё правильно и есть возможность.
Контейнеры. Удобнее куда-нибудь доставить и где-нибудь поднять уже готовое приложение со всеми конфигами, файликами и прочим. Как минимум, это быстрее. На сцену выходит Docker, царь контейнерного хайпа. Лишь избранные знают и думают о других решениях. На самом деле вполне стоит и подумать, т.к. Docker не панацея и для ряда задач имеет смысл прикинуть альтернативы.
Оркестровка. Нравится это слово в контексте «хорошо, давайте управлять всеми этими контейнерами на этих инстансах в этих облаках». Тут поле боя, на котором рубятся Swarm с Kubernetes. Правда, тут снова тема Docker, но чё уж, мода. Сюда же Nomad для спартанцев.
Сборка и тесты. Так лаконично свёл CI в две задачи. На деле, конечно, решается гораздо больший спектр. Навскидку тут можно назвать три продукта: Jenkins, TeamCity, Travis CI (ваш выбор, если open source). Каждый со своими чудесами, своими лицензиями и ценами. Но вряд ли вы обойдётесь без них при внедрении CI в инфраструктуру. Писать скрипты запуска и сборки по крону занятно, спору нет, но лучше не надо.

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