Чем камин отличается от буржуйки?
Если бы авторы требований к программному обеспечению знали, сколько их требования стоят, то в мире стало бы гораздо меньше требований.
Вот делаете вы ремонт у себя в городской квартире. Почему вы не просите прораба построить какую-нибудь дорогую глупость, вроде камина или финской сауны в ванной? Это же в принципе осуществимо. Вас останавливает стоимость — это в банальном смысле нерационально.
Когда вы выступаете в роли источника требований в софтовом проекте, модель отношений точно такая же — вы что-то заказываете, а кто-то, кто умеет, этот заказ выполняет. Даже сроки в стройке проебываются так же, как в разработке.
Одно отличие — вы скорее всего даже примерно не понимаете, сколько стоят ваши требования. Запилить и поддерживать какую-нибудь дополнительную кнопку на третьем экране может по стоимости сравниться с разработкой целой фичи.
Для того, чтобы отличить камин от буржуйки, достаточно простого житейского опыта. А чтобы отличить фичу на час от фичи на день — нужен наметанный глаз. И дело вовсе не в том, что у прораба работа простая, а у программиста — сложная. Дело в банальной привычке: программисты, если не тренируются специально, точно так же ошибаются в оценке, как и вы.
Так что учите своих программистов самих работать с требованиями прямо во время выполнения задачи, либо переходите на вероятностную модель оценки, типа как в моей любимой книге про оценку Как измерить что угодно.
Если бы авторы требований к программному обеспечению знали, сколько их требования стоят, то в мире стало бы гораздо меньше требований.
Вот делаете вы ремонт у себя в городской квартире. Почему вы не просите прораба построить какую-нибудь дорогую глупость, вроде камина или финской сауны в ванной? Это же в принципе осуществимо. Вас останавливает стоимость — это в банальном смысле нерационально.
Когда вы выступаете в роли источника требований в софтовом проекте, модель отношений точно такая же — вы что-то заказываете, а кто-то, кто умеет, этот заказ выполняет. Даже сроки в стройке проебываются так же, как в разработке.
Одно отличие — вы скорее всего даже примерно не понимаете, сколько стоят ваши требования. Запилить и поддерживать какую-нибудь дополнительную кнопку на третьем экране может по стоимости сравниться с разработкой целой фичи.
Для того, чтобы отличить камин от буржуйки, достаточно простого житейского опыта. А чтобы отличить фичу на час от фичи на день — нужен наметанный глаз. И дело вовсе не в том, что у прораба работа простая, а у программиста — сложная. Дело в банальной привычке: программисты, если не тренируются специально, точно так же ошибаются в оценке, как и вы.
Так что учите своих программистов самих работать с требованиями прямо во время выполнения задачи, либо переходите на вероятностную модель оценки, типа как в моей любимой книге про оценку Как измерить что угодно.
Не бросайся решать задачи «в лоб»
Наверное, самая частая причина нарастания говнокода на проектах, после некомпетентности исполнителей — это привычка решать задачи «в лоб». Почему-то большинство ребят, которые получают сложные творческие задачи, первым делом не откладывают их в уголок мозга для обдумывания, а сразу бегут писать код.
Чтобы не плодить плохих решений, любая задача, которая подразумевает исследование, или просто кажется вам «необычной» должна обязательно проходить через три этапа.
Первый и самый долгий — ничегонеделание. Дайте задаче отлежаться, как минимум переночуйте с ней. Хорошие идеи приходят не во время лихорадочного стучания по клавишам, а в душе, на пробежке, по дороге в офис или из офиса. В общем-то в любом месте, отличном от того, где вы эту задачу потом будете делать.
Второй этап — эксперимент. Выделите части из придуманного решения, в которых вы сомневаетесь и придумайте эксперимент, который их проверит. Иногда можно обойтись и мысленным экспериментом, но лучше — написать код. Скажем, если вы делаете интеграцию с банком — просто научитесь отправлять хотя бы простые платежи с фейковыми данными.
Когда будете делать прототип — не допускайте даже и мысли потом его использовать в работающем проекте. Прототип — только на свалку.
И уже третья часть — реализация. Здесь вы должны соответствовать принятым на проекте правилам, думать о деталях решения, показывать код коллегам и т.д.
Как в стройке — архитектор не работает одновременно с прорабом, даже если они оба — это один человек, который строит сам себе загородный дом.
Наверное, самая частая причина нарастания говнокода на проектах, после некомпетентности исполнителей — это привычка решать задачи «в лоб». Почему-то большинство ребят, которые получают сложные творческие задачи, первым делом не откладывают их в уголок мозга для обдумывания, а сразу бегут писать код.
Чтобы не плодить плохих решений, любая задача, которая подразумевает исследование, или просто кажется вам «необычной» должна обязательно проходить через три этапа.
Первый и самый долгий — ничегонеделание. Дайте задаче отлежаться, как минимум переночуйте с ней. Хорошие идеи приходят не во время лихорадочного стучания по клавишам, а в душе, на пробежке, по дороге в офис или из офиса. В общем-то в любом месте, отличном от того, где вы эту задачу потом будете делать.
Второй этап — эксперимент. Выделите части из придуманного решения, в которых вы сомневаетесь и придумайте эксперимент, который их проверит. Иногда можно обойтись и мысленным экспериментом, но лучше — написать код. Скажем, если вы делаете интеграцию с банком — просто научитесь отправлять хотя бы простые платежи с фейковыми данными.
Когда будете делать прототип — не допускайте даже и мысли потом его использовать в работающем проекте. Прототип — только на свалку.
И уже третья часть — реализация. Здесь вы должны соответствовать принятым на проекте правилам, думать о деталях решения, показывать код коллегам и т.д.
Как в стройке — архитектор не работает одновременно с прорабом, даже если они оба — это один человек, который строит сам себе загородный дом.
#техническое
Circle CI: деплой
Конечная ступень любого процесса CI — доставка софта до продакшена. Circle позволяет автоматизировать доставку практически любой сложности. Здесь я приведу готовые рецепты, которые мы используем в своих проектах на Django.
Выложить на голое железо — самый простой способ. Читаем статью Deploying Django, берем какой-нибудь fabric и пишем скрипт, который выкладывает файлы и рестартует демона. Вот пример fabfile.py, который мы используем на простых проектах.
Выложить в кластер — у нас это swarm. Выстраиваем чуть более сложный воркфлоу, зато получаем масштабируемость. Делаем две задачи — собрать\отправить в реестр докер-образ, и обновить сервисы в кластере. Пример конфиги для двух этих задач — вот. В конфиге используется мой собственный велосипед под названием d, в современных сетапах для уменьшения бойлерплейта вместо него лучше использовать Orbs.
Выложить в облако — на самом деле, подвид предыдущего пункта, только подойдет любой облачный хостинг вроде zeit.co. Мы используем облака несколько нестандартно — для хранения статичных файлов django, чтобы не заморачиваться с маршрутзиацией статики. Если интересно как и зачем мы делаем — напишите в личку.
Circle CI: деплой
Конечная ступень любого процесса CI — доставка софта до продакшена. Circle позволяет автоматизировать доставку практически любой сложности. Здесь я приведу готовые рецепты, которые мы используем в своих проектах на Django.
Выложить на голое железо — самый простой способ. Читаем статью Deploying Django, берем какой-нибудь fabric и пишем скрипт, который выкладывает файлы и рестартует демона. Вот пример fabfile.py, который мы используем на простых проектах.
Выложить в кластер — у нас это swarm. Выстраиваем чуть более сложный воркфлоу, зато получаем масштабируемость. Делаем две задачи — собрать\отправить в реестр докер-образ, и обновить сервисы в кластере. Пример конфиги для двух этих задач — вот. В конфиге используется мой собственный велосипед под названием d, в современных сетапах для уменьшения бойлерплейта вместо него лучше использовать Orbs.
Выложить в облако — на самом деле, подвид предыдущего пункта, только подойдет любой облачный хостинг вроде zeit.co. Мы используем облака несколько нестандартно — для хранения статичных файлов django, чтобы не заморачиваться с маршрутзиацией статики. Если интересно как и зачем мы делаем — напишите в личку.
На vc.ru появился новый раздел «Разработка». Надеюсь, они смогут сказать новое слово в мире отечественных медиа для программистов и составят достойную конкуренцию надоевшим всем переводам статей с медиума.
Написал туда для эксперимента про Circle CI — https://vc.ru/dev/56022-opyt-ispolzovaniya-circle-ci.
Что думаете? Будете читать новый раздел?
Написал туда для эксперимента про Circle CI — https://vc.ru/dev/56022-opyt-ispolzovaniya-circle-ci.
Что думаете? Будете читать новый раздел?
Качество кода в аутсорсной разработке
Когда ребята сидят на аутсорсе и пишут код для чужих продуктов, они продают своё время маленькими порциями. Практически неважно, что программист напишет за час: 10 тестов или три костыля — этот час все равно будет оплачен одинаково и для бизнеса, и для программиста.
Конечно, качество кода у хорошего подрядчика не идёт ни в какое сравнение с качеством умельца с апворка. Однако сам формат отношений, в которых заказчик сегодня платит деньги тебе, а завтра — другому, заставляет подрядчиков ориентироваться на краткосрочные результаты, пусть и ценой жертв в таких непрозрачных местах, как исходный код.
Чтобы подтвердить мои слова, повспоминайте знакомые аутсорсные компании или агентства. Сколько из них пишут тесты?
Нет никакого смысла заботится о качестве кода, если это не увеличивает количество денег. Гораздо проще выкатывать быстрые решения, и получать за них деньги здесь и сейчас. А до момента, когда качество начинает играть критичную роль, заказчик может и не добежать. Или добежать, но с другим подрядчиком.
Когда ребята сидят на аутсорсе и пишут код для чужих продуктов, они продают своё время маленькими порциями. Практически неважно, что программист напишет за час: 10 тестов или три костыля — этот час все равно будет оплачен одинаково и для бизнеса, и для программиста.
Конечно, качество кода у хорошего подрядчика не идёт ни в какое сравнение с качеством умельца с апворка. Однако сам формат отношений, в которых заказчик сегодня платит деньги тебе, а завтра — другому, заставляет подрядчиков ориентироваться на краткосрочные результаты, пусть и ценой жертв в таких непрозрачных местах, как исходный код.
Чтобы подтвердить мои слова, повспоминайте знакомые аутсорсные компании или агентства. Сколько из них пишут тесты?
Нет никакого смысла заботится о качестве кода, если это не увеличивает количество денег. Гораздо проще выкатывать быстрые решения, и получать за них деньги здесь и сейчас. А до момента, когда качество начинает играть критичную роль, заказчик может и не добежать. Или добежать, но с другим подрядчиком.
Некоторые ребята восприняли мой прошлый пост про аутсорсную разработку резко негативно и привели противоположную точку зрения — типа аутсорсеры топят за результат (иначе им бы не платили деньги), а внутренние команды — за процесс.
Ребята в общем-то правы — когда нужны быстрые результаты за короткое время, в аутсорсе их часто выдают быстрее, чем ин-хаус.
Разница такая же, как между бегунами на короткие дистанции и марафонцами. Аутсорсеры хороши в коротких забегах, когда нужно быстро запустить MVP одного продукта или фичи. Когда гипотеза доказана, и MVP нужно хоть чуть-чуть развить, ребята, которые не заботятся о качестве, начинают тормозить, уставать и выдыхаться.
Свои же разработчики, наоборот, всегда работают с одной, стабильной скоростью.
Так что за быстрыми задачами можно смело ходить в аутсорс, а для больших продуктов — строить свою команду.
Ребята в общем-то правы — когда нужны быстрые результаты за короткое время, в аутсорсе их часто выдают быстрее, чем ин-хаус.
Разница такая же, как между бегунами на короткие дистанции и марафонцами. Аутсорсеры хороши в коротких забегах, когда нужно быстро запустить MVP одного продукта или фичи. Когда гипотеза доказана, и MVP нужно хоть чуть-чуть развить, ребята, которые не заботятся о качестве, начинают тормозить, уставать и выдыхаться.
Свои же разработчики, наоборот, всегда работают с одной, стабильной скоростью.
Так что за быстрыми задачами можно смело ходить в аутсорс, а для больших продуктов — строить свою команду.
Проблемы со сроками
Когда один человек получает от другого задачу, подразумевается, что он сам решит все возникающие по ходу проблемы.
Юристы не принимают договор, который тебе проучили? Согласовывай — твоя проблема. Код внезапно потребовал рефакторинга? Твоя проблема.
Клево, когда все проблемы решаются «внутри» задачи, не отвлекая постановщика.
Кроме одной — сроков. Проблемы со сроками, даже возможные, нужно всегда, и как можно раньше доносить до постановщика. Вдруг у него под твою задачу запланирована рекламная кампания? Или бизнес вот прямо сейчас нанимает людей, которые будут пользоваться вашей фичей?
Если проблему со сроками поднять честно и вовремя, то скорее всего ничего страшного не случится.
Когда один человек получает от другого задачу, подразумевается, что он сам решит все возникающие по ходу проблемы.
Юристы не принимают договор, который тебе проучили? Согласовывай — твоя проблема. Код внезапно потребовал рефакторинга? Твоя проблема.
Клево, когда все проблемы решаются «внутри» задачи, не отвлекая постановщика.
Кроме одной — сроков. Проблемы со сроками, даже возможные, нужно всегда, и как можно раньше доносить до постановщика. Вдруг у него под твою задачу запланирована рекламная кампания? Или бизнес вот прямо сейчас нанимает людей, которые будут пользоваться вашей фичей?
Если проблему со сроками поднять честно и вовремя, то скорее всего ничего страшного не случится.
Вопрос: что ты как CTO думаешь про монорепозитории?
Думаю то же самое, что и про serverless, vue.js или SCRUM.
Если у команды есть задачи, которые монорепозиторий решает лучше — значит это хорошо. К примеру у вас в компании живет злостная служба служба безопасности, которая проверяет каждый коммит каждого программиста. Конечно для всех будет быстрее, если комиты складывать в одно место — не нужно будет ходить к безопасникам за «регистрацией репозитория». Или к вам из начала двухтысячных приполз какой-нибудь самописный скрипт деплоя на перле, и он умеет только в один репозиторий.
А если у вас монорепозиторий потому что так в фейсбуке, или у вас сломалась кнопочка «add repo» в гитхабе — это конечно плохо.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Думаю то же самое, что и про serverless, vue.js или SCRUM.
Если у команды есть задачи, которые монорепозиторий решает лучше — значит это хорошо. К примеру у вас в компании живет злостная служба служба безопасности, которая проверяет каждый коммит каждого программиста. Конечно для всех будет быстрее, если комиты складывать в одно место — не нужно будет ходить к безопасникам за «регистрацией репозитория». Или к вам из начала двухтысячных приполз какой-нибудь самописный скрипт деплоя на перле, и он умеет только в один репозиторий.
А если у вас монорепозиторий потому что так в фейсбуке, или у вас сломалась кнопочка «add repo» в гитхабе — это конечно плохо.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Не работаю с мудаками
В отношениях с людьми я руководствуюсь простым правилом — не работать с мудаками.
Недавно я отменил заказ сантехника, который за три минуты до назначенного времени прислал СМС, что опаздывает на час, а потом опоздал ещё на два.
Без сомнений я расстаюсь с сотрудниками, которые молча нарушают обещания, ведут себя невежливо, неконструктивно спорят или проявляют любую иную токсичную форму поведения.
Расставаясь с такими людьми, я делаю лучше и им, и себе.
Мне от этого лучше потому, что если программист не в состоянии сдержать слово, он скорее всего и код плохой напишет. Мудакам тоже лучше — им легче работать с теми, кто терпимо относится к их поведению.
Даже тем руководителям, с которыми мудаки будут работать вместо меня, я делаю лучше — к ним придут люди привычного и понятного формата.
В отношениях с людьми я руководствуюсь простым правилом — не работать с мудаками.
Недавно я отменил заказ сантехника, который за три минуты до назначенного времени прислал СМС, что опаздывает на час, а потом опоздал ещё на два.
Без сомнений я расстаюсь с сотрудниками, которые молча нарушают обещания, ведут себя невежливо, неконструктивно спорят или проявляют любую иную токсичную форму поведения.
Расставаясь с такими людьми, я делаю лучше и им, и себе.
Мне от этого лучше потому, что если программист не в состоянии сдержать слово, он скорее всего и код плохой напишет. Мудакам тоже лучше — им легче работать с теми, кто терпимо относится к их поведению.
Даже тем руководителям, с которыми мудаки будут работать вместо меня, я делаю лучше — к ним придут люди привычного и понятного формата.
API гитхаба
За последний месяц я оценил, насколько удобно у гитхаба построена система интеграций. Такое ощущение, что API продумывали дизайнеры, а не программисты.
К примеру, сейчас мы вводим внутри стандарты оформления пулл-реквестов. Ничего особенного — просто называем их по-русски и требуем указывать ссылку на задачу.
Написать соответствующую проверялку при помощи probot заняло у меня около 4 часов, два из которых я потратил на чтение документации. У того же probot, кстати, есть целый каталог приложений, к примеру удобная удалялка смердженных веток.
Или еще пример — недавно мы осознали, что команда выросла настолько, что пора бы уже начать более оперативно рассказывать всем об изменениях в проекте — не в конце спринта, как раньше, а прямо как только закрыли задачу. Всего за два часа на питоне написали простой скрипт, который ходит в API гитхаба и рассылает всем письмо со списком закрытых вчера задач.
Так что если вы задумываетесь, что вам не хватает функциональности гитхаба — почитайте повнимательнее документацию. Возможно лучше потратить пару дней на написание кода, чем убивать производительность и мотивацию переходом на какую-нибудь толстую Jira.
За последний месяц я оценил, насколько удобно у гитхаба построена система интеграций. Такое ощущение, что API продумывали дизайнеры, а не программисты.
К примеру, сейчас мы вводим внутри стандарты оформления пулл-реквестов. Ничего особенного — просто называем их по-русски и требуем указывать ссылку на задачу.
Написать соответствующую проверялку при помощи probot заняло у меня около 4 часов, два из которых я потратил на чтение документации. У того же probot, кстати, есть целый каталог приложений, к примеру удобная удалялка смердженных веток.
Или еще пример — недавно мы осознали, что команда выросла настолько, что пора бы уже начать более оперативно рассказывать всем об изменениях в проекте — не в конце спринта, как раньше, а прямо как только закрыли задачу. Всего за два часа на питоне написали простой скрипт, который ходит в API гитхаба и рассылает всем письмо со списком закрытых вчера задач.
Так что если вы задумываетесь, что вам не хватает функциональности гитхаба — почитайте повнимательнее документацию. Возможно лучше потратить пару дней на написание кода, чем убивать производительность и мотивацию переходом на какую-нибудь толстую Jira.
Вопрос: работаю удаленно, помидорками по 25 минут. Если сложить помидорки за день, то получается всего 5 часов. Это нормально? Надо ли больше?
Если в вашей команде (как у нас в mtrl.ai) не трекают рабочее время, и вы за эти 5 часов успеваете выполнить все задачи — то да, это нормально.
Другой вопрос в том, куда вы деваете оставшееся время? Если оно уходит на то, чтобы превышать ожидания команды, на саморазвитие или свои проекты — вам повезло.
А вот если большинство оставшегося времени уходит на потребление — это проблема.
#вопрос
Если в вашей команде (как у нас в mtrl.ai) не трекают рабочее время, и вы за эти 5 часов успеваете выполнить все задачи — то да, это нормально.
Другой вопрос в том, куда вы деваете оставшееся время? Если оно уходит на то, чтобы превышать ожидания команды, на саморазвитие или свои проекты — вам повезло.
А вот если большинство оставшегося времени уходит на потребление — это проблема.
#вопрос
Я ничего не понял
Каждому из нас периодически падают плохо проработанные, непонятные и невежливые письма: «Коллеги нужна выгрузка генеральный требует ASAP». Как самим не писать такие письма, почитайте «Новые правила переписки». А в этой заметке я расскажу про заклинание, которое от таких писем помогает. Когда-то услышал его на тренинге Максима Дорофеева про джедайские техники.
Заклинание называется «я ничего не понял». Если вам написали неопрятное письмо, даже не озаботившись тем, чтобы из него было понятно, чем можно помочь — просто пишите в ответ «я ничего не понял».
Конечно, прежде чем так писать, нужно искренне приложить усилия, чтобы разобраться — не все люди умеют выражать свои мысли.
Но если вы потратили несколько минут, а письмо понятнее не стало — просто вежливо напишите «я ничего не понял». Если человеку и правда от вас что-то нужно — он напишет еще одно, понятное письмо, или предложит созвониться.
Каждому из нас периодически падают плохо проработанные, непонятные и невежливые письма: «Коллеги нужна выгрузка генеральный требует ASAP». Как самим не писать такие письма, почитайте «Новые правила переписки». А в этой заметке я расскажу про заклинание, которое от таких писем помогает. Когда-то услышал его на тренинге Максима Дорофеева про джедайские техники.
Заклинание называется «я ничего не понял». Если вам написали неопрятное письмо, даже не озаботившись тем, чтобы из него было понятно, чем можно помочь — просто пишите в ответ «я ничего не понял».
Конечно, прежде чем так писать, нужно искренне приложить усилия, чтобы разобраться — не все люди умеют выражать свои мысли.
Но если вы потратили несколько минут, а письмо понятнее не стало — просто вежливо напишите «я ничего не понял». Если человеку и правда от вас что-то нужно — он напишет еще одно, понятное письмо, или предложит созвониться.
Feature flags
Фиче-флаги — это настройки, которые позволяют в рантайме менять поведение программы, к примеру включать и выключать фичи.
Чаще всего их формирует фронтенд, и отсылает на бекенд в момент каждого запроса: типа вот этому пользователю в списке друзей показываем количество общих, а тому — нет. Пример — гитхаб, который передает фиче-флаги в заголовке media при каждом запросе. Сейчас у них в API, к примеру, включается-выключается одновременно 30 фич.
Есть ещё одно очень полезное применение фиче-флагов — полное отключение функций приложения на уровне инстанса бекенда. К примеру у нас в ЦРМ есть простая фича — уведомлять пользователя по СМС о статусе заказа. Но я не хочу, чтобы СМС уходили с тестовых стендов или из CI, даже если кому-то хватит ума прописать боевые ключи на них. Поэтому я делаю фиче-флаг
Для серьезных случаев, когда одна фича затрагивает несколько проектов, есть суровые системы корпоративного feature toggle, вроде Unleash. Получается централизованное хранилище признака `включенности` фич.
Фиче-флаги — это настройки, которые позволяют в рантайме менять поведение программы, к примеру включать и выключать фичи.
Чаще всего их формирует фронтенд, и отсылает на бекенд в момент каждого запроса: типа вот этому пользователю в списке друзей показываем количество общих, а тому — нет. Пример — гитхаб, который передает фиче-флаги в заголовке media при каждом запросе. Сейчас у них в API, к примеру, включается-выключается одновременно 30 фич.
Есть ещё одно очень полезное применение фиче-флагов — полное отключение функций приложения на уровне инстанса бекенда. К примеру у нас в ЦРМ есть простая фича — уведомлять пользователя по СМС о статусе заказа. Но я не хочу, чтобы СМС уходили с тестовых стендов или из CI, даже если кому-то хватит ума прописать боевые ключи на них. Поэтому я делаю фиче-флаг
ENABLE_NOTIFICATIONS и включаю его только в переменных окружения на проде.Для серьезных случаев, когда одна фича затрагивает несколько проектов, есть суровые системы корпоративного feature toggle, вроде Unleash. Получается централизованное хранилище признака `включенности` фич.
Вопрос: расскажи, как у вас устроен процесс работы с ветками.
Очень просто — мы ничего не придумывали, а взяли готовый Github flow: фичи пилим в ветках, ветки мерджим в мастер, мастер всегда на продакшене.
У редких проектов, вроде внутренних библиотек, есть исключения — там мы не деплоим мастер, а пользуемся функциональностью релизов в гитхабе: скажем, если я выпускаю новую версию Django-приложения, которое подтягивает в проект нашу базу товаров, я просто публикую новый релиз на гитхабе, CI публикует его в gemfury, а затем я вручную обновляю зависимости у всех сервисов, где мне нужна новая версия.
Пара наших дополнений к github flow:
— Названия ветки начинаем с номера задачи, скажем для задачи 100500 ветка будет называться
— Для очистки веток используем delete-merged-branch.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Очень просто — мы ничего не придумывали, а взяли готовый Github flow: фичи пилим в ветках, ветки мерджим в мастер, мастер всегда на продакшене.
У редких проектов, вроде внутренних библиотек, есть исключения — там мы не деплоим мастер, а пользуемся функциональностью релизов в гитхабе: скажем, если я выпускаю новую версию Django-приложения, которое подтягивает в проект нашу базу товаров, я просто публикую новый релиз на гитхабе, CI публикует его в gemfury, а затем я вручную обновляю зависимости у всех сервисов, где мне нужна новая версия.
Пара наших дополнений к github flow:
— Названия ветки начинаем с номера задачи, скажем для задачи 100500 ветка будет называться
100500/wrote-some-code. Так удобнее работать с консольным git — проще запоминать номера задач, чем названия веток.— Для очистки веток используем delete-merged-branch.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Ценность менеджера: не делать то, что можно не делать
Менеджер, который просто делает задачи в виде, в котором они лежат в беклоге, даже если это происходит быстро, качественно и дешево — плохой менеджер.
Представим пример — на проекте интернет-магазина менеджеру приходит задача сделать отзывы. Первый позыв — декомпозировать задачу: так, что нам нужно? Нужны макеты и фронтенд. Вроде все просто, пишем дизайнеру. Нужна наверное и админка? Окей, напишем еще и бекендеру.
Но для того, чтобы попросить макеты у дизайнера, менеджер не нужен! Это может сделать и фронтендер, и бекендер, и даже заказчик.
Менеджер нужен, чтобы посмотреть на задачу со стороны, увидеть большую картинку:
— Зачем мы делаем эти отзывы? Мы уверены, что это повысит конверсию? А вдруг нет? Давайте лучше запилим прототип за два часа и устроим a\b тест?
— Нам правда нужно давать пользователям форму для отзывов в первой итерации? А как мы их мотивируем?
—Откуда мы возьмем первоначальные отзывы? Давайте может напарсим что-нибудь? А надо ли парсить? Может вручную скопируем?
— На каких товарах отзывы появятся первыми? А может есть товары, которым отзывы вообще не нужны, потому что на их карточки никто не ходит?
— Авторам отзывов действительно нужна загрузка аватарок?
А писать письма и планировать сроки взрослые люди могут и без менеджера.
Менеджер, который просто делает задачи в виде, в котором они лежат в беклоге, даже если это происходит быстро, качественно и дешево — плохой менеджер.
Представим пример — на проекте интернет-магазина менеджеру приходит задача сделать отзывы. Первый позыв — декомпозировать задачу: так, что нам нужно? Нужны макеты и фронтенд. Вроде все просто, пишем дизайнеру. Нужна наверное и админка? Окей, напишем еще и бекендеру.
Но для того, чтобы попросить макеты у дизайнера, менеджер не нужен! Это может сделать и фронтендер, и бекендер, и даже заказчик.
Менеджер нужен, чтобы посмотреть на задачу со стороны, увидеть большую картинку:
— Зачем мы делаем эти отзывы? Мы уверены, что это повысит конверсию? А вдруг нет? Давайте лучше запилим прототип за два часа и устроим a\b тест?
— Нам правда нужно давать пользователям форму для отзывов в первой итерации? А как мы их мотивируем?
—Откуда мы возьмем первоначальные отзывы? Давайте может напарсим что-нибудь? А надо ли парсить? Может вручную скопируем?
— На каких товарах отзывы появятся первыми? А может есть товары, которым отзывы вообще не нужны, потому что на их карточки никто не ходит?
— Авторам отзывов действительно нужна загрузка аватарок?
А писать письма и планировать сроки взрослые люди могут и без менеджера.
Вопрос: у нас на продакшене kubernetes, и во всей команде только один специалист понимает, как с ним работать. Стоит ли учить остальных или нанимать отдельного девопса?
Зависит от размеров команды. Если вы можете позволить себе заботиться об уровне знаний каждого отдельного разработчика, то конечно лучше учить. Лично для меня, самый комфортный формат команды — небольшое количество универсалов, где все в разное степени умеют делать все, а не конвейер фронтенд-бекенд-девопс.
Конкретно в случае k8s\docker думаю обучить команду будет несложно — через пару лет не знать технологии контейнеризации будет так же стыдно, как не знать хоткеи в ИДЕ.
Ну а если ваша команда больше N, то придется либо искать ещё одного универсала, который умеет в k8s, либо нанимать девопса, да. По моим ощущениям N точно не должно быть меньше 10.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Зависит от размеров команды. Если вы можете позволить себе заботиться об уровне знаний каждого отдельного разработчика, то конечно лучше учить. Лично для меня, самый комфортный формат команды — небольшое количество универсалов, где все в разное степени умеют делать все, а не конвейер фронтенд-бекенд-девопс.
Конкретно в случае k8s\docker думаю обучить команду будет несложно — через пару лет не знать технологии контейнеризации будет так же стыдно, как не знать хоткеи в ИДЕ.
Ну а если ваша команда больше N, то придется либо искать ещё одного универсала, который умеет в k8s, либо нанимать девопса, да. По моим ощущениям N точно не должно быть меньше 10.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Письмо самому себе
Из ГТД я вынес для себя три вещи: ежедневные обзоры дел, пустой инбокс и письма самому себе.
Первые две вещи настолько банальны, что на них не стоит останавливаться. А вот про письма в будущее расскажу подробнее.
Вы когда-нибудь задумывались, почему маленькое сообщение в телеграме заставляет людей отвлечься от интересной беседы или важной работы? Все дело в распространенной логической ошибке, которая называется привлекательность новизны. Грубо говоря, каждая последующая мысль пришедшая в голову, кажется более важной, чем предыдущая.
Если не сохранять внезапные мысли, то они будут улетать в бездонную пропасть. А если постоянно на них переключаться, то вы просто ничего не будете успевать — ведь рано или поздно вместо важной мысли вам придет голову идея проверить личные сообщения в фейсбуке, и вы проснетесь вечером в обнимку с котиками или очередной петицией против кровавого режима.
Чтобы не терять важное, я пишу письма самому себе. Как только в голову приходит любая мысль, которая не имеет отношения к тому, чем я занят сейчас, я ее записываю и отсылаю себе на почту. Мысль из головы сразу же уходит, и я возвращаюсь обратно к тому, что делал. Мысль не проебется — почту я проверяю периодически и полностью вычищаю ящик.
Раньше для для отсылки писем я пользовался программой на айфоне, которая так и называлась — Mail to Self. Однако со временем пришло понимание, что каждый клик понижает вероятность того, что мысль будет записана. Особенно Mail to Self страдала, когда хотелось отправить себе скриншот или фотографию.
Поэтому я пошел дальше и написал себе бота для телеграма — @selfmailbot. Бот делает простую штуку — все что я ему пишу, оказывается у меня на почте. Привычный интерфейс телеграма помогает лениться еще меньше и записывать вообще все, что приходит в голову.
Бот, кстати, бесплатный и открытый, так что если вы ГТД-шник — смело пользуйтесь — @selfmailbot.
Из ГТД я вынес для себя три вещи: ежедневные обзоры дел, пустой инбокс и письма самому себе.
Первые две вещи настолько банальны, что на них не стоит останавливаться. А вот про письма в будущее расскажу подробнее.
Вы когда-нибудь задумывались, почему маленькое сообщение в телеграме заставляет людей отвлечься от интересной беседы или важной работы? Все дело в распространенной логической ошибке, которая называется привлекательность новизны. Грубо говоря, каждая последующая мысль пришедшая в голову, кажется более важной, чем предыдущая.
Если не сохранять внезапные мысли, то они будут улетать в бездонную пропасть. А если постоянно на них переключаться, то вы просто ничего не будете успевать — ведь рано или поздно вместо важной мысли вам придет голову идея проверить личные сообщения в фейсбуке, и вы проснетесь вечером в обнимку с котиками или очередной петицией против кровавого режима.
Чтобы не терять важное, я пишу письма самому себе. Как только в голову приходит любая мысль, которая не имеет отношения к тому, чем я занят сейчас, я ее записываю и отсылаю себе на почту. Мысль из головы сразу же уходит, и я возвращаюсь обратно к тому, что делал. Мысль не проебется — почту я проверяю периодически и полностью вычищаю ящик.
Раньше для для отсылки писем я пользовался программой на айфоне, которая так и называлась — Mail to Self. Однако со временем пришло понимание, что каждый клик понижает вероятность того, что мысль будет записана. Особенно Mail to Self страдала, когда хотелось отправить себе скриншот или фотографию.
Поэтому я пошел дальше и написал себе бота для телеграма — @selfmailbot. Бот делает простую штуку — все что я ему пишу, оказывается у меня на почте. Привычный интерфейс телеграма помогает лениться еще меньше и записывать вообще все, что приходит в голову.
Бот, кстати, бесплатный и открытый, так что если вы ГТД-шник — смело пользуйтесь — @selfmailbot.
Важная мысль про сложные переговоры, которой почему-то нет в книгах
Когда мне предстоят важные и сложные переговоры, значит я скорее всего уже делаю что-то не так. Если результат мне так важен, то почему я поставил его в зависимость всего лишь от одной встречи?
Скажем, я нервничаю перед встречей, которая должна спасти отношения с важным клиентом. Почему я не следил за этими отношениями раньше? Почему испортил их до такого состояния, что надо идти и уговаривать кого-то остаться? Что мешало мне поставить на проект более сильного менеджера или построить систему сигналов, которая уведомляет меня в случае проблем?
Или нервяк перед собеседованием на работу. Какие причины нервничать, если я отлично разбираюсь в том, чем занимаюсь, у меня крутое резюме и рекомендации от известных людей?
Если за спиной все в порядке, то любые переговоры будут простыми. А если вы не уверены в себе, то никакие манипуляционные техники из книжек не помогут.
Единственный автор, который хоть немного подводит к этой мысли — Джим Кэмп со своей системой про «Нет». А остальные, кажется, просто пишут селф-хелп про то, как побороть неуверенность.
Когда мне предстоят важные и сложные переговоры, значит я скорее всего уже делаю что-то не так. Если результат мне так важен, то почему я поставил его в зависимость всего лишь от одной встречи?
Скажем, я нервничаю перед встречей, которая должна спасти отношения с важным клиентом. Почему я не следил за этими отношениями раньше? Почему испортил их до такого состояния, что надо идти и уговаривать кого-то остаться? Что мешало мне поставить на проект более сильного менеджера или построить систему сигналов, которая уведомляет меня в случае проблем?
Или нервяк перед собеседованием на работу. Какие причины нервничать, если я отлично разбираюсь в том, чем занимаюсь, у меня крутое резюме и рекомендации от известных людей?
Если за спиной все в порядке, то любые переговоры будут простыми. А если вы не уверены в себе, то никакие манипуляционные техники из книжек не помогут.
Единственный автор, который хоть немного подводит к этой мысли — Джим Кэмп со своей системой про «Нет». А остальные, кажется, просто пишут селф-хелп про то, как побороть неуверенность.
Вопрос: у нас небольшая команда без менеджера, и мне кажется, что один из участников недорабатывает. Спринты закрываем вовремя, но этот участник мало коммитит в приоритетные задачи. Что делать? Надо ли вообще?
Для начала, надо разобраться, почему это вас беспокоит.
Если сосед ставит под угрозу каждый спринт, и вам с коллегами приходится из-за него работать ночами — попробуйте сами увеличить его нагрузку. Эмоциональный разговор с выяснением отношений тут не поможет — просто системно, каждый спринт, просите делать его больше работы, присылая конкретные запросы, уровня «напиши такой-то код по такой-то задаче».
Если не хотите прокачиваться в дипломатии — сходите к тому, кто может решить вашу проблему — CTO, тимлиду, скрам-мастеру.
Но если сосед не создаёт явных проблем для планов, то может быть и ничего страшного в этом нет — просто производительность у всех людей разная.
Так что начните с честного ответа на вопрос, почему вас это беспокоит. Если ответ окажется неизмеримым — сфокусируйтесь лучше на своей производительности, чем на чужой: так будет гораздо больше выхлопа лично для вас.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Для начала, надо разобраться, почему это вас беспокоит.
Если сосед ставит под угрозу каждый спринт, и вам с коллегами приходится из-за него работать ночами — попробуйте сами увеличить его нагрузку. Эмоциональный разговор с выяснением отношений тут не поможет — просто системно, каждый спринт, просите делать его больше работы, присылая конкретные запросы, уровня «напиши такой-то код по такой-то задаче».
Если не хотите прокачиваться в дипломатии — сходите к тому, кто может решить вашу проблему — CTO, тимлиду, скрам-мастеру.
Но если сосед не создаёт явных проблем для планов, то может быть и ничего страшного в этом нет — просто производительность у всех людей разная.
Так что начните с честного ответа на вопрос, почему вас это беспокоит. Если ответ окажется неизмеримым — сфокусируйтесь лучше на своей производительности, чем на чужой: так будет гораздо больше выхлопа лично для вас.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
MVP и юнит-тесты
В руководствах для стартаперов часто пишут — забейте на идеальный код, не пишите юнит-тестов во время разработки MVP.
По-моему, не писать тесты — это то же самое, что отказаться от фигурной скобки или от отступов в коде. Конечно идеальный код писать действительно глупо — кому он нужен, если проект не запустился?. Но вот тесты — важная вещь даже для founders code.
Дело в том, что на этапе MVP критично важна скорость изменений — вы должны очень быстро выкатывать кучу сырых фич. А выкаченная фича — это когда код написан, выложен на прод и выполняет свою работу.
И если первые два пункта без тестов получаются немного быстрее (в первую неделю), то последний начинает тянуть вас вниз: программист без внешней помощи не может уследить за работоспособностью созданной им системы. И закрытые задачи начинают открываться обратно.
В компании из трех человек начинаются избыточные процессы вроде «приемки задачи», когда CEO будущего единорога садится и проверяет код за программистов. Ну а что, не станете же вы нанимать QA, чтобы тестировать MVP?
Самый хороший вариант — вообще не писать сложного кода на начальных этапах. Разместите свою бизнес-логику на каких-нибудь готовых движках, на худой конец напишите serverless. А если уж взялись пилить функциональность — покройте тестами хотя бы API. И пишите тесты не когда-нибудь потом, а до первой строчки кода.
В руководствах для стартаперов часто пишут — забейте на идеальный код, не пишите юнит-тестов во время разработки MVP.
По-моему, не писать тесты — это то же самое, что отказаться от фигурной скобки или от отступов в коде. Конечно идеальный код писать действительно глупо — кому он нужен, если проект не запустился?. Но вот тесты — важная вещь даже для founders code.
Дело в том, что на этапе MVP критично важна скорость изменений — вы должны очень быстро выкатывать кучу сырых фич. А выкаченная фича — это когда код написан, выложен на прод и выполняет свою работу.
И если первые два пункта без тестов получаются немного быстрее (в первую неделю), то последний начинает тянуть вас вниз: программист без внешней помощи не может уследить за работоспособностью созданной им системы. И закрытые задачи начинают открываться обратно.
В компании из трех человек начинаются избыточные процессы вроде «приемки задачи», когда CEO будущего единорога садится и проверяет код за программистов. Ну а что, не станете же вы нанимать QA, чтобы тестировать MVP?
Самый хороший вариант — вообще не писать сложного кода на начальных этапах. Разместите свою бизнес-логику на каких-нибудь готовых движках, на худой конец напишите serverless. А если уж взялись пилить функциональность — покройте тестами хотя бы API. И пишите тесты не когда-нибудь потом, а до первой строчки кода.
Размер бандла как сервис
У фронтендеров весьма сложная жизнь — в работе приходится использовать огромные объемы кода, которые не в состоянии охватить не только человек, но иногда и компьютер.
Пара мегабайт кода на фронтенде сейчас считается нормой — туда входят и пакеты совместимости со старыми браузерами, и удобные библиотеки из трех строк вроде left-pad.
Чтобы не раздувать бандл с кодом до предела, нужно постоянно замерять его размер. Для разового замера подойдет webpack-bundle-analyzer, но если вы не хотите сами колдовать с конфигой вебпака и настройкой CI, то есть прикольный сервис — packtracker.io.
Работает при помощи простого плагина к вебпаку, который отправляет результаты каждой сборки на сервер. Packtracker можно интегрировать с гитхабом, что позволяет буквально мышкой настраивать попроектные лимиты на размер бандла.
За 3 приватных проекта сервис просит $9 в месяц. Ребята кажется достаточно плотно завязаны на вебпак, поэтому интересно, что они будут делать, когда мир перейдет на zero-config сборщики вроде parcel. Но пока — норм.
У фронтендеров весьма сложная жизнь — в работе приходится использовать огромные объемы кода, которые не в состоянии охватить не только человек, но иногда и компьютер.
Пара мегабайт кода на фронтенде сейчас считается нормой — туда входят и пакеты совместимости со старыми браузерами, и удобные библиотеки из трех строк вроде left-pad.
Чтобы не раздувать бандл с кодом до предела, нужно постоянно замерять его размер. Для разового замера подойдет webpack-bundle-analyzer, но если вы не хотите сами колдовать с конфигой вебпака и настройкой CI, то есть прикольный сервис — packtracker.io.
Работает при помощи простого плагина к вебпаку, который отправляет результаты каждой сборки на сервер. Packtracker можно интегрировать с гитхабом, что позволяет буквально мышкой настраивать попроектные лимиты на размер бандла.
За 3 приватных проекта сервис просит $9 в месяц. Ребята кажется достаточно плотно завязаны на вебпак, поэтому интересно, что они будут делать, когда мир перейдет на zero-config сборщики вроде parcel. Но пока — норм.