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

— Достаточно ли просто тестировать получившийся код? Если возникают проблемы с написаниями тестами, то где-то тут попахивает плохим кодом.
— Хорошо ли этот код масштабируется вертикально? И речь тут не о запуске нескольких приложений рядом, а о добавлении сущностей уровня выше. Вроде company_id если хотите.
— Легко ли придумать название методу или переменной? Если называние не слишком очевидное или придумывается тяжело, то скорее всего и содержимое не слишком очевидно.
— Много ли методов нужно переопределять? Много ли граничных условий обрабатывается? Или в общем случае: как формулируются правила по которым работает ваша функциональность и сколько исключений из этих правил? Касается это не сколько бизнес-логики, а сколько правильно подобранной архитектуры и структуры кода. Если в системе нашелся неприятный баг и исправить его можно, добавив еще одно условное ветвление, то значит этот баг появился не на пустом месте, а от неправильно подобранной структуры кода.

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

#перечитываяэкстраполяцию

«Аджайл — он о процессе, а не о результате. Поэтому если вам процесс важнее результата, то смело его используйте».

В современном мире айти-разработки, при преобладании удаленной работы и сотрудничестве с фрилансерами появился занятный феномен перекладывания ответственности за простой в работе. В офисном мире, если у программиста нет задач, он может делать что угодно и ему за это все-равно заплатят, он же в офисе! У фрилансеров же обратная ситуация. Почему-то принято считать, что отсутствие задач у фрилансера (или удаленного сотрудника) – это проблема самого фрилансера. Решение выбирают фрилансеры вполне логичное и очевидное — берут себе несколько проектов и постоянно переключаются между ними. Из-за этого, собственно, и пошла легенда, что фрилансером быть тяжелее, чем офисным сотрудником.

А быть должно все наоборот. Только никому не говорите, что это я вам рассказал. Ставьте сами себе задачи с формулировкой «Мне же все-равно нечего делать, поэтому буду делать вот эту полезную задачу. Остановить меня можно только другой задачей». Профессиональным будет считаться не только качественное выполнение таких задач, тщательное описание до и отчет после, но и адекватность поставленных задач. Очевидно, что задач вида «перепишу-ка я вот этот модуль, потому что там код – говно» быть не должно в принципе, а вот формулировка «помнится, проекту давно была нужна вот эта фича, а сейчас как раз подходящий момент, чтобы ее сделать» крайне удачная. Дополнительной выгодой от такой стратегии поведения будет демонстрация руководству проекта (менеджеру, если хотите) того, как по-вашему должны выглядеть поставленные вам задачи.

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

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

#перечитываяэкстраполяцию

Ребята, #экстрапиар от подписчика.

Основатель проекта signum.ai, подписчик канала «Экстраполяция IT», прислал ссылку с описанием своего проекта. Идея проекта состоит в том, что с помощью матмодели и собираемых данных можно определить трендовость и хайповость конкретной темы.

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

Тем не менее, в стате ребята пишут об положительной тенденции, платящих клиентах и удачной мат.модели. И я бы с удовольствием послушал бы о конкретных примерах работы такого сервиса. Давайте лайками попросим основателей написать нам какой-нибудь конкретный случай?

https://vc.ru/tribuna/67458-signum-ai-otslezhivayte-zarozhdenie-novyh-trendov-i-haypov-na-samyh-rannih-etapah

Ребята, в эту субботу (26 октября) в Киеве будет Рубимедитейшн и я тоже планирую там побывать.

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

К слову, нам даже 10% скидки дали по коду extrapolation. Увидимся там?

http://bit.ly/2VP51Ot

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

Менеджер у меня офигенная.

Лупашил три недели, перевернул горы говна, само собой конфеткой его не сделал, сделал фичу всего лишь, но сделал её не насрав сверху, а занырнув и попереставляв вот это вот всё, пока оно не стало (1) делать ещё и то, что мне нужно и (2) попутно ряд мест, где что-то делается тремя способами, слились в одно, где, что-то делается одним способом, который я и подкрутил. +2000 строк, -800 строк.

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

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

Моя менеждер: «Дмитрий готов мёржится, возражения есть?».
Я «вот пулл-реквест, если что».
Все: <молчат>.
Таша (через пару часиков): возражений нет. Дмитрий, мёржись.

Менеджер у меня офигенная.

#dimoneverything

Работа над одной и той же кодовой базой, у разработчиков может быть бесконечное количество разных инструментов которые как-то взаимодействуют с файлами. А те, в свою очередь, оставляют кучу мусора после себя. Всякие папки .idea, тильда-файлы и прочие штуки, которые относятся к окружению, а не к коду сразу же хочется добавить в .gitignore, автоформатирование в гит-хуки (не в сами хуки, а в зависимый пакет, который уже что-то там делает с хуками). Или, допустим, способ запустить несколько процессов сразу из одной папки делается разными способами и один из самых удобных — фореманоподобные утилиты, а их написано уйма, в кедом языке по несколько штук. Отсюда и желание добавить этот пакет управления вебхуками в зависимости. И фореман туда же давайте тоже добавим.

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

Отсюда простые правила:

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

2. Игнорируйте файлы глобально с помощью gitignore global настройки специфичные для вашей рабочей станции. То, что ваша операционная система создаёт файлы DS_store вообще не проблема всех остальных.

3. Декларируйте настройки и принятые стандарты в репозитории. Например, хорошо договориться, что версия языка будет лежать в специальном файлике, скажем, .node-version, но навязывать nvm всем разработчикам нельзя. По той же причине описывать необходимый для установки софт в Brewfile тоже не желательно. Уж лучше в readme.md словами описать.

Внутренности ЭктивРекорда выглядят, как мой проект.
Тоже одна и та же вещь делается в трёх местах.
Зачастую тремя способами.
Деда Мороза не существует, блин.

#dimoneverything

Удивительное дело.

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

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

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

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

К тому же это дисциплинирует. Во-первых перестаешь использовать жаргонные слова. А во-вторых пытаешься формулировать мысль сразу за один раз.

В общем, это целая находка для меня, как для человека, который не может найти времени написать пост в «экстраполяцию».

Ребята, внезапно #экстравакансия от автора «Экстраполяции».

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

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

Работа удалённая, но офис в Киеве.

Что будем проверять:

- отсутствие стремления побыстрее слинять в чистый и незамутненный джаваскрипт. Джаваскрипт, конечно, знать нужно, но писать огромные реакт-приложения не прийдётся.
- умение профилировать веб-приложения. Знать про fps, понимать от чего оно зависит и куда нужно надавить, чтобы сделать хотя бы 30 или все 60.
- знать, что сайтами могут пользоваться дальтоники и плохо видящие.
- знать, что бывают ещё и другие браузеры, а не только хром.
- уметь удовлетворить метрики поисковых систем по адаптивности, инклюзивности, интегрируемости и изоморфности.
- понимать какое слово лишнее в предыдущем требовании.
- разбираться в вебпаке, в бабеле и в плагинах и первого и второго.
- веб-графика. Векторная, растровая, спрайтовая, 3D. С анимацией и без. Ну, или хотя бы что-то из этого.
- веб-типографика. Что там в шрифтах, из чего они состоят и в каких форматах бывают. Что такое интерлиньяж и когда rem лучше, чем em. Ну и какие шрифты лучше купить, а какие и бесплатные ничего.

Что нужно обязательно знать:
- css/html;
- гит на базовом уровне;
- английский на уровне чтения документации;
- базовая работа с командной строкой;

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

Пишите мне личным сообщением (https://www.tgoop.com/aratak) если это про вас или отправляйте друзьям, если это про них. Спасибо.

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

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

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

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

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

Нормальным будет сделать пулл реквест, в котором появляется абстрактный класс, а реализация — отдельными пулл реквестами. Если новые 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. Объяснить можно пытаться только технологию, в которой разобрался очень хорошо. Попытка делать доклады по только что прочитанным ридми проваливается полностью.