Помещение

Далее является ответом на прекрасную статью Джоша Коллинсворта, которую вы можете найти здесь.

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

Поэтому эту статью следует рассматривать как серию идей, отражающих личное мнение. Из 12 приведенных цитат я согласен с ✅ 8 из них, не согласен с ❌ 3 и не имею мнения по поводу ? 1.

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

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

✔Я полностью согласен с этим утверждением.

Фронтенд слишком долго считался «младшим братом» бэкенда, и это ошибка. Интерфейс — это часть приложения, которую видит и с которой взаимодействует конечный пользователь, и поэтому он имеет основополагающее значение для успеха продукта. Его важность нельзя недооценивать, однако это случается слишком часто, и Я сам иногда считал свою работу в качестве фронтенд-разработчика «уступающей» тому, что я делал в бэкенде.

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

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

✅ И здесь я согласен.

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

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

✔Я согласен.

Как уже упоминалось в ответ на предыдущую цитату, я считаю, что проблема CSS связана с его операционной логикой и особым синтаксисом. Проблема в том, что его часто рассматривают как «второстепенный» язык по сравнению с JavaScript, тогда как на самом деле это язык сам по себе, со своими правилами и особенностями, и требует времени на обучение, сравнимого со временем программирования. CSS — мощный и сложный язык, и его роль нельзя недооценивать.

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

✔ Частично согласен.

Честно говоря, мне эта тема видится гораздо более откровенной, чем говорит автор. На самом деле, мне часто приходится дискутировать с людьми, которые считают, что фронтенд — это «второстепенная» работа по сравнению с бэкендом, и которые считают, что фронтенд-разработчик должен быть не программистом, а поддержка тех, кто делает настоящую работу — бэкэнд. Когда меня спрашивают, какова моя роль, я всегда отвечаю Full-Stack, потому что в моем обучении и росте есть разные элементы, и для меня важны и значимы обе стороны медали.

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

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

Наша продукция в какой-то степени является художественной, а художественные вещи имеют долгую и легендарную историю трагического обесценивания просто потому, что они кажутся простыми и приятными.

✔Я согласен.

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

Во-первых, часто не фронтенд-разработчик решает дизайн приложения, а дизайнер (UX, UI, называйте как хотите). Разработчик внешнего интерфейса призван перевести проект в код и сделать это эффективным и высокопроизводительным способом. Это требует технических навыков и конкретных знаний, которые выходят далеко за рамки простого написания кода.

Во-вторых, как уже говорилось выше, обязанности фронтенд-разработчика часто выходят далеко за рамки простого написания кода. Если я изменю код в своем серверном приложении, автоматические тесты, скорее всего, заметят любые регрессии раньше, чем я смогу. Если я изменю код во внешнем приложении, весьма вероятно, что единственный способ заметить какие-либо регрессии — это вручную протестировать приложение или дождаться отчета от конечных клиентов*. Это делает работу фронтенд-разработчика гораздо более сложной и требовательной, чем можно подумать. Не говоря уже о количестве бизнес-логики и управления состоянием — оба быстро вливаются во внешний интерфейс — что делает эту роль все более интегрированной с бизнесом.

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

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

? Нет мнения по этому поводу.

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

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

✔Я согласен.

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

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

✔Я согласен с внутренним смыслом этого утверждения.

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

Да, как группа, мы с нетерпением ждем новых вещей. Но почему это не делает нас любопытными, адаптируемыми или любознательными? Почему нас не хвалят за радость обучения, а не унижают за отказ оставаться на месте?

❌ С этим я согласен меньше.

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

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

✔ Полностью согласен.

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

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

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

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

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

Похоже, никто больше не считает фронтенд важной частью продукта; они думают о нем только как о красивой коробке, в которой поставляется продукт.

❌ И здесь я, увы, не согласен с Джошем.

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