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 не лучший вариант для вычислений высокой производительности. Не ленитесь искать решение, которое наилучшим образом подойдет для вашей конкретной задачи.