Что учить джуниору, чтобы найти работу в крутом ИТ-стартапе?
anonymous poll

Node.js😱 – 128
👍👍👍👍👍👍👍 59%

Джанго – 66
👍👍👍👍 30%

Рельсы – 23
👍 11%

👥 217 people voted so far.

​​​​​​Фичреквесты, которые не стоит выполнять

Даже самые полезные фичи в момент появления скорее всего выглядят уродливо.

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

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

Обычно этим занимается выделенный продуктовый менеджер, или дизайнер, который умеет задавать вопросы. Если у вас таких людей пока нет — внедрите хотя бы стоп-задачи: запросы, которые НИКОГДА не обрабатываются в сыром виде:

— выгрузка в Эксель
— автоматическое письмо в посту/слэк/СМС
— добавить любую кнопку/галочку
— покрасить что-нибудь в красный/выделить жирным

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

#чтобычто

Как мы мониторим заказы

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

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

​​Сервис: uptimerobot

На рынке есть куча SaaS-решений для мониторинга работоспособности — от простого statuscake родом из 2000-х, до дорогущего new relic или специализированных связок из prometheus и продуктов elastic.

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

Uptimerobot — отличное решение для тех, кто не хочет разбираться в раздутых интерфейсах и перипетиях ценообразования. Бесплатно можно мониторить до 50 ресурсов, работает интеграция с телеграмом и кучей других сервисов.

За 5,5$ в месяц дают мониторить неограниченное количество сайтов, проверяют их раз в минуту (вместо раза в 5 минут), отслеживают живость SSL-сертификатов и рассылают СМС.

Продолжаю публиковать отрывки из нашей внутренней документации. Здесь рассказано, как новые специалисты поднимают у себя проекты, чтобы начать разработку (спойлер — почти никак).

Инструкция будет интересна небольшим командам, которые хотят получить нормальный девопс — с ее помощью мы в mtrl.ai добились того, что новый фронтендер, знающий vue.js, может контрибьютить в прод в первый рабочий день.

Ссылки на докерфайлы ведут на закрытые ресурсы, если интересно что-то оттуда — пишите в личку, расскажу.

Красиво решать задачи

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

Мой любимый критерий красивого решения — время. Причем время не календарное (если ваша команда не может делать задачи быстро, вам не до «красивости»), а относительное. Почти любую сложную задачу можно решить быстрее, чем при помощи первого пришедшего в голову варианта: не пилить микросервис, а сделать кеширование; не рефакторить все приложение, а сделать микросервис; не писать новый компонент, а допилить и переиспользовать старый.

Медленное и некрасивое решение обычно выглядит так: заказчик пришел с проблемой → уходим пилить → заказчик пришел еще с одной проблемой → проебали обе.

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

К сожалению, чтобы в продукте появлялись красивые и эффективные решения, нужна целая экосистема, т.н. «культура разработки»: сильные тимлиды, отсутствие авралов, разумный техдолг, умение ставить задачи-проблемы вместо задач-решений, вести диалог и еще много всего. А без экосистемы программисты думают не над эффективностью, а над тем, как сделать, чтобы от них отъебались.

Пример решения из предыдущего поста

У нас в mtrl.ai есть понятие «виртуального склада» — это огромный массив ценовых предложений со строительных рынков, который мы накопили и постоянно обновляем. Благодаря этому массиву мы можем быстро прогнозировать конкретный рынок (и даже конкретного продавца), который лучше всего повезёт заказ.

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

Чтобы задача не болела, мы применили тупое решение — просто увеличили в два раза ресурсы на сервере с базой.

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

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

В итоге мы потратили 30 минут вместо трёх дней просто за счет того, что дали себе спокойно подумать.

Как я распределяю нагрузку среди членов команды: буфер

В личке часто спрашивают, как мне удается нормально распределять нагрузку между программистами в условиях жёстких дедлайнов и коротких спринтов.

Самое главное правило — не обманывать себя при планировании и помнить, что планы без запаса не сбываются.

Свой запас я держу в буфере, который называется «можно проебать», это прям такой лейбл в трекере. Лейбл ставится на задачи, которые мы будем делать только, если успеем закончить остальные.

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

Если спринт спланирован хорошо, то примерно половина из буферных задач успешно закрывается. Если плохо — закрываются или все, или ни одной.

В следующем посте расскажу, как планируем задачи, которые проебать нельзя.

Знакомая проблема?

"У нас в бэклоге есть много задач, которые мы реализуем, но очень медленно. Что делать? Искать инвестиции на увеличение количества разработчиков? Как-то разделять задачи по приоритетам – но как?".

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

2. Как ни странно – 2. Увеличение количества разработчиков на реализацию одной фичи, скорее всего, увеличит время разработки этой фичи. Эффект, подмеченный еще Бруксом в "Мифическом человеко-месяце".

3. Единственный совет, который можно дать в такой ситуации – разделить все задачи на три категории.
– Первая категория – реализация фич, которые уверенно дадут вам улучшение конверсии. Эта уверенность базируется на их очевидности. Следствие из очевидности – увеличение конверсии будет ожидаемым, но не критичным.
– Вторая категория – фичи из серии "Хрен его знает, но это может быть круто". Мы не знаем, сработает это или нет. Но, если сработает – конверсия вырастет в разы.
– Третья категория – фичи из серии "Полезно, красиво, удобно, нужно".

4. Так вот, в первую очередь надо реализовывать задачи из второй категории. Потому что этап стартапа – это этап проверки рискованных гипотез. Только в них заложен шанс на взрывной рост.

5. Если мы добираемся до задач из первой категории, стоит задать себе вопрос – а мы уже исчерпали фантазию по поводу рискованных гипотез? Мы уже довольны тем ростом, который у нас есть?

6. А вот задачи из третьей категории вообще не надо реализовывать. Никогда.

Как я распределяю нагрузку среди членов команды: обещания

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

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

Ребята знают, что в ситуации, когда ничего не успевается, нужно не страдать ночами над клавиатурой, а идти ко мне и обсуждать проблему. Спринты у нас длятся с понедельника по понедельник, и обычный день для таких обсуждений — четверг (помните про правило 50%?)

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

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

Изучение того, как флексить, стоит с советов Товеровского.

Сегодня выкладываю подборку материалов, которую мы используем в mtrl.ai для обучения новых программистов. Эта статья в вики так и называется — «Что сделать, приступая к работе».

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

Правила
1. Мы работаем через Github flow.
2. Беклог храним в issues, спринты планируем в milestones.
3. Спринт длится одну неделю, со вторника по понедельник включительно.
4. Мы знаем, что значит сделать.
5. Не решаем придуманные проблемы.


Бекенд
1. Если не чувствуете себя уверенно с Питоном, то почитайте Марк Лутц — Изучаем Питон.
2. Если вдруг еще не знаете, изучите PEP-8.
3. Если мало работали с Джанго, то пройдите официальную обучалку.
4. Прочитайте Требования к коду.
5. Почитайте про TDD.
6. Прочитайте Obey the testing goat.
7. Почитайте про REST и изучите Django REST Framework.
8. Изучите процесс CI и поймите, что делается на каждом этапе.

Фронтенд
1. Изучите ES2015.
2. Изучите airbnb style guide.
3. Для работы над сайтом изучите CSS Grids, или вот, вот и вот.
4. Прочитайте документацию Вью, Вьюкс, Вью-роутера и накста.
5. Изучите ководство и пришлите Федору 5 статей, которые считаете самыми важными.
6. Чтобы писать меньше CSS, изучите Стилус для бекофиса и SCSS для всего остального.
7. Посмотрите Технолог — тоже дизайнер.
8. Чтобы лишний раз не переспрашивать у бекендера, как выполнить ту или иную манипуляцию данными, почитайте про REST.
9. Почитайте про анимацию для разработчиков интерфейсов.
10. Почитайте о том, как писать надписи в интерфейсах.


Коммуникация
1. Настроить пустой инбокс с единой папкой входящих. Почта — основное средство связи в команде.
2. Прописать в почте имя и фамилию ЛАТИНИЦЕЙ.
3. Убедиться, что коммиты в гитхаб делаются от твоего имени.
4. Вступить в чатик для обмена гифками и присылать не менее двух мемасиков в день.

​​Вопрос: Достался говнокод в наследство

В личку задали вопрос — «вот ты топишь за красивый код, а как быть на проектах, где в наследство досталась гора говнокода, с которой сделать ничего невозможно?»

Ситуация на самом деле очень частая: есть технический долг на пару человеколет, а проект живой — на него завязаны важные бизнес-процессы, или просто «времени нет переделывать».

Во-первых, нужно понять, что уйти и все переписывать полгода у вас не получится — у бизнеса дедлайны, пользователи ждут фич и вообще, большие планы не сбываются.

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

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

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

см. также: #техдолг

Есть #вопрос? Присылай в @fedor_borshev, если понравится — отвечу в канале.

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

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

​​Гитхаб выкатил классную фичу для питонистов — Dependency Graph на основе анализа requirements.txt. Помимо красивого, но бесполезного вывода версий библиотек, гитхаб теперь умеет присылать алерты безопасности. До этого эта фича работала только с Руби (в гитхабе много рубистов) и JS.

Продолжаю считать гитхаб единственным местом, в котором стоит хранить свой код (кроме жесткого диска для бекапов, конечно) — по удобству и количеству фич он далеко опережает конкурентов вроде гитлаба и битбакета.

#гитхаб

Вопрос по понедельникам: Начинаю изучать ПХП, стоит ли идти стажёром в агенство, которое работает на битриксе?

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

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

К тому же Битрикс — вещь в себе: становясь специалистом по Битриксу, вы намертво связываете себя с российским рынком (больше про него нигде не знают), и с нестандартными, мягко говоря, способами решать стандартные задачи.

Последний пункт поясню. К примеру, если вы знаете условный Laravel, то вы понимаете, что такое MVC, зачем нужна ORM, как устроена маршрутизация в веб-приложениях. Вы уже наверняка несколько раз наступили на стандартные новичковые грабли, вроде толстых вьюх или N+1. Это означает, то вы достаточно легко можете пересесть на любой другой веб-фреймворк — хоть Yii, хоть Django, или вообще какой-нибудь Meteor. А если вы знаете Битрикс, то вы знаете только Битрикс. Вы, вероятно, даже документацию на английском читать не умеете.

Так что, если сможете найти агенство без битрикса — идите туда смело, научитесь не только базовым софтскиллам, но ещё и немного программированию. Если повезет с наставником, конечно.

Есть #вопрос? Присылай в @fedor_borshev.

Требования к питоньему коду

После поста про погружение новых программистов, много ребят попросили выложить наши требования к коду в в mtrl.ai. Я даже не думал, что на канале столько питонистов.

Формальных требований у нас совсем немного — все требования мы стараемся выражать при помощи автоматизированных инструментов в IDE и CI, чтобы несоответствие стандартам выявлялось на этапе написания кода, а не на код ревью.

На питоне вы для этого используем кучу плагинов для flake8, кроме стандартных это commas, bugbear, isort, print. Еще ждем релиза pep8-naming с моим патчем.

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

А вот и сами требования (на английском, по историческим причинам).

Style
— Obey django's style guide.
— Configure your IDE to use flake8 for checking your python code. For running flake8 manualy, do cd src && flake8
— Prefer English over your native language in comments and commit messages.
— Commit messages should contain the unique id of issue they are linked to (refs #100500 -- changed smth)
— Every model and a model method should have a docstring.

Testing
— We use TDD, so all of your code (except admin declarations) should be covered by tests.
— Unit tests are split into 4 categories:
— Unit (check at least 90% of the flow graph for every method)
— Functional: business-logic, cross-app relations, testing views
— API
— Integration: integration with other services or complex business-cases, like creating an order with certain payment type and delivery.

Code organisation
— DRY and KISS.
— Obey django best practices.
— Make models fat. No logic is allowed within the views or templates. Only models.
— Use PEP-484 type hints when possible.
— Prefer composition over inheritance.
— Prefer Manager methods over static model methods.
— Obey Attribute\method order for your models.
— Do not use signals for business logic. Signals are good only for notification purposes.
— No l10n is allowed in python code, use django translation.

Презентация самому себе

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

Иногда бывает, что работу сдавать некому — дизайнер\менеджер не отвечает, вы делаете задачу на своем проекте, или просто не считаете нужным кого-то отвлекать.

Чтобы не запускать неработающее говно, проведите презентацию самому себе. А еще лучше — выберите коллегу поопытнее, и представьте, как проводите презентацию ему.

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

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

О таких проблемах гораздо лучше узнавать от воображаемого коллеги, а не от реального.