Вопрос: мне дают много кода на ревью. Прям так много, что иногда не остается времени на свои задачи. Как соблюдать баланс между своими задачами и чужими?
Можно попробовать мою методику разделения времени. Я делю свое рабочее время на две части — личное и условно-свободное. Личное время я трачу на то, что важно для меня — мои задачи, аналитика, стратегические исследования. На личное время уходят самые продуктивные часы (у меня это утро).
Условно-свободное время я занимаю тем, что важно сейчас — это может быть и ревью кода, и ответы на письма, и помощь кому-то с решением задачи.
Личное время — это святое: оно закрыто в календаре, в это время я не пользуюсь почтой, не захожу в телеграм и даже стараюсь избежать гитхаба, чтобы случайно не увидеть, как кто-нибудь от меня чего-нибудь ждет.
#вопрос
Можно попробовать мою методику разделения времени. Я делю свое рабочее время на две части — личное и условно-свободное. Личное время я трачу на то, что важно для меня — мои задачи, аналитика, стратегические исследования. На личное время уходят самые продуктивные часы (у меня это утро).
Условно-свободное время я занимаю тем, что важно сейчас — это может быть и ревью кода, и ответы на письма, и помощь кому-то с решением задачи.
Личное время — это святое: оно закрыто в календаре, в это время я не пользуюсь почтой, не захожу в телеграм и даже стараюсь избежать гитхаба, чтобы случайно не увидеть, как кто-нибудь от меня чего-нибудь ждет.
#вопрос
Форс-пуши в гитхабе
#гитхаб продолжает радовать полезными фичами — теперь даже при перезаписи истории через force push, он все равно сохраняет промежуточные результаты.
Force push — это такой способ поддерживать красивую историю изменений, когда программист локально переписывает историю коммитов задним числом, а потом отправляет изменения на сервер. Обычно это делают в рамках пулл-реквестов, чтобы легче было понять, что именно задумал автор.
В последнее время в бету прилетело еще много нового — показ похожих тасков при создании новых, возможность удалять их и переносить между проектами.
#гитхаб продолжает радовать полезными фичами — теперь даже при перезаписи истории через force push, он все равно сохраняет промежуточные результаты.
Force push — это такой способ поддерживать красивую историю изменений, когда программист локально переписывает историю коммитов задним числом, а потом отправляет изменения на сервер. Обычно это делают в рамках пулл-реквестов, чтобы легче было понять, что именно задумал автор.
В последнее время в бету прилетело еще много нового — показ похожих тасков при создании новых, возможность удалять их и переносить между проектами.
Параллельность в Circle CI
Это — начало рассказа о том, как у нас устроен Continuous Integration среднеразмерного (> 100K SLOC) приложения на Django. Сейчас мы гоняем в CI около 6000 тестов, а процесс от мерджа в мастер до появления на проде у нас занимает около 4-х минут.
Пока я не совсем понимаю, насколько вообще это вам интересно, поэтому продолжение буду писать только если этот пост наберет 200 лайков.
Начну с самого важного умения Circle CI — параллельности. Сейчас в самом большом нашем проекте около 6000 юнит-тестов, и весь прогон в один поток занимал бы около часа. Для таких ребят как мы серкл дает два инструмента — более быстрые контейнеры и разбиение тестов на несколько машин. Мы используем оба варианта.
Более быстрые контейнеры подразумевают разделение тестов на множество потоков средствами самого тестраннера — мы используем обычный pytest-xdist с двумя потоками на ядро. В данный момент для того, чтобы вам включили возможность самому управлять ресурсами, вам придется связываться с поддержкой (подробнее тут), которая вам предложит специальный вариант оплаты — не за количество контейнеров, как на официальном сайте, а за машинное время, которое вы тратите на сборку. Я советую соглашаться — на наших проектах, перейдя на поминутную оплату, мы стали экономить около 50% денег.
Второй метод, параллельность, доступен всем — при помощи фирменной утилиты, вы разбиваете тесты на несколько пакетов, каждый из которых работает в отдельном контейнере. Когда все контейнеры отрабатывают штатно — запускается следующая задача (к примеру деплой), уже в одном контейнере.
В итоге параллельность позволяет нам минимальными затратами добиться цифр из приложенной картинки.
Интересно продолжение? Лайкайте.
Это — начало рассказа о том, как у нас устроен Continuous Integration среднеразмерного (> 100K SLOC) приложения на Django. Сейчас мы гоняем в CI около 6000 тестов, а процесс от мерджа в мастер до появления на проде у нас занимает около 4-х минут.
Пока я не совсем понимаю, насколько вообще это вам интересно, поэтому продолжение буду писать только если этот пост наберет 200 лайков.
Начну с самого важного умения Circle CI — параллельности. Сейчас в самом большом нашем проекте около 6000 юнит-тестов, и весь прогон в один поток занимал бы около часа. Для таких ребят как мы серкл дает два инструмента — более быстрые контейнеры и разбиение тестов на несколько машин. Мы используем оба варианта.
Более быстрые контейнеры подразумевают разделение тестов на множество потоков средствами самого тестраннера — мы используем обычный pytest-xdist с двумя потоками на ядро. В данный момент для того, чтобы вам включили возможность самому управлять ресурсами, вам придется связываться с поддержкой (подробнее тут), которая вам предложит специальный вариант оплаты — не за количество контейнеров, как на официальном сайте, а за машинное время, которое вы тратите на сборку. Я советую соглашаться — на наших проектах, перейдя на поминутную оплату, мы стали экономить около 50% денег.
Второй метод, параллельность, доступен всем — при помощи фирменной утилиты, вы разбиваете тесты на несколько пакетов, каждый из которых работает в отдельном контейнере. Когда все контейнеры отрабатывают штатно — запускается следующая задача (к примеру деплой), уже в одном контейнере.
В итоге параллельность позволяет нам минимальными затратами добиться цифр из приложенной картинки.
Интересно продолжение? Лайкайте.
Плохое делегирование
Плохое делегирование — это когда ты отдаешь задачу, а потом проверяешь каждый шаг. Типа отдал задачу на неделю, а на следующий день уже пишешь «как дела? что уже сделал?».
Мало того, что на такое делегирование уходит столько же времени и внимания, как на саму работу, так это еще и бесит: не всем приятно, когда с ними обращаются как с ребенком.
Еще один плохой эффект — если людям не давать обосраться, то они привыкают к внешним стимулам. Через месяц работы на стимулах, любой, даже супер-осознанный сотрудник или сбегает, или переключается в режим ежика, который не взлетает, пока его не пнешь.
Плохое делегирование — это когда ты отдаешь задачу, а потом проверяешь каждый шаг. Типа отдал задачу на неделю, а на следующий день уже пишешь «как дела? что уже сделал?».
Мало того, что на такое делегирование уходит столько же времени и внимания, как на саму работу, так это еще и бесит: не всем приятно, когда с ними обращаются как с ребенком.
Еще один плохой эффект — если людям не давать обосраться, то они привыкают к внешним стимулам. Через месяц работы на стимулах, любой, даже супер-осознанный сотрудник или сбегает, или переключается в режим ежика, который не взлетает, пока его не пнешь.
Поговорили с Дмитрием Зыбкиным, ведущим канала @java_developer о том, чем занимается CTO в современном мире
Forwarded from Java Developer
Кто такой CTO
Задал несколько вопросов Фёдору Борщёву, CTO в ГдеМатериал и автору канала @pmdaily.
— Расскажи, как прошел свой путь от простого программиста до технического директора
Я работал в небольшом провинциальном веб-агенстве. Там достаточно быстро начал руководить всей командой разработки. Думаю, это не было моей заслугой — просто в компании было тяжело с людьми, которые одновременно умеют брать на себя ответственность и понимать, как работают технические штуки.
В какой-то момент я осознал, что у меня хорошо получается самостоятельно прокачиваться в хард-скиллах, но вот с софт-скиллами вообще ничего не происходит. Взвесил себя на рынке труда и понял, что со своим балансом знаний я не подхожу ни для чего кроме скучной работы низкопробного веб-программиста, и немного приуныл.
Тогда я и решил на какое-то время завязать с программированием, перебрался в Москву и пошел в студию Лебедева руководить дизайн-проектами. Студия — место с особой атмосферой и особенными людьми. Думаю, именно студия дала мне то, чего не хватало, чтобы стать CTO.
За время редких студийных выходных я выучил Django и сопутствующий стек (до этого писал на PHP). И под конец работы в студии начали сыпаться предложения об интересных технически-сложных проектах.
— Чем занимается CTO?
С точки зрения бизнеса, первая задача CTO — сделать работу с техническими специалистами такой же управляемой как, скажем, с менеджерами по продажам. Бизнес не должен задумываться о том, сколько у него программистов, на каких технологиях они работают, какое у них покрытие кода тестами и объем технического долга. Вместо этого он должен выдавать требования, получать в ответ цифры ФОТ (оплата труда) и результат к заявленному сроку.
Дальше начинается специфика — в маленьких компаниях CTO должен быть мастером на все руки. И в продукт влезть не хуже продакт-менеджера, и код пописать на уровне синьора, и бизнесу рассказать, какие требования лучше отдать в разработку, а какие сделать по старинке на Экселе и AmoCRM.
В больших компаниях, наоборот, CTO становится ближе к администрированию — выбирает правильных подрядчиков, задает им бизнесовые KPI, обращает много внимания на HR — как делить команды (по продуктам? по компетенциям? по фичам?), кого ставить во главу этих команд, как нанимать правильных людей и организовать передачу знаний.
Кроме бизнеса «сверху», есть еще программисты. Программисты обычно ждут от CTO хороших процессов — все хотят получать четко поставленные задачи с четкими критериями приемки, работать на актуальных технологиях, иметь возможность самим принимать решения и расплачиваться с техническом долгом, знать у кого из коллег о чем стоит спросить и т.д. В общем задача CTO для программистов — сделать, чтобы они были счастливыми, а значит — производительными.
— Насколько глубоко CTO должен разбираться в языках программирования? И какие технологии должен знать?
Для маленьких компаний, где CTO «работает руками», чем больше технологий — тем лучше :-) Лично я стараюсь фокусироваться на том, что важно для комфортной и быстрой работы команды, но при этом тяжело дается для изучения на «боевых» задачах — девопс, новые инструменты\механики тестирования, какие-то вещи про будущее.
Кроме самих технологий, CTO должен понимать, куда движется рынок в целом. Скажем года два назад хороший CTO для JS-проектов должен был изучать такие популярные сейчас вещи как Vue.js, typescript, jest, задумываться о serverless, знакомиться с netlify, предсказывать, что хайп вокруг NoSQL сойдет на нет и т.д.
А для больших компаний желание работать руками скорее будет минусом, чем плюсом.
Задал несколько вопросов Фёдору Борщёву, CTO в ГдеМатериал и автору канала @pmdaily.
— Расскажи, как прошел свой путь от простого программиста до технического директора
Я работал в небольшом провинциальном веб-агенстве. Там достаточно быстро начал руководить всей командой разработки. Думаю, это не было моей заслугой — просто в компании было тяжело с людьми, которые одновременно умеют брать на себя ответственность и понимать, как работают технические штуки.
В какой-то момент я осознал, что у меня хорошо получается самостоятельно прокачиваться в хард-скиллах, но вот с софт-скиллами вообще ничего не происходит. Взвесил себя на рынке труда и понял, что со своим балансом знаний я не подхожу ни для чего кроме скучной работы низкопробного веб-программиста, и немного приуныл.
Тогда я и решил на какое-то время завязать с программированием, перебрался в Москву и пошел в студию Лебедева руководить дизайн-проектами. Студия — место с особой атмосферой и особенными людьми. Думаю, именно студия дала мне то, чего не хватало, чтобы стать CTO.
За время редких студийных выходных я выучил Django и сопутствующий стек (до этого писал на PHP). И под конец работы в студии начали сыпаться предложения об интересных технически-сложных проектах.
— Чем занимается CTO?
С точки зрения бизнеса, первая задача CTO — сделать работу с техническими специалистами такой же управляемой как, скажем, с менеджерами по продажам. Бизнес не должен задумываться о том, сколько у него программистов, на каких технологиях они работают, какое у них покрытие кода тестами и объем технического долга. Вместо этого он должен выдавать требования, получать в ответ цифры ФОТ (оплата труда) и результат к заявленному сроку.
Дальше начинается специфика — в маленьких компаниях CTO должен быть мастером на все руки. И в продукт влезть не хуже продакт-менеджера, и код пописать на уровне синьора, и бизнесу рассказать, какие требования лучше отдать в разработку, а какие сделать по старинке на Экселе и AmoCRM.
В больших компаниях, наоборот, CTO становится ближе к администрированию — выбирает правильных подрядчиков, задает им бизнесовые KPI, обращает много внимания на HR — как делить команды (по продуктам? по компетенциям? по фичам?), кого ставить во главу этих команд, как нанимать правильных людей и организовать передачу знаний.
Кроме бизнеса «сверху», есть еще программисты. Программисты обычно ждут от CTO хороших процессов — все хотят получать четко поставленные задачи с четкими критериями приемки, работать на актуальных технологиях, иметь возможность самим принимать решения и расплачиваться с техническом долгом, знать у кого из коллег о чем стоит спросить и т.д. В общем задача CTO для программистов — сделать, чтобы они были счастливыми, а значит — производительными.
— Насколько глубоко CTO должен разбираться в языках программирования? И какие технологии должен знать?
Для маленьких компаний, где CTO «работает руками», чем больше технологий — тем лучше :-) Лично я стараюсь фокусироваться на том, что важно для комфортной и быстрой работы команды, но при этом тяжело дается для изучения на «боевых» задачах — девопс, новые инструменты\механики тестирования, какие-то вещи про будущее.
Кроме самих технологий, CTO должен понимать, куда движется рынок в целом. Скажем года два назад хороший CTO для JS-проектов должен был изучать такие популярные сейчас вещи как Vue.js, typescript, jest, задумываться о serverless, знакомиться с netlify, предсказывать, что хайп вокруг NoSQL сойдет на нет и т.д.
А для больших компаний желание работать руками скорее будет минусом, чем плюсом.
Forwarded from Java Developer
— Какая зарплатная вилка у CTO сейчас?
Зарплата — вопрос сугубо индивидуальный и переговорный. Если посмотреть на рынок труда, то CTO можно называть и единственного веб-программиста, который дорабатывает лендос у сервиса онлайн-курсов, а могут — руководителя производства, критичного для компании уровня ВК или Ламоды. Вот такая же и разница в зарплатах.
— Как программисту стать управленцем?
Вообще любой менеджер будет очень рад, если у него в команде появится программист, с которым можно поделиться ответственностью.
Для начала сделай так, чтобы тебя не нужно было менеджерить — научись выполнять свои собственные обещания и разбираться в задачах. Покачай софтскиллы — пойми зачем в принципе одни люди приходят к другим людям. Вот классические книги, которые в этом помогут:
• Стивен Кови — 7 навыков высокоэффективных людей. Про принятие решений и обещания.
• Джим Кэмп — Сначала скажите «нет». Про то, как разговаривать с другими людьми, чтобы им было полезно.
• Элияху Голдратт — Цель и Критическая цепь. Как лучше разбираться в постановке задач и управлении проектами.
Когда научишься менеджерить себя, останется совсем немного до того, чтобы научиться менеджерить других.
— Как научился брать на себя ответственность? Как понял, что больше хочешь быть управленцем, чем программистом?
Первоначально мне все эти штуки про ответственность были не очень интересны — казалось более прикольным ковыряться в коде и железках :-) Нужно сказать огромное спасибо коллегам, которые начали требовать этого от меня. Ну а дальше — начал читать книги.
Вообще программистам повезло с профессией. Есть, к примеру профессии, в которых можно получать удовольствие только от процесса, но не от результата — рабочий на производстве, дальнобойщик, официант в кафе. Есть наоборот, профессии, в которых важен только результат — это управление большими компаниями или собственным бизнесом, политика.
У программистов есть своеобразный баланс: мы сами выстраиваем себе удобный процесс, и сами выбираем в какой мере отвечать за результат. Не хотим отвечать за результат — пожалуйста, находим команду с хорошим менеджером, и не думаем ни о чем, кроме кода. Даже таким ребятам еще лет 5 будут платить среднерыночную зарплату, пока сохраняется кризис на рынке труда.
А вообще я считаю, что каждый программист должен забирать на себя столько ответственности, сколько только может. Ведь это же твоя жизнь, и именно ответственность определяет ее качество: будешь ли ты сам доволен результатом того, что делаешь?
Зарплата — вопрос сугубо индивидуальный и переговорный. Если посмотреть на рынок труда, то CTO можно называть и единственного веб-программиста, который дорабатывает лендос у сервиса онлайн-курсов, а могут — руководителя производства, критичного для компании уровня ВК или Ламоды. Вот такая же и разница в зарплатах.
— Как программисту стать управленцем?
Вообще любой менеджер будет очень рад, если у него в команде появится программист, с которым можно поделиться ответственностью.
Для начала сделай так, чтобы тебя не нужно было менеджерить — научись выполнять свои собственные обещания и разбираться в задачах. Покачай софтскиллы — пойми зачем в принципе одни люди приходят к другим людям. Вот классические книги, которые в этом помогут:
• Стивен Кови — 7 навыков высокоэффективных людей. Про принятие решений и обещания.
• Джим Кэмп — Сначала скажите «нет». Про то, как разговаривать с другими людьми, чтобы им было полезно.
• Элияху Голдратт — Цель и Критическая цепь. Как лучше разбираться в постановке задач и управлении проектами.
Когда научишься менеджерить себя, останется совсем немного до того, чтобы научиться менеджерить других.
— Как научился брать на себя ответственность? Как понял, что больше хочешь быть управленцем, чем программистом?
Первоначально мне все эти штуки про ответственность были не очень интересны — казалось более прикольным ковыряться в коде и железках :-) Нужно сказать огромное спасибо коллегам, которые начали требовать этого от меня. Ну а дальше — начал читать книги.
Вообще программистам повезло с профессией. Есть, к примеру профессии, в которых можно получать удовольствие только от процесса, но не от результата — рабочий на производстве, дальнобойщик, официант в кафе. Есть наоборот, профессии, в которых важен только результат — это управление большими компаниями или собственным бизнесом, политика.
У программистов есть своеобразный баланс: мы сами выстраиваем себе удобный процесс, и сами выбираем в какой мере отвечать за результат. Не хотим отвечать за результат — пожалуйста, находим команду с хорошим менеджером, и не думаем ни о чем, кроме кода. Даже таким ребятам еще лет 5 будут платить среднерыночную зарплату, пока сохраняется кризис на рынке труда.
А вообще я считаю, что каждый программист должен забирать на себя столько ответственности, сколько только может. Ведь это же твоя жизнь, и именно ответственность определяет ее качество: будешь ли ты сам доволен результатом того, что делаешь?
Вопрос: если посреди задачи программист понимает, что получил недоработанную задачу, что делать — бежать к постановщику или додумывать самому?
Если вы маленькая компания, то скорее всего соотношение мозговремени, потраченного на планирование задачи, с мозговременем, потраченным на ее производство, выглядит так:
Получается, именно программист несколько дней подряд уходит домой и просыпается с задачей в подсознании, в отличие от менеджера и дизайнера, которые давно заняты чем-то другим.
Если в этот момент программист немножко высунется из своей скорлупки и подумает не только про код, но и про бизнес, то он сильно облегчит жизнь всем коллегам, ведь у него же самое системное мышление из всех. Ну а если вылезать лень — можно и постановщику задачу вернуть.
См. также — приходи с решением, а не с проблемой.
Есть #вопрос? Задавай в @fedor_borshev.
Если вы маленькая компания, то скорее всего соотношение мозговремени, потраченного на планирование задачи, с мозговременем, потраченным на ее производство, выглядит так:
|——|———————|. Из всех участников процесса больше всего над задачей думает конечный исполнитель — программист.Получается, именно программист несколько дней подряд уходит домой и просыпается с задачей в подсознании, в отличие от менеджера и дизайнера, которые давно заняты чем-то другим.
Если в этот момент программист немножко высунется из своей скорлупки и подумает не только про код, но и про бизнес, то он сильно облегчит жизнь всем коллегам, ведь у него же самое системное мышление из всех. Ну а если вылезать лень — можно и постановщику задачу вернуть.
См. также — приходи с решением, а не с проблемой.
Есть #вопрос? Задавай в @fedor_borshev.
Positive review против Negative review
Знаю, как многих ребят (я в их числе) бесит, когда написанный код нужно кому-то показывать. Бывают даже крайние случаи, когда код нельзя мерджить, пока не покажем двум-трем ребятам.
Обязательный код-ревью убивает мотивацию и сильно замедляет разработку — ревьюер может быть занят, может не уметь делать ревью (это вообще сплошь и рядом), или вообще начать доебываться до неважных вещей, вроде форматирования кода (это же работа линтера).
Несмотря на это, я все равно ввожу обязательный ревью для всех новичков. Дело в том, что код-ревью — это незаменимый инструмент для передачи знаний. Старшие товарищи всегда ткнут пальцем на ошибки, связанные с незнанием контекста, вроде попыток повторно написать уже написанный код или непонятных юнит-тестов. Они же укажут на критично нагруженные участки кода, в которых нужно быть повнимательнее.
Вообще, в любом приложении есть множество эвристических правил, которые невозможно зафиксировать в регламентах. И код-ревью их отлично передает из одной головы в другую, уменьшая bus factor.
Когда новичок осознает ценность ревью и проходит испытательный срок, он переходит на positive review — его код могут посмотреть товарищи уже после мерджа (а могут и не смотреть). При этом он всегда будет сам звать других ребят, если почувствует, что ему не хватает опыта или знания контекста.
Знаю, как многих ребят (я в их числе) бесит, когда написанный код нужно кому-то показывать. Бывают даже крайние случаи, когда код нельзя мерджить, пока не покажем двум-трем ребятам.
Обязательный код-ревью убивает мотивацию и сильно замедляет разработку — ревьюер может быть занят, может не уметь делать ревью (это вообще сплошь и рядом), или вообще начать доебываться до неважных вещей, вроде форматирования кода (это же работа линтера).
Несмотря на это, я все равно ввожу обязательный ревью для всех новичков. Дело в том, что код-ревью — это незаменимый инструмент для передачи знаний. Старшие товарищи всегда ткнут пальцем на ошибки, связанные с незнанием контекста, вроде попыток повторно написать уже написанный код или непонятных юнит-тестов. Они же укажут на критично нагруженные участки кода, в которых нужно быть повнимательнее.
Вообще, в любом приложении есть множество эвристических правил, которые невозможно зафиксировать в регламентах. И код-ревью их отлично передает из одной головы в другую, уменьшая bus factor.
Когда новичок осознает ценность ревью и проходит испытательный срок, он переходит на positive review — его код могут посмотреть товарищи уже после мерджа (а могут и не смотреть). При этом он всегда будет сам звать других ребят, если почувствует, что ему не хватает опыта или знания контекста.
Circle CI, начало: обзор конфигурации, задачи
Прошлый пост набрал 200 лайков за 3 часа, так что я начну длинную серию с описанием возможностей Circle CI для приложения на Django.
Начнем с базовых вещей — примитивов, используемых в конфигурации.
Для того, чтобы начать собирать ваш проект в Circle CI нужно положить в репозиторий файл
Команда, или шаг (step) — самый маленький шаг, который вы используете в сборке. К примеру «восстановить кеш зависимостей» или «запустить линтер».
Задача (job) — последовательность шагов, которая выполняется в рамках одного контейнера. К примеру «запустить тесты», или «выкатить в прод».
Воркфлоу — последовательность задач, нужная для какого-то осознанного шага в реальном мире, к примеру «после каждого коммита собирать и проверять приложение, а затем выкатывать в прод, если комит был в мастер», или «каждую ночь собирать и выкладывать в докерхаб образы бекенда и базы для фронтендеров»
Разберем подробнее основные характеристики задачи
executor — контекст выполнения: machine (в заранее собранном окружении) или docker — в контейнере на основе любого (хоть вашего внутрикорпоративного) образа. Circle поддерживает целую кучу официальных образов для всех версий популярных языков. Дальше мы, как настоящие хипстеры, рассматриваем только докер.
resource_class — сколько ресурсов будет выделено под вашу задачу. По умолчанию всем дают 2 ядра и 4Гб памяти, но если вы платите серклу за машинное время, то можете выбирать от 1 до 8 CPU, с соответственно меняющимся объемом памяти. Обратите внимание, что эта характеристика привязана к задаче, а не ко всему workflow, то есть вы можете скажем распаковывать и ставить приложение на слабом контейнере, а под тесты, которые хорошо параллелятся — собирать мощные контейнеры хоть с 8 CPU.
parallelism: сколько контейнеров с задачей запускать одновременно. Разбиение нагрузки между контейнерами — на вас.
environment: переменные окружения, скажем доступ к базе или фиче-флаги. Если ваши переменные окружения приватны (к примеру содержат реквизиты для внутреннего реестра контейнеров) то хранить их лучше не здесь, а в настройках проекта, это облегчит распределение доступа внутри компании.
steps: собственно набор шагов, который вы хотите выполнять для сборки.
В следующей заметке будет про workflows и ночные сборки.
Прошлый пост набрал 200 лайков за 3 часа, так что я начну длинную серию с описанием возможностей Circle CI для приложения на Django.
Начнем с базовых вещей — примитивов, используемых в конфигурации.
Для того, чтобы начать собирать ваш проект в Circle CI нужно положить в репозиторий файл
.circleci/config.yml, в котором вы описываете последовательность сборки. Примеры файлов для всех языков можно найти в документации, а в этой заметке мы рассмотрим основные примитивы, которые используются в настройке CI под ваши нужды.Команда, или шаг (step) — самый маленький шаг, который вы используете в сборке. К примеру «восстановить кеш зависимостей» или «запустить линтер».
Задача (job) — последовательность шагов, которая выполняется в рамках одного контейнера. К примеру «запустить тесты», или «выкатить в прод».
Воркфлоу — последовательность задач, нужная для какого-то осознанного шага в реальном мире, к примеру «после каждого коммита собирать и проверять приложение, а затем выкатывать в прод, если комит был в мастер», или «каждую ночь собирать и выкладывать в докерхаб образы бекенда и базы для фронтендеров»
Разберем подробнее основные характеристики задачи
executor — контекст выполнения: machine (в заранее собранном окружении) или docker — в контейнере на основе любого (хоть вашего внутрикорпоративного) образа. Circle поддерживает целую кучу официальных образов для всех версий популярных языков. Дальше мы, как настоящие хипстеры, рассматриваем только докер.
resource_class — сколько ресурсов будет выделено под вашу задачу. По умолчанию всем дают 2 ядра и 4Гб памяти, но если вы платите серклу за машинное время, то можете выбирать от 1 до 8 CPU, с соответственно меняющимся объемом памяти. Обратите внимание, что эта характеристика привязана к задаче, а не ко всему workflow, то есть вы можете скажем распаковывать и ставить приложение на слабом контейнере, а под тесты, которые хорошо параллелятся — собирать мощные контейнеры хоть с 8 CPU.
parallelism: сколько контейнеров с задачей запускать одновременно. Разбиение нагрузки между контейнерами — на вас.
environment: переменные окружения, скажем доступ к базе или фиче-флаги. Если ваши переменные окружения приватны (к примеру содержат реквизиты для внутреннего реестра контейнеров) то хранить их лучше не здесь, а в настройках проекта, это облегчит распределение доступа внутри компании.
steps: собственно набор шагов, который вы хотите выполнять для сборки.
В следующей заметке будет про workflows и ночные сборки.
Вопрос: считаете ли вы трудозатраты, сколько обошлась выкатка фичи в прод?
Нет, не считаем. Во-первых мы вообще не учитываем ничье время, потому что договариваемся друг с другом о результатах (работающих фичах), а не о процессе (затраченном времени).
Во-вторых, непонятно куда можно было бы использовать такую статистику. Скажем, у нас есть программист, который запилил фичу A за X времени. Допустим, у нас есть фича B, которая коллективным решением (ха-ха), признана в 2 раза сложнее, чем фича A. Значит ли это, что время, которое уйдет на фичу B, равняется 2X? Нет, и математика тут не поможет — во время разработки фичи B программист может заболеть, наткнуться на непреодолимые преграды в коде, может упасть прод, прийти менеджер с более срочной задачей (у нас не может), в конце концов оценка может оказаться неправильной.
#вопрос Задать свой — @fedor_borshev
Нет, не считаем. Во-первых мы вообще не учитываем ничье время, потому что договариваемся друг с другом о результатах (работающих фичах), а не о процессе (затраченном времени).
Во-вторых, непонятно куда можно было бы использовать такую статистику. Скажем, у нас есть программист, который запилил фичу A за X времени. Допустим, у нас есть фича B, которая коллективным решением (ха-ха), признана в 2 раза сложнее, чем фича A. Значит ли это, что время, которое уйдет на фичу B, равняется 2X? Нет, и математика тут не поможет — во время разработки фичи B программист может заболеть, наткнуться на непреодолимые преграды в коде, может упасть прод, прийти менеджер с более срочной задачей (у нас не может), в конце концов оценка может оказаться неправильной.
#вопрос Задать свой — @fedor_borshev
Управляй своим временем
— Договорились. Когда сделаешь?
— Эм, дай подумать... В следующую среду.
— Ой, а давай в понедельник? А то у нас презентация важная.
— Ну давай.
Все, пиздец, управление потеряно.
Вокруг очень много людей, которые стремятся отнять у тебя право управлять твоим собственным временем. Их можно понять: любому человеку комфортнее, когда ситуацией управляет он сам, а не кто-то другой (ты).
К тому же менеджер, который только что украл у тебя время, наверняка уже много раз сталкивался с плохими исполнителями, нарушающими любой срок, который только ни назовут. Чтобы добиться результата от таких ребят, приходится прожимать их по срокам, чтобы пораньше можно было спросить «ну как?», и запустить инструменты повышения продуктивности, вроде телефонных звонков и начальства в копии.
Не будь тем, кому нужно звонить. Никогда не торгуйся по срокам. Просто не давай лишних обещаний, а дал обещание — выполняй вовремя.
— Договорились. Когда сделаешь?
— Эм, дай подумать... В следующую среду.
— Ой, а давай в понедельник? А то у нас презентация важная.
— Ну давай.
Все, пиздец, управление потеряно.
Вокруг очень много людей, которые стремятся отнять у тебя право управлять твоим собственным временем. Их можно понять: любому человеку комфортнее, когда ситуацией управляет он сам, а не кто-то другой (ты).
К тому же менеджер, который только что украл у тебя время, наверняка уже много раз сталкивался с плохими исполнителями, нарушающими любой срок, который только ни назовут. Чтобы добиться результата от таких ребят, приходится прожимать их по срокам, чтобы пораньше можно было спросить «ну как?», и запустить инструменты повышения продуктивности, вроде телефонных звонков и начальства в копии.
Не будь тем, кому нужно звонить. Никогда не торгуйся по срокам. Просто не давай лишних обещаний, а дал обещание — выполняй вовремя.
Circle CI: Ночные сборки
Workflows в Circle CI — это мощнейший инструмент для автоматизации девопса. В простом варианте (build → test → deploy) его использует все, а в этой заметке я расскажу про де полезные вещи, которые можно делать с помощью расписания workflows.
В mtrl.ai мы активно пользуемся ночными сборками. То есть просто каждую ночь собираем проект, тегаем текущей датой и раскладываем образы по песочницам для программистов и тестовым стендам. Получается, что в обмен всего на 10 строк в YAML-файле у нас появляются автоматически обновляемые песочницы!
Кроме ночных сборок, при помощи circle мы каждую ночь собираем докер-образы с нашей базой данных, доступные всей команде.
Такие образы гарантируют, что фронтендер всегда работает со свежими данными с прода — больше никаких рыбных текстов или таблиц, поехавших после публикации на проде.
У бекендеров тоже куча применений для таких образов — начиная от проверки миграций, и заканчивая поисками сложных багов.
Хитрости в процессе сборки образа с БД:
— Нужно делать его максимально тонким. Мы, к примеру, не берем в образ записи пользовательского журнала, телефонных звонков и других данных, которые нужны раз в год и не критичны для работы приложения.
— Образ с базой нужно тегать текущей датой. Так вы получите (почти) полный автоматический бекап своей базы прямо в докерхабе, если у вас не кастомный реестр контейнеров, конечно.
Workflows в Circle CI — это мощнейший инструмент для автоматизации девопса. В простом варианте (build → test → deploy) его использует все, а в этой заметке я расскажу про де полезные вещи, которые можно делать с помощью расписания workflows.
В mtrl.ai мы активно пользуемся ночными сборками. То есть просто каждую ночь собираем проект, тегаем текущей датой и раскладываем образы по песочницам для программистов и тестовым стендам. Получается, что в обмен всего на 10 строк в YAML-файле у нас появляются автоматически обновляемые песочницы!
Кроме ночных сборок, при помощи circle мы каждую ночь собираем докер-образы с нашей базой данных, доступные всей команде.
Такие образы гарантируют, что фронтендер всегда работает со свежими данными с прода — больше никаких рыбных текстов или таблиц, поехавших после публикации на проде.
У бекендеров тоже куча применений для таких образов — начиная от проверки миграций, и заканчивая поисками сложных багов.
Хитрости в процессе сборки образа с БД:
— Нужно делать его максимально тонким. Мы, к примеру, не берем в образ записи пользовательского журнала, телефонных звонков и других данных, которые нужны раз в год и не критичны для работы приложения.
— Образ с базой нужно тегать текущей датой. Так вы получите (почти) полный автоматический бекап своей базы прямо в докерхабе, если у вас не кастомный реестр контейнеров, конечно.
TCO, или полная стоимость фичи
Каждая фича, которую вы впиливаете в продукт, стоит денег. Причем бóльшую часть этих денег вы отдаете не за производство фичи, а за поддержку ее на плаву. И чем больше времени фича живет (пусть и заброшенная), тем больше она стóит.
Помните, ту выгрузку в эксель, которую вы сделали год назад за вечер, потому что конец квартала? За год она 5 раз сломалась в процессе разработки, один раз в релизе, не дала команде перейти на новый HTTP-фреймворк и повлияла на тимлида, склонив выбрать неудачный подход к функциональному тестированию (правда он этого не понял).
И неважно, что выгрузкой за год воспользовались два раза — ни один из инженеров, который ее касался, об этом не знал, а значит тратил на нее столько же времени, сколько и на любой другой код в приложении.
Для большинства программистов ваша выгрузка в эксель ничем не отличается от, скажем, авторизации по СМС, которой пользуются 1000 раз в день. Так уж устроен мозг программиста.
На своих проектах я даже поддерживаю процесс выпиливания фич — прям каждый спринт мы ищем и удаляем куски кода от фич, которые не заработали. Иначе бы нам пришлось тянуть в будущее код, который не выполняется, но требует поддержки и денег.
Каждая фича, которую вы впиливаете в продукт, стоит денег. Причем бóльшую часть этих денег вы отдаете не за производство фичи, а за поддержку ее на плаву. И чем больше времени фича живет (пусть и заброшенная), тем больше она стóит.
Помните, ту выгрузку в эксель, которую вы сделали год назад за вечер, потому что конец квартала? За год она 5 раз сломалась в процессе разработки, один раз в релизе, не дала команде перейти на новый HTTP-фреймворк и повлияла на тимлида, склонив выбрать неудачный подход к функциональному тестированию (правда он этого не понял).
И неважно, что выгрузкой за год воспользовались два раза — ни один из инженеров, который ее касался, об этом не знал, а значит тратил на нее столько же времени, сколько и на любой другой код в приложении.
Для большинства программистов ваша выгрузка в эксель ничем не отличается от, скажем, авторизации по СМС, которой пользуются 1000 раз в день. Так уж устроен мозг программиста.
На своих проектах я даже поддерживаю процесс выпиливания фич — прям каждый спринт мы ищем и удаляем куски кода от фич, которые не заработали. Иначе бы нам пришлось тянуть в будущее код, который не выполняется, но требует поддержки и денег.
Почему нужно записывать видео и делать скриншоты
Самый лучший способ разобраться в теме — попробовать ее объяснить кому-нибудь другому. Именно по этому мы в mtrl.ai требуем, чтобы в каждой задаче был минимум один скриншот\видео — в начале (что делаем), и в конце (что стало).
Скриншот в начале помогает сориентироваться в постановке задачи. Убедиться, что автор понимает в состоянии внятно проиллюстрировать задачу. Если вдруг это не так, значит задача — говно, и лучше на нее не тратить ничье время.
Скриншот (а лучше видео) в конце задачи помогает убедиться, что программист осознал юзкейс, воспроизвел его и проверил в понятном для пользователя виде (почему-то не все пользователи понимают вывод pytest).
Скриншоты и видео — это как юнит-тесты, только для задачи — четкое и ясное доказательство того, что задача поставлена и выполнена.
Самый лучший способ разобраться в теме — попробовать ее объяснить кому-нибудь другому. Именно по этому мы в mtrl.ai требуем, чтобы в каждой задаче был минимум один скриншот\видео — в начале (что делаем), и в конце (что стало).
Скриншот в начале помогает сориентироваться в постановке задачи. Убедиться, что автор понимает в состоянии внятно проиллюстрировать задачу. Если вдруг это не так, значит задача — говно, и лучше на нее не тратить ничье время.
Скриншот (а лучше видео) в конце задачи помогает убедиться, что программист осознал юзкейс, воспроизвел его и проверил в понятном для пользователя виде (почему-то не все пользователи понимают вывод pytest).
Скриншоты и видео — это как юнит-тесты, только для задачи — четкое и ясное доказательство того, что задача поставлена и выполнена.
Не терпеть говно вокруг себя
Важный навык, которого не хватает многим соотечественникам — говорить о проблемах. Это когда ты утыкаешься в какую-нибудь неудобную хуйню, типа CI который работает 15 минут вместо 2, и, вместо того, чтобы обсудить эту хуйню с руководителем или тем, кто может исправить, просто сидишь и молча страдаешь.
Частично это решает скрам с его ежедневными встречами, на которых в общем-то принято рассказывать о трудностях в работе. Но только частично — вещи, которые плохо работают давно, вроде длительности CI, которая росла до 15 минут по 1 минуте в неделю, это не выявляет.
Чтобы научиться не терпеть говно вокруг себя, надо немного подвинуть парадигму. В первую очередь нужно осознать, что руководителю твоя производительность более выгодна, чем тебе (ведь это же ты на него работаешь, а не он на тебя).
Во-вторых, нужно просто перестать терпеть говно. Если тебя беспокоит процесс CI — добейся того, чтобы он стал работать быстро: допинай руководителя, поговори с тем, кто умеет это чинить, почитай документацию сам, наконец.
Если получаешь отпор, типа «и так работает» — подумай, в той ли лодке ты сидишь? Чему, кроме терпимости, ты научишься у людей, которые терпят вокруг себя говно?
Важный навык, которого не хватает многим соотечественникам — говорить о проблемах. Это когда ты утыкаешься в какую-нибудь неудобную хуйню, типа CI который работает 15 минут вместо 2, и, вместо того, чтобы обсудить эту хуйню с руководителем или тем, кто может исправить, просто сидишь и молча страдаешь.
Частично это решает скрам с его ежедневными встречами, на которых в общем-то принято рассказывать о трудностях в работе. Но только частично — вещи, которые плохо работают давно, вроде длительности CI, которая росла до 15 минут по 1 минуте в неделю, это не выявляет.
Чтобы научиться не терпеть говно вокруг себя, надо немного подвинуть парадигму. В первую очередь нужно осознать, что руководителю твоя производительность более выгодна, чем тебе (ведь это же ты на него работаешь, а не он на тебя).
Во-вторых, нужно просто перестать терпеть говно. Если тебя беспокоит процесс CI — добейся того, чтобы он стал работать быстро: допинай руководителя, поговори с тем, кто умеет это чинить, почитай документацию сам, наконец.
Если получаешь отпор, типа «и так работает» — подумай, в той ли лодке ты сидишь? Чему, кроме терпимости, ты научишься у людей, которые терпят вокруг себя говно?
Код для космических кораблей
Недавно наткнулся на адски-сложный код в исходниках кубернейтс. Сложность заключается в огромном количестве ветвлений — сложно понять, что делает код, даже будучи глубоко в контексте.
В шапке прям большими буквами написано — «пожалуйста, не пытайтесь ничего упрощать». Автор рассказывает, что такой код пишут для космических кораблей в NASA — каждый if должен обязательно содержать свой else, чтобы убедиться, что программист предусмотрел вообще все возможные ситуации. Даже те, которые никогда не случатся.
По словам автора, такой «подробный» код легче поддерживать (не вообще, а конкретно в этом месте). Учитывая, что код отвечает за Persistent Volumes, в это хочется поверить.
Почему бы просто не покрыть все тестами на 100% и не переписать понятно и с нуля?
Потому, что код выполняется в средах, где ОЧЕНЬ много одновременных вычислений. Ситуация точно такая же, как с космическим кораблем: единственное место, в котором возможно провести полноценное интеграционное тестирование — это космос. В случае с Persistent Volumes в k8s — это супернагруженные системы, которые хранят наши с вами данные, к примеру вот эту заметку. Или код, который вы писали весь прошлый год.
Стоит ли писать такую лапшу на работе? Нет, не стоит. Нужно ли отступать от правил, когда это требуется для бизнес-задачи? Да, нужно.
Недавно наткнулся на адски-сложный код в исходниках кубернейтс. Сложность заключается в огромном количестве ветвлений — сложно понять, что делает код, даже будучи глубоко в контексте.
В шапке прям большими буквами написано — «пожалуйста, не пытайтесь ничего упрощать». Автор рассказывает, что такой код пишут для космических кораблей в NASA — каждый if должен обязательно содержать свой else, чтобы убедиться, что программист предусмотрел вообще все возможные ситуации. Даже те, которые никогда не случатся.
По словам автора, такой «подробный» код легче поддерживать (не вообще, а конкретно в этом месте). Учитывая, что код отвечает за Persistent Volumes, в это хочется поверить.
Почему бы просто не покрыть все тестами на 100% и не переписать понятно и с нуля?
Потому, что код выполняется в средах, где ОЧЕНЬ много одновременных вычислений. Ситуация точно такая же, как с космическим кораблем: единственное место, в котором возможно провести полноценное интеграционное тестирование — это космос. В случае с Persistent Volumes в k8s — это супернагруженные системы, которые хранят наши с вами данные, к примеру вот эту заметку. Или код, который вы писали весь прошлый год.
Стоит ли писать такую лапшу на работе? Нет, не стоит. Нужно ли отступать от правил, когда это требуется для бизнес-задачи? Да, нужно.
Devops и маленькие команды
Каждый раз, когда от небольших ребят я слышу понятие dev-сервера, я настораживаюсь.
Обычно под этим именем скрывается специально выделенная машина, на которую программисты заливают код. И наличие такой машины означает, что в команде серьезные проблемы с девопсом.
Когда с девопсом все хорошо, то любой кусок инфраструктуры в актуальном состоянии можно развернуть хоть на утюге — фронтендеры держат бекенд на локальной машине, обновляя код и данные хоть по 10 раз в день; на каждую ветку в гите разворачивается деплой-превью; QA может отдельно комбинировать любые ветки и запускать все у себя на машине.
Неважно, сколько у вас программистов — 2 или 50, все равно вам нужен нормальный девопс: вы же не хотите, чтобы вместо вашей фичи программисты занимались перекладыванием файлов или настройкой nginx?
Каждый раз, когда от небольших ребят я слышу понятие dev-сервера, я настораживаюсь.
Обычно под этим именем скрывается специально выделенная машина, на которую программисты заливают код. И наличие такой машины означает, что в команде серьезные проблемы с девопсом.
Когда с девопсом все хорошо, то любой кусок инфраструктуры в актуальном состоянии можно развернуть хоть на утюге — фронтендеры держат бекенд на локальной машине, обновляя код и данные хоть по 10 раз в день; на каждую ветку в гите разворачивается деплой-превью; QA может отдельно комбинировать любые ветки и запускать все у себя на машине.
Неважно, сколько у вас программистов — 2 или 50, все равно вам нужен нормальный девопс: вы же не хотите, чтобы вместо вашей фичи программисты занимались перекладыванием файлов или настройкой nginx?
Бесплатные репозитории на гитхабе, это случилось
Спустя 10 лет, гитхаб таки подарил всем разработчикам приватные репозитории на бесплатном тарифе.
Платная подписка теперь называется «Pro», и отличается от бесплатной только беджиком в профиле и тем, что в приватные репозитории можно добавлять больше трех участников. Еще в бесплатных репозиториях не работают всякие мелочи вроде вики, pages или защищенных веток, но без них вполне можно жить.
Это очень важная веха на пути гитхаба, потому что отсутствие приватных репозиториев — по большому счету единственное, что заставляло людей пользоваться гитлабом и битбакетом с их упоротыми UI.
Давайте порадуемся за команду гитхаба, которая продолжает принимать сильные решения под влиянием майкрософта. Ну и конечно за программистов, которые наконец-то могут выкладывать личные проекты на удобный хостинг не тратя ни копейки.
#гитхаб
Спустя 10 лет, гитхаб таки подарил всем разработчикам приватные репозитории на бесплатном тарифе.
Платная подписка теперь называется «Pro», и отличается от бесплатной только беджиком в профиле и тем, что в приватные репозитории можно добавлять больше трех участников. Еще в бесплатных репозиториях не работают всякие мелочи вроде вики, pages или защищенных веток, но без них вполне можно жить.
Это очень важная веха на пути гитхаба, потому что отсутствие приватных репозиториев — по большому счету единственное, что заставляло людей пользоваться гитлабом и битбакетом с их упоротыми UI.
Давайте порадуемся за команду гитхаба, которая продолжает принимать сильные решения под влиянием майкрософта. Ну и конечно за программистов, которые наконец-то могут выкладывать личные проекты на удобный хостинг не тратя ни копейки.
#гитхаб
Как мы используем Чатру для поддержки
Есть много сервисов для общения с пользователями, начиная от монстров вроде zendesk или jira service desk, и заканчивая моим любимым хипстерским Groove.
Однако для себя мы выбрали еще более простое решение — Чатру. Самое главное преимущество Чатры — в нее действительно легко написать. В отличие от традиционного сервисдескного софта, Чатру делали не для того, чтобы облегчить жизнь саппортерам, а чтобы общаться с пользователями на сайте — этот как всем надоевший «живой консультант» на плохих интернет-магазинах, только аккуратный и ненавязчивый.
Нам важно, чтобы любой сотрудник в компании легко мог написать о любой мысли или проблеме — это критично, когда у твоего продукта не 500 000 пользователей, а всего 100, но зато супер-важных.
С Чатрой мы избежали появления еще одного источника правды — обычный софт для хелпдеска обязательно содержит встроенный трекер, где все обращения пользователей превращаются в новые задачи. Такие задачи надо как-то закрывать, измерять, отслеживать появление нового.
От Чатры никто не ждет порядка — это же бесконечный чат. Если в чате появляется что-то, что нужно сделать или обдумать, то мы просто пишем письмо ответственному. Если баг — исправляем дежурным программистом.
Конечно, с такой системой мы никогда не разобьем сапорт на первую и вторую линию, не сможем измерять KPI каждого сотрудника поддержки (которых у нас нет). Но мы же маленькая команда, и добились главного — у нас каждый сотрудник может в один клик выразить свое мнение про продукт, и его точно услышат.
Есть много сервисов для общения с пользователями, начиная от монстров вроде zendesk или jira service desk, и заканчивая моим любимым хипстерским Groove.
Однако для себя мы выбрали еще более простое решение — Чатру. Самое главное преимущество Чатры — в нее действительно легко написать. В отличие от традиционного сервисдескного софта, Чатру делали не для того, чтобы облегчить жизнь саппортерам, а чтобы общаться с пользователями на сайте — этот как всем надоевший «живой консультант» на плохих интернет-магазинах, только аккуратный и ненавязчивый.
Нам важно, чтобы любой сотрудник в компании легко мог написать о любой мысли или проблеме — это критично, когда у твоего продукта не 500 000 пользователей, а всего 100, но зато супер-важных.
С Чатрой мы избежали появления еще одного источника правды — обычный софт для хелпдеска обязательно содержит встроенный трекер, где все обращения пользователей превращаются в новые задачи. Такие задачи надо как-то закрывать, измерять, отслеживать появление нового.
От Чатры никто не ждет порядка — это же бесконечный чат. Если в чате появляется что-то, что нужно сделать или обдумать, то мы просто пишем письмо ответственному. Если баг — исправляем дежурным программистом.
Конечно, с такой системой мы никогда не разобьем сапорт на первую и вторую линию, не сможем измерять KPI каждого сотрудника поддержки (которых у нас нет). Но мы же маленькая команда, и добились главного — у нас каждый сотрудник может в один клик выразить свое мнение про продукт, и его точно услышат.
Все коммиты привязывать к задаче
Во многих командах есть требование — каждый коммит в репозитории должен быть привязан к задаче в трекере. Однако есть ребята, которые не понимают, зачем это нужно, и считают это пустым формализмом. Попробую рассказать.
Во-первых, задача в трекере — это как тест до кода: прочитав\поставив задачу, ты уже определил конечный результат. Ты понимаешь, что и для чего ты делаешь, а не работаешь в режиме свободного художника.
Во-вторых, когда код не привязан к задаче, его сложнее смотреть — в глазах ревьюера он превращается из решения задачи в бессмысленные строчки на экране. В коде, который смотрели без привязки к задаче, никогда не найдут серьезных смысловых ошибок — только стилевые и другие очевидные вещи, которые вообще-то должен искать статический анализатор.
Ну и в-третьих, это блейм — тебе же самому через полгода захочется понять, зачем ты написал ту или иную строку. Ссылка на задачу в этом случае прибавит контекста. А что-нибудь вроде «changed layout» только добавит желания выкинуть весь старый код и написать новый.
Во многих командах есть требование — каждый коммит в репозитории должен быть привязан к задаче в трекере. Однако есть ребята, которые не понимают, зачем это нужно, и считают это пустым формализмом. Попробую рассказать.
Во-первых, задача в трекере — это как тест до кода: прочитав\поставив задачу, ты уже определил конечный результат. Ты понимаешь, что и для чего ты делаешь, а не работаешь в режиме свободного художника.
Во-вторых, когда код не привязан к задаче, его сложнее смотреть — в глазах ревьюера он превращается из решения задачи в бессмысленные строчки на экране. В коде, который смотрели без привязки к задаче, никогда не найдут серьезных смысловых ошибок — только стилевые и другие очевидные вещи, которые вообще-то должен искать статический анализатор.
Ну и в-третьих, это блейм — тебе же самому через полгода захочется понять, зачем ты написал ту или иную строку. Ссылка на задачу в этом случае прибавит контекста. А что-нибудь вроде «changed layout» только добавит желания выкинуть весь старый код и написать новый.