5 советов сеньорам: автоматизация, отмазки, потери времени, слово пацана и образование

CBernardes

---

Об авторе

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

---

Источник

10 habits of Senior Software Developers (part 1)

---

Переводчик

Сергей Попов

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

Автоматизируйте всё что возможно

В сферах CI/CD и DevOps происходит столько всего, что порой это похоже на дурдом, куда вы ещё не готовы переезжать. Но можно сэкономить время на разработке, автоматизировав некоторые часто выполняемые действия, например:

• запуск ежедневно выполняемых скриптов, который можно запланировать;
• стандартные команды. Вместо того чтобы использовать четыре команды для запуска приложения, объедините их в один скрипт/команду: npm run prepareSeedBuildStart, npm start или prepareSeedBuildStart.sh;
• ежемесячные запросы данных, которые можно запустить с помощью скрипта.

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

Тестируйте свои фичи

Возможно, это звучит банально, но тем не менее многие допускают эту ошибку. Если нужно создать новое CRUD-приложение, не забудьте протестировать не только «счастливый путь» (happy path), но и «неверные пути» (invalid paths).

К invalid paths относятся попытки сохранения без данных, чтение данных, которыми не владеет инициатор, обновление без обязательного поля и так далее. Если вы всё же полагаете, что эти задачи входят в список обязанностей тестировщика или кого-то ещё, задайте себе несколько вопросов:

• Если будет выявлен баг, кто будет нести за это ответственность?
• Если баг будет выявлен в созданной вами фиче, кто, вероятнее всего, будет исправлять его?
• Что лучше: если вы сами обнаружите баг и исправите его или если это сделает кто-то другой?
• Как это отразится на ваших навыках программирования?

Думаю, нет смысла отвечать на эти вопросы. Надеюсь, что они заставят вас задуматься над тем, насколько важную роль тестирование играет в процессе разработки. Предположим, вам понадобится 15% дополнительного времени, чтобы протестировать фичу. Это позволит избежать:

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

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

Всегда сдерживайте свои обещания

Вы пообещали кому-то отправить файл через несколько минут? А как насчёт срочной услуги, о которой вас попросили в разговоре? Не забыли про сообщение, на которое обещали ответить «прямо сейчас»?

Мы все прекрасно понимаем, что такие запросы должны быть оформлены в виде заявок, но очень часто это правило не будет соблюдаться; именно поэтому я хочу напомнить, что надо непременно сдерживать свои обещания.

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

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

Никогда не говорите «на моём компьютере это работало»

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

• упорно требовать внедрения CI;
• удостовериться, что ваше приложение тестируется не только локально, но и после развёртывания в промежуточной среде или среде тестирования.

Как правило, возникают следующие проблемы:

• Вы локально установили зависимости или плагины, но забыли добавить их в проект (npm выяснит это).
• Вы добавили новые данные конфигурации в локальную БД, но забыли добавить их в скрипт развёртывания.
• Ваша локальная версия инструментов и плагинов отличается от их версии в среде.
• Вы не аннулировали кэш (как для фронтенда в браузерах, так и для бэкенда).

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

Постоянно учитесь новому

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

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

Само собой, лучше получать новые знания именно в своей профессиональной области. Впрочем, можно с уверенностью утверждать следующее: лучше учиться хоть чему-то (даже если это не относится к вашей сфере деятельности), чем не учиться вообще. У человека можно забрать всё, кроме его знаний.