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

Принципы проектирования FrontEnd

1. Сократите время обучения.

Придерживайтесь стандартов, широко известных в экосистеме, и убедитесь, что документация легко понятна, чтобы новые участники могли посвятить время изучению методов компании и бизнес-процессов и начать приносить пользу как можно скорее. Высокие крутые кривые обучения просто заставляют много времени уделять изучению инженерных шаблонов, которые очень спорны и полны неиспользуемых сложных абстракций. Хорошо известные шаблоны имеют семантический HTML и CSS, а функциональный JS здесь, чтобы остаться по одной простой причине; это язык браузеров. Примером этого может служить React JSX, который в первую очередь стремится выглядеть как HTML.

2. Избавьтесь от путаницы

Пожалуйста, пожалуйста, пожалуйста, не злоупотребляйте слоем абстракций или очень локализованными соглашениями об аббревиатурах, которые не добавляют ценности, а только создают ненужную путаницу и усложняют процесс обучения. Такие элементы, как блочная модель Styled-Systems с такими атрибутами, как p={[1,2,3]}, mt=”big”, mx={2}, просто добавляют ненужное усложнение к и без того трудно читаемому характер кода. Даже эта библиотека делает их подход более гибким после перехода от версии 3 к версии 5, включая стандартные свойства CSS в JS, такие как padding и marginTop. Другой пример — местные стандарты смешиваются и сочетаются, как сервисы наблюдателей из angular в React, берут на себя обязательство придерживаться выбранной экосистемы.

3. Выберите язык.

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

4. Используйте более широкий язык элементов пользовательского интерфейса.

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

5. Рассмотрите различные устоявшиеся соглашения

Код предназначен для компиляции машинами, но написан разработчиками. Стандарты Html CSS и JS являются основой нашей дисциплины, и мы всегда должны иметь прочные корни, чтобы другие разработчики могли легко их понять. Оптимизация должна выполняться инструментами транспилеров, а не разработчиками. Нет такой вещи, как много комментариев или длинных имен переменных, поскольку они подходят для снижения барьера для присоединения новых разработчиков. Оптимизация и сокращение могут быть достигнуты с помощью транспиляторов и инструментов упаковки, таких как Babel и Webpack. Таков, например, принцип машинописи.

6. Автономия с последовательностью.

Выслушайте меня, я знаю, что это звучит противоречиво, но; простые шаблоны могут сделать это возможным, предоставив разработчикам право собственности на функции, а не на код. Обзоры кода должны оценивать принципы и ошибки, но понимать, что во FrontEnd Development есть более 1 способа достичь одного и того же результата. Такие методологии, как TDD (разработка через тестирование), оправданы на определенных уровнях (управление состоянием, редукторы, вспомогательные функции и т. д.), но ими легко злоупотреблять и генерировать нечитаемый код. Тем не менее, BDD (Behavior Driven Developer) приносит больше пользы, фокусируя внимание на бизнес-результатах и ​​отношениях с целевым пользователем; где легче проводить тесты на интеграцию с имитацией песка. Автоматическое покрытие кода просто неприменимо к интерфейсу на 100%.

7. FrontEnd — это все об изменениях.

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

Бонус

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