Как стать программистомКарьераПереводы

Почему Senior-ы пишут тупой код и как разглядеть Джуна за милю

В одном из Slack-каналов моих разработчиков я заметил небольшую, но важную статью на Hackernoon. Она посвящена стремлению к простоте и лаконичности. Как сторонник тех же стремлений, я спешу поделиться с Вами её переводом.

Одной из моих любимых цитат являются слова Брайна Гётца, умного парня из мира Java, среди прочего, являющегося соавтором книги «Многопоточность в Java на практике». Фраза появилась в интервью, которое Oracle опубликовал под названием «Пишите тупой код». Гётца спросили о том, как писать хороший производительный код. Вот, что он ответил:

«Зачастую способ написания быстродействующего кода приложений на Java состоит в создании простого (тупого) кода — кода прямолинейного, понятного, чистого и следующего наиболее очевидным принципам объектно-ориентированного программирования».

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

Код Ведущего разработчика

Если Вы, как и я, когда-то были джуном, то наверняка помните свой опыт чтения кода Ведущего разработчика с мыслями вроде: «Я тоже могу так написать. Почему я не Senior?»

Тем не менее, тогда я долго пытался написать такой же код, но не смог. Для меня было загадкой то, что я понимаю код, но ведь он максимально прост! Должно быть что-то ещё.

«Где всё остальное?» — думал я. «Как вот ЭТО делает всю работу?»

С тех пор я выучил все принципы и качества кода, которые делали его простым: YAGNI, Принцип единственной ответственности (SRP), DRY, Принцип единого уровня абстракций (SLAP), слабое зацепление (low coupling), и т.д. И я стал «Ведущим разработчиком». (Вообще, я ненавижу словосочетание «Ведущий программист» («Senior Dev») и называю себя просто «разработчиком» («software engineer»), но это совсем другая история).

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

Как опознать Джуна за милю?

В книге «Рефакторинг: Улучшение существующего кода» Кент Бек отмечает:

«Любой идиот может написать код, который поймёт компьютер. Хорошие программисты пишут код, который могут понимать люди»

Вы всегда опознаете джуна, когда будете читать код, полный замудрёных однострочных выражений, неявных абстракций с уймой применений всех возможностей языка. Я бы сказал, что последнее встречается чаще всего. Это код, который кричит: «Посмотрите на меня! Мой создатель реально шарит в языке! Я использую стандартные интерфейсы синхронизированных ThreadLocal JavaBean-копий с кастомными обобщёнными исключениями и JAXB Lombok для генерации кода!»

Да, я написал ерунду, потому что ерунда — это то, во что может превратиться код, попади он в руки того, кто думает только об аспектах программирования, а не о людях.

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

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

Рецензия от меня

Разумеется, в названии своей статьи Скот Шип использует словосочетание «тупой код» для привлечения внимания. Тем не менее, он прав — в современных решениях мы часто встречаем стремление разработчиков получить не максимально лаконичное решение, а решение максимально крутое. И это идёт в ущерб функциональности. Этакий iPhone в кредит, не находите?

Я полностью разделяю мнение автора на тему стремления к простоте. И оно касается не только кода. Во всём — в архитектуре, в повседневной деятельности, в жизни — нужно понимать функциональное назначение того или иного элемента. И если Вам удастся побороть этот зоопарк из технологий/конструкций/вещей, Вы сэкономите энергию, время и деньги!

В завершение я бы хотел поделиться цитатой Леонардо да Винчи.

«Простота — это то, что труднее всего на свете; это крайний предел опытности и последнее усилие гения.»

Почему Senior-ы пишут тупой код и как разглядеть Джуна за милю: 4 комментария

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

    1. Кстати, как строите структуру кода? Сразу пишете или проектируете сначала?

  2. Интересно написано. Но для для новичков в Айти — я например проработал только 1.5 года — может быть не понятна иностранная терминология. Чем отличается «Джун» от «Senior», и зачем вообще нужен Senior. У нас в компании с например за этими словами закрепился дурной подтекст. Когда я пришел в команде было 4 разработчика. И один называл себя сеньором а двух других презрительно — джунами. Просто потому что он дядечка весьма уже в возрасте — по моему тогдашнему мнению — лет 45, никто не мог ему ничего возразить. Так вот весь день он сидел и играл в игрушки и работал от силы пару часов день. При этом ему явно платили как за двоих «джуниоров». Не понятно почему наш тестировщик держал его в компании, по блату скорее всего, или на резервный случай: вдруг понадобится на какой нибудь дикий проект, дырки в перфокартах строчить. В итоге когда начался кризис и начальство хотело урезать премии, мы объяснили ему после работы, что он не вписывается в корпоративную культуру нашей компании и он ушел. Теперь стараемся не брать никаких сеньоров

    1. Спасибо! В одной статье всего не охватить. Будет статья обо всём и ни о чём. Но про градации можете почитать в другой моей статье здесь https://devenergy.ru/archives/756

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *