Причины прекращения кодирования
Сейчас я не пишу код. В команде и так 12 FE-разработчиков помимо меня, так что заниматься требуется менеджерскими активностями. Расстраивает ли меня это? Нисколько, и дальше я объясню, почему.
В своё время, желая писать качественный код, я прошёлся по соответствующей литературе. Были там и известные книги вроде «Чистого кода» или «Паттернов проектирования». Были и малоизвестные: Bad Programming Practices 101, Refactoring for Software Design Smells и другие.
Всего на тему качественного написания кода я прочитал около 12 книг. Это не считая того, что относится к конкретным языкам программирования. То есть знаменитые JavaScript: The Good Parts сюда не входят. Казалось бы, Герман, сиди да радуйся, в чём твоя проблема?
Проблема в том, что, несмотря на множество прочитанного и желание его применять, возможности делать это масштабно совершенно нет. Хорошо, наведу я порядок в этих 20 относящихся к задаче файлах, а дальше что? Во-первых, в остальной 1000 и нет этого порядка, а, во-вторых...
...оттого, что порядок случился где-то локально, совсем не следует автоматическое принятие этого порядка командой и системой. То есть дальше никто, кроме меня ничего подобного делать не будет. Если вы на этом моменте уже собрались дать отпор этим двум проблемам, то не спешите.
Есть проблема покрупнее, чем две упомянутых. Значительно крупнее, я бы сказал. Заключается она в том, что, как бы мне и многим из нас того не хотелось, истинно правильного и единственного способа программировать нет. Нет и полностью неправильного.
Если вы не согласны с моим способом программирования, то мне вам и сказать-то нечего. Приходится выходить из мира кода и вести торг в других областях. Однако, это не значит, что ничего поделать совсем нельзя.
Как команда мы можем начать вырабатывать свои подходы. Наше время ещё хорошо и тем, что есть и подходы по умолчанию, выложенные в интернете в виде линтеров и форматтеров. Они не покрывают уж очень существенных вещей, но можно не беспокоиться о всякой мелочи.
А как вырабатывать эти подходы? Тут нам на помощь придут качественные характеристики систем. Помните любимые многими производительность, адаптивность, устойчивость к падениям и прочее? Не только запущенное программное обеспечение может обладать характеристиками.
Система исходного кода может обладать и своими собственными. Сюда относится и почти эзотерическая читаемость, обнаруживаемость, доступность для поиска. Всё это пока пустой звук, но подумайте, как обстоят дела с доступностью для поиска у Git-репозитория ОС Windows?
Эта мономегарепка уже в 2017-м году весила 270 GB, отчего Microsoft потребовалось разработать технологию виртуализации GVFS. Идея в том, что файлы скачиваются только по прямому требованию, а не в момент клонирования. А так они висят как заглушки в десктопном UI облаков.
Сразу оговорюсь, что я пока в начале своего большого исследовательского пути в организации процесса разработки ПО и могу перегибать палку или ошибаться. Поправляйте меня, если знаете предмет лучше.
Итак, как же нам наделить сутью эти качественные характеристики? Ответ мы найдём в рукописях слегка древних людей: статистиков Уолтера Шухарта и Уильяма Деминга. Первого я не читал, но с удовольствием сейчас изучаю труды и наследие второго. Нам нужны операциональные определения.
Это что за чертовщина!? Это определения, выраженные в терминах операций. Что такое мытая картошка? Возьмите картошку, подставьте её под струю тёплой воды и счищайте грязь металлической губкой до тех пор, пока её не останется. Результат этих действий и есть мытая картошка.
А как же мы можем определить в терминах операций читаемость? Мы можем сказать, что файл, пропущенный через форматтер, считается в нашей команде читаемым. Если этого будет мало, то можно добавить дополнительную операцию обработки и учитывать её в определении.
Есть ли у нас какое-нибудь подспорье для операционных определений? Да, автоматизированное тестирование. «Что в нашей компании «работающий продукт»?» «Продукт, успешно проходящий все виды автоматизированного тестирования, запускающиеся в нашем CI, и собирающийся без ошибок».
Как вы уже могли заметить, команде нужно постоянно что-то вырабатывать. Я могу войти традиционно: «тимлид — это самый умный разработчик,» и сказать всем, что нужно делать, но рабочая ли это схема? Мне видится, что нет. Беспрекословное подчинение — не свойство нашей профессии.
Итак, если я не кодирую, то как же я могу повлиять на качество кода? Через изменение окружающей среды. Эдакая командная урбанистика. Часто разработчикам предлагают поднапрячься и превозмочь, но делать это, скорее всего, нужно не вам. Вы и так уже делаете зависящее от вас.
Мы снова послушаем дедушку Деминга, и он скажет нам, что не более 6% всех проблем находятся в поле деятельности рядовых работников. А значит 94% всех проблем должны решаться менеджментом. И эти проблемы связаны с тем, что окружающая среда не поощряет качество.
Стоит ли вообще слушать дедушку Деминга? Это большой вопрос. Практически уже 72 года назад высший менеджмент одной разгромленной в войне страны решил послушать. Затем с 1968-го по 2010-й их страна была второй экономикой мира.
А что это за такая окружающая среда при разработке программного обеспечения? Во-первых, это сами задачки. Помните выражение «мусор на входе — мусор на выходе»? Это справедливо и для нас как для системы, разрабатывающей ПО.
Если хотите посмотреть на забавную иллюстрацию этого, то рекомендую видео с экспериментом с красными и белыми бусинами. В нём работников «мотивируют» как можно лучше вынимать белые бусины и избегать красных. «Нормально делай — нормально будет».
youtube.com/watch?v=ckBfbv…
Путём этих размышлений мы пришли к тому, что без совместной работы троих людей над одной задачей её решение будет вопиюще неполным. А может ли решение быть полным? Нет, таковым оно быть не может. А может ли быть полным в достаточной степени? Да, такое возможно.
Правда, сразу хочется отметить, что здесь не всё так просто, вчера я уже писал об этом.
twitter.com/itunderhood/st…
А прочее — это уже действительно то, что нас окружает. Начиная с рабочего места, продолжая тем, как удобно взаимодействовать с разрабатываемым приложением в принципе. Можно ли запустить его локально? Как много времени занимает сборка? А что насчёт встреч?
Мы без конца проклинаем стендапы, и, разумеется, за дело. Формат «Что сделал?», «Что сделаю?», «Что меня блокирует?» фокусируется на ложных вещах, но такой формат очень подходит для проверки здоровья.
Они тоже являются окружающей средой. Помните я писал, что популярный формат стендапа фокусируется на ложных вещах? Давайте посмотрим подробнее. На чём фокусируются вопросы «Что сделал?», «Что сделаю?», «Что меня блокирует?»?
twitter.com/itunderhood/st…
Они фокусируются на занятости работника, а не на задачах. Что интересно сделать бизнесу при разработке новой функциональности? Выпустить её как можно скорее, выяснить, подходит ли она пользователям. Но тогда и фокусироваться надо на задачах, а не занятости работников.
Формат стендапа, в котором осуществляется проход по всем задачам и используется вопрос «что нам необходимо сделать, чтобы перевести задачу на следующий этап?» мне кажется куда более соответствующим этой цели. То есть даже вопрос — уже окружающая среда.
А что за известный специалист занимался в своё время вопросами балансирования сквозного прохода через всю организацию? Элияху Голдратт со своей теорией ограничений. Но применимы ли его идеи к нам? Да, на его идеях построена идея DevOps, и описано это в книге «Проект Феникс».
Полный хохотач в этом вопросе случается со мной по той причине, что в индустрию из DevOps'а утекла только непрерывная интеграция, которая была описана ещё в 1999-м году в «Экстремальном программировании» Кента Бека. А может, и того раньше в неизвестном мне источнике.
Если подводить итог под тем, что мне кажется необходимой деятельностью лида, то это будет выстраивание среды, способствующей качественной разработке программного обеспечения. И если давать этому более подходящий термин, то вместо «руководителя» я предлагаю «средоустроителя».
Герман Тебиев