Маленькие пулл реквесты и рабочий мастер.

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

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

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

А фишка в том, что в мастере не должно быть законченное целое количество фич, а мастер просто должен быть рабочим.

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

В общем, правила такие:
1. Пулл реквест должен быть как можно меньше. Если пулл реквест можно разбить на два отдельных — бейте.
2. В мастере должны проходить все тесты. Ну, или мастер должен технически запускаться и не падать, если вдруг у вас нет тестов.
3. Вполне допустимо в пулл реквесте сделать код, который не используется по назначению прям в этом пулл реквесте, а будет использоваться в следующих. И убедить коллег в работоспособности этого кода проще всего с помощью тестов. Или пистолета.
4. Технические изменения пулл реквеста должны описываться одним предложением. Не «сделал фичу», а «поменял сигнатуру метода» или «обновил библиотеку и зависимости». Человеческие описания оставьте задачам, а в пулл реквестах говорите о коде.

14 декабря в Киеве я буду докладываться на Рубимедитейшен. Я буду рассказывать о том, как мы делали реалтайм приложение без тонны джаваскрипта. Буду рад вас там видеть, друзья.

https://rubymeditation29.eventbrite.com?discount=extrapolation

Ссылка уже со скидкой в 10%.

Что-то вообще на канале тихо стало, простите. Надеюсь, вы скучаете.

А у нас пока #экстравакансия от Антона. Он ищет себе напарника в американский стартап (https://securitytrails.com/). Хочется эликсирщика хорошего или отличного уровня. Работа удаленная, без привязки ко времени с остальными всеми самыми вкусными плюшки подобной работы.

Я Антона знаю, как крутого разработчика и офигенского эликсирщика. Самое классное, что скорее всего вы знаете Антона тоже, если пишете на эликсире. Антон — автор библиотеки espec.

Пишите ему в личку (@anton_mishchuk), он ответит на ваши вопросы.

Утиная типизация настройки серверов.

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

Ребята, не существует продакшена, стейджинга или девелопмента. Есть кеширование, генерация статических файлов, обфускация, количество тредов, номер порта, пароль к базе данных и всё такое прочее. Вместо проверки константой ISPRODUCTION значительно правильней проверять отдельно CACHE и отдельно HOTRELOAD.

Да, многие сервисы и библиотеки полагаются на, скажем, NODEENV=production, чтобы вообще начать работать и да, в некоторых случаях допустимо выставлять дефолты, опираясь на NODEENV, но менять логику поведения всего приложения, основываясь на этой переменной ужасно плохо.

Не спрашивайте как и зачем, но недавно я узнал об одном термине фитнес-моделей и не смог пройти мимо этой концепции.

У них там в бодибилдинге принято не отрабатывать съеденный сникерс, а зарабатывать на то, чтобы съесть эту вкусняшку. Поняли, да? Идея того, что съеденная вкуснятина будет отработана сполна даже не рассматривается и нет доверия даже к себе самому. «Наверняка я съем раз в десять больше калорий, чем потом отработаю. А вот если я сначала тяжелыми физическими упражнениями заработаю, то потом смогу съесть строго лимитированное количество вредной еды». Вполне обыденно для фитокачков и вообще не очевидно зачем об этом рассказывать в «Экстраполяции».

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

Выдержка из чата с хештегом #dimoneverything от Дмитрия:

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

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

Технический долг появляется по одной из двух причин:

1. Враги сожгли родной продакшен, Дима, я попросила Аарона и он уже создал для тебя хотфикс бранч, он называется hotfix/2019.11.04, лупашь, всё лежит, QA-инженеры обосрались. В этой ситуации сказать, что у нас уже превышен кредитный лимит и давай я сначала порефакторю невозможно.

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

Многие воспринимают гит, как инструмент для синхронизации кода между разработчиками. Признаков у такого подхода несколько: один коммит в день, пулл реквест с названием «dashboard-v2», постоянное использование команды «git add .», оправдание «я не пушу, потому что не закончил» и всякое такое подобное. Этот подход настолько плох, что минусы и недостатки даже перечислять не хочется.

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

К репозиторию нужен относится, как к в принципе единственному способу менять проект.

Интересная штука этот ваш говнокод.

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

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

Формулировка мысли.

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

1. Если разработчик не может что-то объяснить, это не значит, что он этого не знает. Это стоит учитывать на собеседованиях.

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

Ну, ладно, сам афоризм приписывают Ричарду Фейману и я думал его все знают.

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

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

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

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

Учим современную бизнес-лексику. Если кому-то говоришь «пшел вон» и не уточняешь куда конкретно, то ты ментор. А если уточняешь куда ему конкретно идти — ты коуч. А если при этом объясняешь как быстро и что будет, если он не пойдет — ты тьютор.

Ребята, затишье в «Экстраполяции» было не зря, я считаю. Мы тут второй сезон «Лямбдашоу» запилили. Анонс и самореклама вот прям вот тут:

https://www.youtube.com/watch?v=OQYs3URQ8Sw

Лайки, сабскрайбы и вот это вот всё.

Итак, первое видео нового сезона будет из рубрики «Lambda Short Stories» и в нем Павел Суйков коротко расскажет о том, что же такое Лямбда-куб.

А если поделитесь этим видео в чатиках с коллегами, то тогда таких видео станет больше.

https://www.youtube.com/watch?v=b0YSHqul7I0

Ребята, так как сейчас все работают из дому, проблема окружающих шумов во время аудиоразговоров стала острее всех других.

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

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

Мы же, как будто всегда готовились к пандемиям и работу свою настроили так, что принципиально не важно как и где находится коллега. К слову, об этом мы говорили с Евгением Выборовым (техдиректором из YayPay) в последнем выпуске лямбдашоу. Не буду повторяться и пересказывать видео, лучше посмотрите.

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

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

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

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

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

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

Как вам идея?

В этот раз, в Лямбдашоу в гостях был Влад Пранскевичус, основатель letsenhance.io и он рассказал о сложностях планирования проектов с машинным обучением. А это, черт побери, не сайтики рисовать. Смотрите сами:

https://youtu.be/utEV6wSvXBo

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

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

Если классифицировать все причины важности, то их по сути три:

1. Улучшения и изменения системы. Попросить поменять могут что угодно и когда угодно и нужно быть к этому готовым. Чем прямее код соответсвует реальным процессам, тем проще вносить изменения, которые могут попросить.

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

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

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

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

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

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

3. Не все языки и фреймворки готовы к такому. Скажем, джаваскриптовый npm к такому не готов, а вот yarn имеет опцию workspaces, которая ведёт себя ровно так, как хочется.

4. Автотесты становятся просто необходимыми. Без них уж очень много ручной необходимой работы.

5. Публичными зависимостями и их версиями нужно управлять автоматически. У нас настроен бот renovate, который каждое утро делает пулл реквесты с обновлением всех зависимостей во всех репозиториях. Ещё в планах настроить правильный автомерж таких вот пулл реквестов, но пока приходится вручную.

6. Нужна жесткая фиксация версий внешних зависимостей. Никаких ">= 1.14", только "1.14.5". Так и обновлять легче и синхронизировать удобнее.

7. Изменения в сабмодули вносить стало очень удобно. Просто cd submodulename и уже там работаешь с сабмодулем непосредственно. А в родительском репозитории можно даже коммитить изменения дочернего, чтобы оно вместе работало. Потом с релизом дочернего всё станет, как должно быть.

8. Всего-то пару настроек в гите и работа с субмодулями становится такой же, как и без сабмодулей. Все твики и хуки легко можно нагуглить.

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

Ребята, кому эликсира? Наш хорошо знакомый эликсирклуб организует встречу с Андреа Леопарди, который один из разработчиков языка первого круга. Рассказывать будет про OTP и уверен, даже те, кто пишут на эликсире, узнают что-то новое обязательно. Детали по ссылке, нам традиционная десятинная скидка по коду extrapolation

https://www.facebook.com/events/293583834971044/?active_tab=discussion