Привет, Хабр! Представляю вашему вниманию перевод статьи «What habits made me a better Software Engineer?» от Sonny Recio.

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

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

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

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

Создавайте архитектуру для каждого приложения

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

Большую часть времени я придерживался лучших практик: помня, когда использовать шаблоны проектирования и разделяя ответственность кода, используя принципы SOLID и Domain-Driven Design(DDD) подход. Может быть я немного перфекционист, когда дело касается чистого кода, потому что я верю, что это сохранит мне много времени в будущем и в дальнейшем уменьшит частоту появления спагетти-кода, которая увеличивает энтропию программного обеспечения с течением времени.

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

Архитектура программного обеспечения стала намного очевиднее, когда я перешел к MVC парадигме и перенес DDD в миксины. Это просто показывает как важна концепция разделения ответственности (Separation of Concerns, SoC) в разработке приложений, тем более при разработке крупномасштабных корпоративных приложений. Это был наиболее продуктивный момент в моей жизни как разработчика ПО.

Единственное исключение, когда я пишу простые сниппеты или демо-приложения, которые мне нужно протестировать для демонстрации. Или какое-то экспериментальное приложение для тестирования.

Всегда пишите тесты

Еще одна вещь, которую я практикую в моей работе разработчика ПО — всегда писать тесты. Test-Driven Development (TDD), на мой взгляд, очень важная дисциплина для реализации Юнит-тестов.

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

Более того, TDD позволяет создавать более чистый код и архитектуру, что не дает вашему коду стать неуправляемым (спагетти-код) в долгосрочной перспективе через реализацию Интерфейсов и SOLID принципов. Если все сделано правильно, вы можете использовать заглушки в качестве фиктивной замены для конкретной реализации логики.

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

Возьмем к примеру функцию Add(). Вы наверняка знаете как создать тест для этой функции и применить методологию TDD. Но что если вам нужно написать тест, который проверяет отображение информации во ViewModel? Вы конечно можете сделать это. Но так ли это необходимо?

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

Пишите статьи о том, что вы изучили

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

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

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

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


Может вам стоит попрактиковаться в дисциплине «Техника Феймана»?

Используйте систему контроля версий такую как git

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

Благодаря системе контроля версий такой как git, я могу создавать ветки, которые относятся к определенным фичам, над которыми мне необходимо работать. В таком случае вам не нужно будет откатываться назад, потому что скорее всего вы не сможете объединить ветку с фичей и мастер ветку, пока хорошенько не протестируете ваш код и не убедитесь, что он отлично работает. Если что-то пошло не так, вы можете выйти из этой ветки без объединения с мастер веткой.

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

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

Используйте канбан-доску

Когда я серьезно занимаюсь проектом или идеей, я использую приложение с канбан-доской, например trello. Я помещаю на нее все свои идеи/баги/проблемы, с которыми я сталкиваюсь при создании своего MVP (minimum viable product, минимально жизнеспособный продукт). В командах я обычно вижу, что разработчики используют trello в качестве их обычной практики, чтобы отобразить идеи и фичи, которые нужно преподнести.

В канбан-досках вы обычно видите следующие колонки в соответствии со статусом задачи над которой вы сейчас работаете: To-do (нужно сделать), In Progress (выполняется) и Done (выполнено). Вы также можете расширять набор колонок. У некоторых команд, в которых я работал, на доске задач (доске trello) есть статус «For Discussion», в который задачи попадают для обсуждения разработчиками до перехода их на статус «To Do» и готовности к реализации программистами.

Как отдельного пользователя, который работает над несколькими проектами (будь то мой собственный проект или стартап или что-то в этом роде), это избавило меня от кучи головной боли. Я стал лучше понимать, куда я в данный момент иду и какие идеи уже были реализованы.

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

Решайте проблемы под другим углом

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

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

Я также пытаюсь проанализировать скорость работы алгоритма в моем коде с использованием нотацию О большое.

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

Занимайтесь в тренажерном зале

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

Ученые сделали открытие, что физические упражнения могут сделать вас умнее. Согласно исследованию, упражнения на выносливость улучшают когнитивные способности (прим. перев. — память, внимание, концентрация, воображение, логическое мышление) и защищают мозг от дегенерации.

Я люблю тренироваться в зале, и это приносит свои плоды. Нам не нужно работать и утомлять себя 24/7 перед экраном компьютера. Нам необходимо заниматься физическими нагрузками и быть здоровыми.

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

Избегайте прокрастинации

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

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

Давайте немного посчитаем сколько времени вы тратите на фейсбук: вы сидите на фейсбуке около 2х часов в день. Вы обычно это делаете 30 раз в месяц. Теперь умножим 2 часа на 30 дней. Получается 60 часов, верно? Это почти три дня. Это может звучать не так страшно. Итак, давайте сделаем подсчет за год.

Теперь, предположим, что вы тратите 3 дня в месяц на фейсбук. Умножаем это на 12. И получается, что вы тратите 36 дней, всего лишь используя фейсбук.

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

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

Читайте книги

Наконец, это привычка, которую я ненавидел больше всего. Чтение книг. Но теперь я ценю ее. Я читаю книги каждый день.

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

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

Это заставляет меня лучше думать и делает меня лучше как программиста в целом.

Финальные мысли

Я бы не смог стать лучше и успешнее как разработчик ПО без этих привычек.

А что насчет вас? Какие привычки делают вас лучше как разработчика? Поделитесь ими в комментариях ниже.