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

Я для себя особенно выделил некоторые жизненные наблюдения, которые как мне кажется являются определяющими в этом вопросе.

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

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

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

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

Графика намного упрощает восприятие и создание. Нарисовать в [draw.io](http://draw.io) схему взаимодействия модулей намного понятнее и быстрее воспринимать и запоминать. Также я использую всем известный plantUML. Исходники в xml должны быть обязательно приложены.

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

Почему это важно?

- Вы сами через 2-4 недели забудете то, что вы делали (в подробностях точно). Добавили себе кучу времени на вспомнить.
- Коллеги не будут вас так часто (но не совсем) дергать если у них будет проектный google. Меньше стресса, выше эффективность.
- Снижается bus factor (о его опасности для проектов написаны тонны текста)
- Новые люди будут входить в разы быстрее. Принятие нового человека не будет таким страданием для него и для вас. Даже если это и бывает нечасто.

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

Принял участие в беседе на тему найма. В целом тема актуальная для многих компаний, которые имеют в штате удаленных сотрудников. https://habr.com/ru/company/skyeng/blog/463553/

О личной продуктивности (todo)

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

Свои методики я вырабатывал долго и продолжаю постоянно это делать. Как и в любой другой работе огромное значение имеет качественный и подходящий инструмент. Чего я только не перепробовал: отрывные листки, бумажные ежедневники, немыслимое количество различных тудушников, пока не остановился на [todoist.com](https://todoist.com/r/anton_gubarev_ekuurb) И то не с первого раза. Сначала был восторг, потом разочарование, а потом более-менее научился эффективно пользоваться 🙂 (и купил премиум подписку). Сейчас todoist ежедневно говорит мне чем я сегодня должен заниматься. Это самодостаточная система, в которую можно вкидывать свои проблемы, которые поедут по конвееру (уже в ручном режиме, но поедут). Один раз настроил и забыл.

Основные правила, по которым я организую свой todoist.

1. Метки. Метки = действия. read, dev, manage, communicate, call и т.д. Когда я вечером на сон грядущий решаю что есть настроение на почитать я фильтрую все таски по метке read. Когда у меня есть еще 30 минут до следующей встречи и начинать что-то девелопить неэфективно, я открываю метку call и успеваю сделать несколько звонков.
2. Повторяющиеся задачи. Скопился длинный backlog в jira? Появляется задача "Разрешить мин 2 задачи из backlog", которая создается автоматически каждый день или через день. За 2-3 месяца backlog значительно худеет. Появилось большое совещание по пятница в 15:00. Появляется задача "Подготовиться к совещанию", которая создается сутра в пятницу.
3. Inbox. Когда вспоминаешь про какое-то дело поти всегда лень открывать тудушник и его туда вписывать. На телефоне есть удобный виджет, в который я пишу поток мыслей. На ноуте есть аппликейшен, в который также можно быстро вкинуть мысль. Мозг автоматически перестает эту проблему думать. Все это валяется в inbox, который я раз в какое-то время разгребаю и раскладываю по своим местам, принимаю решение что с этим делать.

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

Todoist это далеко не единственный мой инструмент и скоро напишу еще об остальных.

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

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

Но я это все к чему. А к тому что даже в надежных проектах (5 лет без видимых поломок!) рано или поздно неизбежно случаются поломки. Что это значит? Что можно не париться ведь все равно все сломается? Нет. Можно и нужно работать над качеством и надежностью проекта, чтобы ломалось раз в 5 лет, а не через день.

Очень полезная штука когда надо быстро сделать некое подобие мока бэкенда

jsonbox — бесплатное удалённое хранилище для JSON: https://jsonbox.io/

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

Документация: https://github.com/vasanthv/jsonbox#readme

#инструменты #api #json

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

70% стоимости решения большинства задач — в коммуникациях.

Один из вариантов решения проблемы - утвердить "SLA" на уровне компании (кстати похожим образом сделано у нас в Skyeng). Согласовать со всем руководством, оформить документально (например в confluence), ознакомить всех сотрудников с документом. Затем включить вопрос ознакомления с этим правилом в процесс онбординга новых сотрудников.

Схематичный пример как могут выглядеть правила:

- Сообщение в slack. Не дольше 3 часов.
- Сообщение по электронной почте. Не позднее следующего рабочего дня.
- Личные встречи и звонки согласовываются заранее и заносятся в календарь

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

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

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

В эту субботу в Воронеже буду выступать на https://gdgvrn.ru с докладом об особенностях построения рабочих процессов в распределнной команде.

Очень полезный мануал для тех кто еще не начал писать доки к своему api. Или уже начал но получается не то что хотелось бы

Перевод курса по документированию API теперь есть в форме сайта: https://starkovden.github.io.

Заметил последнее время много шума вокруг асинхронных инструментов в php. В PHP дайджесте на Хабре даже отдельный раздел под это завели. Из того, что я более-менее видел, это https://reactphp.org/) и https://www.php.net/manual/ru/book.swoole.php. Кстати, много интересной информации по этим инструментам можно почерпнуть в блоге моего коллеги Сергея Жука https://sergeyzhuk.me/reactphp-series.

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

Я пару лет назад начал писать на go. Это отдельная история как и почему, сейчас не об этом. Мне кажется нет смысла объяснять отдельно как выглядит асинхронность там. Когда приходится сталкиваться с задачами, где действительно требуется утилизировать ресурсы или где милисекунды решают, то я вряд ли буду смотреть в сторону ReactPHP, а скорее решу эту задачу на go, потому что он создавался как раз для подобных задач, а вот php совсем для других.

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

21 ноября состоится митап про страхи в php http://it.skyeng.ru/php21 Я там буду участвовать в качестве спикера в том числе. Кому интересна какая-то из тем или кто хочет пообщаться регистрируйтесь и приходите!

Мои предсказания о будущем php
https://habr.com/ru/company/skyeng/blog/474724/

В php 8 будут объедиенные типы. https://github.com/nikic/php-rfcs/blob/union-types/rfcs/0000-union-types-v2.md Подавляющим количеством голосов предложение принято. Выглядит как возвращение к тому, от чего пытались уходить.

Рутинная работа, наверное одно из самых демотивирующих явлений. Как подумаешь что прежде чем сесть за интересную задачу, которую руки чешутся решить, нужно сначала разгрести таск-трекер, так сразу настроение начинает идти вниз.
Думаю пора начать серию постов о своем опыте автоматизации рабочих процессов и не только рабочих. Эта серия зрела давно. В двух словах сказать все что набралось невозможно. Поэтому постараюсь по порядку осветить все то, с чем пришлось столкнуться и что получилось успешно решить с помощью автоматизации.
И начну пожалуй с самой частой проблемы, о которой немного сказал вначале. Проблемы рутины. Давным-давно, когда я еще занимался работой на аутсорсе с небольшой командой, столкнулся с проблемой актуальности статусов и другой информации о задаче в таск-трекере. Приходилось ежедневно вручную контролировать этот вопрос, что утомляло и занимало время. В команде использовался redmine и он поддерживал интеграцию с git из коробки. Если указать в названии коммита номер задачи и статус, то он сменится в задаче автоматически. Но как заставить разработчиков не забывать правильно оформлять сообщения коммитов? Даже если они ответственные люди, все равно не исключен человеческий фактор и нарушения форматов будут, а это значит, что надеяться на этот механизм нельзя и нужно продолжать контролировать вручную. Безнадега.
Изучив тему, решил попробовать воспользоваться pre-receive хуком, который запускается на стороны сервера до того, как изменения будут приняты в репозиторий. Написать этот хук можно на bash/pyton/php и других скриптовых языках. Мне было это проще сделать на php. Скрипт занимался тем, что проверял сообщения коммитов на четко заданный формат, примерно такой "#{task-id}-{status} | {message}". Список возможных значений для status был жестко ограничен, так как соответствовал статуса в redmine. Хук не пропускал коммиты с неправильными статусами или неверными форматами сообщений. Он просто не давал пушить. Первое время это частенько кого-нибудь выбешивало, когда забывал оформить по правилам. Приходилось даже делать rebase когда коммитов в пуше не один и просто ammend не мог помочь. Но скоро уже все привыкли, комиты оформлялись правильно на автоматизме и проблема исчезла. В дальнейшем этот хук стал также проверять и статус задачи, например, не давая пушить в закрытые задачи. Это было несложно доработать с помощью Redmine API и даже нашелся [готовый php-клиент](https://github.com/kbsali/php-redmine-api).
Реализация заняла у меня часа 4-5 в сумме. Если не считать первых попыток на bash, которые не увенчались успехом в виду моих не достаточно глубоких познаний в этом инструменте. В итоге статусы в задачах стали меняться автоматически, в каждой задаче был список коммитов, на которые можно было перейти и посмотреть что именно мы меняли. В истории git была привязка к задачам, в рамках которых делались изменения, я этим кстати часто пользовался, чтобы посмотреть для чего делались те или иные правки, смотрел переписку по задаче. Также часто помогало поиском по истории собрать воедино все правки по проблеме когда коммиты разбросаны. Вообщем время это экономило массу и привнесло порядка. Ну и конечно же я перестал беспокоиться об актуальности статусов и просто начал ими пользоваться. Если стоит статус released значит задача в мастере, если ready for development - значит ни одного коммита еще не сделано и т.д.
Все в команде настолько к этому привыкли, что как-то раз, когда этот хук внезапно отвалился, это вызвало небольшую волну возмущений, "а почему статусы перестали проставляться". Хук конечно же быстро починили.
Но правда одно ограничение все же есть. Pre-receive срабатывает на стороне сервера. И если у вас облачный github/gitlab/bitbucket, то использовать эту возможность не получится. По крайней мере я не нашел способа. Если кто-то его знает, то за подсказку в личку буду благодарен.

Недавно писал пост про переработки в другой канал

Привет, Антон @antgubarevcom Губарев продолжает поднимать вечные и холиварные темы. Сегодня он хочет поговорить с вами

Про переработки ⏳🎡

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

У нас в Skyeng в официальной вики четко прописано, что переработки не приветствуются. Но я:

• всё ещё встречаю рассказы о компаниях, в которых переработки не только распространены, но и поддерживается на уровне руководства 🤦‍♂️

• вижу ситуации, когда сотрудники пытаются перерабатывать по своей воле 🧟‍♂️

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

Хуже, когда в коллективе заводится трудоголик или карьерист. Человек, готовый работать по 60 часов в неделю просто потому, что для него это норма (ну или он так думает)🤖 Казалось бы, вот он, локомотив, который способен затащить задачи, которые другим не под силу. Но вид такого “стахановца”, скорее всего, будет демотивировать неуспевающих. И исправить их неуспеваемость станет сложнее. Да и неспроста выгоревший трудоголик — всё более частое явление.

40 часов на работу в неделю

https://meetups-online.ru/php-may-2020 В эту субботу буду рассказывать как мы в непростых условиях смогли избавиться от очень старого легаси монолита и не упасть в грязь лицом перед бизнесом.

Этот анонс напомнил мне о том что на этом мероприятии будет интересный доклад от слепого разработчика.

На ближайших выходных сразу два крутых PHP-мероприятия. Ребята уже скоординировались и больше таких коллизий не будет. Ну а в этот раз можно насладиться выбором.

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

Кроме того, 30 и 31 мая будет проходить PHP fwdays online. Программа вот тут https://fwdays.com/en/event/php-fwdays-2020#program-event.

Сам жду доклад Макса Рафалко (Infection) о принципах проектирования пакетов. Уж очень понравился его документ о выделении пакета из Infection https://github.com/infection/infection/issues/922.

Организаторы PHP fwdays предоставили пару билетов для розыгрыша — он в следующем сообщении.