4 практики кодирования, которые я перенял, работая в стартапе

4 практики кодирования, которые я перенял, работая в стартапе

2 марта 2022 г.

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


Масштабируемость дизайна


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


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


Допустим, при импорте сотрудников из сторонних систем, Gusto и BambooHR, у них должны быть следующие требования к настройке:


  • Сопоставление местоположения (сотрудники, соответствующие местоположению в рамках третьей стороны, должны быть добавлены только в местоположение, выбранное клиентом)

  • Возможность отправить приглашение всем успешно импортированным сотрудникам

Здесь решение простое, как показано в примере кода Vue.js ниже:


```javascript


<шаблон>




>




настраивать() {


постоянное состояние = реактивный ({


индекс: 0,


интеграция: $route.params.integration,


конфигурация: {},


функция startImport () {


startBackgroundJob(state.integration, state.configuration);


функция setMapping (сопоставление) {


state.configuration.locationMapping = сопоставление;


функция setInvite (canInviteEmployees) {


state.configuration.inviteEmployees = canInviteEmployees;


функция следующая вкладка () {


состояние.индекс++;


return {состояние, startImport, setMapping, setInvite, nextTab};


Но что, если мы добавим еще одну интеграцию, Zero, которая также требует сопоставления типов отпусков (т. е. синхронизации ежегодного отпуска, отпуска по болезни и отпуска по уходу за ребенком, которые могут быть у сотрудника, в нашей системе). Мы могли бы либо продублировать шаблон, который у нас есть выше, и добавить новый элемент, leave-mapping, либо мы могли бы повторно использовать этот шаблон и убедиться, что интеграции видят только те элементы, которые им требуются. Для этого большинство разработчиков использовали бы операторы if, что идеально подходит для моей следующей практики кодирования.


Избегайте использования операторов if без крайней необходимости


Возьмите это для кода, например:


```javascript


если gusto показать это:


если bamboohr показать, что:


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


Вместо этого использование определений в виде объектов JavaScript намного быстрее и упрощает масштабирование приложения. Взгляните на следующий код 👨‍💻


```javascript


LOCATION_MAPPING = {


КОМПОНЕНТ: «отображение местоположения»,


... другие необходимые свойства,


СОТРУДНИК_INVITE = {


КОМПОНЕНТ: «приглашение сотрудника»,


... другие необходимые свойства,


LEAVE_TYPE_MAPPING = {


КОМПОНЕНТ: «сопоставление типов листьев»,


... другие необходимые свойства,


ИНТЕГРАЦИИ = {


BAMBOOHR: [LOCATION_MAPPING, EMPLOYEE_INVITE],


ВКУС: [LOCATION_MAPPING, EMPLOYEE_INVITE],


НОЛЬ: [LOCATION_MAPPING, LEAVE_TYPE_MAPPING, EMPLOYEE_INVITE],


Мы создали объект, который содержит все интеграции, с которыми мы работаем для этой конкретной задачи. Каждая интеграция имеет свойства компонентов, которые она будет использовать, например, BambooHR использует LOCATION_MAPPING и EMPLOYEE_INVITE, которые, в свою очередь, предоставляют нам полезную информацию, связанную с ними, что позволяет нам масштабироваться. Одна из этих сведений — COMPONENT, которая, по сути, сообщает нам имя связанного с ними шаблона Vue. Имея доступное нам имя компонента, мы можем использовать Vue мета-компонент , который позволяет нам для динамического отображения необходимых компонентов по мере необходимости: <component :is="componentName" />


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


```javascript


<шаблон>


<компонент :is="state.currentTab" />





// импортировать определения


// импорт компонентов


настраивать() {


постоянное состояние = реактивный ({


tabIndex: 0,


состояние.интеграция: $route.params.integration,


currentTab: вычислено(() => INTEGRATIONS[state.integration][state.tabIndex].COMPONENT),


hasNext: вычислено(() => state.tabIndex + 1 !== INTEGRATIONS[state.integration].length


}); функция следующая вкладка () {


состояние.tabIndex++;


} функция startImport() {


// Делаем то, что нужно


} вернуть {состояние, nextTab, startImport};


Есть много других причин, по которым следует избегать операторов if, но это будет для другой статьи!


Соглашение об именовании


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


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


Комментарии


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


```javascript


// начать отсчет


пусть счет = 0;


Есть ли в этом комментарии информация, которую нельзя было бы сказать, просто прочитав код? Нисколько! Комментарии как таковые мешают работе и требуют от программиста постоянного переключения контекстов, что дорого обходится. Основное практическое правило — писать код, который не требует от вас объяснения того, что он делает, на простом английском языке. Это также означает наличие функции, которая выполняет только одну работу, которая идет рука об руку с правильным именованием вещей. Наличие функции с именем getThirdPartySalesData должно дать представление о том, что мы можем ожидать от этой функции, поэтому комментарии вообще не требуются! При этом понять, какие параметры требуются для функции, может быть сложно, и еще сложнее в данном случае узнать, какие свойства мы можем ожидать в возвращаемом объекте. Для случаев как таковых и для целей документации мы можем использовать JSDoc, PHPDoc и другие.


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


Также опубликовано [Здесь] (https://javascript.plainenglish.io/4-coding-practices-ive-picked-up-working-for-a-startup-64cb92f001e0)



Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE