Привет, я — Лёша, и я люблю веб. Иногда это даже взаимно.

В жизни часто бывает, что едва ты начинаешь думать, что наконец стал разбираться в чём-то, что-нибудь происходит и оно говорит тебе: “Нет”. И это не всегда плохо.

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

Код — это продукт, программисты — его пользователи

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

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

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

Продукт имеет пользователей

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

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

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

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

Продукт решает задачу

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

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

Создать лишние переменные, чтобы повысить читабельность кода? Сюда. Нарушить DRY, чтобы не плодить абстракции? Запросто. Давать длинные, некрасиво выглядящие самоописывающие имена? Беру!

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

Продукт не должен быть перенасыщен функциональностью

Когда пользователи говорят о том, что бы они хотели видеть в продукте, как правило, эти пожелания не реализуются сразу. Они анализируются, в них выделяется что-то абстрактное, общее и уже потом претворяются в жизнь. “Пользователь хочет A и B. Что, если вместо этого мы сделаем C, которое позволит делать и A, и B?”. В противном случае на каждое действие было бы по отдельной кнопке.

И это то, что можно использовать и в обычной работе. Не реализовывать фичу в “лоб”, а подумать — можно ли то, что я хочу написать, использовать для других целей? Относиться к коду как к API, не слишком конкретно, но и не слишком размыто. Уметь балансировать между абстрактностью и функциональностью, чтобы не свалиться в оверинжиниринг.

Код, который реализует какую-то фичу “в лоб”, это повод обратить внимание. Может быть, это можно абстрагировать? Если можно, то насколько сильно это усложнит код? Иногда какие-то вещи всё-таки стоит оставлять как есть, если это значительно повышает простоту кода. Либо внести только какие-то небольшие изменения, потому что простота кода — главный приоритет. Да, это сложно, нужно балансировать, но разве наша жизнь и есть не что иное, как постоянный поиск компромиссов?

Заключение

  1. Обсуждать с командой код как продукт с точки зрения пользователя.

  2. Делать простоту и читабельность кода главным приоритетом.

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

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

Ссылка на мой плагин.

Комментарии (17)


  1. Apv__013
    23.05.2024 05:31
    +12

    Бла бла


    1. theillarionov Автор
      23.05.2024 05:31

      ❤️


  1. DamBalDoor
    23.05.2024 05:31

    Интересно, спасибо!


    1. theillarionov Автор
      23.05.2024 05:31

      ❤️


  1. UnknownQq
    23.05.2024 05:31
    +3

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

    Леш (обращение сугубо из текста), ты - джун?

    Именно пользователи определяют, что такое продукт.

    Я вот в качестве контрпримера приведу мелкомягких: xp ->7->8->10->11 Самое забавное, что вот с каждым выпуском они утверждение в цитате, имхо, вертели все активнее и активнее. Сейчас уже турбины оборотам позавидуют. Но, простите, я отклонился: иногда пользователи даже не знают о продукте и найдя его случайно - радуются как дети: и все им удобно. Это я к тому, что решение каким будет продукт все-таки принимает не пользователь.

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

    А система git, ну или отдельный ресурс, под это дело не проще ли? А если пользвателей будет 1000? 1 000 000 ? Нет, я серьезно - раз программист, так делать нужно все основательно.

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


    1. theillarionov Автор
      23.05.2024 05:31

      Леш (обращение сугубо из текста), ты - джун?

      Нет.

      Я вот в качестве контрпримера приведу мелкомягких

      Сложно что-то говорить про мелкомягких, всё-таки компании такого размера не совсем стандартный случай. Я больше про то, что обычно создание продукта ведь начинается с пользователя. Кастдев, все дела.

      А система git, ну или отдельный ресурс, под это дело не проще ли? 

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

      В общем, простите меня, Алексей, может быть я желчный слегка.. 

      Ничего страшного, бывает )


      1. UnknownQq
        23.05.2024 05:31
        +1

        Нет.

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

        Речь идет про ретро внутри команды.

        Так внутри команды тем более проще на гите (хоть гитлаб, гитхаб или еще какой-нибудь гит*) создать проект и туда команда будет заливать и пул реквесты, если кому-то что-то прямо надо, и баги. Оно же для этого и сделано. Это к вопросу программистам от программистов.

        всё-таки компании такого размера не совсем стандартный случай

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


        1. theillarionov Автор
          23.05.2024 05:31

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

          "Об этом" это о чем конкретно?

          Так внутри команды тем более проще на гите

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

          Идея рождается у, условно, программиста, он начинает ваять. Есть его взгляды, а есть - пользователей.

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

          Некоторые до сих пор, кстати.

          Ну, это ведь как раз-таки подтверждает, что пользователи создают продукт. Хабр сейчас точно совсем не тот, каким был. И концептуально, и по трафику.

          Просто, вся эта статья похожа на статью выпускника школ программирования 

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


          1. theillarionov Автор
            23.05.2024 05:31

            Не знаю, может статью надо было назвать "Свежий взгляд на старые правила", что ли )


          1. UnknownQq
            23.05.2024 05:31

            "Об этом" это о чем конкретно?

            Ну, это уже слишком сильно выглядит как попытка пропиариться, причем, весьма неуклюжая.

            Если нет анонимности

            То есть, если мне нравится, например, KeePass, у меня есть предложение к автору, я обязан делать это анонимно? Я немного утрирую, но Вы точно ту литературу читаете?

            Ну, все книжки по запуске продуктов как раз-таки и пишут о том, что это неправильный подход

            Ехидно подмечу, что запускают те, кто не читают такие книжки, а потом уже их пишут.

            Чем?

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

            Вы путаете спрос на приложение (если это коммерческая тема) с пожеланиями для развития приложения.

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


            1. theillarionov Автор
              23.05.2024 05:31

              Ну, это уже слишком сильно выглядит как попытка пропиариться, причем, весьма неуклюжая.

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

              То есть, если мне нравится, например, KeePass

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

              Возможно и правда это не совсем очевидно из статьи.

              то Вам определенно стоит рассмотреть другие точки зрения, некомфортные

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

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

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


            1. theillarionov Автор
              23.05.2024 05:31

              Кажется я понял, да, мне не нужно было размещать статью в "Совершенный код"


        1. raspberry-porridge
          23.05.2024 05:31
          +1

          пользователи имеют синдром отмены. Некоторые до сих пор, кстати.

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


  1. rukhi7
    23.05.2024 05:31

    Ссылка на мой плагин.

    Это конечно хорошо, еще бы понять, а почему там нужен именно плагин, разве анимации не работают без плагина?

    Я правильно понимаю сам плагин в каталоге ЛИБ, а полный проект это демонстрашка для него?

    Но плюс поставил в надежде на более содержательное продолжение.


    1. theillarionov Автор
      23.05.2024 05:31

      разве анимации не работают без плагина?

      Работают, конечно ) С помощью плагина привязывается проигрывание анимации к скроллу. По сути то же самое, что и scroll-timeline, только более кастомизируемое и работающее во всех браузерах уже сейчас

      Я правильно понимаю сам плагин в каталоге ЛИБ

      Сам плагин лежит в lib, да. В docs - примеры.


      1. rukhi7
        23.05.2024 05:31

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

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


        1. theillarionov Автор
          23.05.2024 05:31

          Ничего, у него нет зависимостей. Установка вот здесь - https://github.com/the-illarionov/the-supersonic-plugin-for-scroll-based-animation?tab=readme-ov-file#installation

          Вот здесь примеры https://the-illarionov.com/the-supersonic-plugin-for-scroll-based-animation/examples но кажется надо под vpn заходить