Кодер говорит о коде
Том здесь пишет, страстный разработчик всего, что связано с веб и нативными технологиями. Прошло много лун с тех пор, как я впервые начал писать несколько строк кода. Настал славный момент «Hello World», и с тех пор я написал намного больше строк гораздо большего количества кода, начиная от систем оповещения в реальном времени, медицинских приложений, поддерживающих врачей в их повседневных задачах, до многоплатформенных встреч - и - программное обеспечение для планирования и управления. Попутно я тоже кое-чему научился, и сегодня я хочу поделиться одним аспектом кодирования, который не всегда может получить столько внимания, особенно в тяжелые времена в середине проекта. Давайте поговорим об ответственности кодера, а если быть точнее, о наследии кода кодера.
Пирамиды Javascript
Работа архитектора заключается не только в том, чтобы определить фундаментальную планировку нового здания, форму стен, окон и дверей или выравнивание дома, пропорциональное полуденному солнцу. Помимо всего прочего, архитектор знает, что здание должно выдержать долгие годы, что оно должно выдерживать суровую природу сильных ветров, проливных дождей, холодной зимы и жаркого лета. Конечная цель работы архитектора - сделать так, чтобы у людей, живущих в здании, был безопасный дом. Все дело в долговечности его работы. Все дело в его наследии.
В разработке программного обеспечения все идет очень быстро, особенно при работе в стартапах. Важно быстро выпускать новые функции, завоевывать популярность на рынке и поддерживать интерес пользователей. Фокус во время разработки, как правило, ограничивается текущим спринтом или реализацией этой одной высокоприоритетной функции как можно скорее.
Тем не менее, когда я пишу код, не следует ограничиваться только тестами, которые светятся зеленым цветом, или только крайним сроком, который должен быть достигнут. Оказавшись на свободе, люди используют приложения, которые могут полагаться на них в своей повседневной работе. Программа, которую я создаю сегодня, - это наследие, которое я оставлю завтра.
Возьмем для примера Интернет: никогда не было так просто найти компоненты, которые обеспечивают функциональность, которую я ищу прямо сейчас, через NPM. Они быстро устанавливаются и подключаются к остальной кодовой базе. Но когда дело доходит до долговечности моего приложения, сторонние зависимости могут остановить весь процесс обновления, b / c обновление этой одной зависимости останавливает работу другой. Это баланс между тем, что реализовать самостоятельно, форкнуть или установить напрямую из диспетчера пакетов.
Однако код от сторонних поставщиков может подойти. Перед использованием библиотеки или фреймворка важно проверить некоторые факторы: насколько хорошо было обслуживание в прошлом, сколько активных вкладов было сделано сейчас, есть ли дорожная карта с изложением будущих изменений или улучшений, полностью ли пакет управляется сообществом или поддерживается спонсоры, чтобы помочь в его развитии?
Переходя от внешнего кода к моей собственной кодовой базе, я постоянно должен напоминать себе об одной вещи: не срезать углы во время разработки, чтобы быстрее достичь цели. Каким бы заманчивым это ни показалось в краткосрочной перспективе, плохо спланированный код отомстит и нанесет ответный удар. Размышление о коде больше, чем его написание, помогает смягчить многие проблемы. Ключевым фактором здесь, безусловно, является опыт, но и младшие разработчики с самого начала должны понимать важность поддерживаемого кода. То, что сейчас приводит к ошибкам, может никогда не быть исправлено из-за сроков проекта и может быть решено только обходными путями, что приведет либо к беспорядку в коде, плохому взаимодействию с пользователем, либо к обоим.
Менталитет машиниста
Еще один аспект продуманного программирования, о котором я хочу написать, - это целевая аудитория приложения, пользователь. Поскольку я сижу с 9 до 5 перед экраном своих электрических слайд-линейок, просматривая строки кода и сосредотачиваясь на задаче, которую мне поручили, трудно помнить, что вся моя работа в конечном итоге для использования тем, кто использует его частично или полностью во время повседневной работы. И не имеет значения, создаю ли я приложение для нетехнических специалистов или API для других разработчиков - то, что я создаю, должно быть эргономичным в использовании.
Я знаю по собственному опыту, что пользователи могут взаимодействовать с вашим приложением странным и по большей части необъяснимым образом. Я как создатель склонен отвергать «непреднамеренное» поведение моего сервиса, тем более, если я уже вложил в него много времени и энергии. Тем не менее, сохранять спокойствие при получении отзыва и, если необходимо, заставлять себя прислушиваться к нему, играет ключевую роль в понимании фактического, реального поведения аудитории.
Мы, разработчики, живем в мире порядка и единообразия при кодировании, где применяется особый вид физики и гравитации и где мы знаем все правила. Это мир, который нужно принять и полностью погрузиться в него, как мы его создатели и обитатели. Но столкновение с обратной связью, то есть критикой извне, обычно приводит к ее неприятию разработчиками. Работа с пользовательскими отчетами и опциями должна быть изучена и оценена как важный вклад в разработку. Это урок, который я усвоил, и он очень помогает на каждом этапе проекта быть открытым для изменений и обратной связи.
process.exit ();
Подводя итог, подумайте не только о коде, который вы пишете сегодня, но и о том, который люди будут использовать в ближайшие годы. Принимайте продуманные решения относительно использования пакетов внешнего кода, а также структуры и реализации проекта, чтобы конечный продукт можно было использовать эргономично и эффективно, отражая фактические потребности целевой аудитории. Понимание обратной связи является ключевым моментом и очень помогает выпускать качественный продукт, которым можно гордиться.
- Tom
