В одном из 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.5 года — может быть не понятна иностранная терминология. Чем отличается «Джун» от «Senior», и зачем вообще нужен Senior. У нас в компании с например за этими словами закрепился дурной подтекст. Когда я пришел в команде было 4 разработчика. И один называл себя сеньором а двух других презрительно — джунами. Просто потому что он дядечка весьма уже в возрасте — по моему тогдашнему мнению — лет 45, никто не мог ему ничего возразить. Так вот весь день он сидел и играл в игрушки и работал от силы пару часов день. При этом ему явно платили как за двоих «джуниоров». Не понятно почему наш тестировщик держал его в компании, по блату скорее всего, или на резервный случай: вдруг понадобится на какой нибудь дикий проект, дырки в перфокартах строчить. В итоге когда начался кризис и начальство хотело урезать премии, мы объяснили ему после работы, что он не вписывается в корпоративную культуру нашей компании и он ушел. Теперь стараемся не брать никаких сеньоров
Спасибо! В одной статье всего не охватить. Будет статья обо всём и ни о чём. Но про градации можете почитать в другой моей статье здесь https://devenergy.ru/archives/756
Конечно же, описанный Вами сеньор скорее сеньор помидор, нежели Senior Developer. Но градации все равно помогают. Нужно только осознать их, понять наполнение.