Программируя - думай мозгом

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

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

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

Эта общая тенденция не очень хороша и полезна.

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


Если говорить чисто о себе, то нужно начать с того, что нужно задавать вопросы типа "А зачем это? А почему так? А как работает это? А в каких случаях эта практика будет вредить?". В общем, таки да, стоит просто почаще думать. Причём тут дело исключительно в том, что вы уже умеете думать, но возможно вы делаете это не так часто, как можете.

А вот если говорить о команде, то тут уже сложнее. Увы, я лично пока что не научился развивать команду в направлении думать. Но вижу примерно такие варианты:

  • Давать возможность совершить ошибку и объяснять в чем же ошибка;
  • Пичкать команду полезными статьями и показывать, что можно делать по другому (например, чуваки погрязшие в jQuery-лапше могут просто тупо не знать про knockout/angular/react и прочее);
  • Вместо спускания строгой директивы "так надо" стараться объяснять почему так надо. Тут хорошим примером могут быть код-стили: увы, очень часто код-стили пишутся без пояснения причин, зачем нужно то или иное правило. Отсутствие объяснения приводит к странным ситуациям, когда люди начинают считать код-стили чем то данным свыше и не хотят их менять, вне зависимости от того, полезны они или вредны;
  • Вовлекать других членов команды в аргументированные дискуссии, в обдумывание, в планирование, в код-ревью (вовлекать во все шаги разработки);
  • Вводить технические митинги о том, как стоит писать хороший код. Это не те техническое митинги, на которых вы обсуждаете какие-то унылые технологии;
  • Не давить авторитетом и пиздить тех, кто им давит
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.