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

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

Подробнее в аккуратно написанной статье:
https://riter.co/blog/results-of-our-survey-on-project-management-tools

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

Тырим подходы у этих парней: https://innoq.style/. У них там Atomic Design (общая философия для делелния на компоненты)+ ITCSS (структура организации стилей, где они раскладываются по слоям. Там находится место и всяким миксинам/тулзам, которые даже не генерируют цсс и всяким ресетам/нормалайзам) + BEM (для синтаксиса и правил для определения классов). В последнем проекте мы заменили BEM на bliss-css, что слегка поменяло синтаксис классов, в некоторые места принесло чуток больше ясности, а в некоторые конфликты с ITCSS. В чем были конфликты не вспомню, но они были мелкими и вполне нормально разруливаемыми и документируемыми. В этом последнем проекте мы действительно заморочились и сделали все правильно: https://visdeal.gitlab.io/

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

Сегодня просто цитата из рабочей переписки:

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

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

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

​​Внезапная заметка о пулл реквестах.

Ошибочно считать, что фича должна быть сделана за один пулл реквест. Или, если подходить формально, за наименьшее количество пулл реквестов. С такими пулл реквестами искать ошибки и причины их появления становится значительно тяжелей. В добавок совершенно непонятно на какой стадии находится разработка текущей фичи. Почти готова ли она или там только начало — точно не знает даже разработчик этой самой фичи. Кроме того, гит-конфликты будут возникать на каждом шагу и будут настолько огромны, что будут тянуть на небольшую такую задачку с абсурдным названием «пытаемся смержить текущий мастер в мою ветку на 100+ коммитов» с оценкой часов в пять. Ну, и вишенкой на торте будет полностью парализованный git bisect. При марафонском пулл реквесте с мириадой коммитов с уверенностью можно будет утверждать, что «баг где-то там, между двумя мастерами».

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

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

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

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

2. Очень важно разобраться с формулировкой задач. Задачи, вроде «обновить библиотеку А с версии 1.0.3 до 1.0.5» быть не может, ведь это никому не интересно, ни разработчику, ни менеджеру, ни управляющему. Все задачи должны быть сформулированы исключительно с точки зрения пользователя системы. В этом смысле очень нравится термин «user story» (не знаю как это правильно перевести, не потеряв смысл), где сразу становится понятно что же будет являться той самой историей пользователя, а что не будет.

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

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

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

Итак, физика (наука).

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

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

Если вам надо сверстать новую страничку с какими-то новыми доселе неведомыми сущностями и при этом не пришлось выписывать новую пачку css-правил, то у вас в стилях все хорошо.

#cssэкстраполяция

Последний пост в цикле #cssэкстраполяция и он будет про попиксельную верстку. И сначала у меня несколько утверждений.

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

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

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

Учитывая эти три штуки, требовать от верстальщика пиксельперфект — путь к усложнению работы и ухудшению кода.

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

Итого:

1. Дизайнеру нужно рисовать больше макетов, чтобы было с чем сравнивать попиксельно.

2. Верстальщик превращается в “psd2html converter” и от него требуют перестать задумываться над смыслом свёрстанного. Мол, ты верстай, а думать другие будут.

3. Пропадает возможность исправить логическую ошибку на этапе верстки.

4. Умным и творческим или просто амбициозным людям нет никакого резона оставаться просто верстальщиками.

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

Наверняка интересующиеся это уже видели, 10 месяцев прошло в конце-то концов, но коммит очень хорош.

https://github.com/reduxjs/redux/commit/9276ff0af6400633d6731b15fed6e70c3561887e

Если рекрутер начинает своё письмо «Дмитрий, я вижу, что вы открыли моё предыдущее письмо, но мне ничего не ответили, неужели со мной что-то не так?», допустимо ли ответить «я когда открывал письмо, вас за спиной точно не стояло, хватить следить за мной, ненормальная»?

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

Цитата из рабочей переписки:

«Если бы это чёртово железо никогда не тормозило, я был бы офигенным архитектором».

Ребята, тут знакомые в сообществе жалуются на то, что никто не хочет быть первопрходцами. Может, среди нас есть энтузиасты?

https://yangx.top/server_side_swift

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

Этим постом сформулирую несколько утверждений. Как-нибудь потом продолжу с выводами.

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

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

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

4. Некий базовый набор знаний все-таки получить можно, но он настолько фундаментален, что легко учится самостоятельно. Гит, основы юникса, алгоритмизация, немного математики. Плюс ещё некие основы для конкретной профессии. В веб-программировании, например, нужно понимать html, css, http и все такое прочее.

#экстраакадемия

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

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

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

1. О цене речь не идет. Она есть и как бы устраивает и вас и их и аргументом в споре быть не может.
2. Отзывам ваших предыдущих клиентов верить клиент не будет.
3. Портфолио у вас впечатляющее, но аргументом клиенту оно не зайдет.
4. Как бы доверять вам, клиент доверяет, но крайне осторожно.
5. Послать куда подальше клиента нельзя, таки надо его убеждать.

Как всегда, хочется ваших решений и ваших стратегий. Пишите мне личным сообщением (@aratak), только не забывайте тег добавлять #экстрасейлз, чтобы потом я все эти сообщения нашел. Все посты по этой теме в «Экстраполяции» почитать можно с тегом #экстрасейлз

Ребята, воскресенье — хорошее время для обратной связи. Следующими сообщениями я задам несколько вопросов со смайликами вместо ответов. Даже если вы обычно не ставите смайлики, то, прошу вас, не поленитесь в этот раз. Чмоки.

Ну, и смайлы в этом сообщении относятся к самому процессу опроса. Ничего, если периодически будут опросы (⭐️)? Не нравятся опросы, но пару раз можно (😕)? Будут ещё соцопросы — отпишусь к чертям (🤮)?

Лонгриды или коротенькие твиты?

Демагогия с философией (🤔), шутки с афоризмами (😂), новости и ссылки (🌎) или практические советы (👨‍🔧)?

Поэкспериментировать с разными форматами? Видеоподкаст там, аудиоподкаст.

Только около программирования или разбавлять всяким непрограммированием?

Стòит ли добавить рекламу?