CSSSR

Кодекс тестировщика

Wed, 08 Apr 2020 00:00:00 +0000

Разработка — это хорошо, но без тестирования — никуда. Количество проектов в CSSSR постоянно увеличивается. Растет штат разработки, а значит, растет и потребность в квалифицированных QA-инженерах. Чтобы ускорить процесс отбора, мы, аналогично вакансиям для разработчиков, придумали тестовый квест для QA.

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

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

Тестировщик должен быть внимательным

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

Тестировщик должен быть азартным

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

Тестировщик должен думать как пользователь

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

Тестировщик должен быть изобретательным

Никакие препятствия не должны останавливать вас на пути ловли багов. Не можете найти android определенной версии или отсмотреть Safari? Внимание! Именно для таких случаев в природе существуют онлайн-эмуляторы, и не онлайн тоже есть, есть платные версии, есть абсолютно бесплатные. Вот эта статья должна помочь.

Тестировщик должен быть ловким

Познавайте науку владения инструментами. Изучайте новый инструментарий, периодически проводите ревизию старого, придумывайте новые способы, но не забывайте и про стандартные решения. Подсказка в два слова: Dev Tools.

Тестировщик должен быть командным игроком

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

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

Тестировщик должен уметь оптимизировать

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

Тестировщик должен быть чист умом и помыслами

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

Тестировщик должен быть немного больше, чем тестировщиком

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

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

Если вы обладаете вышеперечисленными качествами и не боитесь принять на себя ответственность за качество продукта, то смело откликайтесь на вакансию. Мы очень вас ждем!

Список полезных ссылок

Список полезных книг для тестировщика

Универсальная схема для тестирования веб-приложения

Особенности тестирования веб-приложения

Потренить свои скиллы

Познавательные ресурсы: Radio QA PractiTest

Про автоматизацию: Webdriver Selenium

Если вы хотите быть модным автотестером :)

Почувствуй себя автоматизатором

Итоги 2019 от CSSSR

Thu, 26 Dec 2019 00:00:00 +0000

Пролог

Живу один в сталинке в ЦАО. Звукоизоляция от внешнего мира потрясающая, ибо стены из кирпича больше метра толщиной (где снаружи пилястры идут — больше полутора). От соседей звукоизоляция так себе, но это компенсируется их малой активностью, доходящей до незаметности. Неважно. Не суть.

Часто я сижу в полнейшей тишине такого масштаба, что начинает казаться, что на десятки метров вокруг меня нет ничего живого в доме. Совершенная, абсолютная, полная тишина. Я выключаю свет, зажигаю свечи в канделябрах моего дореволюционного Мюльбаха и в густом бархатном охристом полумраке играю на гитаре, импровизируя в недобрых модальных ладах с недобрыми интервалами. Ощущения охуенные, чувствую себя мамкиным Эрихом Цанном. А если серьезно, тишина и общий антураж таковы, что реально ощущение, будто за окном Москва 1919-го, и как раз только что Осоргина посадили в корабль смерти, а кого-то ведут под Варсонофьевский гараж.

И в этой циклопической, почти хтонической тишине, в ставшей уже аметистовой комнате, ты видишь его…

10 лет немого крика…

…кажется, подходят к концу. Всё началось в мае 2009 года с первым релизом Ноды, потом через год релиз AngularJS, потом были knockout, meteor и backbone. Наконец релиз React в мае 2013го. Рывок JavaScript от jQuery до полноценных фреймворков оказался таким сильным, что в тот момент в сознании IT-индустрии появилось понятие «фронтенд разработка».

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

Всё JavaScript

10 лет насмешек над «снежинками» и «наследование не на классах? Ха-ха», «вот так просто взять и создать объект? Умора!».

Но что мы имеем сейчас? Всё JavaScript. Не только веб-интерфейсы. Игровые тоже, и это не «индюшатина», а Battlefield. Electron и React Native — для устройств. Даже TensorFlow имеет порт на JavaScript.

Посмотрите на ТОП-50 гитхаба. JavaScript стал символом опенсорс-разработки, раскатистым гимном того, что программирование доступно каждому пользователю Интернета.

На этом, думаю, с ретроспективой покончено. Самое время перейти к «широко известным в узких кругах» событиям, не вошедшим в новогодний хит-парад подкаста «Новости 512».

Deno

Это новый (альтернативный?) виток эволюции Node, за авторством всё того же Райана Дала.

Помните скандал c event-stream в ноябре прошлого года? Тогда малварь утекла на тысячи машин. Возможность достучаться к файловой системе — ахиллесова пята Node.

В отличие от Node, Deno, по умолчанию, выполняет код в «песочнице». Это означает, что у среды выполнения нет возможности выполнить «посторонние» скрипты или работать с файловой системой. (На самом деле доступ есть и к файловой системе, и переменным окружения, но для этого нужно передать специальные ключи)

Вторая киллер фича — TypeScript из коробки, никаких конфигов, никаких лоадеров. По сути получается, что Deno — это рантайм для TS.

Мультиязычность GraalVM

У GraalVM в этом году первый стаблильный релиз

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

По сути это универсальная виртуальная машина для выполнения разных языков, в том числе и JS. Мы можем запускать приложения на разных языках в одной среде с возможностью шаринга данных между ними. Соответственно, можно юзать разные библиотеки (из разных ЯП) в одном проекте.

CommonJS -> AMD -> UMD -> «It don’t matter if you’re black or white»

Да-да, это те самые michael-jackson-файлы (.mjs). А если говорить общепринятым языком, ECMAScript Modules.

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

BigInt

Математика больших чисел в этом году заехала во все популярные браузеры, за исключением Egde. Но Edge простительно, сами понимаете из-за чего.

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

Очевидно, что нативная реализация должна быть существенно производительней текущих third-party решений.

Нет виртуального DOM. Нет фреймворков поверх фреймворков. Нет фреймворка в рантайме. Есть Svelte. И тот «исчезающий».

Строго говоря, само существование Svelte не ново. В этом году был релиз аж третьей версии. Но именно после третьей версии о Svelte заговорили. Да как заговорили! Сотни комментов только к статьям-переводам. И речь не про косяки Реакта или очередной «You don’t need Redux».

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

Logux

Ещё одно детище отечественного опенсорса, собранного под эгидой Андрея Ситника и его алчущих «ваших мозгов» марсиан. Тут ситуация сродни Svelte: о технологии знают достаточно давно. Среди киллер-фич были замечены:

offline first,
синхронизация между вкладками,
упрощение (и часто замещение) клиентского Redux.

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

По словам Андрея:

Само собой, сайт построен не на популярных реакт-решениях. В треде расскажу об экспериментах, которые удалось в нём реализовать. 17 килобайт веса, 100 очков на Lighthouse, никаких фреймворков. Фокус на DX и UX.

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

Эпилог

Мы заигрались за 10 лет становления JavaScript и фронтенда. Да так успешно, что все в награду получили аметистового протодракона. Сейчас покажу, как это вышло:

Ну было же? Было?

С ежегодной речью выступил Максон «Черная Борода» Вислогуров. До новых встреч в новом десятилетии! Все по драконам!

Оценка задач. Как перестать гадать и начать угадывать

Wed, 04 Sep 2019 00:00:00 +0000

Работа с оценкой и сроками — это стресс и ответственность, и некоторые разработчики даже придумывают идеологические отмазы против оценки. Но хотят они того или нет, в IT-мире всё вертится не вокруг качества кода, а вокруг сроков и оценок. Разрабатывая быстрее, компания получает конкурентное преимущество перед себе подобными, а адекватная оценка позволяет точно рассчитывать расходы. Заказчика в первую очередь интересуют сроки и конкретная стоимость работы, и оба этих параметра завязаны на оценке разработчика, изучавшего проект на пресейле. Конечно, менеджер заложит дополнительные риски, но это не поможет, если разработчик обсчитался в 3 раза.

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

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

Создайте условия

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

На оценку выделяется достаточно времени

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

Оценка крепко вплетена в ваш воркфлоу

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

Задачи ставятся качественно

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

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

В идеале оценка должна состоять из двух фаз:

Вы внимательно читаете ТЗ, задаёте по нему вопросы аналитику или представителю заказчика.
Получаете ответы и оцениваете задачу.

Но на правду больше похожа другая история:

Вы внимательно читаете ТЗ и задаёте возникшие вопросы носителю идеи.
Вы получаете ответы, на основе которых возникает ещё больше вопросов.
И снова.
И снова.

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

Работайте над собой

Теперь перейдём к правилам оценки и поговорим о том, что можете сделать лично вы для улучшения перформанса команды.

Декомпозируйте задачу и делайте это на совесть

Ешьте слона частями. Хорошая декомпозиция даёт мощный буст к укладываемости в оценку. Это стоит делать, даже если вы не планируете распараллеливать задачи между разными разработчиками. Во-первых, декомпозируя, вы смотрите на задачу чуть ближе, вертите так и сяк, планируете, как будете её выполнять, а значит — видите новые хитрости и заковыристости, на которые стоит заложить дополнительное время. Во-вторых, это дополнительная возможность самоконтроля: если вы пилите монолитную задачу на 120 часов, проще не уследить за временем и потратить 30 часов там, где стоило бы потратить 12. С декомпозицией такое не пройдёт.

Сравнивайте свои оценки и фактически затраченное время

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

Учитывайте риски

Отдельно оговаривайте всё, что может существенно повлиять на оценку. К таким факторам относятся:

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

Сообщайте об этом при оценке задачи, кричите погромче о том, что изменение постановки задачи повлечёт за собой рост трудозатрат.

Будьте реалистами

Ваш менеджер или тимлид, задавая вопрос «Сколько времени это займёт?», интересуется вовсе не тем, сколько вам понадобится времени конкретно на написание кода. Тем не менее, на этом первое время сыпятся все (ну или почти все). Здесь эта цифра бесполезна, она не соотносится с реальностью. Так что возьмите время, которое вы потратите на написание кода, прибавьте к нему время на покурить, выпить кофе, не выспаться и протупить полдня в стену, спросить совета у соседа, подождать ответа от аналитика, правок макета от дизайнера, заблокироваться бэкендом, разблокироваться, десять раз упасть и одиннадцать подняться. Сколько именно закладывать на риски? Мой совет — начните с 20% для больших задач и 50% для маленьких. Затем смотрите на результат и при необходимости корректируйте эту цифру.

Не прогибайтесь

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

Не завышайте оценки (существенно)

Если с заниженными оценками всё более-менее понятно, то что не так с оценками завышенными? Разве задача, сделанная в два раза быстрее, чем ожидалось, не станет приятным сюрпризом? Возможно, где-то, для кого-то. С некоторыми оговорками:

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

Это губительно для планирования и процессов в вашей команде. Во-первых, загрузка разработчика спланирована наперед на определенный срок. Если каким-то образом карточки двухнедельного спринта уйдут в 3-4 дня, остальная команда останется в недоумении, а разработчик-стахановец — без задач. И выглядит это не геройски, а даже немного глупо, к тому же заставляет серьёзно сомневаться в навыках такого разработчика. Во-вторых, процесс разработки ПО не ограничивается одним написанием кода. Есть аналитика, планирование, тестирование, код-ревью, в которых участвуют другие специалисты. И вот ваш бэклог уже пуст, а всем этим ребятам надо прям вот щас всё бросить и побежать, оставляя свои, возможно, срочные дела, чтобы грумить вам новые задачи и тестировать старые. Таким образом, эффективность планирования и взаимодействия команды плавно пикирует к нулю, плодя хаос и разрушение.

И, пожалуй, последний совет.

Расслабьтесь :)

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

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

Есть ли жизнь на удалёнке или как перестать верить в единорогов

Wed, 26 Jun 2019 00:00:00 +0000

Однажды разработчик перешёл на удалёнку, уехал на Бали, больше никогда не стоял в пробках, забыл про дресс-код, курил на рабочем месте, жил-поживал и добра наживал. Конец?

Привет, мы рекрутеры CSSSR, и мы должны вас предостеречь. Работать в распределённой команде — радостно и приятно. А ещё сложно и утомительно. Многие кандидаты приходят к нам после офиса или фриланса и надеются на кардинально лучшую жизнь. И перспективы действительно радужные:

Работа в штате = стабильность: есть пул задач, перспективы карьерного роста и равномерный финансовый поток.
Свободу перемещений при этом никто не отменял — если не брать самые строгие случаи, то home office может быть где угодно, так что зимовки на Бали вполне реальны.
Кажется, что можно успевать намного больше — не нужно тратить время на поиск задач (фриланс) или дорогу (офис), коллеги не отвлекают перекурами, а ходить на встречи можно сидя.
Отсутствие дресс-кода становится приятным дополнением для тех, кто до этого работал в классическом офисе. Даже если в компании приняты видеосозвоны, брюки можно не надевать.
В некоторых случаях это может быть единственным приемлемым вариантом — например, для тех, кто по каким-то причинам не может каждый день добираться до офиса, кому сложно находиться среди людей целый день или кто в офлайн-мире подвергается дискриминации.

Где же подвох?

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

* * *

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

«Я работала из Тасмании по московскому времени (с обеда и до ночи). Было обидно, когда пару раз я пропустила Южное сияние (Аврору) только потому, что не смогла сорваться сразу и поехать на гору его смотреть — были запланированы созвоны и другие задачи, которые можно решить только в команде и только в рабочее время»

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

Вот вам пруф:

Безусловно, работать на берегу моря — очень романтично. И настолько же неудобно. Где розетка? Где туалет? Где тень? Зато точно знаешь, где песок — он повсюду, в том числе в клавиатуре. У бабушки в деревне — прекрасно, но проблемы с вайфаем. В кафе может оказаться и розетка, и вайфай, зато шумно и официант навязчиво предлагает заказать что-нибудь ещё. По нашему опыту, спонтанно путешествовать на постоянной основе и при этом эффективно работать — тонкий лёд.

«Каждый день менять себе рабочее место нельзя. В реальности мы путешествуем так — переезжаем на несколько месяцев в страну и задницу с места там не поднимаем»

«Это называется Ньепи — четвёртый день местного НГ [День Тишины на Бали, в этот день запрещено выходить на улицу, включать свет и вообще проявлять признаки жизни]. Я попал на него в прошлом году, и у меня интернет не отключали. Свет тоже был, но включать его я не решился, т.к. сказали, что можно запросто получить за это кирпичом в окно. Если выйдешь на улицу, тебя поймает и отведёт в полицию специальный отряд печалангов (так они зовутся). В этом году инет отключали, но я свалил на соседний остров, чтобы не страдать»

* * *

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

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

«Проводить целый рабочий день за обычным кухонным столом, сидя на табуретке, — больно»

Другая насущная проблема: при работе из дома теряется ритм «пришёл в офис — работаю, ушёл — отдыхаю». Может быть сложно погрузиться в работу утром или, наоборот, переключиться на другие дела вечером.

«Не ожидал столкнуться с тем, что рабочий день может случайно и не закончиться. Как с утра сел — так ночью и отвалился от компа :D»

К тому же интенсивность работы на удалёнке часто бывает выше, чем в офисе — коллеги, понятно, не видят, что вы отошли или разговариваете с кем-то другим, решая срочный вопрос. Спасают статусы в Slack, менеджмент задач и много терпения.

«Бывает ли у вас в офисе, что с вами одномоментно говорят 5 человек с разных проектов по 5 разным вопросам, и ты обязан им одновременно отвечать, иначе они возмущаются, что ты их не слушаешь и вообще куда-то пропал? Скорее всего нет. А на удаленке это самый обычный рабочий день менеджера»

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

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

* * *

Итак, вы проявили мудрость — сидите дома, подготовили рабочее место, настроили инструменты и предвкушаете продуктивный день. Что же мы имеем? Ожидание: меньше стресса, знакомая обстановка, тишина, «дома и стены помогают». Реальность: хорошо бы на этих стенах обои переклеить, а ещё вот собака просится на улицу, а раз уж ты идёшь с собакой, то сходи-ка в магазин и на почту… Cосредоточиться будет тяжело. Особенно это касается тех, кто живёт не один. Безобидные вопросы, заботливые приглашения к завтраку/обеду/чаю и даже простой бытовой шум будут сбивать с толку и мешать концентрироваться. В тяжёлых случаях работа из дома может вообще не восприниматься домашними всерьёз.

«У меня мама очень переживала, что я в шараге какой-то работу нашёл. Частично успокоилась она только после того, как компания оплатила мне билеты на митап в Москву и когда трудовой договор привёз. И совершенно успокоилась, когда я ушёл в оплачиваемый отпуск»

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

«Поначалу было сложно не отвлекаться на котиков»

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

* * *

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

«Раньше я думал, это [работать удалённо] наверное слишком интровертно для меня, и я оказался прав. Большую часть рабочего дня я сижу дома или в кофейне, или иногда выползаю в коворкинг, и * БЛИН * я просто ужасно страдаю от одиночества. Это стало моей самой лютой проблемой на удаленке»

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

«Жить как интроверт круто только первые полгода. Потом ты постепенно теряешь человеческий вид»

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

«Вынести мусор может быть приключением, если всю неделю работаешь, не выходя из дома»

* * *

Так что же это, игра не стоит свеч? Безусловно, стоит. Просто нужно хорошо знать правила этой игры:

Отнеситесь к переходу на удалённую работу ответственно, взвесьте для себя все плюсы и минусы.
Самоорганизованность спасёт мир. По крайней мере, ваш внутренний.
Работа должна быть отделена от дома и личной жизни, даже если это в одном помещении и на одном компьютере.
Важно организовать качественное рабочее место. Нет, не на диване.
Не забывайте двигаться и выходить на свежий воздух.
Удивительно, но живое общение — важно. Если не хотите брать количеством, берите качеством.
Перемещаясь по миру, помните о трёх китах — интернет, розетка, тишина — и заранее продумывайте, где их найти.

Ну и напоследок простой, но дельный совет: если вы подумываете об удалёнке, попробуйте взять пару дней в неделю на текущей работе. Это очень многое расставит по своим местам.

// На самом деле у нас есть ещё много советов, но об этом в другой раз.

P.S. Коллеги периодически пишут полезные статьи про быт удалёнщика, не проходите мимо:

Полезные привычки для удалённой работы
Стимуляторы работы программиста: Обстановка, Мотивация, Здоровье
Правила общения удалённых разработчиков

Формальная и интуитивная семантика языка программирования на примерах JS и JSX

Sun, 26 May 2019 00:00:00 +0000

Эта статья — расширенная версия доклада на PiterJS tour#1.

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

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

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

Декларативность

Многие называют «декларативное» программирование панацеей понятности и читаемости, но так ли это на самом деле? Почему кто-то с этим согласен на все 100%, а кто-то совершенно не разделяет энтузиазма? Нужно разобраться.

Все, наверное, слышали, чем декларативное программирование отличается от императивного: декларативное описывает, что нужно сделать, а императивное — как это нужно сделать. Но говоря об этом, обязательно стоит помнить, что при декларациях того, что нужно сделать, идет оперирование какими-то существующими элементами, о которых мы знаем, как они работают (иначе наши декларации ничего бы не стоили). Декларативное программирование — это способ описания программы через набор верхнеуровневых инструкций, детали реализации и исполнения которых скрыты за исполнителем этих инструкций. Под исполнителем могут подразумеваться: функции высшего порядка (ramda, react, redux-saga), макросы (JSX) в случае кодогенерации, JIT компилятор в случае исполнения (синтаксис ЯП — языка программирования), машинные коды — декларативное описание логики переключения транзисторов процессора. Т.е. средство описания деклараций всегда имеет какой-то контекст, и «декларативность» означает не какой-то конкретный паттерн, а текущий уровень восприятия глубины абстракции разработчиком.

Например, классическим примером декларативного программирования является код в функциональном стиле:

array.filter(predicate)

А что можно сказать про такой код?

instruction = { type: 'filter', target: array, arguments: [predicate] }

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

Так же можно рассмотреть классический «императивный» код:

for (let i = 0; i < array.length; i++) {
  if (predicate(array[i])) result.push(array[i])
}

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

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

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

export const validateFormFields = state => {
  const displayedFields = selectFormFieldsNames(state)
    .map(name => selectFormField(state, name))
    .filter(isSystem);

  const arrayFields = displayedFields.filter(isArray);

  const emptyRequiredArraysErrors = arrayFields
    .filter(field => isArrayEmpty(field) && field.required)
    .map(field => selectFriendlyText(state, field.title, field.name));

  const arrayCellsErrors = arrayFields
    .filter(field => !isArrayEmpty(field) && isTable(field))
    .reduce((acc, field) => [...acc, ...validateArrayCells(state, field)], []);

  const notArrayFields = displayedFields.filter(field => !isArray(field));
  const notArrayFieldsErrors = notArrayFields
    .filter(field => field.required && isValueExist(field.value))
    .map(field => selectFriendlyText(state, field.title, field.name));

  return [
    ...notArrayFieldsErrors,
    ...emptyRequiredArraysErrors,
    ...arrayCellsErrors
  ];
};

function validateFormFields(state) {
  const fieldsNames = selectFormFieldsNames(state);
  const result = [];

  for (let i = 0; i < fieldsNames.length; i++) {
    const field = selectFormField(state, fieldsNames[i]);

    if (isSystem(field)) continue;

    if (!isArray(field) && field.required && isValueExist(field.value))
      result.push(selectFriendlyText(state, field.title, field.name));

    if (!isArray(field)) continue;

    if (isArrayEmpty(field) && field.required)
      result.push(selectFriendlyText(state, field.title, field.name));

    if (!isArrayEmpty(field) && isTable(field))
      result.push(...validateArrayCells(state, field));
  }

  return result;
}

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

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

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

P.S. Код был в итоге переписан в функциональном стиле, но с вынесением определенной логики в отдельные функции.

Семантика

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

Явность кода — это не про code style в плане визуального форматирования и именования переменных. Явность кода зависит от множества контекстов — это про микро и макро архитектуру всего приложения и принятых стандартов написания кода. Можно ли обобщить? И тут я подумал: что объединяет все языки программирования? То, что это языки программирования.

Язык в общем и язык программирования в частности — это синтаксис и семантика. Две ключевых составляющих, которые определяют, что такое язык, как им пользоваться и выражать на нём свои мысли. И если с синтаксисом всё более менее понятно, то что такое семантика можно долго и упорно (не) понимать, хотя я догадывался, что все ответы на вопросы явности кода — в ней.

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

Си́нтаксис (др.-греч. σύν-ταξις — составление) — раздел лингвистики, изучающий строение и функциональное взаимодействие различных частей речи в предложениях, словосочетаниях и пр. языковых единицах.

Сема́нтика (от др.-греч. σημαντικός «обозначающий») — раздел лингвистики, изучающий смысловое значение единиц языка.

Семантика отвечает за смысловое значение — ясность выражения мысли.

Ну вот определения, ну вот они что-то описывают — но что это в действительности значит, и как это можно использовать? Всё понимается проще на аналогиях, и можно попытаться найти их для определения синтаксиса и семантики применительно к ЯП. Мне нравится такая: если синтаксис — это какой-то инструмент, то семантика — это правила пользования инструментом.

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

Эволюция ЯП в улучшении абстракций: машинные коды, переменные (ассемблер), процедуры и условные переходы (Фортран), структуры (Алгол 68, Паскаль), ООП, функции высшего порядка и развитые системы типов. Сейчас мы, программисты, пользуемся этим, зачастую не задумываясь, как работают языки высокого уровня, какая история за ними стоит и почему они именно такие, какие есть. Но интересно, что сам принцип ЭВМ в процессе развития языков не менялся.

Вычислительная машина — это большой конечный автомат, точнее, конечный преобразователь (трансдьюсер). Её инструкции — набор переходов. Человеку сложно оперировать такими понятиями, особенно в большой программе, он в принципе мыслит иначе и для быстрого понимания чего-то часто применяет интуицию и абстракции, обобщая логику описания поведения (программы). Мостом же между инструкциями для вычислительной машины и человеком выступает интерфейс, который называется языком программирования. Вообще при написании кода и выражении задачи в виде набора операторов всё, что происходит — это перебор возможных вариантов работы с возможными данными, попытка описать строго формальным языком какую-то абстракцию — бизнес-задачу. И этот процесс (и код, в частности) очень похож на формальное математическое доказательство — бескомпромиссное, чёткое выведение верного решения. Эта похожесть называется «Соответствие Карри — Ховарда». Но отличие математического доказательства от написания программы заключается в том, что логика построения программы в первую очередь строится не на формальных доказательствах, а на интуитивных умозаключениях программиста, которые он уже пытается наложить на формальные правила ЯП. Потому что каждую задачу можно описать по-разному. Это, в частности, зависит и от личного представления программиста о задаче, от его привычек и способа мышления, знаний и умения использовать то или иное API языка, библиотек, фреймворков. Но как соотнести абстрактное представление программиста о задаче с чётким и формальным алгоритмом, можно ли формализовать это соотношение? Есть ли какое-то правило, функция, которая описывает и представляет разницу между индивидуальным кодом программиста и формальным необходимым результатом? Вот это как раз и называется семантика.

Синтаксис — для парсинга AST и построения структуры программы

Семантика — для понимания программы компилятором и интерпретатором

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

Прикладные примеры

`null` VS `undefined`

null — это намеренно пустое значение, undefined — это неопределённое значение или, актуально для JS, неожиданно пустое значение.

С интуитивной точки зрения и null, и undefined означают пустое значение и имеют одно и тоже поведение, но с точки зрения формальной семантики это разные конструкции, что проявляется в мелочах. Например, если выражение obj.prop === null верно, можно быть уверенным, что свойство prop есть в объекте, но его значение пусто. Но если выражение obj.prop === undefined верно, то нет никаких гарантий, что свойство prop вообще есть в объекте, из этого ясно лишь то, что значение этого свойства отсутствует. И это наглядный пример, когда интуитивная и формальная семантика разные: первая рассказывает о проверке свойства и значения в объекте, вторая проверяет только значение. Для тех, кто работает с JS давно, это может быть очевидным, но в общем и целом, если я пишу код, в котором есть обращение к свойству, я ожидаю работу со значением этого свойства и не ожидаю, что этого свойства может не быть вовсе. Для проверки наличия свойства я буду использовать оператор in или метод hasOwnProperty — это более явно говорит о том, что делает код.

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

Cсылочная прозрачность

// [1]
setTimeout(f, time, prop)
// [2]
setTimeout(() => f(prop), time)

Два небольших сниппета кода, приведённых выше, с точки зрения интуитивной семантики, постановки задачи, одинаковые — нужно через какое-то время выполнить колбэк f. Однако фактически они различаются, и интересно, на что это может повлиять. Строго говоря, у второго варианта отсутствует ссылочная прозрачность: колбэк, который будет выполнен, зависит от переменной prop, которая может быть изменена после инициализации таймаута, но до выполнения колбэка. В первом варианте это невозможно, т.к. аргумент передаётся по ссылке, а не через переменную замыкания. Это очень хороший пример того, как различия в интуитивной и формальной семантике могут ненамеренно привести к неожиданному поведению и ошибке.

Тонкости спецификации

// [1]
console.log({ '2': null, ...({ '1': null, '2': null }) })
// [2]
console.log({ '2.0': null, ...({ '1.0': null, '2.0': null }) })

С первого взгляда может показаться, что это очень похожий код, результаты которого тоже будет похожи. Но, согласно спецификации, сортировка свойств объекта имеет некоторые особенности, поэтому в первом случае результат будет {1: null, 2: null}, а во втором {2.0: null, 1.0: null} — первыми свойствами всегда идут валидные индексы. Как можно заметить, во втором варианте порядок свойств поменялся. Эта логика не интуитивна и описывается в дебрях спецификации ЯП — формальной семантикой.

Паттерн «заместитель»

// [1]
function include(array, target) {
  for (let i = 0; i < array.length; i++) {
    if (array[i] === target) return true;
  }
  return false;
}
// [2]
function include(array, target) {
  for (const element of array) {
    if (element === target) return true;
  }
  return false;
}

Вот ещё похожий код. Интересный вопрос: какая у него может быть разница в производительности и почему? Продвинутые знания ЯП о работе итераторов могут подсказать, что for of должен быть немного медленнее, но здесь скрывается ещё одна хитрая проблема.

Proxy, get и set реализуют паттерн «заместитель», при котором возможно перехватить обращение к свойствам целевого объекта для выполнения какой-то дополнительной логики. Проблема этого паттерна в том, что он воздействует на поведение программы, но это воздействие никак не отражается визуально. Т.е., говоря о формальной семантике: в этом паттерне она вообще никак не отображается, соответственно, не сходится с интуитивной семантикой.

Если сравнить код 1 и 2, то станет понятно, что с функциональной точки зрения разницы в нём нет, но если array будет обёрнут в прокси, то каждый вызов array[i] будет «утяжелён» перехватчиком, поэтому у этого, казалось бы, одинакового кода может быть заметная разница в производительности в пользу варианта с for of (там перехватчик отработает лишь один раз на Symbol.iterator).

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

JSX vs JS

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

<Component />
// babel ->
React.createElement(Component, null)

JSX с точки зрения интуитивной семантики — вёрстка, он отвечает за то, что будет отображаться, а не как, потому что его задача именно в инкапсуляции логики document.createElement (формальной семантики). И на этом примере можно понять, что хорошая декларативность / метапрограммирование — это когда фактической разницы в результате работы кода с точки зрения интуитивной и формальной семантики нет. Но возвращаясь к JSX: он, как и результат самого HTML, всегда должен быть статичен, независимо от данных. В подтверждение этому выступает API хуков жизненного цикла в классах или хуков в функциональных компонентах — они описываются в JS, до блока с JSX, это наглядно.

import { Switch, Route, Redirect } from 'react-router'

<Switch>
  <Route exact path="/" component={Home} />
  <Route path="/about" component={About} />
  <Redirect to="/" />
</Switch>

Например, react-router является примером очень плохого API, т.к. через компонент <Switch> он предлагает описывать логику зависимостей от данных прямо в JSX, более того, сам элемент превращается в управляющий блок. При этом классическая семантика полностью рушится, что ведет к ментальному усложнению чтения кода — в JSX может быть спрятана не только вёрстка, и его уже нужно читать вдумчивее, в голове нужно держать больше контекста. Правильнее в JS в начале блока функционального компонента или метода render описывать все зависимости, высчитывать их и потом в конечный возвращаемый JSX вставлять всё необходимое. Это и есть декларативное описание.

title = predicate ? 'first' : 'second';
return <span>{title}</span>

Желание описать роутинг или что угодно ещё (есть даже библиотека с компонентами <If>, <For>) декларативно — понятно, т.к. это кажется нагляднее и проще (хотя не всё так просто, потому что пониманиеАбстракции = время(документация)). Но нужно понимать, что декларативное описание не обязано иметь единственный синтаксис/шаблон. JSX — это декларативный синтаксис к описанию биндинга модели приложения на DOM, и это означает, что его не нужно использовать для декларативного описания конструкций, которые не относятся к DOM напрямую. Для написания декларативного кода можно использовать, например, библиотеку Ramda, писать макросы и много другое.

Также react-router нарушает принцип SSoT, если в приложении имеется глобальный стейт-менеджер. Из-за этого компоненты, использующие и роутер, и стор, часто имеют какие-то костыли или выступают мостом между двумя стейтами. Хорошим решением было бы использовать роутинг через глобальный стор.

{
  render(){
    return (
      <div>
        {this.renderHeader()}
        {this.renderError()}
        {this.renderList()}
      </div>
    )
  }
}

Есть подход «рендерМетодов», который подразумевает вынесение каких-то логических частей JSX в отдельные методы. Но проблема заключается в том, что связанность такого кода сильно увеличена из-за разброса props и отсутствия этих методов в react-devtools (отображается просто портянка JSX, непонятно откуда взявшаяся).

{
  render(){
    return (
      <div>
        <Header />
        <Error />
        <List />
      </div>
    )
  }
}

Чтобы избежать проблем с «рендерМетодами», достаточно вынести их тело в отдельные компоненты. При этом их проще будет отследить в react-devtools, а некоторые зависимости класса, которые получаются из контекста, скорее всего, получится перенести в новые дочерние компоненты и разгрузить таким образом связанность в родительском компоненте.

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

Render Props через children тоже подходит как явный пример антипаттерна семантики. Да, сам подход хорошо решает технические проблемы, но сильно ухудшает читаемость кода, нарушая принципы ответственности JSX. Решением может быть использование сведе’ния render-props.

Плохие советы по render-props дают даже на популярном ресурсе css-tricks:

const App = () => {
  return (
    <Wrapper link="https://jsonplaceholder.typicode.com/users">
      {({ list, isLoading, error }) => (
        <div>
          <h2>Random Users</h2>
          {error ? <p>{error.message}</p> : null}
          {isLoading ? (
            <h2>Loading...</h2>
          ) : (
            <ul>{list.map(user => <li key={user.id}>{user.name}</li>)}</ul>
          )}
        </div>
      )}
    <Wrapper/>
  );
}

Приведённый код выглядит как каша: JSX и JS сильно смешаны, очень сложно разобрать саму вёрстку.

Можно попробовать не использовать JSX для контейнеров. Интересно, что тогда код больше похож на использование хуков:

const App = () => {
  return React.createElement(
    Wrapper,
    { link: "https://jsonplaceholder.typicode.com/users" },
    ({ list, isLoading, error }) => {
      const errorView = error && <p>{error.message}</p>
      const listView = list.map(user => <li key={user.id}>{user.name}</li>)
      const bodyView = isLoading ? <h2>Loading...</h2> : <ul>{listView}</ul>

      return (
        <div>
          <h2>Random Users</h2>
          {errorView}
          {bodyView}
        </div>
      )
    }
  )
}

Во втором примере errorView и bodyView проще вынести в отдельные компоненты и уменьшить связанность.

Показательным примером важности семантики расстановки блоков кода являются новые хуки в React.js:

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

Вывод

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

В читаемом и понятном коде нет разницы между интуитивной и формальной семантикой

На этом всё, но я буду продолжать исследовать семантику в ЯП и связанные с ней вещи в поисках универсальных правил явности и кодочитаемости. Если у вас будут какие-то предложения — оставляйте комментарии или пишите мне в Телеграм (@artalar)

Полезные материалы

Презентация
Университетская лекция «Языки программирования, синтаксис, семантика, прагматика»
Что такое зацепленность
Что такое соответствие Карри — Ховарда
Практические советы по качеству кода
Разница классов и хуков в React.js
Доклад «Краткий пересказ утерянных глав руководства по фронтенду»
Доклад по этой статье

Мнение редактора, сотрудников компании и ваше может не совпадать с авторским, но в этом ведь и смысл дискуссионных статей ¯ \_(ツ)_/¯

Стимуляторы работы программиста. Здоровье

Tue, 07 May 2019 00:00:00 +0000

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

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

Глава 3. Здоровье

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

* * *

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

Посмотрите на жителей тех стран, где лечение стоит баснословно дорого. Где все жители по утрам? Правильно, на пробежке. Лично я не призываю бегать, я люблю ходить. Я хожу очень много и на большие расстояния. Хоть я и работаю дома, но хожу в дальние магазины, провожаю жену на работу, выдумываю дела в другом конце района. Как мотивировать себя много ходить? Расскажу, как приучал меня к этому папа. Когда я был маленьким и не умел читать, папа рассказывал нам с сестрой разные истории из книг. Длинные истории, содержательные, увлекательные. Но у него был один простой принцип: идём по улице — рассказывает, пришли в помещение — замолкает. Мы с сестрой искали любой повод пойти с папой куда угодно.

Сейчас, чтобы не скучно было ходить, всегда беру с собой наушники. На YouTube у меня есть плейлист «Поход», куда я складываю все ролики, которые собираюсь послушать во время пеших походов. Поверьте, этот плейлист приходится постоянно пополнять, ведь я хожу минимум час в день. А другие потребляют и больше аудио-видео контента, но при этом сидят на стульях или лежат на диванах, сажая зрение, портя спину, тратя мыслетопливо впустую. Лучше прогуляйтесь, не пожалеете.

Для плохой погоды у меня есть беговая дорожка. Бегать на ней я, конечно же, не люблю. Ходить могу. Но тоже не очень люблю. Распространённая ошибка — думать, что дорожка сама вас замотивирует, как только вы её купите. Но на ней можно смотреть фильмы или ролики подлиннее и таким образом растягивать «удовольствие».

* * *

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

Лично мне хватает 15-20 минут дневного сна, чтобы потом до самого позднего вечера чувствовать себя продуктивным. Даже если вы работаете в офисе, можно найти возможность поспать — я, например, бегал спать в машину. Бросайте отговорки, спите. Только знайте, что 30-40 минут дневного сна работают уже против вас — это связано с чередованием фаз сна. Бодрости такой перерыв не прибавит, мыслетоплива тоже.

Если вы не можете позволить себе сиесту днём (зря, конечно), делайте между завтраком и обедом 1-2 перекуса, чтобы за счёт этого сократить объём потребляемой в обед пищи. Ещё один из универсальных приёмов уменьшения размера обеда — плотный завтрак, основанный на «долгих» углеводах. Обратите внимание и на другие факторы, которые влияют на прожорливость в вашем случае. Может быть, вы погружаетесь в соцсети, не замечая, сколько съедаете, а может быть, не сразу чувствуете насыщение? Всё это, конечно, индивидуально, поэтому поэкспериментируйте над собой и на практике подберите оптимальный режим.

Ну и немаловажно: кушайте полезную еду. Узнавайте, какая еда полезная. Редко едите яблоки? Утром разрежьте яблоко и положите в прозрачном контейнере возле рабочего места. Ну и помните, что лёгкие стадии рахита, цинги, авитаминоза, хрупкости костей, ожирения, болезни печени — всё это сопровождает не только мореплавателей, но и производителей ПО для мореплавателей, если они не питаются разнообразно и полезно.

Старайтесь есть в одно и то же время, не используйте как напоминание, что пора перекусить, ваших коллег и, тем более, функцию Math.random(). Если вы питаетесь нерегулярно, то организм успевает проголодаться, почувствовать нехватку глюкозы и других питательных веществ, и срабатывает система защиты — она будет заставлять вас съесть больше, чтобы накопить запасы. Регулярные обеды позволят вам войти в режим и ввести в режим коллег, которые подсознательно привыкнут, что все вопросы вам нужно задавать до определённого времени. Кроме того, сделав перерыв на обед, вы отвлечётесь, а все ваши задачи при этом продвинутся, так как мозг в фоновом режиме будет продолжать решать все зависшие вопросы и укладывать информацию в голове. Вспомните, как после обеда вы стирали или переписывали весь код, который писали всё утро. Запой вреден, в том числе в работе.

Да, о запоях. Очень многие программисты пьют во время работы. Чай, кофе, газировку, воду и другие напитки. Поговорим об этом. Лично я работаю по системе Pomodoro, и на каждую «помидорку», которая в моём нестандартном случае длится 52 минуты (20 минут перерыв), мне нужна большая кружка жидкости. Эту кружку я выпиваю, не замечая. Привычка, выработанная годами.

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

* * *

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

Так вот, вернёмся к кофе. Горячая тема в среде любых много работающих людей. Кофе в долгосрочной перспективе, как и большинство стимуляторов, не даёт энергетического преимущества в производительности. Тут как с кредитом — вы получаете производительность здесь и сейчас, но потом вам хочется спать, и, чтобы продолжать жить в этом состоянии, вам нужно снова выпить кофе, при этом ваш долг будет расти. В придачу, абсолютно бесплатно, ваш организм получает зависимость и необходимость повышать дозу. Зависимость даже обсуждать не буду, почитайте в других местах, но кофе, выпитый после 15:00, может влиять на сон. А сон — это наше всё.

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

Удивляюсь, как мало людей знает о самом древнем стимуляторе производительности. Китайский чай. Запомните слово Пуэр. Найдите чайный магазин, купите маленький кусочек от чайного «блина». Попросите закинуть вам побольше задач в бэклог, заварите этот чёрный напиток — уверяю, вас ждёт сюрприз. Одна чашечка Пуэра даёт мне эффект чашки кофе, но растянутый до самого вечера и, о чудо, не влияет на сон. Больше о китайском чае я ничего не скажу, чтобы не спугнуть ваше промелькнувшее желание попробовать.

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

* * *

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

Многие программисты работают без свежего воздуха. Если у вас часто болит голова, вам душно, есть сонливость, ничего не хочется — это может быть признаком кислородного голодания. И если вы думаете, что открыв окно, вы это голодание прекратите, то ошибаетесь. Воздух в комнате должен обновляться дважды в час, это минимум. Должна быть приточная и вытяжная вентиляция. Если вы дышите, но не двигаетесь, то организм не насыщается кислородом. Вспоминаем систему Pomodoro и во время 5-15 минутных перерывов открываем окна, не забывая открыть дверь в комнату.

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

* * *

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

Уже знаете, что такое туннельный синдром (надеюсь, не на своём опыте)? Это когда любое движение рукой — провести по пальцами по тачпаду, нажать кнопку на клавиатуре, подвинуть мышку — отдаётся болью, и боль с каждым днём всё сильнее и сильнее. В принципе, это одна из немногих профессиональных болезней программистов, о которой задумываются, когда уже поздно. О какой производительности может идти речь, когда вы в состоянии набирать текст на клавиатуре только одним пальцем? Да, у меня тоже был туннельный синдром. Как я его победил? Вот список мер: Стал пользоваться трекпадом с подставкой для запястья, чтобы рука не висела в воздухе. Клавиатуры использую или slim, где запястье лежит на столе, или с подставкой. Научился пользоваться левой рукой для трекпада, теперь одинаково хорошо управляюсь, ломка была лишь одну неделю. Люблю повисеть на турнике. Предпочитаю помогать коллегам не при помощи чата, а при помощи созвона с расшаренным экраном, времени уходит меньше, а клавиатура вообще не требуется — многие недооценивают, сколько текста они набирают в чатах. К сожалению, ресурс наших суставов не бесконечный. Делаю регулярные перерывы. Чтобы не сдавливать локтевой сустав, подкладываю подушечки под локти или пользуюсь мягкими подлокотниками стола. Слежу, чтобы во время сна не лежать на руке. Выучил горячие клавиши, изучил vim раскладку и активно ей пользуюсь. Ну и всё-таки ходите к врачам: не превращайте себя в кота Шрёдингера, добавьте наблюдателя.

Резюмирую: чередуйте работу и отдых, разумно питайтесь, занимайтесь физическим трудом, много ходите, проветривайте комнату, не пренебрегайте диспансеризацией — и у вас впереди будет много счастливых человеко-часов за компьютером, и большинство из них будут оплачены деньгами, опытом, удовольствием, а не здоровьем.

Стимуляторы работы программиста. Мотивация

Mon, 18 Mar 2019 00:00:00 +0000

Итак, вы обставили свой домашний офис, выбрали клавиатуру, настроили высоту кресла, поставили фотку любимого кота на рабочий стол (ещё нет? Тогда вам сюда: Глава 1. Обстановка). Пора приступать к работе. Но… не хочется!

Глава 2. Мотивация

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

* * *

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

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

Но суровая реальность такова, что, несмотря на корону, никто не обязан давать вам только интересные задачи. Скучные проекты не означают, что руководство вас особенно не любит. Просто то, что интересно другим, не всегда интересно вам, и наоборот. Все люди разные.

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

Как унылую задачу сделать интересной? Для запоминания скучной информации, вроде списка покупок, часто используют мнемонические приёмы (например, придумывают смешные образы, ассоциирующиеся с тем, что нужно запомнить). Но что делать с полноценной задачей? Ответ: рассмотреть её повнимательнее, оценить опыт, который можно получить, выбрать другой способ выполнения, чтобы превратить её из скучной в увлекательную. Вам дали задачу оцифровать целую тонну xls файлов и превратить в таблицы БД с вложенностью, а сделать это больше некому? Напишите автоимпорт с ручным принятием решения там, где программа затрудняется с ответом. И, чтобы снизить градус нудности задачи, всю редактуру текста делайте в vim, попутно изучая его горячие клавиши. Научитесь хитрить.

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

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

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

* * *

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

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

Как ещё помочь себе войти в состояние потока? Вспомните фильм «Начало». Используйте триггер. Я люблю один простой приём: включать определённую музыку только во время работы. У меня есть плейлист, который я прослушал уже более тысячи раз. Если начал отвлекаться — открыл новостной сайт, социальные сети или приступил к чтению книги — выключаю плейлист. Должен вырабатываться рефлекс: конкретная музыка = работа. Можно придумать и другой ритуал, который поможет вам включиться в процесс.

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

* * *

Для организации рабочих интервалов есть различные техники, например «Pomodoro». Это когда вы заводите будильник на 25 или 52 минуты (или другой индивидуально подобранный промежуток). А после того, как он прозвонил, сбегаете с рабочего места отдохнуть. Отдых длится, соответственно, 5 или 17 минут. Во время перерыва у вас тоже тикает таймер, чтобы не появилось соблазна удлинить отдых. Лично у меня в это время идет процесс обдумывания прошлой «помидорки», и после перерыва я зачастую или переписываю, или вообще удаляю код, который написал, не подумав.

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

Техника Pomodoro помогает не отвлекаться. Вы отключаете все уведомления, кроме самых важных, и предупреждаете коллег, что работаете по этой системе. Тогда все сообщения будут накапливаться и вы сможете перед окончанием «помидорки» просмотреть уведомления и начать на них отвечать. Как проверить, нужно ли вам отключать уведомления? Если по выходным, рано утром или поздно вечером, когда все ушли с работы и не отвлекают, вам работается лучше и вы успеваете за эти пару часов сделать больше, чем за весь день — бинго. 25 минут без вас спокойно обойдутся, поэтому заводите таймер.

Человек многозадачен лишь в теории, он как JavaScript в браузере. Кажется, что можно выполнять задачу и смотреть фильм в фоне. На самом же деле, мозг будет постоянно переключаться между фильмом и программированием, а потом ты удивляешься, как так вымотался, делая простейшую задачу. Делайте одно дело за раз, а остальные забывайте, а лучше записывайте.

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

Опять же, возьмите большой фонарик и осветите преступника «уведомление». Он вас отвлекает. Он вам мешает. Он поглощает всё ваше внимание. Вы превращаетесь в short messages поколение. Всё это незаметно, по грамму, по десять тратит ваше внимание.

Я люблю представлять, что вся моя мотивация, желание работать, действовать, думать, читать — это «мыслетопливо» (ёмкий термин, который ввёл Максим Дорофеев в книге Джедайские техники»). Работая, ты его тратишь. Отдыхая — накапливаешь. Многие думают, что, когда они прокрастинируют, мыслетопливо накапливается. На самом деле, оно только тратится на все те мелкие дела, которые выдумывает прокрастинирующий. Сесть на диван, закрыть глаза и ничего не делать — вот это верный путь накопления. Вся идея мыслетоплива в том, что нужно уметь анализировать себя и понимать, что конкретно в вашем случае его потребляет, а что производит. И постарайтесь расходовать его продуктивно. Доставайте большой фонарь и освещайте все свои попытки потратить энергию на всякую ерунду.

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

Стимуляторы работы программиста. Обстановка

Thu, 28 Feb 2019 00:00:00 +0000

Все хотят написать гениальный код на одном дыхании и после рабочего дня удовлетворенно смотреть на уменьшившийся список задач. Но у одних это получается регулярно, у других только пока Луна в Козероге, а у кого-то практически никогда. Как же себе помочь?

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

Глава 1. Обстановка

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

Как я себе представляю программирование большой сложной системы: ты в голове выстраиваешь из хрустальных игральных карт дворец, учитываешь все коммуникации, удобство интерфейсов, просчитываешь вес конструкции, делаешь запас прочности, стараешься не забыть про все требования, пытаешься интегрироваться с чужим полцарством… Так, стоп, кувалдой в центральную башню — Бах! — Пусть осколки тут полежат, потом соберёшь, что случилось? А это всего лишь короткий вопрос от семейства: «Кушать будешь?», а для тех, кто работает в офисе, сообщение: «Молоко, яйца, хлеб и вкусненькое». Про то, как бороться с отвлечением, мы ещё поговорим в дальнейших статьях, а сейчас — о самой обстановке.

* * *

Многие успешные стартапы начинались в гараже. В гараже много хлама, помещение не похоже на офис, а чтобы начать работу, приходится выгонять автомобиль. Вместо стола — доски, зимой холодно, летом жарко. Обстановка вроде бы не способствует созданию шедевров… Ан нет, я всё же думаю, что именно гараж, в немалой степени, идеальный образ офиса для многих. В нём нет близких, которые отвлекают, зовут покушать, заходят задать якобы не сильно отвлекающий вопрос: «Ты просто скажи — да или нет». При отключенных мессенджерах даже летящий к гаражу метеорит не сможет вас отвлечь от процесса создания универсальной модалки.

«Подожди, парень, — скажете вы, — то были другие времена. Вот давай мы тебя сейчас посадим за самый дешёвый ноутбук Acer с TFT экраном с разрешением 1024 пикселей и заставим собирать при помощи webpack тяжёлый проект — как ты запоёшь? Какая будет производительность? Давай мы ещё тебя посадим на табурет, вместо стола будет пара картонных коробок, а позади тебя рабочие будут усердно грузить чеснок». «Сложно будет», — отвечу я. Но нормальный программист должен воспринимать такие условия как хороший повод потренировать свою помехозащищённость. Профи могут выйти с такого ноутбука в облако, настроить там среду разработки и комфортно работать, попутно обучившись новому навыку настройки серверов.

Ок, палку не перегибаем, в крайности не впадаем. На картоне не работаем, Windows 95 не используем, неудобные стулья, мышки, клавиатуры обходим стороной. Пока вы ещё джуниор и не имеете большого стажа сидения за компьютером, ваш организм не подаёт сигналов. Чуть позже от коллег, из статей, а, не дай Бог, и от своих кистей или поясницы вы услышите: «Друг, купил бы ты хороших инструментов, а то мы скоро тебе покажем прелести остеохондроза, туннельного синдрома и прочих радостей, которые при определённой настойчивости могут сделать тебя инвалидом!»

* * *

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

Всё это я организовал у себя на балконе с тройным зеркальным остеклением, кондиционером и теплым полом. Главный плюс балкона — полная изоляция от квартиры. Я могу слушать музыку без наушников, никому не мешая, и мне, в свою очередь, тоже никто не мешает. Можно сказать, это такой современный аналог гаража в российской действительности. Главный минус — внутренний резко континентальный климат: солнце может превратить балкон в 40-градусную теплицу (даже ноутбук чуть вздулся от жары). Поэтому задумывать балкон как постоянный кабинет означает запланировать приобретение кондиционера.

Один из самых актуальных вопросов — мониторы. Сколько их должно быть? Какого размера? Может, хватит экрана ноутбука? Как это влияет на производительность? Путём долгих экспериментов я выяснил, что если у вас достаточно большой монитор, то производительность при добавлении ещё одного монитора может и упасть. Ведь есть вероятность, что вы расположите там чат или будете тратить время на дирижирование окнами. Кстати, отвлекитесь, поставьте менеджер окон, который умеет двигать окна горячими клавишами. Вы никогда не ставили запись своего экрана и не смотрели таймлапсом за своей работой? Попробуйте, вы удивитесь и сделаете полезные выводы. Так сколько мониторов нужно для высокой производительности? Ответ: не меньше одного. Дальше уже вопрос практики и личных предпочтений. Лично я обожаю повернутый на 90 градусов экран — почти все статьи, сайты, код, чаты, да практически всё, кроме видео, удобнее смотреть на таком экране. Скроллинг почти не нужен, и глаза находят информацию мгновенно.

Что ещё помогает мне каждый день? Механическая клавиатура Leopold на topre клавишах. Беспроводной трекбол — спасение от профболезней программистов. Apple-наушники с микрофоном.

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

* * *

Ну вот, неплохое рабочее место мы устроили, но, может быть, что-то забыли и его можно сделать ещё лучше? Тут, главное, не впадать в крайности. Организовывая своё рабочее место, очень многие попадают в западню, которую я называю инструментальная прокрастинация. Если вместо того, чтобы доделать модалку для Джарвиса, вам захотелось подвигать стул, отрегулировать стол, закрыть окно, протереть клавиатуру, поменять разрешение монитора или добавить новый — поздравляю! Вы сейчас инструментально прокрастинируете.

Стол, стул, большое количество мониторов, лучшая в мире клавиатура, мышка с трекпадом, рядом беговая дорожка, массажное кресло, доставка еды по расписанию, кресло-мешок, переговорка и спортзал, где можно вздремнуть, отдельный кабинет, коллеги, с которыми можно посоветоваться… Многие думают, что именно этого не хватает, чтобы быть производительным: «Вот сейчас у меня этого всего нет, поэтому я отложу сложную задачу с развитием своего домашнего проекта, так как не хватает ни времени, ни обстановки. Да и спал я не очень, так что завтра…» Но западня как раз в том, что чем больше у вас будет денег, тем больше вы будете инструментально прокрастинировать. Вы будете сливать все ваши доходы на эксперименты, вы будете улучшать ваше рабочее место. Вы будете доводить его до идеала, а производительность будет вырастать только на недельку-две, а потом снова падать.

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

Для меня однажды было откровением, что задача программиста не всегда будет интересной. Язык, на котором нужно написать код, не должен быть хорошим. Фреймворк, который выбрал заказчик, не обязан быть модным. Хороший программист при наличии альтернатив, конечно, выбирает оптимальные инструменты, но он должен уметь выполнить свою задачу и при «военном положении». Нужно уметь захотеть выполнить задачу. Как захотеть? Ответ в следующей главе «Мотивация».

Итоги 2018 от CSSSR

Sun, 16 Dec 2018 00:00:00 +0000

Здравствуйте! В 2016 я уже подводил итоги, но тогда у нас в CSSSR не было своего радио и широко охватить события минувшего года не представлялось возможным. В этом году у нас вышли «Новости 512», и вы наверняка уже слушали предновогодний спецвыпуск (если нет, то вот он), в котором Ислам рассказал о самых знаковых событиях года. Сегодня я расскажу о том, что не вошло в итоговый хит-парад «Новостей» в силу самых разных обстоятельств, но о чём всё же стоит упомянуть.

В целом статья будет выдержана в несколько постироничном, декадентском характере. Многие события года были не совсем позитивными. Скорее противоречивыми. Но, как говорит Никита Прокопов: «Иногда на пасмурном небосводе просвечивают лучики надежды». Да, кстати, со статьи Никиты я и начну.

Осторожно! Присутствует ненормативная лексика. 18+

«Нынешняя ситуация — полное дерьмо»

В очередной раз GitKraken чуть не спалил мне ноут. В очередной раз прогон jest чуть не спалил мне ноут. Мой ноут легонько потрескивает на Ведьмаке 3, но намертво зависает, если открыть WebStorm, Atom или большую репу в кракене. Это вообще законно?

cd csssr.blog
mkdir article
cd article
touch why-is-modern-software-such-a-shit.md

Почему современный софт такое дерьмо? Это не только фронтенда касается, а софта вообще. Интерфейс PS4 — это череда загрузочных экранов и тупящих анимаций. На сайте PS Store форма оплаты работает через раз. Форма оплаты, Карл! Тачбар на макбуке зависает, пока меняешь ползунок громкости. В общем, я хотел излить своё негодование на головы читателей, но Никита меня опередил. Оригинал тут. Тысячи комментов и ретвитов — значит, не только у меня «пригорело», значит, сообществу не всё равно.

Бета luna-lang

— А если бы кто-нибудь умер? Если бы взорвался макбук прямо в Старбаксе?

— Я просто хотел быть как вы.

— Ты должен быть лучше. Верни мне костюм.

— Но я никто без костюма!

— Если без него ты никто — ты его не достоин!

Luna — это функциональный язык програмирования, главной «фишкой» которого является возможность рисовать или чертить программы. Этакая школьная доска «на стероидах». Без шуток, вы можете моделировать компоненты и буквально рисовать связи и способы передачи данных между ними. Почти как Тони Старк в своей лаборатории. Компоненты в Luna представляют собой вложенные графы потоков данных. Благодаря этому можно перемещаться между различными уровнями абстракций: от визуальной части к побитовым операциям внутри компонента.

Выглядит это всё, конечно, сногсшибательно, но есть одна проблема. Это «костюм» Luna, его визуальная часть, невероятно разогревающая компьютерное железо. Отдельного упоминания заслуживает лендинг Lunа, отправляющий макбуки в глубокий термотроттлинг. Печально, но без «костюма» перспективы у языка весьма и весьма призрачные.

UPD: На момент написания статьи (середина декабря) лендинг всё же отрефакторили, уже без термотроттлинга.

Перспективный стейт-менеджмент

XXX: я вот чо узнал в этом году и мне прям понравилось https://github.com/zerobias/effector

YYY: И чому оно замена редаксу?

XXX: это не замена редаксу, это лучше

YYY: Документация конечно огонь тут, всё понятно [САРКАЗМ] Надо понять, чому оно лучше

XXX: потому что это продвинутый инструментарий для работы с шиной событий типа вот редакс зачастую прост не нужен, т.к. query там реализован на одном сторе, который отслеживается целиком а тут query это просто чтение из конкретного места change-detection и не нужен command тут вообще огонь, это просто функция которая файрит событие по сути как в редаксе но есть эффекты и домены прям простор для фантазии то какой

YYY: Ну вроде годится, я как раз такие непопулярные экземпляры собираю

XXX: ну и так как там ваще говоря по большому счёту шина событий, то прикрутить продвинутые сторы ваще как делать нечего типа mobx

YYY: А раньше подобной либы не было? Это революционная идея что ли? Чому в редаксе так не сделают?

XXX: так было во флаксе по сути mobx можно так организовать

YYY: Так это изобретение флакса?

XXX: не, ну домены, эффекты и тд чувак сам придумал но общая концепция могла увидеть свет и во флаксе просто сделано заебись, хочется пользоваться

YYY: Да бля, как ты понял?((( ни доки, ничего нет

XXX: ну посмотрел)))
вообще штука сырая и не прод реди

Примерно такой диалог состоялся у меня в этом году (авторская орфография и пунктуация сохранены). TLDR: вот ссылка на либу, которая, предположительно, воплощает в себе концепцию реактивного флакса и продвинутого стейт-менеджмента. Уйдут ли эти идеи в массовый прод — подскажет статистика: 123 звезды на гитхибе и 0 PR’ов.

SSR не нужен!

И CRITICAL_CSS тоже. И rel=”preload”. И чанки. И бандлы. В список можно докинуть ещё техник, «прокачивающих» загрузку первого экрана. В твите факты, указывающие на такие перемены.

Every website in 2018 pic.twitter.com/Gm7jhfuuUO
— Daryl Ginn (@darylginn) 20 октября 2018 г.

Больше не нужно беспокоиться о first-time user experience. Пользователь всё равно этого не заметит, ведь первые 20-30 секунд он будет прокликивать и пиксельхантить все попапы, алерты, GPS-метрики и push уведомления. Пусть ваш сайт, SPA или даже PWA отрендерится сразу на клиенте без каких-либо оптимизаций вообще. Времени хватит на всё. В попытке не упустить пользователя, старгетировать его интересы, а с мая этого года и соблюсти GDPR визуальным мусором стал наглухо забиваться UX.

Да, кстати, что там с GDPR? Так ли он нужен? Ведь неспроста…

…p2p наносит ответный удар!

Почему это произошло?

Вообще, тут, конечно, нужно вспомнить, в контексте каких событий прошел год. Шпионские скандалы вокруг Google, сливы инфы от Facebook, блокировки телеги, архивы с личными данными от ВК. На этом фоне набиравшие доселе популярность решения с end-to-end шифрованием и единым центром оказались скомпроментированы.

Проекты вроде Beaker Browser или getaether очень быстро завоевали внимание пользователей, нуждающихся в настоящей приватности в сети.

Одним этим дело не ограничивается, прозвенели ещё «звоночки», говорящие о децентрализации веба, об интернете на блокчейнах:

Андре «Cycle.js» Штальц разрабатывает p2p социальную сеть manyverse. Open Source, без рекламы, аналитики и слежки.
PoW релиз либы OrbitDB — библиотеки, реализующей базу данных на основе p2p сети.

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

Странный эксперимент с нодой

Всё произошло с релизом 10.5, добавляющим поддержку working_threads. Что странного?

Первое — потоки (не путать со стримами) эти не могут нормально между собой данными обмениваться, для передачи объекта из треда в тред объект копируется. Workers can share and transfer memory, but not JS objects Соответственно, конкурентные коллекции на этом не построишь.
Второе — сама суть изменений. Асинхронность, однопоточность всегда была визитной карточкой Ноды. Фактически, Нода создавалась как альтернатива многопоточным бэкендам (Джаве, например)…

Ну ладно, насчёт «становления» Джавой, я, пожалуй, слукавил. Воркер-треды, скорее, должны дополнить асинхронность Ноды, стать фичей, типа child process. При этом явно об этом в официальной доке ни слова. Так сказать, «имеющий глаза да увидит». Согласитесь, выглядит странно, учитывая невозможность конкурентных коллекций. Радует, что функционал ещё экспериментальный, наверняка ещё будут поясняющие PR’ы.

Посыл года

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

В ноябре этого года к тому посылу добавился вот этот, от анонимного Дона:

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

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

P.S

Ладно, что-то я нагнал на всех тут. Я сам-то только недавно перешел из реакт-верстальщиков в реакт-программисты.

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

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

Безболезненный линтинг CSS с помощью stylelint

Wed, 05 Dec 2018 00:00:00 +0000

Некоторые приемы, описанные в статье, ориентированы на использование PostCSS (в связке с css-modules и webpack), однако они с легкостью адаптируются под LESS / SASS / ванильный CSS.

Часть I. Кодстайл vs личные предпочтения. Делаем одинаково

Рано или поздно перед любой командой разработчиков встаёт вопрос о внедрении стандартов написания кода и подключении линтеров на проект. Стандартизация кода позволяет:

быстрее проводить code review, так как полностью убирается необходимость следить за общим форматированием и распространёнными ошибками (благодаря --fix флагу);
упростить работу с компонентами других членов команды — за счёт одинакового порядка свойств/селекторов вы всегда знаете, в каком именно месте искать проблемное свойство/селектор при рефакторинге/поддержке;
быстрее вводить в проект новых разработчиков, так как полностью пропадет необходимость объяснять все договоренности о кодстайле. Здесь стоит отметить, что в идеале все ваши стандарты написания кода должны проверяться линтером, если линтер не может проверить какой-либо кейс — не вводите такое требование к коду.

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

Часть II. Общее форматирование. Делаем красиво

Под общим форматированием я имею в виду все правила stylelint, отвечающие непосредственно за внешний вид кода и никак не влияющие на его работу. Разделять ли селекторы пустой строкой, переносить каждое правило на новую строку или писать все правила в одну линию? Отделять ли открывающую фигурную скобку селектора пробелом, писать hex-цвета в сокращённом или длинном виде, оставлять или опускать ведущие нули у чисел? Всё это (и еще многое другое) относится только к форматированию и на работу ваших стилей никак не влияет.

Все пишут по-разному

Взгляните на примеры ниже — на каждом из них реальный, работающий код, хотя манеры его написания очень различаются:

.main-info{
    padding: 0;
    padding-top: 21px;
    margin: 0;
    border: none;
    margin-bottom: 50px;
    &__field{
        display: flex;
        align-items: flex-end;
        margin-bottom: 19px;
    }
    &__field-name{
        color: $grey;
        font-size: 22px;
        font-weight: 700;
        margin-right: 18px;
    }
}

.root {
  padding-top: 60px;
}

.title {
  margin: 0 auto 40px;
  width: 170px;
  height: 70px;
  color: transparent;
  background-image: url('./images/title.svg');
  background-size: contain;
  user-select: none;

  @media (--tablet-large) {
    margin: 0 auto 60px;
    width: 328px;
    height: 136px;
  }
}

body
	font-family PTSansBold
.wrap
	width 1000px
	margin 0 auto
	background-image url(../images/background.png)
.wrap__header
	display flex
	justify-content space-between
.wrap__logo
	padding 62px 0 0 112px
.wrap__secret
	padding 48px 54px 0 0
.wrap__content
	padding 0 112px 73px 112px

Абсолютно разные подходы к форматированию стилевых файлов

Конечно же, использование определённых пре- или постпроцессоров накладывает свои ограничения, но некоторые из нюансов форматирования остаются всегда. Но представьте себе, что творилось бы на проекте без линтера, если бы на него одновременно пришли авторы трёх кодов выше. Боль.

Линтим форматирование

По сути, подходов к решению проблемы стандартизации форматирования всего два.

Вы разрабатываете свой собственный кодстайл и прописываете правила линтера в соответствии с этими требованиями. В этом случае ваш .stylelintrc может выглядеть примерно так:

{
    "rules": {
        "indentation": 2,
        "string-quotes": "single",
        "declaration-colon-space-before": "never",
        "declaration-colon-space-after": "never",
        "rule-empty-line-before": "never",
        "media-feature-range-operator-space-before": "never",
        "media-feature-range-operator-space-after": "never",
        "media-feature-colon-space-before": "never",
        "media-feature-colon-space-after": "never"
    }
}

Либо вы можете взять уже готовый кодстайл, написанный какой-либо известной компанией,

npm install stylelint-config-airbnb --save-dev

и использовать его в виде расширения конфигурации линтера. .stylelintrc в таком случае приобретёт следующий вид:

{
  "extends": "stylelint-config-airbnb"
}

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

Результат работы линтера

Prettier

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

Как следствие отключения правил линтера — в текстовом редакторе пропадают предупреждения об ошибках форматирования, так как stylelint вообще перестаёт наблюдать за этими правилами. Это требует от разработчиков не забывать запускать Prettier либо через CLI, либо через плагин для текстового редактора (вот такой, к примеру, для VS Code).

Часть III. Порядок свойств внутри селектора. Делаем структурированно

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

Если все ваши свойства сгруппированы по логическому смыслу и отсортированы внутри этих групп, код становится более структурированным. Преимущества такой сортировки:

более быстрое нахождение определённых свойств (например, вы всегда уверены, что position идёт самым первым свойством, а margin всегда идут до padding);
внедрение новых фич не снижает качество кода (как бы вы ни были организованы в плане написания кода на первоначальном этапе разработки, чаще всего, к моменту выхода проекта на стадию поддержки эта организованность значительно снижается);
упрощается работа с кодом, который писали не вы, а другой разработчик команды.

Реализация сортировки

Для достижения поставленной цели в виде сгруппированных и отсортированных свойств следует воспользоваться плагином для stylelint.

npm install stylelint-order --save-dev

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

{
  "plugins": [
    "stylelint-order",
  ],
  "rules": {
    "order/properties-order": [
      "position",
      "z-index",
      "top",
      "right",
      "bottom",
      "left",
    ],
  },
}

Порядком расположения не перечисленных в конфиге свойств относительно перечисленных можно управлять с помощью необязательного параметра unspecified.

"order/properties-order": [
  [
    "position",
    "z-index",
  ],
  {
    unspecified: "bottom"
  }
]

Результат работы линтера

Часть IV. Очерёдность в «нестинге». Снижаем риски и повышаем читаемость

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

Если же говорить про кодстайл, то при командной разработке вы наверняка хотели бы иметь возможность управлять очерёдностью в нестинге. Ведь код, в котором очерёдность ‘БЭМ модификатор — media — псевдоклассы — псевдоэлементы’, будет ОЧЕНЬ сильно отличаться от кода с обратной очерёдностью.

Различные варианты сортировки в нестинге

Так же как и одинаковый порядок свойств в селекторе, одинаковая очерёдность в нестинге позволяет облегчить работу с кодом, который писал другой разработчик команды, так как вы всегда уверены, в каком именно месте искать определенные вложенные правила. Плюс это страхует от ошибок при поддержке кода, когда, к примеру, к уже существующим media добавляется ещё одно, но в неправильной очерёдности. Добавьте к этому правило о максимальной глубине вложенности и запрет на любые селекторы внутри media (т.е. чтобы изменить эффект при наведении на планшетах, вы обязываете своих разработчиков вкладывать media в hover, а не наоборот) — и на выходе получите очень мощный инструмент стандартизации кода.

Реализация сортировки

Данная сортировка достигается за счёт использования упомянутого выше плагина stylelint-order, возможный конфиг .stylelintrc может выглядеть так:

{
  "plugins": [
    "stylelint-order",
  ],
  "rules": {
    "order/order": [
      "declarations",
      {
        "type": "at-rule",
        "name": "media"
      },
      {
        "type": "rule",
        "selector": "^&::(before|after)"
      },
      {
        "type": "rule",
        "selector": "^&:\\w"
      },
      {
        "type": "rule",
        "selector": "^&_"
      },
      {
        "type": "rule",
        "selector": "^."
      }
    ],
  },
}

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

Результат работы линтера

Часть V. Не форматированием единым. Заботимся о качестве

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

Хотите запретить использование тегов или id в селекторах? Застраховаться от дублирования правил внутри селектора или дублирования самих селекторов? Запретить !important, ограничить максимальную глубину нестинга, запретить использование em или px? А может, запретить целые правила, вроде сокращённой записи margin/padding/flex? stylelint предоставляет огромное количество правил, отвечающих именно за такие ситуации. За счет их использования внутри команды достигается некое единообразие в самой логике написания стилевых файлов.

Помимо стандартных правил stylelint также стоит обратить внимание на плагины, расширяющие возможности проверки кода — например, можно запретить использование media без custom-media или запретить вкладывать селекторы внутрь media.

Использование таких правил очень сильно зависит от договоренностей внутри команды. Главный посыл здесь должен быть «не навреди» — обсуждайте внедрение правил с командой, ставьте их под сомнение, разбирайте все плюсы и минусы их использования. Хорошим маркером для подключения нового правила (или расширения уже подключенного) является момент, когда при прохождении code review ошибка встречается более двух раз, т.е. в первый раз разработчик поправил ошибку после замечания, но через некоторое время снова отправил на проверку код с такой же ошибкой.

«Качественные» ошибки линтера

Часть VI. Автоматизация процесса. Убираем боль

Итак, вы потратили достаточно времени на составление добротного конфига stylelint, который покрывает все требуемые вашим кодстайлом моменты — общее форматирование, различные сортировки правил, а также «качественные» нюансы. Следующий вопрос, который вам предстоит решить — «в какой момент запускать проверку линтера, и что должно происходить при наличии ошибок в этой проверке?». Этот вопрос имеет огромное значение.

Представьте себе такую ситуацию — ваша система сборки (gulp/webpack/etc.) настроена таким образом, что проверка линтера запускается на каждое сохранение файла и при наличии ошибок не даёт обновить локальный сервер, т.е. вы не сможете увидеть результат внесённых изменений. Неважно, на какой стадии находится проект — на начальном этапе разработки самых мелких реиспользуемых компонент или же на этапе поддержки, когда код вносится в уже функционирующую систему с огромным количеством файлов и строк кода. Вы не увидите ни одного изменения до тех пор, пока не расставите все написанные правила в правильном порядке и не соблюдёте все бест-практики, предписанные кодстайлом. Боль.

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

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

Разделяй и властвуй

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

Помимо --fix флага существует ещё и такой флаг как --config, который позволяет указать путь к определённому конфигу, а не использовать для проверки дефолтный конфиг. Такая возможность позволяет разделить правила для нашего кодстайла на два конфига:

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

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

Автоматизация запуска линтера

Как уже упоминалось выше, есть как минимум три способа запуска линтера, обеспечивающие автоматизацию процесса проверки.

Первый — запуск линтера в момент сохранения файлов. Этого можно достичь за счёт настройки вашей системы сборки (так — для webpack и вот так — для gulp). Лично мне не нравится этот подход по ряду причин:

из-за сортировок код перемешивается прямо у вас на глазах, что вызывает дискомфорт, т.к. теряется положение курсора на последнем месте изменения в редакторе, а также нарушается порядок действий для cmd/ctrl + z команды;
повышается задержка между сохранением файла и реальным отображением правок в браузере (hot reload), а ведь сохранений в течение рабочего дня может быть ОЧЕНЬ много;
нет гарантий того, что код с ошибками не попадёт в репозиторий.

Второй — запуск линтера перед созданием коммита (т.к. в репозитории хранится вся история коммитов, мы не можем полагаться именно на момент отправки кода в него). Преимущества подхода:

линтер не вмешивается в процесс активной разработки, автоисправления будут применены, только когда работа с кодом завершена;
количество запускаемых проверок снижается в разы, что повышает общую производительность процесса разработки;
код с ошибками линтера не может попасть в репозиторий, так как наличие ошибок при проверке просто не даст создать новый коммит (конечно же, флаг --no-verify никто не отменял, но за его использование следует бить по рукам).

Именно реализацию такого подхода мы и рассмотрим далее. Заключается она в использовании прекоммит хука, запускающего проверку линтера (с расширенным конфигом и флагом --fix) с помощью husky и lint-staged.

Третий способ заключается в использовании CI (Continuous integration), проверка линтером в таком случае может быть проведена автоматически для каждого отдельного Pull/Merge Request. Такой подход обеспечивает чистоту и порядок в стабильной ветке проекта без необходимости запуска проверки для каждого отдельного коммита в feature-ветках.

husky + lint-staged + prettier = ❤️❤️❤️

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

lint-staged — позволяет запускать линтер только для тех файлов, которые находятся в «staged» состоянии, а не прогонять проверку всего проекта целиком.

prettier — форматтер кода, который будет отвечать за следование правилам общего форматирования (о них шла речь во второй части статьи) нашего кодстайла.

Перейдём к настройке этих инструментов для работы в связке. Первым делом установим зависимости:

npm install prettier husky lint-staged stylelint-order stylelint-config-prettier stylelint-config-recommended --save-dev

Далее нужно настроить ваш .package.json следующим образом:

{
  "devDependencies": {
    "husky": "^1.2.0",
    "lint-staged": "^8.1.0",
    "prettier": "^1.15.2",
    "stylelint": "^9.8.0",
    "stylelint-config-prettier": "^4.0.0",
    "stylelint-config-recommended": "^2.1.0",
    "stylelint-order": "^2.0.0"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "linters": {
      "*.css": [
        "prettier --write",
        "stylelint --fix --config ./.stylelintrc-format",
        "git add"
      ]
    }
  }
}

Для того, чтобы переопределить дефолтные настройки prettier, можно создать .prettierrc файл в корне вашего проекта. Выглядеть он может, к примеру, так:

{
  "singleQuote": true,
  "tabWidth": 4
}

Также убедитесь в том, что вы передаете нужный конфиг в строке с вызовом линтера (скорее всего, это будет не дефолтный .stylelintrc).

Итоговый результат

Настроив связку инструментов по приведённым выше примерам, на выходе мы получим следующую логику работы линтера на проекте:

базовый конфиг .stylelintrc включает в себя только «качественные» правила, плагины для текстовых редакторов / IDE используют именно его;
на этапе локальной работы с кодом проверки линтера не запускаются и не препятствуют разработке;
в момент создания коммита для файлов, которые находятся в «staged» состоянии, сначала отработает prettier, пофиксив общее форматирование. Затем запустится stylelint с расширенным конфигом и --fix флагом, пофиксив сортировки правил и нестинга. Далее проводится проверка «качественных» правил, и в случае наличия ошибок коммит не будет создан. Если же ошибок нет, то все изменения, внесённые в результате автоисправлений, будут автоматически добавлены в «staged» состояние и коммит будет создан.

Допустим, что ваш итоговый конфиг имеет следующий вид:

// .stylelintrc
{
  "rules": {
    "declaration-block-no-imortant": true,
    "property-blacklist": ["flex"],
    "unit-blacklist": ["em", "rem"],
  },
}

// .stylelint-format
{
  "extends": [
    "stylelint-config-recommended",
    "stylelint-config-prettier",
  ],
  "plugins": [
    "stylelint-order",
  ],
  "rules": {
    "declaration-block-no-imortant": true,
    "indentation": 2,
    "rule-empty-line-before": "always",
    "at-rule-empty-line-before": "always",
    "property-blacklist": ["flex"],
    "unit-blacklist": ["em", "rem"],
    "order/order": [
      "declarations",
      {
        "type": "at-rule",
        "name": "media",
      },
      {
        "type": "rule",
        "selector": "^&:\\w"
      },
      {
        "type": "rule",
        "selector": "^&_"
      },
    ],
    "order/properties-order": [
      [
        "position",
        "top",
        "right",
        "bottom",
        "left",
      ],
      {
        unspecified: "bottom",
      }
    ],
  },
}

// .package.json
{
  "devDependencies": {
    "husky": "^1.1.3",
    "lint-staged": "^8.0.4",
    "prettier": "^1.15.2",
    "stylelint": "^9.8.0",
    "stylelint-config-prettier": "^4.0.0",
    "stylelint-config-recommended": "^2.1.0",
    "stylelint-order": "^1.0.0"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "linters": {
      "*.css": [
        "prettier --write",
        "stylelint --fix --config ./.stylelintrc-format",
        "git add"
      ]
    }
  }
}

Тогда работа линтера будет выглядеть так (обратите внимание, что в staged состоянии находится только один стилевой файл):

Попытка коммита вызывает прекоммит хук и автоисправление форматирования. Линтер падает с ошибками на «качественных» правилах, внесённые prettier изменения форматирования при этом сохраняются

Пример успешного коммита без ошибок в «качественных» правилах

Заключение

С каждым днем stylelint становится всё мощнее, дополняясь новыми правилами и возможностями для автоматических исправлений. Так что если вы ещё не используете данный инструмент, я очень надеюсь, что после прочтения этой статьи вы хотя бы попробуете внедрить его на свои проекты. Также некоторые подходы, описанные в статье, применимы к линтингу не только стилевых файлов, но и, к примеру, JSX файлов, но это уже совсем другая история…

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

Конфиги линтера, которые используются в моей команде, вы можете найти тут.

Спасибо за внимание!

CSSSR

Кодекс тестировщика

Тестировщик должен быть внимательным

Тестировщик должен быть азартным

Тестировщик должен думать как пользователь

Тестировщик должен быть изобретательным

Тестировщик должен быть ловким

Тестировщик должен быть командным игроком

Тестировщик должен уметь оптимизировать

Тестировщик должен быть чист умом и помыслами

Тестировщик должен быть немного больше, чем тестировщиком

Список полезных ссылок

Итоги 2019 от CSSSR

Пролог

10 лет немого крика…

Всё JavaScript

Deno

Мультиязычность GraalVM

CommonJS -> AMD -> UMD -> «It don’t matter if you’re black or white»

BigInt

Нет виртуального DOM. Нет фреймворков поверх фреймворков. Нет фреймворка в рантайме. Есть Svelte. И тот «исчезающий».

Logux

Эпилог

Оценка задач. Как перестать гадать и начать угадывать

Создайте условия

Работайте над собой

Есть ли жизнь на удалёнке или как перестать верить в единорогов

Формальная и интуитивная семантика языка программирования на примерах JS и JSX

Декларативность

Семантика

Прикладные примеры

null VS undefined

Cсылочная прозрачность

Тонкости спецификации

Паттерн «заместитель»

JSX vs JS

Вывод

Полезные материалы

Стимуляторы работы программиста. Здоровье

Глава 3. Здоровье

Стимуляторы работы программиста. Мотивация

Глава 2. Мотивация

Стимуляторы работы программиста. Обстановка

Глава 1. Обстановка

Итоги 2018 от CSSSR

«Нынешняя ситуация — полное дерьмо»

Бета luna-lang

Перспективный стейт-менеджмент

SSR не нужен!

…p2p наносит ответный удар!

Странный эксперимент с нодой

Посыл года

P.S

Безболезненный линтинг CSS с помощью stylelint

Часть I. Кодстайл vs личные предпочтения. Делаем одинаково

Часть II. Общее форматирование. Делаем красиво

Все пишут по-разному

Линтим форматирование

Prettier

Часть III. Порядок свойств внутри селектора. Делаем структурированно

Реализация сортировки

Часть IV. Очерёдность в «нестинге». Снижаем риски и повышаем читаемость

Реализация сортировки

Часть V. Не форматированием единым. Заботимся о качестве

Часть VI. Автоматизация процесса. Убираем боль

Разделяй и властвуй

Автоматизация запуска линтера

husky + lint-staged + prettier = ❤️❤️❤️

Итоговый результат

Заключение

`null` VS `undefined`