Мы построили наш мир на знаниях тех, кто был до нас.

Учимся строить поверх чужой работы

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

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

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

Внимание, спойлер: вероятно, более 500 (за многие годы)

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

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

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

Однако знать, что хорошо выглядит, и как создать что-то с нуля — совершенно разные вещи.

Хотя я рад, что потратил столько времени на совершенствование своего дизайна и навыков UX; если бы мне пришлось вернуться, мои проекты были бы более продуктивными. Если бы я просто использовал существующее решение, а не изобретал велосипед.

Мы можем забыть о мелочах и сосредоточиться на общей картине.

Он объединяет все эти отдельные компоненты эстетичным, удобным и интуитивно понятным способом.

Что насчет практического опыта?

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

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

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

Когда идти с нуля

Конечно, для разработки программного обеспечения не существует серебряной пули; всегда есть исключения.

Прежде чем вы отправитесь в раздел комментариев и закричите ЕРЕСЬ, вот несколько сценариев, в которых имеет смысл развернуть свой собственный.

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

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

Откуда я родом

В настоящее время я создаю стартап Saas Project, и хотя я знаю, как создавать пользовательский интерфейс с нуля, я понял, что это будет огромной тратой времени.

Вот несколько причин, по которым не следует развертывать собственный:

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

Хотелось бы, чтобы каждый поделился своим опытом в этом вопросе.

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

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

Выбор правильной библиотеки

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

Цели и качество библиотеки

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

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

Рекомендуемый размер пакета для React составляет около 200 КБ.

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

Будущее библиотеки и кодовая частота

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

Как заметил Pål Thingbø, выбор неправильной библиотеки может привести к новым проблемам, включая проблемы с лицензией, неподдерживаемую библиотеку, проблемы с безопасностью и т. д.

Уменьшение размера пакета

Размер пакета может стать проблемой при развертывании вашего веб-сайта в Интернете.

Здесь я приведу несколько советов, если вы используете реакцию.

Ленивая загрузка компонентов

В новых версиях React вы можете лениво загружать компоненты.

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

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

Удаление исходных карт из производственной сборки

Еще одна вещь, которую следует учитывать при развертывании вашего внешнего интерфейса (реакции), — это удаление исходных карт.

Карты исходного кода помогают связать работающий мини-пакет javascript с написанным вами кодом.

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

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

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

Разделение проекта на поддомены

Мой проект состоит из логина, панели инструментов и целевой страницы.

Моя целевая страница известна как «одностраничная» и поэтому не может использовать отложенную загрузку.

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

Добавление react-router и разделение целевой страницы на несколько страниц — это то, что я рассматриваю в будущем. При создании целевой страницы это может значительно уменьшить первоначальный размер пакета, так что имейте это в виду.

Что я делаю сейчас

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

Нужен выбор даты? Панель поиска со встроенным автозаполнением? Система сетки, которая легко реагирует, используя хуки и условия внутри компонента реакции?

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

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

Почему это лучший выбор для меня

Если вы все еще сомневаетесь, стоит ли вам это делать, это зависит от обстоятельств.

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

Я делаю все прямо сейчас.

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

В конце концов, именно таким должен быть MVP.

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

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

Поделитесь своим опытом

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

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

Я хотел бы услышать о вашем опыте работы с другими библиотеками компонентов или о развертывании вашего решения с нуля!

Обязательно оставьте комментарий! Мы построили наш мир на основе тех, кто был до нас.