Несколько важных правил написания кода

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

Возможно, вы никогда не слышали о едином репозитории (тогда вам можно только позавидовать). Объясняем: в нем объединено большое количество репозиториев, содержащих исходное ПО для вашего проекта. 

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

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

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

2. Сначала – план решения, только потом инструменты

Совершенно естественно, что у всех есть свой излюбленный инструментарий: Redis, MongoDB, MySQL или любой другой. Проблемой это становится тогда, когда мы на все задачи начинаем смотреть через призму этих инструментов и ищем решение не с позиции логики, а отталкиваясь от своего набора “любимчиков”. 

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

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

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

3. Не бойтесь спрашивать

И не отмахивайтесь от этого “детского” совета. На самом деле многие забывают о таком простом, но крайне важном правиле. Что-то непонятно? Спросите. Хотите уточнить определенный момент? Спросите. Сомневаетесь? Спросите.

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

К тому же, это один из самых действенных способов, как влиться в коллектив или обосноваться на новом рабочем месте. Главное – не бойтесь показаться глупым. Обращаться со всевозможными вопросами к более опытным коллегам – это нормальная линия поведения для новичка. Только так можно разобраться во всех нюансах рабочего процесса организации, который довольно часто строится на принципах “так нужно”, “здесь так принято” и т.п. 

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

4. Не пытайтесь вставить квадратный колышек в круглое отверстие

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

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

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

Лучше обсудите с менеджером возможность перейти в другую команду; всё-таки смените БД и начните работать с ОРМ. Не стучитесь в закрытые двери и не толките воду в ступе! Вместо этого сделайте так, чтобы у вас была возможность действовать в комфортных условиях. А проблемой совмещения квадратных колышков с круглыми отверстиями позвольте заняться умникам вроде учёных NASA.

5. Выбирайте  лучшие инструменты (не зацикливайтесь на Java)

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

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

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

А теперь попробуем взглянуть на вещи трезво. Сколько вы можете назвать магазинов софта, применяющих в работе Java, которые разрабатывают один код и намерены запускать его на многих ОС или архитектурах? Наверняка таких не большинство. 

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

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

В конце концов, не стоит забывать и о недостатках Java, которые нивелируют все перечисленные преимущества. Один из таких – зависимость языка от JVM, из-за чего приложениям требуется больше памяти для работы.

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

А вот контейнеры компилируемых конкурентов Java вроде Rust и Go очень маленькие и скудные. Они чаще всего имеют лишь единственную двоичную систему и весят примерно 4 Мб. Это имеет значение для крупных компаний, в которых сетевая производительность играет важнейшую роль. Между контейнерами размером 5 и 400 Мб они естественно предпочтут загружать первые.

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

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