Какие привычки делают меня лучше как разработчика ПО?

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

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

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

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

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

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


image

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

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

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

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

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

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


image

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

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

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

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

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

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

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


image

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

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

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

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


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

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


image

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

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

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

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

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


image

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

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

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

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

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


image

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

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

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

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

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


image

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

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

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

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

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


image

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

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

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

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

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

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

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


image

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

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

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

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

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


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

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

Комментарии 27

    +5
    Если включать тренажерный зал, то тогда лучше и «Высыпайтесь» совет включить.
    Гораздо важнее любой тренажерки.
      0
      А также хорошо питаться важно. Заметил что если сравнивать с вузом когда ел раз в день примерно (бывало еще реже, перекусами обходился), то когда на работу устроился и стал питаться нормально — резко поумнел (хотя возможно это с возрастом произошло, не знаю даже)
        +1
        Вот так люди придумали религию)
          0
          Скорее это связано с тем что пока ты студент ты по определению тупее чем преподы и аспиранты, а потом на работе начали окружать всякие люди.
            0
            Да нет, действительно когнитивные способности ниже были. Как минимум при плохом и недостаточном питании гораздо больше сонливость, хуже память, способность концентрироваться.
        +9
        Опыт показывает иное: разработчик в первую очередь должен пользоваться своим п/о сам — именно эта привычка сделает из любого разработчика самого лучшего. А вовсе не эти ваши гиты, канбаны и тренажёрный зал ;)
          +1
          Это конечно здорово иметь возможность пользоваться своим же ПО, так как ты видишь продукт и как разработчик и как пользователь. Это повышает заинтересованность в разработке, но что делать тем, кто лишен такой возможности? Например ПО для управления атомной станцией, РЛС или самолетом.

          А система контроля версия с возможностью локальных коммитов и легким способ реорганизовывать их — это очень удобно. Что-то пробуешь, меняешь и всегда можешь откатиться назад, что-то оставить, а что-то выкинуть и переписать.
            0
            В своей конторе я так и работаю. В целом согласен, но самому писать ТЗ, по кототому потом писать программу — это дико.
              0
              Когда я работал в Яндексе, нам говорили ровно противоположное: первое правило программиста — «я нерепрезентативен». Если что-то нравится лично вам (как пользователю программного продукта), это совершенно не значит, что то же самое понравится большинству пользователей. Нужно провести исследование и плясать от его результатов.
                0
                Это не противоречит тому, что если разработчик пользуется софтом который создает, то его заинтересованность в качественном выполнении будет выше. А для проведения исследований и анализа рынка есть другие люди. И опять же, если они сами пользуются продуктом их заинтересованность будет выше.
                  +1
                  Что же, глядя на то, как Яндекс регулярно генерирует новости своими же продуктами (то Почтой, то Диском, то Деньгами, то Картами, то КиноПоиском — но про сервис Новости в свете прошлых (и уж тем более предстоящих) выборов давайте деликатно промолчим) — думаю, что такая политика работает и даёт свои плоды, и верю Вам на слово.

                  Я вот такой роскоши позволить себе пока не могу — до сих пор реагирую на каждого обратившегося за помощью человека просто потому, что изначально делал своё п/о для людей, а в первую очередь — для себя.
                    0
                    Я работал в Яндексе 6 лет назад, и тогда качество продуктов в целом было высоким. Ну а изредка ошибки в production уходят у всех.
                    0
                    Это со стороны UX, а вот со стороны ошибок… ПО управления автомагнитолой — в половине случаев(сценариев) проигрывание ставится на паузу, в половине — нет. Это заметно сразу и означает что
                    а) разработчики не пользуются этим (банально машина не по их заработку),
                    б) тестов у них нет на все случаи (это даже юнит-тестами должно быть покрыто, не говоря о проверке всей системы, когда это видно невооружённым глазом).
                      0
                      Ну так тестирование по-любому должно быть
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Если ваше ПО написано для разработчиков то возможно Вы правы, но если им будут пользоваться люди далекие от IT то получается что выделает продукт под себя а не для клиентов.
                      А вовсе не эти ваши гиты, канбаны и тренажёрный зал ;)

                      Про git написана глупость. Тренажерный зал не обязателен, необходимо хотя бы делать зарядку и нормально питаться, я очень сильно сомневаюсь, что большинство людей способны создавать что-то стоящее, когда у них какие то серьезные проблемы со здоровьем.
                      +3
                      Не затачивать всю свою жизнь в работу, потому что это ведет к быстрому выгоранию.
                        –1
                        «лучше быстро сгореть, чем долго тлеть»
                        +5

                        Сколько ни читаю подобных статей, не понимаю, со мной что-то не так, либо с автором.
                        Работа, pet-project, спортзал, книги (в идеале не только технические, но и художественные), сон, еще должен быть отдых, еще девушка, плюс/минус еще ребенок, ремонт. Про пробки и транспорт не забывайте. Ааа, еще новый Angular подоспел.


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

                          +1
                          — семья, — ремонт и всякая работа по дому, немного -отдых и нормально)
                            +3
                            Ну так он и не пишет, как стать хорошим семьянином. Все совместить не получится как ни крути.
                              +4
                              Так сон же в статье не упомянут. Вот вам еще 8 часов в сутки
                                0
                                Ремонт — тот же спортзал: поднятие тяжестей, имитация высокогорья (работа в маске), тренировка ловкости и координации (поклейка этих, ..., прилипающих обоев).
                                  0
                                  Так статьей про тайм-менеджмент не меньше, чем «подобных» :)
                                  0

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

                                    0
                                    Про листание «фейсбука» совет на уровне «не смотрите телевизор». Только не учитывает нюанс, что один по ТВ смотрит рекламу прокладок и дом-2, а другой смотрит канал культура и нэшнл-географик. Подпишитесь в фейсбуках на тематические каналы по тому же программированию и прочие %развивающие_темы_нейм% и тратьте по часу-два в день с пользой для развития и необходимым отвлечением от кодинга.
                                      0
                                      Парочка рекомендаций довольно субъективна и скорее индивидуальна. Я например не могу совмещать тренажёрку и программирование. А если могу, то исключительно после программирования, ибо мысли после занятий превращаются в кашу, и появляется дикое желание упасть и уснуть. Зато положительно на мне сказывается сдвиг рабочего времени в ночь. Вот так внезапно: чувство лёгкой сонливости мне почему-то добавляет внимательности и сосредоточенности. По сему за одну ночь не редко могу сделать то, что не могу дня за три. Жаль пока эту особенность не могу совместить с работой. Но я не думаю, что это будет хорошей рекомендацией для ряда людей.
                                      А вот в цзен TDD так и не въехал (именно в TDD, а в не в тесты). М.б. как-то не так применял. М.б. кто-нибудь посоветует неплохую литерату на тему.

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

                                      Самое читаемое