Сервисы: dependabot
Важная часть гигиены кодовой базы — актуализация зависимостей. Устаревшие зависимости приводят к мелким незаметным проблемам, которые вместе съедают кучу времени — на 5 минут дольше разворачивается проект; появляются свой код, который дублирует то, что давным-давно есть в апстриме; код не работает на новой убунте и т.д.
Если на проекте не обновлять зависимости, то он создает ощущение легаси еще до первого запуска. К примеру, тестовое задание, которое я даю бекендерам, содержит снимок проекта с начала 2016 года, и периодически находятся ребята, которые просто не могут его развернуть. А прошло всего два года.
Dependabot решает эту проблему методом брутфорса: он постоянно мониторит зависимости и делает пулл-реквест с новой версией сразу после выхода. Первое внедрение становится тяжелым — вам упадет 20–30 ПР, с которыми как-то нужно будет разобраться. Зато потом вы получаете гарантию, что ваши зависимости не застрянут в каменном веке — просто нажимайте на зеленую кнопку: у вас же наверняка хорошее покрытие, и вы не боитесь обновляться, правда?
Важная часть гигиены кодовой базы — актуализация зависимостей. Устаревшие зависимости приводят к мелким незаметным проблемам, которые вместе съедают кучу времени — на 5 минут дольше разворачивается проект; появляются свой код, который дублирует то, что давным-давно есть в апстриме; код не работает на новой убунте и т.д.
Если на проекте не обновлять зависимости, то он создает ощущение легаси еще до первого запуска. К примеру, тестовое задание, которое я даю бекендерам, содержит снимок проекта с начала 2016 года, и периодически находятся ребята, которые просто не могут его развернуть. А прошло всего два года.
Dependabot решает эту проблему методом брутфорса: он постоянно мониторит зависимости и делает пулл-реквест с новой версией сразу после выхода. Первое внедрение становится тяжелым — вам упадет 20–30 ПР, с которыми как-то нужно будет разобраться. Зато потом вы получаете гарантию, что ваши зависимости не застрянут в каменном веке — просто нажимайте на зеленую кнопку: у вас же наверняка хорошее покрытие, и вы не боитесь обновляться, правда?
Самый первый дедлайн
Любая долгая работа — это отношения. Я знаю совсем немного компаний, которые довольны своей разработкой. И вторая причина недовольства, после банального отсутствие опыта у программистов — их неумение строить отношения.
Представьте ситуацию — к вам пришел новый подрядчик\операционный директор\кто угодно, кто в терминологии скрама входит в группу куриц. Вы обсуждаете с ним несколько задач, обещаете их сделать «на неделе» и расходитесь.
В этот период вас оценивают. Ваши будущие отношения будут построены не по тому, как вы вели себя на встрече, а по тому, как вы поведете себя в эту неделю.
Даже самый опытный заказчик, которого наебывали по срокам уже пятьдесят раз, верит, что вы — тот единственный, кто не нарушает обещания.
Как только вы нарушаете обещание — вы становитесь «обычными» программистом. И тут же получаете весь букет стандартной менеджерской хуйни: вас просят оценить задачи в часах, работать по скраму с ежедневными стендапами, быть онлайн с 9 до 18. С вами торгуются по срокам — все равно вы не выдержите, почему бы не отжать побольше?
Не проебывайте первый дедлайн. Договоритесь об ФФФ, срежте 90% работ, но решите задачу полезно для бизнеса. Даже маленький результат за спиной позволит управлять ситуацией, а не созерцать, как все катится под гору из-за недоверия.
Любая долгая работа — это отношения. Я знаю совсем немного компаний, которые довольны своей разработкой. И вторая причина недовольства, после банального отсутствие опыта у программистов — их неумение строить отношения.
Представьте ситуацию — к вам пришел новый подрядчик\операционный директор\кто угодно, кто в терминологии скрама входит в группу куриц. Вы обсуждаете с ним несколько задач, обещаете их сделать «на неделе» и расходитесь.
В этот период вас оценивают. Ваши будущие отношения будут построены не по тому, как вы вели себя на встрече, а по тому, как вы поведете себя в эту неделю.
Даже самый опытный заказчик, которого наебывали по срокам уже пятьдесят раз, верит, что вы — тот единственный, кто не нарушает обещания.
Как только вы нарушаете обещание — вы становитесь «обычными» программистом. И тут же получаете весь букет стандартной менеджерской хуйни: вас просят оценить задачи в часах, работать по скраму с ежедневными стендапами, быть онлайн с 9 до 18. С вами торгуются по срокам — все равно вы не выдержите, почему бы не отжать побольше?
Не проебывайте первый дедлайн. Договоритесь об ФФФ, срежте 90% работ, но решите задачу полезно для бизнеса. Даже маленький результат за спиной позволит управлять ситуацией, а не созерцать, как все катится под гору из-за недоверия.
Микроменеджмент ←———→ доверие
Для меня всегда слово «микроменеджмент» был антонимом слова «доверие».
Если вы доверяете людям, то вы их не менеджерите — не «спускаете сверху» сроки, а просите их самих распланировать время. Вы не требуете отчетов о затраченном времени, не влезаете в рабочие процессы и детали реализации. У вас даже общего чатика нет (или чат состоит только из мемасиков, как у нас).
Вместо этого вы помогаете — интересуетесь как дела, следите за тем, чтобы у ребят все было удобно: формулировки задач, инфраструктура, отношения в коллективе.
А если вы занимаетесь микроменедментом, значит вы не доверяете коллегам. Насколько вообще имеет смысл работать с людьми, которым нельзя доверять?
Для меня всегда слово «микроменеджмент» был антонимом слова «доверие».
Если вы доверяете людям, то вы их не менеджерите — не «спускаете сверху» сроки, а просите их самих распланировать время. Вы не требуете отчетов о затраченном времени, не влезаете в рабочие процессы и детали реализации. У вас даже общего чатика нет (или чат состоит только из мемасиков, как у нас).
Вместо этого вы помогаете — интересуетесь как дела, следите за тем, чтобы у ребят все было удобно: формулировки задач, инфраструктура, отношения в коллективе.
А если вы занимаетесь микроменедментом, значит вы не доверяете коллегам. Насколько вообще имеет смысл работать с людьми, которым нельзя доверять?
Работа мечты: Сделать домашнюю работу
В последние несколько месяцев мы быстро растем и проводим много собеседований. Для меня это способ понаблюдать и поделать выводы о состоянии рынка труда программистов, вернее той его части, которую еще не съели крупные ребята типа Яндекса и Мейл.ру.
Я потихоньку начинаю делиться этими наблюдениями в формате «что сделать, чтобы попасть на работу мечты». Предупреждаю — мои советы точно работают при найме к нам в mtrl.ai, и вероятно больше не пригодится нигде.
Начнем с самой важной части процесса — домашней работы. Хорошо проделанная домашняя работа гарантирует быструю встречу с CTO, а ее отсутствие — встречу с HR и тестовое задание до собеседования.
Чтобы сделать домашнюю работу:
— Прочитайте вакансию.
— Прочитайте вакансию полностью.
— Подготовьте примеры работ на стеке, который требуется в вакансии. Приведите их в сопроводительном письме: «видел, что вы используете пайтест, вот у меня целый проект на нем — ссылка». Желательно, чтобы работы были с исходниками.
— Если нет релевантных работ — дайте какие-нибудь другие, хоть чуть-чуть похожие по стеку на требуемый.
— Если и таких работ нет, то лучше всего пойти и что-нибудь сделать, а затем откликаться.
Примеры работ — это самый обычный скрининг: люди на той стороне так же берегут время как и вы, и не хотят встречаться с теми, кто 100% не подходит по измеримым критериям.
Важный вопрос: а что делать, если домашняя работа кажется бессмысленной? Думаю, стоит устраиваться в ту компанию, ради которой есть смысл делать домашнюю работу.
#работамечты
В последние несколько месяцев мы быстро растем и проводим много собеседований. Для меня это способ понаблюдать и поделать выводы о состоянии рынка труда программистов, вернее той его части, которую еще не съели крупные ребята типа Яндекса и Мейл.ру.
Я потихоньку начинаю делиться этими наблюдениями в формате «что сделать, чтобы попасть на работу мечты». Предупреждаю — мои советы точно работают при найме к нам в mtrl.ai, и вероятно больше не пригодится нигде.
Начнем с самой важной части процесса — домашней работы. Хорошо проделанная домашняя работа гарантирует быструю встречу с CTO, а ее отсутствие — встречу с HR и тестовое задание до собеседования.
Чтобы сделать домашнюю работу:
— Прочитайте вакансию.
— Прочитайте вакансию полностью.
— Подготовьте примеры работ на стеке, который требуется в вакансии. Приведите их в сопроводительном письме: «видел, что вы используете пайтест, вот у меня целый проект на нем — ссылка». Желательно, чтобы работы были с исходниками.
— Если нет релевантных работ — дайте какие-нибудь другие, хоть чуть-чуть похожие по стеку на требуемый.
— Если и таких работ нет, то лучше всего пойти и что-нибудь сделать, а затем откликаться.
Примеры работ — это самый обычный скрининг: люди на той стороне так же берегут время как и вы, и не хотят встречаться с теми, кто 100% не подходит по измеримым критериям.
Важный вопрос: а что делать, если домашняя работа кажется бессмысленной? Думаю, стоит устраиваться в ту компанию, ради которой есть смысл делать домашнюю работу.
#работамечты
Вопрос: куда пойти работать начинающему веб-программисту: в студию или продуктовую команду?
У каждого из направлений свои плюсы.
В студии скорее всего выше будет рабочая нагрузка: вы лучше научитесь управлять собственным временем, быстрее поймете, как выглядит результат в глазах клиента.
Продуктовая команда работает более вдумчиво: там следят за качеством кода, больше времени тратят на оплату техдолга, в целом дают больше времени на задачи.
Если вы джуниор, то лучший выбор — это студия. Только посмотрите внимательно на используемые технологии: в провинциях до сих пор встречаются динозавры, которые клепают лендинги на джумле и джей-квери, их лучше избегать.
Когда станете мидлом и выше — в какой-то момент сами придете к варианту с продуктовой командой.
Есть #вопрос? Присылай на @fedor_borshev
У каждого из направлений свои плюсы.
В студии скорее всего выше будет рабочая нагрузка: вы лучше научитесь управлять собственным временем, быстрее поймете, как выглядит результат в глазах клиента.
Продуктовая команда работает более вдумчиво: там следят за качеством кода, больше времени тратят на оплату техдолга, в целом дают больше времени на задачи.
Если вы джуниор, то лучший выбор — это студия. Только посмотрите внимательно на используемые технологии: в провинциях до сих пор встречаются динозавры, которые клепают лендинги на джумле и джей-квери, их лучше избегать.
Когда станете мидлом и выше — в какой-то момент сами придете к варианту с продуктовой командой.
Есть #вопрос? Присылай на @fedor_borshev
Самый частый ответ на вопрос «почему вы не пишете тестов» — «ну, нам не дают времени, чтобы делать все хорошо».
Парадокс — заказчик жмет время на то, чтобы команда работала спокойно и без регрессий, зато щедро отсыпает ресурсы на проебаные сроки, неработающий код и починку багов в продакшене.
Может ему просто дихотомию никто не смог объяснить?
Парадокс — заказчик жмет время на то, чтобы команда работала спокойно и без регрессий, зато щедро отсыпает ресурсы на проебаные сроки, неработающий код и починку багов в продакшене.
Может ему просто дихотомию никто не смог объяснить?
Работа мечты: Резюме
Банальные советы про резюме:
— Лучшее резюме — это гитхаб. Покажите работодателю сразу, как вы умеете отрывать жопу от кресла.
— Круче гитхаба может быть только профессиональный блог, в котором больше 5 заметок.
— В текстовом резюме перечисляйте только релевантный опыт: всем пофиг, как вы в 16 лет целое лето проработали эникейщиком в ООО «Вектор-Инвест».
— Пишите о результатах, а не перечисляйте должностные обязанности. Не «разрабатывал о поддерживал внутреннюю ЦРМ», а «интегрировал систему с Альфа-банком и SalesForce». Первое не говорит ни о чем, а второе вполне может оказаться созвучным с текущими проблемами работодателя.
— Напишите кратко о себе: чем вы отличаетесь от усреднённого коллеги из прошлого офиса? Что цените в работе? Чем можете быть полезны для будущей команды?
В маленьких компаниях такое резюме позволит вам сразу пробиться к CEO и CTO, и даст фору перед другими кандидатами.
#работамечты
Банальные советы про резюме:
— Лучшее резюме — это гитхаб. Покажите работодателю сразу, как вы умеете отрывать жопу от кресла.
— Круче гитхаба может быть только профессиональный блог, в котором больше 5 заметок.
— В текстовом резюме перечисляйте только релевантный опыт: всем пофиг, как вы в 16 лет целое лето проработали эникейщиком в ООО «Вектор-Инвест».
— Пишите о результатах, а не перечисляйте должностные обязанности. Не «разрабатывал о поддерживал внутреннюю ЦРМ», а «интегрировал систему с Альфа-банком и SalesForce». Первое не говорит ни о чем, а второе вполне может оказаться созвучным с текущими проблемами работодателя.
— Напишите кратко о себе: чем вы отличаетесь от усреднённого коллеги из прошлого офиса? Что цените в работе? Чем можете быть полезны для будущей команды?
В маленьких компаниях такое резюме позволит вам сразу пробиться к CEO и CTO, и даст фору перед другими кандидатами.
#работамечты
FEDOR BORSHEV pinned «Микроменеджмент ←———→ доверие Для меня всегда слово «микроменеджмент» был антонимом слова «доверие». Если вы доверяете людям, то вы их не менеджерите — не «спускаете сверху» сроки, а просите их самих распланировать время. Вы не требуете отчетов о затраченном…»
Сервисы: mailjet.
У команды любого приложения, которое шлет больше, чем один вид транзакционных писем, есть вечная боль — верстка и редактирование шаблонов этих самых писем.
Сложность верстки состоит в том, что в мире существуют десятки почтовых клиентов, каждый из которых имеет свои, понятные только ему, стандарты отображения HTML. Outlook, gmail, thunderbird, Apple mail, Protonmail — по хорошему, каждое письмо нужно проверять в каждом из них.
Даже если вы каким-то чудом сверстали себе работающий шаблон, приходит вторая боль — чтобы поправить запятую в тексте, обычно приходится писать тикет в разработку. А там никто особо вашими запятыми не интересуется — у них там докер, нагрузки, прод упал и все такое.
Mailjet сразу решает обе эти проблемы: транзакционные письма у него собираются мышкой, прямо в интерфейсе. Чтобы отправить письмо через мейлджет, достаточно указать ИД шаблона, который собрал имейл-маркетолог, и прокинуть туда контекст — переменные, которые нужны в письме, вроде имени покупателя или номера заказа.
Для маленьких объемов mailjet бесплатен, тарифы для больших тоже вменяемые.
У команды любого приложения, которое шлет больше, чем один вид транзакционных писем, есть вечная боль — верстка и редактирование шаблонов этих самых писем.
Сложность верстки состоит в том, что в мире существуют десятки почтовых клиентов, каждый из которых имеет свои, понятные только ему, стандарты отображения HTML. Outlook, gmail, thunderbird, Apple mail, Protonmail — по хорошему, каждое письмо нужно проверять в каждом из них.
Даже если вы каким-то чудом сверстали себе работающий шаблон, приходит вторая боль — чтобы поправить запятую в тексте, обычно приходится писать тикет в разработку. А там никто особо вашими запятыми не интересуется — у них там докер, нагрузки, прод упал и все такое.
Mailjet сразу решает обе эти проблемы: транзакционные письма у него собираются мышкой, прямо в интерфейсе. Чтобы отправить письмо через мейлджет, достаточно указать ИД шаблона, который собрал имейл-маркетолог, и прокинуть туда контекст — переменные, которые нужны в письме, вроде имени покупателя или номера заказа.
Для маленьких объемов mailjet бесплатен, тарифы для больших тоже вменяемые.
Я — старый фанат учета времени и, хотя и использую телефон по 20 минут в день, давно мечтал считать и это время тоже.
Мои прошлые попытки учитывать время на мобилке закончились на необходимости каждую неделю фотографировать какую-то дальнюю вкладку в настройках батарейки для Moment, так что я очень сильно обрадовался письму о мобильной версии RescueTime.
Казалось, что разработчики (ребята неторопливые, судя по интерфейсу из начала двухтысячных) напряглись и интегрировались с новой фичей iOS 12. Но нет, они просто записывают время, которое телефон включен, без деления на продуктивное и непродуктивное:
Note about iOS and the Productivity Pulse: Because we can only capture total screen time on iOS instead of individual applications, we don’t feel that time can accurately impact your productivity pulse. It would just be too much of a guess. Therefore, while your iOS time will show up in your reports under the total time, that time will not impact your productivity pulse.
Интересно, в чем ценность такой версии для пользователей RescueTime, единственная фича которой — измерять, насколько продуктивно вы проводите время за компьютером?
Буду ждать тех, кто первым интегрируется со встроенным учетом времени, и уйду, видимо, к ним.
Мои прошлые попытки учитывать время на мобилке закончились на необходимости каждую неделю фотографировать какую-то дальнюю вкладку в настройках батарейки для Moment, так что я очень сильно обрадовался письму о мобильной версии RescueTime.
Казалось, что разработчики (ребята неторопливые, судя по интерфейсу из начала двухтысячных) напряглись и интегрировались с новой фичей iOS 12. Но нет, они просто записывают время, которое телефон включен, без деления на продуктивное и непродуктивное:
Note about iOS and the Productivity Pulse: Because we can only capture total screen time on iOS instead of individual applications, we don’t feel that time can accurately impact your productivity pulse. It would just be too much of a guess. Therefore, while your iOS time will show up in your reports under the total time, that time will not impact your productivity pulse.
Интересно, в чем ценность такой версии для пользователей RescueTime, единственная фича которой — измерять, насколько продуктивно вы проводите время за компьютером?
Буду ждать тех, кто первым интегрируется со встроенным учетом времени, и уйду, видимо, к ним.
Работа мечты: собеседование
Мне всегда странно слышать от знакомых программистов фразу «нервничал на собеседовании». Собеседование, по крайней мере у программистов — наименее важный этап устройства на работу. Вся работа уже сделана: вы уже где-то поработали с заявленными технологиями, показали свои работы и даже, возможно, выполнили тестовое задание.
Цель хорошего собеседования — понять насколько вы совместимы с новым рабочим местом: знаете библиотеки/языки, подходите к команде и процессам.
Если вы хорошо знакомы со стеком, технические вопросы долго не продлятся: человек напротив так же, как и вы, бережет свое время. Если не уверены глубине своих знаний в какой-то определенной области — просто говорите об этом сразу, разговор пойдёт гораздо легче.
Вторая серия вопросов — «личные». Это проверка на совместимость с командой. Где-то важна железная дисциплина, кто-то больше ценит неформальные отношение и ваше участие в жизни команды.
«Личные» вопросы — не экзамен, а именно проверка совместимости: есть команды, в которых вам будет комфортно работать, а есть те, из которых вы сбежите через месяц. Это как с кухней — если вы ненавидите острую еду, то зачем идти в китайский ресторан?
Ну и самое главное — не стесняйтесь сами задавать вопросы (желательно такие, на которые нельзя ответить «да» или «нет»). Собеседование — это знакомство с компанией, и ни в коем случае не экзамен.
Другие заметки: #работамечты
Мне всегда странно слышать от знакомых программистов фразу «нервничал на собеседовании». Собеседование, по крайней мере у программистов — наименее важный этап устройства на работу. Вся работа уже сделана: вы уже где-то поработали с заявленными технологиями, показали свои работы и даже, возможно, выполнили тестовое задание.
Цель хорошего собеседования — понять насколько вы совместимы с новым рабочим местом: знаете библиотеки/языки, подходите к команде и процессам.
Если вы хорошо знакомы со стеком, технические вопросы долго не продлятся: человек напротив так же, как и вы, бережет свое время. Если не уверены глубине своих знаний в какой-то определенной области — просто говорите об этом сразу, разговор пойдёт гораздо легче.
Вторая серия вопросов — «личные». Это проверка на совместимость с командой. Где-то важна железная дисциплина, кто-то больше ценит неформальные отношение и ваше участие в жизни команды.
«Личные» вопросы — не экзамен, а именно проверка совместимости: есть команды, в которых вам будет комфортно работать, а есть те, из которых вы сбежите через месяц. Это как с кухней — если вы ненавидите острую еду, то зачем идти в китайский ресторан?
Ну и самое главное — не стесняйтесь сами задавать вопросы (желательно такие, на которые нельзя ответить «да» или «нет»). Собеседование — это знакомство с компанией, и ни в коем случае не экзамен.
Другие заметки: #работамечты
О чем я пишу в этом канале:
— Рассказываю про софт-скиллы программистов: как отличить процесс от результата, сдавать работу с первого раза, работать быстро и почему важно успевать в срок.
— Делюсь опытом управления проектами:
как делать, чтобы планы сбывались;
какие фичи брать в работу, а какие — ни в коем случае; как избегать закона Паркинсона и не микроменеджить коллег.
— Иногда углубляюсь в специфичные вопросы: как писать понятный код; избавиться от говнокода, доставшегося в наследство; как объяснить важность тестирования коллегам и руководителю.
— Даю подсказки, как устроиться на работу мечты: оформить резюме, попасть сразу к СTO и пройти собеседование. #работамечты
Ну и конечно, я всегда готов взять на работу питонистов с любым уровнем знаний и фронтендеров (vue.js).
— Рассказываю про софт-скиллы программистов: как отличить процесс от результата, сдавать работу с первого раза, работать быстро и почему важно успевать в срок.
— Делюсь опытом управления проектами:
как делать, чтобы планы сбывались;
какие фичи брать в работу, а какие — ни в коем случае; как избегать закона Паркинсона и не микроменеджить коллег.
— Иногда углубляюсь в специфичные вопросы: как писать понятный код; избавиться от говнокода, доставшегося в наследство; как объяснить важность тестирования коллегам и руководителю.
— Даю подсказки, как устроиться на работу мечты: оформить резюме, попасть сразу к СTO и пройти собеседование. #работамечты
Ну и конечно, я всегда готов взять на работу питонистов с любым уровнем знаний и фронтендеров (vue.js).
FEDOR BORSHEV pinned «О чем я пишу в этом канале: — Рассказываю про софт-скиллы программистов: как отличить процесс от результата, сдавать работу с первого раза, работать быстро и почему важно успевать в срок. — Делюсь опытом управления проектами: как делать, чтобы планы сбывались;…»
Страх ошибиться — самый большой враг хорошего кода
Есть много людей, которым лучше не ошибаться — к примеру пилоты самолета или сердечные хирурги. Программистам повезло — им ошибаться можно.
Ошибки программистов проходят через очень хороший контроль: автотесты, отделы QA, фиче-флаги.
Даже когда ошибка добирается до продакшена, у нас есть множество инструментов быстрого отката: k8s не заведет больной контейнер, дежурный инженер откатит непрошедшую миграцию. Если ни один инструмент не подошел, всегда можно просто накатить хотфинкс поверх выложенной кодовой базы.
Но, несмотря на внушительный набор инструментов, мы все еще боимся рефакторинга, «потому что может сломаться». На таких страхах вырастают неуклюжие, плохо пахнущие классы с копипастой, которые постепенно превращаются в легаси.
Давайте не бояться ошибок — мы не пилоты самолета, в конце концов. Хотя и пилоты занимаются на тренажере именно для того, чтобы ошибаться и отрабатывать исправление этих ошибок.
Есть много людей, которым лучше не ошибаться — к примеру пилоты самолета или сердечные хирурги. Программистам повезло — им ошибаться можно.
Ошибки программистов проходят через очень хороший контроль: автотесты, отделы QA, фиче-флаги.
Даже когда ошибка добирается до продакшена, у нас есть множество инструментов быстрого отката: k8s не заведет больной контейнер, дежурный инженер откатит непрошедшую миграцию. Если ни один инструмент не подошел, всегда можно просто накатить хотфинкс поверх выложенной кодовой базы.
Но, несмотря на внушительный набор инструментов, мы все еще боимся рефакторинга, «потому что может сломаться». На таких страхах вырастают неуклюжие, плохо пахнущие классы с копипастой, которые постепенно превращаются в легаси.
Давайте не бояться ошибок — мы не пилоты самолета, в конце концов. Хотя и пилоты занимаются на тренажере именно для того, чтобы ошибаться и отрабатывать исправление этих ошибок.
Выбрать фреймворк для нового проекта
Многие ребята, выбирая инструменты для нового проекта, начинают строить таблицы, сравнивая фичи. Серьезно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.
Если вы выбираете инструменты для «домашнего» проекта — это вполне ок: подобрать приятный тулинг в этом случае настолько же важно, как и запустить проект.
А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта _сейчас_. Подумайте лучше о том, каким будет ваш фреймворк _тогда_. Удержит ли он комьюнити? Успеет ли за быстроизменяющейся средой? Будет ли адекватное предложение на рынке труда?
Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends.
И да, если вы выбираете фреймворк для фронтенда, то берите любой — все равно он протухнет через год.
Многие ребята, выбирая инструменты для нового проекта, начинают строить таблицы, сравнивая фичи. Серьезно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.
Если вы выбираете инструменты для «домашнего» проекта — это вполне ок: подобрать приятный тулинг в этом случае настолько же важно, как и запустить проект.
А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта _сейчас_. Подумайте лучше о том, каким будет ваш фреймворк _тогда_. Удержит ли он комьюнити? Успеет ли за быстроизменяющейся средой? Будет ли адекватное предложение на рынке труда?
Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends.
И да, если вы выбираете фреймворк для фронтенда, то берите любой — все равно он протухнет через год.
Юнит-тесты и фронтенд
Самое сложное место для автоматизированного тестирования — интерфейсы. Сложность тестирования проистекает от их асинхронной природы — ты никогда не поймешь, почему в тесте не нажимается кнопка: потому что она еще не загрузилась из-за задержки в браузере, или потому, что ее действительно сломали в последнем коммите.
С юнит-тестами тоже все плохо — фронтовый код сложно разбивать на вменяемые куски, которые приятно тестировать. Спасает только TDD и хорошие библиотеки типа vue.js, которые сводят количество процедурного кода к минимуму.
Сложность тестирования обостряет извечную проблему для проектов с плохим покрытием — регрессии.
Мой любимый способ борьбы с плохим покрытием на фронте — писать поменьше кода. Серьезно — максимум логики из фронтенда нужно уносить на бекенд: там живут достаточно взрослые и удобные технологии, на которых тесты писать легко и приятно.
Мы в mtrl.ai прямо запрещаем писать бизнес-логику на фронте. Если код в интерфейсе ходит в один эндпоинт, а в зависимости от результатов ходит в другой эндпоинт — это уже не очень хороший код. Если эндпоинта три — мы этот код не пропускаем.
Самое сложное место для автоматизированного тестирования — интерфейсы. Сложность тестирования проистекает от их асинхронной природы — ты никогда не поймешь, почему в тесте не нажимается кнопка: потому что она еще не загрузилась из-за задержки в браузере, или потому, что ее действительно сломали в последнем коммите.
С юнит-тестами тоже все плохо — фронтовый код сложно разбивать на вменяемые куски, которые приятно тестировать. Спасает только TDD и хорошие библиотеки типа vue.js, которые сводят количество процедурного кода к минимуму.
Сложность тестирования обостряет извечную проблему для проектов с плохим покрытием — регрессии.
Мой любимый способ борьбы с плохим покрытием на фронте — писать поменьше кода. Серьезно — максимум логики из фронтенда нужно уносить на бекенд: там живут достаточно взрослые и удобные технологии, на которых тесты писать легко и приятно.
Мы в mtrl.ai прямо запрещаем писать бизнес-логику на фронте. Если код в интерфейсе ходит в один эндпоинт, а в зависимости от результатов ходит в другой эндпоинт — это уже не очень хороший код. Если эндпоинта три — мы этот код не пропускаем.
Сделай это завтра
Тайм-менеджмент в технологической компании — сложная задача: работы всегда больше, чем можно успеть. На проблемы планирования часто накладывается наша эмоциональность — сложно отказать руководителю, который громко требует «пойти и работать». И почти невозможно отказать самому себе, когда хочется поделать фичу, которая только что пришла в голову, и «точно всем нужна».
Моя библиотека книг по тайм-менеджменту ограничена единственной Getting Things Done, поэтому я обрадовался, когда ребята из издательской студии Поле предложили написать рецензию на книгу Марка Форстера «Сделай это завтра», которая выходит у них в ноябре.
Книга приносит идеи, которые будут полезны не только менеджерам, но инженерам. К примеру, закрытые списки дел на день. Список закрыт, если под ним подведена черта, и в него нельзя ничего добавить. Все новые дела, которые появляются за день, нельзя вносить в сегодняшний список — только на завтра.
Моя любимая часть — про «видение». Марк Форстер рассказывает, как клево живется, когда у тебя есть четкая система, которая отделяет вещи, которые нужно делать от вещей, которые делать не нужно.
К примеру, лучше не брать задачу, которую ты считаешь недостаточно важной, или не уверен что сделаешь хорошо. Лучше честно отказать коллегам, чем обмануть ожидания и потратить время на половину результата, которая никому не пригодится.
Конечно, книга не заменяет ГТД с его пустыми инбоксами, но хорошо дополняет. По предзаказу стоит 600 рублей.
Тайм-менеджмент в технологической компании — сложная задача: работы всегда больше, чем можно успеть. На проблемы планирования часто накладывается наша эмоциональность — сложно отказать руководителю, который громко требует «пойти и работать». И почти невозможно отказать самому себе, когда хочется поделать фичу, которая только что пришла в голову, и «точно всем нужна».
Моя библиотека книг по тайм-менеджменту ограничена единственной Getting Things Done, поэтому я обрадовался, когда ребята из издательской студии Поле предложили написать рецензию на книгу Марка Форстера «Сделай это завтра», которая выходит у них в ноябре.
Книга приносит идеи, которые будут полезны не только менеджерам, но инженерам. К примеру, закрытые списки дел на день. Список закрыт, если под ним подведена черта, и в него нельзя ничего добавить. Все новые дела, которые появляются за день, нельзя вносить в сегодняшний список — только на завтра.
Моя любимая часть — про «видение». Марк Форстер рассказывает, как клево живется, когда у тебя есть четкая система, которая отделяет вещи, которые нужно делать от вещей, которые делать не нужно.
К примеру, лучше не брать задачу, которую ты считаешь недостаточно важной, или не уверен что сделаешь хорошо. Лучше честно отказать коллегам, чем обмануть ожидания и потратить время на половину результата, которая никому не пригодится.
Конечно, книга не заменяет ГТД с его пустыми инбоксами, но хорошо дополняет. По предзаказу стоит 600 рублей.
Не тороплюсь смотреть код в конце спринта
Несмотря на принятую у нас систему positive review, бывает так, что мы все равно показываем друг другу код по публикации, а не после.
Если просьба приходит в конце спринта, то я обычно сразу отказываюсь.
Во-первых, это невежливо: я точно так же пишу код, и так же могу что-нибудь проебывать и делать в последний момент.
Во-вторых, две головы лучше одной только тогда, когда близко нет дедлайна. Зачем мне влезать, если ответственность за сдачу лежит не на мне, а написать «все говно» не позволяют сроки?
В-третьих, в пулл-реквесте, который отложили на последний момент, вряд ли все хорошо и понятно: коллега скорее всего торопился, и принимать адекватные решения уже было тяжело. А я обычно отказываюсь смотреть непонятный код.
Так что если у вас осталась незавершенная работа на понедельник — уж выпихивайте как есть: завтра перепишете.
Несмотря на принятую у нас систему positive review, бывает так, что мы все равно показываем друг другу код по публикации, а не после.
Если просьба приходит в конце спринта, то я обычно сразу отказываюсь.
Во-первых, это невежливо: я точно так же пишу код, и так же могу что-нибудь проебывать и делать в последний момент.
Во-вторых, две головы лучше одной только тогда, когда близко нет дедлайна. Зачем мне влезать, если ответственность за сдачу лежит не на мне, а написать «все говно» не позволяют сроки?
В-третьих, в пулл-реквесте, который отложили на последний момент, вряд ли все хорошо и понятно: коллега скорее всего торопился, и принимать адекватные решения уже было тяжело. А я обычно отказываюсь смотреть непонятный код.
Так что если у вас осталась незавершенная работа на понедельник — уж выпихивайте как есть: завтра перепишете.
Два свободных дня
После пятничного поста сразу несколько ребят написали в личку, что если откладывать говнокод на следующие спринты, он повисает мёртвый грузом.
У нас это не так. Во-первых мы весьма адекватно управляем техдолгом (расскажу как-нибудь), во-вторых у нас есть система самолечения.
Самолечение происходит в свободное время — между спринтами каждый программист получает два свободных дня. Свобода — полная, делать можно что угодно. Два условия — это должно быть полезно для проекта, а по итогам нужно будет рассказать коллегам о том, что ты сделал.
Обычно в это время мы занимаемся рефакторингом — делаем вещи, которые позволят нам более приятно и быстро работать в следующем спринте. Иногда берем срочные бизнес-требования, или начинаем большие проекты.
Такое свободное время позволяет не только бороться с легаси, но и делает нас более реактивными, давая возможность поддерживать целую категорию фич, которые появляются на продакшене в течение пары дней после обсуждения, без ожидания следующего спринта.
#техдолг
После пятничного поста сразу несколько ребят написали в личку, что если откладывать говнокод на следующие спринты, он повисает мёртвый грузом.
У нас это не так. Во-первых мы весьма адекватно управляем техдолгом (расскажу как-нибудь), во-вторых у нас есть система самолечения.
Самолечение происходит в свободное время — между спринтами каждый программист получает два свободных дня. Свобода — полная, делать можно что угодно. Два условия — это должно быть полезно для проекта, а по итогам нужно будет рассказать коллегам о том, что ты сделал.
Обычно в это время мы занимаемся рефакторингом — делаем вещи, которые позволят нам более приятно и быстро работать в следующем спринте. Иногда берем срочные бизнес-требования, или начинаем большие проекты.
Такое свободное время позволяет не только бороться с легаси, но и делает нас более реактивными, давая возможность поддерживать целую категорию фич, которые появляются на продакшене в течение пары дней после обсуждения, без ожидания следующего спринта.
#техдолг
Быстрая коммуникация
Важный этап при внедрении новых коллег в нашу команду — отучить их от привычки к быстрой коммуникации.
В безумном мире люди привыкли звонить друг-другу или писать в чат «привет». У нас не так: мы все в разных часовых зонах, а в чатик кидаем только мемасики.
Помимо того, что асинхронная коммуникация позволяет нормально взаимодействовать в разных часовых поясах (у нас всего двое ребят в GMT+3), это еще и приводит голову в порядок: заставляет не задавать глупых вопросов и лучше планировать время.
Как я это объясняю новым ребятам? Просто игнорирую телеграм, а на почту отвечаю тогда, когда это удобно мне, а не им.
Важный этап при внедрении новых коллег в нашу команду — отучить их от привычки к быстрой коммуникации.
В безумном мире люди привыкли звонить друг-другу или писать в чат «привет». У нас не так: мы все в разных часовых зонах, а в чатик кидаем только мемасики.
Помимо того, что асинхронная коммуникация позволяет нормально взаимодействовать в разных часовых поясах (у нас всего двое ребят в GMT+3), это еще и приводит голову в порядок: заставляет не задавать глупых вопросов и лучше планировать время.
Как я это объясняю новым ребятам? Просто игнорирую телеграм, а на почту отвечаю тогда, когда это удобно мне, а не им.