FEDOR BORSHEV
Управление проектами
Подписаться

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

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

#гитхаб

Другие статьи канала FEDOR BORSHEV

FEDOR BORSHEV
Управление проектами
Подписаться
Писать хорошую историю в гите — важная часть гигиены проекта.

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

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

FEDOR BORSHEV
Управление проектами
Подписаться

С первого раза

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

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

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

Я говорю о простых случаях, которые может заметить кто угодно, банальном «нажимаю на кнопку
- получаю ошибку». Непосредственных причин такой хуйни может быть много
- CI упал, код не прошёл валидацию\тесты, программист забыл сделать git push.

А вот фундаментальная причина одна, и ее легко исправить
- это непонимание definition of done. В случае бага все просто
- баг не воспроизводится на продакшене. В сложных фичах приходится задавать вопросы
- что постановщик ожидает получить от фичи? Какие самые частые сценарии использования? В каком виде лучше показывать результат?

Самое лучшее средство от непонимания definition of done
- всегда подкреплять свои слова доказательством. Пофиксил баг
- приложи скриншот. Выкатил фичу
- запиши видосик.

Если не понимаешь, что скриншотить/записывать
- иди за пониманием задачи к тимлиду или менеджеру.

FEDOR BORSHEV
Управление проектами
Подписаться
Вопрос:

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

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

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

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

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

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

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

FEDOR BORSHEV
Управление проектами
Подписаться

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

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

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

FEDOR BORSHEV
Управление проектами
Подписаться
Как я распределяю нагрузку среди членов команды:

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

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

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

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

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

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

FEDOR BORSHEV
Управление проектами
Подписаться
Знакомая проблема?

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


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


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


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


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


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


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

FEDOR BORSHEV
Управление проектами
Подписаться
Как я распределяю нагрузку среди членов команды:

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

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

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

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

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

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

FEDOR BORSHEV
Управление проектами
Подписаться
Пример решения из предыдущего поста У нас в mtrl.

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

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

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

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

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

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

FEDOR BORSHEV
Управление проектами
Подписаться
Красиво решать задачи

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

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

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

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

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

FEDOR BORSHEV
Управление проектами
Подписаться
Продолжаю публиковать отрывки из нашей внутренней документации.

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

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

FEDOR BORSHEV
Управление проектами
Подписаться
Сервис:

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

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

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

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

FEDOR BORSHEV
Управление проектами
Подписаться
Как мы мониторим заказы Начинаю потихоньку публиковать наши внутренние инструкции.

Начну с описания того, как мы мониторим заказы
- какие письма и из каких систем приходят, и как мы на них реагируем.

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

FEDOR BORSHEV
Управление проектами
Подписаться
​​​​​​Фичреквесты, которые не стоит выполнять

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

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

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

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


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

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

#чтобычто

FEDOR BORSHEV
Управление проектами
Подписаться
Что учить джуниору, чтобы найти работу в крутом ИТ-стартапе?

anonymous poll Node.js? – 127??????? 59%

Джанго – 65???? 30%

Рельсы – 23? 11%

? 215 people voted so far.

Рейтинг авторов

  • "Записки Дизайнера" (про дизайн и только про него 157 157 157
  • (Не) только немецкий 157 157 157
  • #анямастерконтента 157 157 157
  • #Фудтех 157 157 157
  • 10 идей и трендов дня 157 157 157
Показать весь рейтинг
Загрузка ...