Наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод.

Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).

Такой провокационный вопрос задал реддитор nenemen в сабреддите Java:

«Я думаю о том, чтобы свой следующий проект сделать на Kotlin + Spring Boot, но мощь всенародной любви к Kotlin и одновременно ненависти к Java заставляют всё это походить на какой-то культ. Поэтому хотел бы услышать аргументы «против».

Мы в FunCorp в своё время сделали именно такой выбор в пользу Kotlin. И сегодня соотношение Java/Kotlin у нас составляет примерно 20 на 80, продолжая уменьшаться при каждом удобном случае. Поэтому ответы на этот вопрос меня заинтересовали, и я стал листать секцию комментариев. Там наткнулся на реплику реддитора rzwitserloot, которая мне показалась настолько взвешенной, многосторонней и рациональной, что я захотел поделиться ей с нашей командой, а заодно и читателями Хабра.

Далее перевод его аргументов.

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

С этих собеседований вынес интересное наблюдение: в первую тройку «пожеланий» попадает такая трудно формулируемая вещь, как «хочется, чтобы в работе был смысл». Если начать раскручивать этот клубок, то часто приходим к более негативной формулировке «прошлый заказчик/бизнес не знает, чего хочет и постоянно меняет требования».

В такие моменты всегда вспоминаю, как познакомился с data-driven подходом. Для себя больше люблю называть это доказательной разработкой (по аналогии с доказательной медициной) и расскажу на примере. Сейчас этот подход кажется обычным и естественным, но когда-то стал для меня настоящим откровением. И, судя по вопросам кандидатов на собеседованиях, все еще может быть полезен, хотя обсуждается уже давно.

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

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

Буквально через два уровня абстракций я оказался в коде, датированном 2016-2017 годами, то есть занялся software archeology. В какой-то момент меня возмутило, что вместо интерфейса репозитория в конструктор класса сервиса была передана реализация. Ещё одним уровнем абстракции ниже оказалось, что это всё-таки был интерфейс, но назывался он просто ContentRepository, а не ContentRepositoryInterface, как написал бы любой адепт ООП и принципов SOLID. Это уже не лезло ни в какие ворота, и я потребовал у архитектора оснований (кстати, рекомендую его статью о том, как мы вдвое ускорили построение лент подписок). Он в свою очередь невозмутимо показал пункт внутренних правил оформления кода, где была проставлена ссылка на статью 2013 года («А» — археология, как и было сказано).

Под катом — перевод этого материала.

Примерно раз в неделю мой вечер выглядит так: я кладу в сумку симпатичную сорочку или две, красивую пару обуви и приезжаю в парк с открытой верандой, ресторан или клуб. Там уже собрались несколько десятков хорошо одетых мужчин и женщин, я быстро переодеваюсь и присоединяюсь к ним. С кем-то я знаком, мы тепло обнимаемся и обмениваемся парой слов за жизнь. Работает бар: можно взять бокал вина, коктейль или сок. Играет несколько старомодная, но красивая и ритмичная музыка. Вот она меняется, я слушаю первые такты, обвожу взглядом помещение, выбираю самую эффектную женщину и пытаюсь поймать её взгляд.

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

Единственное, о чем мы пожалели — что не применили это решение раньше.

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