Продуктивные обсуждения

Если делаете ревью кода или отвечаете на замечяния в нём, то минимизируйте когнитивную нагрузку на собеседника:

Уберите эмоциональную окраску своих сообщений. Собеседник вложит в ваш текст эмоции на свой вкус, обидится и дальнейшая дискуссия будет идти на эмоциях.

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

Опасно:

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

Продуктивно:

— Я не могу принять этот код, потому что он нарушает наши принципы: оформлен не по PSR и не покрыт тестами.
— Тут восемь строчек вызовов библиотечных функций PHP. Ты работаешь со строками, массивами и файлами. Это не имеет никакого отношения к бизнес-логике приложения. Разбей код на функции и назови их согласно предметной области задачи. Ну и чтобы два раза не вставать, этот код сейчас не тестируемый.
— Зачем здесь модель создаётся в контроллере?
— Кажется, это костыль. Я посмотрел в документации по Ларавелю, это решается через default attribute values

Лонгрид с картинками: https://teletype.in/@nickmitin/productive-conversations

Включайте подготовку в задачу

Для неопытного разработчика задача «Изменить цвет кнопки» в незнакомом проекте выглядит так:
— поменять цвет кнопки: 10 минут.

А результат будет такой:

<button style="color: red !important">

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

Для опытного чувака работа выглядит так:
— открыть редактор;
— скачать код;
— налить себе кофе/чай/смузи;
— понять как устроены стили в проекте;
— понять как устроена сборка фронтенда в проекте;
— понять какие соглашения по оформлению кода;
— поправить тесты;
— поменять значение в нужном месте;
— собрать проект;
— запустить тесты;
— показать заказчику;
— задеплоить.

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

Больше драмы:
https://teletype.in/@nickmitin/save-you-weekend

Выпустили пакет для работы с апи ФНС для проверки чеков:
https://pypi.org/project/fnsapi/

Тесты — часть бизнес-задачи

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

Создание моделей, контроллеров, разделов системы, локализация, валидация, сериализация — всё типовые операции, которые покрыты функционалом и документацией, выбранных вами фреймворков.

Если у вас есть необходимость писать утилитарные механизмы, то у вас либо плохой фреймворк, либо вы плохо в неё разобрались.

Разработчику фактически остаётся описывать бизнес-процессы. А бизнес-процессы лучше всего описывать в виде логики и примеров: «Если так, то так, а если вот так, то вот так»

И нет ничего лучше, чем описывать примеры тестами. Поэтому совершенно ясно, что тесты не просто часть задачи, а часть бизнес-задачи. И делать их надо не стыдливо это умалчивая, а с гордостью!

Программирование конфигурациями

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

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

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

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

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

Докер для разделения фронтенда и бэкенда

Если вы используете докер для разработки, то можете делать так:

docker-compose с фейковым АПИ

Фронтендер подключает контейнер с фейковым АПИ, не меняя окружение и разрабатывает:

version: '3.9'
services:
  backend:
    image: qortex/backend:latest-fake-api
  frontend:
    image: qortex/frontend:latest

docker-compose с для фикса бага в версии 1.2

Фронтендер подключает контейнер с фейковым АПИ 1.2, не меняя окружение и разрабатывает:

version: '3.9'
services:
  backend:
    image: qortex/backend:1.2-fake-api
  frontend:
    image: qortex/frontend:1.2

docker-compose с для регрессионного тестирования версии 1.4

Тестовое окружение подключает контейнеры с версиями 1.4, не меняя окружение и тестирует:

version: '3.9'
services:
  backend:
    image: qortex/backend:1.4
  frontend:
    image: qortex/frontend:1.4

Иллюзия решения

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

Из-за попадания таких решений в продакшн, возникает более серьёзная проблема — вендор-лок.

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

В жизни это самописные ЦМС разных компаний-разработчиков, деплои через баш-скрипты, системы работы с данными без интерфейсов и прочая чёрная магия.

Прививка от иллюзии, на примерах

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

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

Поэтому когда вы ставили эту задачу, то одним из критериев её исполнения должен был быть: «Создание отчёта делается одной командой/кнопкой и не занимает больше 30 секунд участия человека». (при этом сам отчёт может собираться хоть сутки, мало ли какой он глубины или сложности). И без выполнения этого требования задача не должна считаться выполеной.

Другой пример. Вы заказали сайт у подрядчика. Работа выполнена, пора запускать. Попросите их созвониться с ними, и показать экран в процессе того, как они будут запускать его. Если там втирают, что это долго, сложно и требует каких-то настроек серверов, чего-то там, бла-бла-бла, то поздравляю, у вас опять вендор-лок. Ваш сайт в плену у этих разработчиков, потому что совершенно точно, что в случае передачи проекта другой команде вы получите дежурное «Ууу, да тут надо всё переделывать и переписывать». В современном мире люди запускают ansible (именно ansible — это важно)-скрипт, который разворачивает и настраивает сервер и заливают туда код, а ещё лучше докер-контейнер, который потом запускают. И занимает это не более 15 минут чистого времени.

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


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

Рассказал журналу Код, о том как стать полезным продуктовым разработчиком:

https://thecode.media/mitin-says-no/

Не делайте коммерческие проекты на самописных ЦМС/фрейморках

Совет, который я бы дал себе лет 10 назад

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

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

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

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

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

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

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

Поэтому вот что важно:

Писать свой фрейморк — это большая работа

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

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

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

У нас появилась задача по разработке плагина для Вордпресса. Так как мы в Кортексе любим Visual Studio Code и порядок, то сразу же сделали шаблон проекта для разработки плагинов для Вордпресса в Visual Studio Code.

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

Если вам такое почему-то нужно, то пользуйтесь:
https://github.com/QortexDevs/wordpress-plugin

Как нетехническому руководителю проекта или компании следить за качеством разработки

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

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

Но как понять в каком состоянии у вас разработка, если вы управляете сайтом, интернет-магазином, аналитическим сервисом или чем угодно, что открывается по ссылке в интернете?

Об этом мы и поговорим на моём вебинаре.

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

Кому: Руководителям проектов или компаний, в которых есть разработка и у которых баги регулярно попадают в продакшн, сроки затягиваются, о проблемах сообщает не внутренний мониторинг, а пользователи, а любой внешний разработчик говорит: «Ууу, да тут надо всё переписывать». При этом разработчики объясняют это всё магической инфраструктурой, нехваткой ресурсов или уникальностью задачи.

Регистрируйтесь по ссылке:

https://events.webinar.ru/37922155/8185759

Отличный пример олимпиадного программирования

Функция просто создаёт уникальное имя файла, если такой уже есть в папке.

Тут вам и time + rand, и конвертирование систем исчисления.

Хотя в данном случае можно было бы просто нумерацию и while использовать 😊

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

Технические и алгоритмические вопросы

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

Рассмотрим пример

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

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

Вы спрашиваете разработчика почему так, а он начинает рассказывать:
«Смотрите, PHP берёт строку из базы, кладёт её в память и начинает перебирать посимвольно, если первая буква Н, то запоминает её позицию и смотрит, какая буква дальше, если дальше идёт о, то предполагает, что тут слово Новая и проверяет последующие буквы. Далее PHP заворачивает строку в тег span со стилем color: red ...»

Конечно, от такого объяснения вам станет страшно и даже покажется, что программирование — это какая-то ужасно сложная область. Но это ложное впечатление. Оно возникает из-за того, что на вас вывалили кучу несущественных деталей и новых терминов: PHP, парсер, тег, стиль. Что это всё такое и какое оно имеет отношение к списку категорий?

А теперь допустим, что разработчик рассказывает так:
«Сначала берём название категории. Если оно начинается со слова Новые, то красим текст в красный. Потом смотрим, есть ли названии категории есть слова стол, стул или шкаф, то красим текст в тёмно-серый и делаем текст жирным».

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

Теперь, когда вы выяснили, как работает алгоритм и согласовали правильное поведение, разработчику нужно поменять блоки алгоритма местами:
«Сначала берём название категории. Если в названии категории есть слова стол, стул или шкаф, то красим текст в тёмно-серый и делаем текст жирным. Затем, если название категории начинается со слова Новые, то красим текст в красный».

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

Неочевидный вред от костылей

Вот какие-то ребята в очередной раз напилили какой-то свой шаблонизатор.

А вот я открыл его в редакторе:

Вопрос: как тут подключить подсветку синтаксиса и автоформаттер, чтобы ничего не сломать?

(Уверен, что авторы вообще об этом не думали)

Главная сила инженера

Опытный инженер решает невероятно сложные задачи очень простыми методами. Потому что он знает, что систему нужно будет поддерживать и развивать. Чтобы не напинать себе же по яйцам он не переусложняет её.

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

Так как программисты — это инженеры, то нас это тоже касается. Главная сила инженера — уметь не делать то, что за него уже давно сделали

Работа с кодом

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

Например, если в коде есть функция на 2000 строк, то не факт, что человек, её написавший, не умеет в методы, функции, ООП и прочие штуки.

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

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

В общем, чтобы ваш код был понятнее и чище, вырабатывайте привычки эффективной работы с ним.

Как внедрять сложные штуки

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

Например, у вас есть интернет-магазин, и вы хотите начать обрабатывать заказы через ЦРМ.

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

Если делать всё и сразу, вы потратите полгода, а потом ещё полгода будете тестировать. Ошибки будут валиться каскадом изо всех мест. Это всегда происходит, когда новая разработка сталкивается с реальными данными.

Чтобы не умереть на таком проекте, нужно внедрять изменения поэтапно.

Сначала реализуйте передачу заказа с сайта в ЦРМ. Создайте тестового пользователя и передавайте все заказы от него и доставку на один адрес. Внедрите это в стелс-режиме, понаблюдайте за процессом две недели. Исправьте все недочёты.

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

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

У такого метода есть ещё крутой психологический эффект: есть постоянное чувство прогресса. А это сильно мотивирует двигаться вперёд и не завязнуть в огромной задаче.