5 правил кода

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

1. Не используйте единый репозиторий

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

При работе с крупными проектами это может быть полезно, но здесь есть и обратная сторона: вы обязаны использовать subversion, при этом уже не получится использовать Git. Git, несмотря на все свои преимущества, не поддерживает sparse checkout’ы наподобие subversion.

Sparse checkout позволяет вам проверять отдельные каталоги, являющиеся частью большого древа, не прибегая к проверке всего древа, как это делает Git. Это означает, что многие программисты или команды могут работать с отдельными частями древа, не пересекаясь.

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

2. Сначала задача, затем решение

У каждого есть некие излюбленные инструменты: Redis, MySQL и т.д. Я считаю это вполне естественным.

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

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

Это уже давно вызывает у меня негодование в отношении групп корпоративной архитектуры и их неимоверного превосходства над простыми смертными, которые, по сути, и создают код.

Зачастую именно такая группа решает, что именно будет использовать компания в качестве технологии или продукта — Kubernetes, OpenShift, AWS и т.п. Как правило, это происходит без достаточного понимания отношения имеющихся задач организации к тем задачам, для решения которых были созданы эти технологии. 

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

И чаще всего именно архитекторы (либо их истощавшие собратья — служба безопасности организации) становились причиной множества препятствий на пути достижения ими же поставленных целей.

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

3. Задавайте вопросы

Звучит очень легко и просто, даже по-детски. Тем не менее это не просто. Вам что-то непонятно? Задайте вопрос. Хотите знать почему сделано так, а не иначе? Задайте вопрос. Желаете знать саму цель проекта? Спросите об этом.

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

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

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

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

Задавая вопросы, оспаривая имеющиеся суждения и глубоко изучая информацию, мы совершенствуем команды, группы, самих себя и наши жизни. Мне удавалось срезать целые слои инфраструктур, просто задавая вопросы. Кто знает, может и вам удастся устранить много лишнего.

4. Квадратные стержни не пролазят в круглые отверстия

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

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

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

Что вместо написания объемного кода по преобразованию уязвимых данных, вы бы могли сделать основную работу с помощью соответствующей базы данных и ОРМ. 

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

Переговорите с менеджером о смене команды, найдите ОРМ и приступайте к работе. Остановитесь и займитесь теми вещами, которые на самом деле позволят действовать непринужденно. Оставьте эту проблему совмещения квадратных стержней с круглыми отверстиями заумным ребятам вроде сотрудников NASA. 

5. Используйте лучшие инструменты для работы (только не Java)

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

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

• Он может быть запущен где угодно.
• Автоматическое управление памятью (с помощью сборщика мусора).
• Обширное сообщество и множество фреймворков, библиотек, плагинов для JVM. 

Давайте же взглянем на вещи реально. Как много вы знаете магазинов софта, разрабатывающих на Java, которые пишут одну кодовую базу с намерением запускать ее на множестве архитектур, операционных систем и пр.? По крайней мере их точно не большинство.

Сегодня Java также не отличается уникальностью в управлении памятью. И в Go, и в Rust существует определенный способ уборки мусора. Python использует подсчет ссылок и многие другие языки тоже.

Помимо прочего, Java далеко не единственный язык с большими активными сообществами. Rust и Python также имеют подобные огромные и отзывчивые коммьюнити, а сообщество Go разрастается с каждым днем.

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

Это не играет очень важной роли, когда речь идет о серверах с гигабайтами свободной памяти. Пара сотен мегабайт для них — это не так уж много. Но в среде плотно контейнеризованного информационного пространства— пара сотен уже является астрономической. Python , правда, также страдает от этого недостатка.

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

Это оказывается очень важным для крупных организаций, где сетевая производительность является приоритетной. В таких случаях предпочтительнее загружать контейнер размером 5 Mb, но точно не 400 Mb.

Помимо этого, JVM и JIT-компиляция в Java оказывают негативное влияние на производительность кода. 

Для приложений с низкой задержкой и высокой производительностью или для сценариев, в которых двоичная упаковка контейнеров сервера очень важна, потеря производительности в связи с преобразованием байткода в системные вызовы не стоит преимуществ Java. 

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

Вы наверняка не станете использовать BASIC, чтобы организовать посадку на луну. Также вы вряд ли станете использовать Java для высокопроизводительного вычисления. Ищите решение, которое лучше подойдет для конкретной задачи.

---

Перевод статьи Peter Christian Fraedrich: 5 Rules of Code