Как написание своего плагина может поменять то как вы пишете код
Привет, я — Лёша, и я люблю веб. Иногда это даже взаимно.
В жизни часто бывает, что едва ты начинаешь думать, что наконец стал разбираться в чём-то, что-нибудь происходит и оно говорит тебе: «Нет». И это не всегда плохо.
Например, я думал, что более-менее знаю, как нужно писать код, пока не написал свой плагин. И это очень сильно поменяло мой подход к программированию.
Код — это продукт, программисты — его пользователи
При создании плагина ты словно запускаешь стартап на минималках: нужно понять своего пользователя, в идеале пообщаться с ним, выявить потребности, ожидания и вот это все маркетинговое. Это классный опыт, особенно если до этого карьера ограничивалась только непосредственно разработкой. Я перестал воспринимать свой код как что-то техническое. Он стал решением чьей-то задачи, тем, чем пользуются другие люди. Продуктом. Это меняет мышление.
Но ещё больше его меняет тот факт, что это отношение к коду как к продукту можно применить и к обычной повседневной разработке, не только к написанию плагина. Каждый день я пишу код, который будет использовать моя команда. И команда пишет код, который буду использовать я. Можно сказать, что каждый из нас создает продукт друг для друга.
А любой продукт, на мой взгляд, имеет 3 важные характеристики: у него есть пользователи, он решает задачу и он не должен быть переусложненным.
Продукт имеет пользователей
Именно пользователи определяют, что такое продукт. Я бы сказал, что продукта не существует без пользователей. Они дают обратную связь, говорят, что им не нравится, чего бы им хотелось увидеть. Это важно, потому что это задает автору продукта направление движения.
В «код-как-продукт», конечно, не так радикально, всё-таки код пишется в первую очередь для решения бизнес-задач. Но на второе место я бы поставил то, что мы пишем код для своих пользователей, для коллег.
Это предполагает, что именно они определяют то, каким должен быть код. То есть, должен быть какой-то механизм постоянной обратной связи, где бы разработчики, как пользователи продукта, могли бы говорить о том, чего бы им хотелось видеть в коде. Как это правильно сделать, чтобы не было кринжово и из-под палки — тема отдельной статьи.
Лично я, например, сделал так, что ребята в течение недели могут присылать мне в личку код и свою обратную связь по нему. На ретро я выбираю наиболее показательный кейс, который можно улучшить и мы вместе обсуждаем как это можно сделать. При этом автор кода, естественно, не называется.
Продукт решает задачу
Вы не знаете, какую конкретно задачу будут решать ваши коллеги, когда будут пользоваться вашим кодом. Но вы знаете, что какой бы она ни была, она должна быть решена быстро и легко.
Поэтому именно простота кода теперь для меня является главной ценностью кода. Не использование всех возможностей языка, не использование паттернов и сложных абстракций и даже не, прости господи, производительность (в разумных пределах, конечно). Простота.
Создать лишние переменные, чтобы повысить читабельность кода? Сюда. Нарушить DRY, чтобы не плодить абстракции? Запросто. Давать длинные, некрасиво выглядящие самоописывающие имена? Беру!
Любое техническое решение теперь я принимаю исходя из того, что я пишу продукт для команды, у которой есть разный контекст, разный технический уровень. В конце концов, для будущего себя, который откроет код через 1 год. И единицей измерения качества кода теперь я считаю количество минут, необходимых постороннему разработчику «с улицы» для полного понимания того, как и почему работает код.
Продукт не должен быть перенасыщен функциональностью
Когда пользователи говорят о том, что бы они хотели видеть в продукте, как правило, эти пожелания не реализуются сразу. Они анализируются, в них выделяется что-то абстрактное, общее и уже потом претворяются в жизнь. «Пользователь хочет A и B. Что, если вместо этого мы сделаем C, которое позволит делать и A, и B?». В противном случае на каждое действие было бы по отдельной кнопке.
И это то, что можно использовать и в обычной работе. Не реализовывать фичу в «лоб», а подумать — можно ли то, что я хочу написать, использовать для других целей? Относиться к коду как к API, не слишком конкретно, но и не слишком размыто. Уметь балансировать между абстрактностью и функциональностью, чтобы не свалиться в оверинжиниринг.
Код, который реализует какую-то фичу «в лоб», это повод обратить внимание. Может быть, это можно абстрагировать? Если можно, то насколько сильно это усложнит код? Иногда какие-то вещи всё-таки стоит оставлять как есть, если это значительно повышает простоту кода. Либо внести только какие-то небольшие изменения, потому что простота кода — главный приоритет. Да, это сложно, нужно балансировать, но разве наша жизнь и есть не что иное, как постоянный поиск компромиссов?
Заключение
Обсуждать с командой код как продукт с точки зрения пользователя.
Делать простоту и читабельность кода главным приоритетом.
Не реализовывать фичи в лоб, а думать над абстракцией, но помня про п.2.
Это то, к чему я в итоге пришел. И я ни в коем случае не догматизирую это. Это работает для меня, но, может быть, не будет работать для вас. В любом случае, напишите свой плагин, это наверняка что-то поменяет в вас.
Ссылка на мой плагин.
Habrahabr.ru прочитано 2555 раз
