Привычки, которые должен усвоить каждый программист

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

Знай свои инструменты

На первый взгляд это может показаться очевидным. «Да, очевидно, я знаю, как писать код в моем редакторе и использовать grep в моей оболочке». Моя точка зрения выходит за рамки этого. Я имею в виду, что вы должны действительно (освоить) свои инструменты до такой степени, чтобы использовать функции, ускоряющие вашу работу.

Давайте посмотрим на пример!

Мои любимые ИДЕИ исходят от JetBrains. Они создают IntelliJ, PyCharm, WebStorm и многое другое. Эти IDEA имеют (почти) одинаковые функции и сочетания клавиш. На протяжении многих лет я посвящал время изучению наиболее полезных сочетаний клавиш, и это делает рефакторинг действительно быстрым.

Переименовать класс? Один ярлык. Извлечь код в метод? Один ярлык. Запустите тест в режиме отладки. Один ярлык.

Это простой пример, но я думаю, вы поняли мою мысль. Я часто вижу, как инженеры младшего и старшего звена используют мышь для нажатия кнопок в пользовательском интерфейсе или копирования и вставки при переименовании переменной. Не относитесь к своей IDEA как к простому текстовому редактору; используйте его как мощный инструмент!

Вы не только сэкономите время, но и почувствуете себя прекрасно ⭐️

Не стремитесь к совершенству

В начале своей карьеры я хотел, чтобы весь код в системе моей команды был идеальным. Я часами занимался рефакторингом классов CSS, думая об именах переменных и создавая красивые абстракции. Затем в один прекрасный день было решено, что система будет заменена другой системой от другой команды 😮 Весь мой идеальный код просто стал бесполезным.

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

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

Поймите, что вы строите

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

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

Абстрактно, но не слишком рано

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

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

Подумайте об этом: вам поручили создать веб-сайт с определенным дизайном. Например, меню в верхней части страницы. "Ага!" вы говорите: «Позвольте мне сэкономить время себе и своим коллегам, создав компонент TopMenuWebsite, который мы можем повторно использовать для следующего веб-сайта».

На следующей неделе компания или клиент говорит вам, что им нужно меню справа, а не вверху. «О черт, я только что потратил столько времени на создание компонента TopMenuWebsite, но теперь он бесполезен».

Да, это простой пример, но суть вы поняли.

Хорошее эмпирическое правило: не абстрагируйтесь, пока у вас не будет трех примеров. Это даст вам хорошее представление о том, какие части можно абстрагировать, а какие нет.

Не переусердствуйте

Я инженер — я провел годы в школе, изучая компиляторы, математику и низкоуровневые языки. Это означает, что я должен создавать сложное программное обеспечение, верно? Нет!

Все слышали о [принципе KISS] (https://www.wikiwand.com/en/KISS_principle)?

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

https://en.wikipedia.org/wiki/KISS_principle

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

Вывод

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

Первоначально опубликовано [здесь] (https://prplcode.dev/5-good-habits-of-a-software-engineer/).