Мысли Криса Койера
Одна из мыслей, которая поселилась в моей голове: должен ли frontend-разработчик быть в курсе всего? В общем смысле, frontend-разработчик может использоваться и на других рабочих местах. Вся команда разработчиков заканчивает разговор на frontend-разработчике. В этом смысл моей идеи. Frontend-разработчики создают те вещи, с которыми будут взаимодействовать люди. Все этапы разработки проходят вместе с frontend-разработчиком. Возможно, именно поэтому это такая забавная работа! Поскольку frontend-разработчик занимает центральное место в цепочке разработки, и при этом мы имеем дело с большим количеством разных специалистов, мы должны понимать их работу и иногда подсказывать, что и как сделать лучше.
От переводчика
Всем привет, с вами Максим Иванов, и сегодня мы поговорим на довольно острую тему в сфере веб-разработки. Как утверждает Крис Койер, frontend-разработчик должен разбираться в очень многих вещах, о которых не все даже и задумываются. Конечно, мы должны понимать, что frontend-разработчик не главный в процессе разработки любого онлайн-сервиса или ПО в целом. На ту же позицию frontend-разработчика вы найдете больше откликов на вакансию, чем на позицию backend-разработчиком. Но почему же тогда Крис Койер считает, что работать frontend-разработчиком сложнее, ибо ты должен специализироваться во всем. Конечно, ситуаций в жизни очень много, разные компании по-разному используют своих специалистов, но в чем наверняка должен разбираться frontend-разработчик? Об этом мы сегодня и поговорим. Жду комментариев на эту тему, а сейчас приступим.
Содержание
- Frontend-разработчик должен разбираться в дизайне
- Frontend-разработчик должен разбираться в работе серверной части (backend)
- Frontend-разработчик должен разбираться в работе сетей
- Frontend-разработчик должен разбираться в производительности
- Frontend-разработчик должен разбираться в контент-стратегии
- Frontend-разработчик должен разбираться в базах данных
- Frontend-разработчик должен разбираться в тестировании
- Frontend-разработчик должен разбираться в системах сборки
- Frontend-разработчик должен разбираться в методологиях разработки
- Frontend-разработчик должен разбираться в настройке веб-серверов
- Frontend-разработчик должен разбираться в юзабилити
- Frontend-разработчик должен разбираться в мобильном дизайне
Frontend-разработчик должен разбираться в дизайне
Если frontend-разработчик не является сам по себе дизайнером, он должен знать, насколько важен дизайн. Он должен иметь хороший вкус. Он должен знать об инструментах, участвующих непосредственно в разработке.
К прочтению:
1. Памятка дизайнеру сайтов
2. Принцип цикады и почему он важен для веб-дизайнеров
3. Стив Круг «Веб-дизайн или Не заставляйте меня думать»
4. Якоб Нильсен «Веб-дизайн»
5. Дональд Норман «Дизайн привычных вещей»
6. Джеф Раскин «Интерфейс»
7. Как за 15 лет изменились главные страницы Apple, Microsoft, IBM, Sony
8. Ководство
9. О дизайне
10. Почему курсор мыши наклонён на 45°?
11. Наберитесь смелости сделать не как все. 12 устаревших интерфейсных и технологических решений
12. Имена людей и интерфейс
13. User experience design: как построить сайт для клиентов, а не для себя
14. Главные особенности китайского веб-дизайна и их истоки
Frontend-разработчик должен разбираться в работе серверной части (backend)
Даже если вы и не backend-разработчик, то вы явно осознаёте всю важность серверной части. Вы понимаете, с чем взаимодействует backend, что передается на сервер, а что нет. Вы знаете об обязанностях backend-разработчика. Вы понимаете, какой язык используется на сервере, и при этом должны уметь объяснить, что должен дать вам backend и что нужно от серверной части frontend-а.
К прочтению:
1. Чему мы научились, разрабатывая backend
2. Собеседование на должность PHP Backend Developer в Германии
3. Пишем backend для мобильного приложения за несколько минут
4. Что должно быть впереди фронтэнд или бекенд?
5. Что нужно знать, чтобы стать Backend разработчиком?
6. Что должен знать «PHP Junior Developer без опыта работы»?
7. Какими технологиями должен обладать backend разработчик (уровень начальных знаний — новичок+)?
Frontend-разработчик должен разбираться в работе сетей
Frontend-разработчик понимает, что сайты располагаются в интернете, данные передаются по сети, и что сеть — это дикое и непредсказуемое. Необходимо понимать, какие бывают сети, как они работают, и насколько они бывают быстрые и надежные.
К прочтению:
1. Принципы работы сети Интернет
2. Архитектура и принципы работы сети
3. Принцип работы торрент-сетей и как достигается высокая скорость
4. Руководство по TCP/IP для начинающих
5. Domain Name Service — cлужба Доменных Имен
Frontend-разработчик должен разбираться в производительности
Если вы не сосредоточены на производительности, то знаете, что производительность имеет важное место в успехе вашего проекта. Frontend-разработчики знают об этом нелегком мире. Нужные навыки помогут вам одержать быструю победу в долгой борьбе. Необходимо понимать насколько быстрым должен быть backend, а также, что оставшиеся 80% времени это загрузка сайта, т.е. это frontend.
К прочтению:
1. Производительность web: Why Performance Matters
2. Тонкости производительности
3. Выигрыш в производительности для rel=noopener
4. Измерение производительности веб-страниц
5. Улучшаем UX посредством оптимизации
6. Подходы к оптимизации (веб-)приложений
7. Пример веб-производительности
8. Производительность рендеринга картинок в Web
9. 10 Ways to Test Your Website Performance
Frontend-разработчик должен разбираться в контент-стратегии
Опять же, вы можете и не разрабатывать контент-стратегию, но должны понимать, что сайт живет и существует благодаря контенту на нем. Отсутствие определенного плана может вызвать определенные сложности, которые вы не сможете предотвратить во время разработки. Люди, которые будут пользоваться ресурсом, и те, кто что-то ищет, должны быть уверены в достоверности и корректности информации.
К прочтению:
1. Как создать контент-стратегию, которую будут обсуждать
2. Супер контент-стратегия. 5 успешных примеров
3. Нужна ли контент-стратегия при наполнении сайта?
4. Эрин Киссейн «Основы контентной стратегии»
5. Как построить SMM-стратегию: пошаговый план продвижения в социальных сетях
6. Как оптимизировать контент для SEO и SMM?
Frontend-разработчик должен разбираться в базах данных
Контент хранится в базе данных. База данных должна корректно работать с контентом. А frontend-разработчик должен уметь работать с тем, что приходит ему из этой самой базы данных. Frontend-разработчику при работе с ответом базы данных нужно уметь комбинировать контент с шаблонами на сайте.
К прочтению:
1. Введение в базы данных
2. Базы данных: SQL (DDL/DML)
3. Ускоряем базу данных веб-сайта
4. Веб-интерфейс для баз данных размером в один .php файл
5. Возможности PostgreSQL, которых нет в MySQL, и наоборот
6. HTML 5. Работа с Web SQL базой данных
7. Базы данных и NoSQL
8. Как отобразить 350 миллионов строк из базы данных на Web-форме
9. Встраиваемая JavaScript база данных с прицелом на API совместимость с MongoDB
Frontend-разработчик должен разбираться в тестировании
Существует большое количество видов тестирования. Интеграционное тестирование. Регрессионное тестирование. Пользовательское тестирование!
К прочтению:
1. Тестирование программного обеспечения
2. Зачем нужны тесты?
3. Модульные тесты и интеграционные: в чём разница?
4. Тестирование
5. JavaScript Testing курс (eng)
6. QUnit. Тестирование javascript кода
7. Как развиваться начинающему тестировщику?
8. Повышаем стабильность Front-end
9. Бек Кент. Экстремальное программирование. Разработка через тестирование
10. Пишем свой первый юнит-тест, на примере методологии BDD и библиотеки Jasmine
10. Процесс тестирования мобильных приложений
11. Макгрегор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения
12. Тестирование JS. Кармический Webpack
Frontend-разработчик должен разбираться в системах сборки
Frontend-разработчики пишут совместный код, и каждый должен брать на себя ответственность за внедрение чего-то нового в проекте. Если вы написали свою систему сборки, другие члены команды должны понимать, что это такое и для чего оно нужно. Даже если кто-то не использует систему сборки, он все равно должен понимать, как использовать такие вещи.
К прочтению:
1. Webpack – один из самых мощных и гибких инструментов для сборки frontend
2. Grunt — Обзор системы сборки
3. Автоматизация сборки
4. Приятная сборка frontend проекта
5. Сравнение популярных систем сборки для frontend-разработчиков
6. Grunt vs Gulp сравнение систем сборки для front-end разработчика
7. Gulp или Grunt, да всё равно
8. Методология сборки БЭМ-проекта
Frontend-разработчик должен разбираться в методологиях разработки
Fronend-разработчик пишет и стилизует код самостоятельно, так же, как и другие разработчики проекта, поэтому им необходимо придерживаться единых установок. Если не вы писали систему сборки, то в любом случае вы должны знать, как с ней работать, что она делает и на что способна. Если вы не умеете развертывать такие системы, то нужно научиться с этим работать.
К прочтению:
1. Необходимый минимум для фронтенд-разработчика
2. Методологии фронтенд-разработки
3. Советы front-end разработчику
4. Какими знаниями должен обладать Front-end разработчик в 2015 году
5. Что нужно знать и уметь front end разработчику в 2015/2016
6. Карта развития веб-разработчика
7. Основные навыки фронтенд-разработчика
8. Isobar Front-end Code Standards
9. Front-end Style Guides
10. JavaScript Style Guide
11. Coding style (Mozilla)
Frontend-разработчик должен разбираться в настройке веб-серверов
Без них не было бы веб-сайтов.
К прочтению:
1. Основные типы серверов
2. Что такое веб-сервер
3. Веб-сервер
4. Простым языком об HTTP
5. Веб-сервисы в теории и на практике для начинающих
6. Сравнение веб-серверов
7. Web-сервера и их использование для управления нагрузкой на приложение.
8. PHP. Встроенный web-сервер
9. Локальный веб-сервер
10. Использование преимуществ встроенного PHP сервера
11. Как поднять сервер для python скриптов за 1 минуту
Frontend-разработчик должен разбираться в юзабилити
Если frontend-разработчик не очень хорошо разбирается в юзабилити, в любом случае он должен понимать насколько это важно. Необходимо уметь тестировать и налаживать юзабилити. Frontend-разработчик должен знать, с кем поговорить на эту тему.
К прочтению:
1. Юзабилити
2. Юзабилити сайта
3. 10 советов по юзабилити сайта, основанных на результатах исследований
4. Основы юзабилити (usability) сайтов
5. Юзабилити-тестирование (ИТМО)
6. Usability vs. User Experience
7. What is the difference between UX and UI designer and web designer?
Frontend-разработчик должен разбираться в мобильном дизайне
Frontend-разработчик должен понимать, что его сайтом могут пользоваться везде, на его сайт могут зайти с любого устройства, поэтому необходимо позаботиться заранее на этот счет. Большие экраны, маленькие, сенсорные, устаревшие устройства. Frontend-разработчик должен быть готов к неизвестному!
К прочтению:
1. Лучшие практики по мобильному UX от Ника Бабича
2. Адаптивный веб-дизайн
3. Responsive Web Design: What It Is And How To Use It
4. Книга Итана Маркотта «Отзывчивый веб-дизайн»
4. 10 адаптивных фреймворков для веб-дизайна
5. Responsive Web Design Fundamentals курс (eng)
Заключение
Это всего лишь часть того, что должен знать frontend-разработчик. Чем больше, тем лучше. Все это, конечно, познается в работе. HTML, CSS, JavaScript, адаптивный дизайн, библиотеки и фреймворки — этот список может долго не заканчиваться.
Комментарии (75)
CodeViking
11.08.2016 00:51+19Многие идут во Front-end, думая что это вёрстка. Мол изучу HTML+CSS+jQuery и пойду сайты клепать. Не тут то было.
Carburn
11.08.2016 11:07Это же и есть front-end, ну еще фреймворки. Иначе это будет full-stack.
Ohar
11.08.2016 17:55+2Нет, это только вершина айсберга.
Есть ещё
- Кроссбраузерность
- Скорость загрузки ресурсов
- Порядок отрисовки
- Порядок выполнения скриптов
- Шрифты, и их форматы
- Векторная графика, иконки
- Оптимизация изображений
- Адаптация к разным экранам
- Адаптация для разных ОС
- Адаптация для разных способов ввода (Мышь + клавиатура, тачскрин, жесты)
- Доступность для разных способов вывода (соблюдение WAI ARIA для слепых, субтитры для глухих, особые цветовые решения для эпилептиков)
- Правила вывода на печать
- Мета-данные для парсеров и роботов
- Деградация на старых устройствах
AterCattus
11.08.2016 01:45-8Лучше бы фронт не пытался лезть в бек, нахвататься верхов, а потом лезть советовать. Каждому свои задачи по знаниям и опыту.
Особенно порадовали требования знать ЯП бека и работу БД.
AndreyRubankov
11.08.2016 08:39+4Ведь никто и не говорил, что фронт должен пилить бек. Фронт должен понимать как работает бек. Как минимум, чтобы было понятно почему иногда нужно делать «еще один костыль на фронтенде». Или подсказать, что он может сделать, чтобы этот костыль и вовсе не пришлось бы пилить.
summerwind
16.08.2016 12:29+1Но, почему-то это «понимание бэка» часто сводится к «запили еще один костыль на бэке, иначе мне на фронте придется целых 3 лишних строчки кода написать».
AndreyRubankov
16.08.2016 15:24По-моему, это уже можно назвать непониманием. В любом случае, нужно уметь договориться. В некоторых случаях костыль лучше делать на фронте, а в некоторых на беке. Если совместно не разобрать все плюсы и минусы отбросив абстрактные «костыль» или «лишний код», то любые споры кто должен запилить — это простой треп.
Skreep
11.08.2016 12:35Буквально на днях столкнулся с проектом, у которого аж три фронтенда. И каждый отдает данные по-своему. В результате три визуально одинаковых элемента работают по-разному. Это частность, но из-за таких вещей фронтенд перегружен. А расхлебывать тому, для кого это все дело пишется — пользователю.
Jabher
11.08.2016 13:24+6Лучше бы идиоты не пытались лезть в фронт. и в бэк. и вообще.
Потому что когда ты приходишь к бэкэндеру с фразой «у нас эндпоинт отдает данные 300 секунд, это неправильно» и получаешь ответ «ой да ладно тебе, как будто ты таймаут побольше выставить не можешь» хочется в лицо бить.
Каждый разработчик должен иметь знания смежных domain of knowledge на уровень ниже. То есть senior front-end должен иметь уровень хотя бы mid-backend, mid-ui, mid-content, mid-QA. Это тянет за собой junior DBA, junior devops, junior design+ux, junior stretegy. Иначе это бесполезный специалист, живущий в своем мирке и не смотрящий по сторонам.
К бэкэндерам это так же относится, только теперь для senior back-end нужно middle devops, middle dba, middle front-end, middle QA, junior UI, junior content.
Это не только про фронтэнд история, это про все. Все знать должны смежные области.
А иначе получится вечная история о том, как умный фронтэндер пришел и обосрал всю архитектуру, после чего пятерых разработчиков разогнали, потому что он оказался frontend/node.js fullstack. Или пхпшник оказался на самом деле сишником, который расширения для пхп уже 5 лет пишет. Или дизайнер оказался неплохим верстальщиком и все на него свалили. Сколько я этих историй уже насмотрелся…Carburn
11.08.2016 19:00-2Все знать должны смежные области. А иначе получится вечная история о том, как умный фронтэндер пришел и обосрал всю архитектуру
Так фронтэндер же и обосрал архитектуру как раз потому, что разбирается в смежных областях.
bagiroff777
11.08.2016 22:06Лезть и не надо. Достаточно знать, как все устроено, чтобы бекенд-разработчику не пришлось обьяснять, как делать не надо и почему не надо.
ZoomLS
11.08.2016 01:53-7А на выходе получается — DevOps.
ainu
11.08.2016 09:52+1Нет, даже не рядом
ZoomLS
11.08.2016 13:31+1Смотря что считать DevOps.
ainu
11.08.2016 13:49+3Ок. Представьте себе DevOps-а (любого, которых принято считать девопсами), который не знает, что такое Docker, Chef, Ansible, bash, linux. Представили? Я — нет.
Ни одного из этих слов в статье нет. Максимум: «знать апач и PHP».
В статье говорится, что фронтенд должен знать, что такое сервер — как минимум, если картинка не показывается, если её nginx затёр, или как правильно управлять кешем этих самых картинок. Даже знать, что такое куки, почему их не надо отправлять вместе с картинками, и почему есть поддомен static.* — полезно. Но Девопсом он от этого не станет, даже рядом.ZoomLS
11.08.2016 14:15+4Ок. Я был не прав.
sumanai
11.08.2016 20:18Даже знать, что такое куки, почему их не надо отправлять вместе с картинками, и почему есть поддомен static.* — полезно.
На заметку- с HTTP2 поддомены вредны.
spmbt
11.08.2016 02:03+18Но это же не всё.
13. Он должен умело писать, чтобы хорошо доносить свои мысли до других, как в этой статье.
14. Он должен хорошо торговаться, чтобы умело продать свою работу и идеи.
15. Он должен уметь поддерживать светский разговор, когда попадёт на ужин с инвесторами.
16. Он должен иметь вкус в одежде, чтобы не шокировать окружающих.
17. Он должен уметь готовить, чтобы создать уютную обстановку при романтической встрече.
18. Он должен виртуозно работать в любой OS, в том числе и в мобильных.
19. Он должен говорить на международном бизнес-языке, чтобы первым улавливать музыку далёких гонгов.
20. Он должен быть материалистом, чтобы отличать ошибочные идеи от выполнимых.
21. Он должен быть в курсе постановлений правительства, чтобы знать, куда бежать.
22. Он должен думать о бекапах имеющих к нему отношение работ.
23. Он должен иметь под рукой компьютер и связь, чтобы рационально использовать своё время.
24. Он должен излучать оптимизм, чтобы быть своим в доску в компании.
25. Он должен иметь нюх на ещё не озвученное решение руководства стартапа о его закрытии.Alexey2005
12.08.2016 12:12+2Если человек хорошо владеет пп.13-25, то знания программирования ему вообще не требуется, он и так займёт достойное место в жизни, и доходы у него будут побольше, чем у большинства разработчиков.
IgorPastukhov
11.08.2016 02:48+6Сразу видно — статью писал front-end разработчик
Ronnie_Gardocki
11.08.2016 05:57+4Оригинальная статья написана очень крутым человеком и по сути дела батей современного фронтенда, как минимум в плане вклада в его развитие и создания вещей этому сопутствующих. Chris Coyer — создатель css-tricks и один из отцов codepen. Это вам не очередные пятничные мысли Васи-сеньера читать.
AndreyRubankov
11.08.2016 08:32+11Автор прав, фронтенд разработчик должен знать это все, хотя бы для понимания как это работает и почему иногда нужно прислушиваться с бекенд-проблемам, а не ныть о своих.
Но все, что автор говорил про фронтенд, в равной мере относится и к бекэнду. Бекэнд разработчик тоже должен знать это все и думать о том, чтобы выполнить свою задачу так, чтобы фронтенду было проще (у них так много боли). А не «отвалите от меня! я сделал свою часть!».
В идеале (и это достижимо) и те и другие должны уметь и хотеть разбираться во всем, и самое важное — уметь договориться как они будут решать поставленную задачу!
OtshelnikFm
11.08.2016 10:29+2«Он должен знать принцип работы генератора — ведь сайты работают от электричества»
«Он должен знать работу АЭС — т.к. генераторы работают там, а они дают электричество, а электричество питает сайты энергией.»
Статья притянута за уши. 80% тезисов верны. Но не являются обязательными. Лишь как рекомендации для хорошего фронтенд мастера.
Pinsky
11.08.2016 10:49+3Мой опыт подсказывает, что бэкенд разработчику почти всегда нужно быть, по факту, фуллстеком(ну может только что не фигачить pixel-perfect вверстку, да и то разок-другой придется делать и такое).
Ohar
11.08.2016 18:02Ну, по-хорошему, всем не помешало бы быть фулстеками и девопсами. Но это физически сложно.
yury-dymov
11.08.2016 11:10+7Хм, что же тогда должен знать full-stack разработчик.
chupasaurus
11.08.2016 11:23+3Исходный код libastral.so, как минимум
Pinsky
11.08.2016 11:42+1Кстати, версию старше 3.5 кто-нибудь собирал?
У меня на зависимостях валится
Mellorn
11.08.2016 11:10-1Frontend-разработчик должен разбираться в настройке веб-серверов
Без них не было бы веб-сайтов.
Что без серверов не было бы сайтов — очевидная вещь. Но, извините меня, каким боком настройка серверов касается frontend-разработчиков и их непосредственной работы?
Или я чего-то не понимаю, или полезность статьи нулевая. Подставить в текст вместо frontend-разработчика любого другого специалиста и смысл ни капли не поменяется.
youngpirate32
11.08.2016 12:54+2Предположу, что надо знать про gzip, https и http 2.0
yury-dymov
11.08.2016 13:04+1Ну это как раз системные вещи, а не frontend. Перед условной нодой будет стоять nginx, который и будет делать gzip, https и все на свете. Я не спорю, что условный express тоже может статику отдавать и жать, но в продакшене я такого давно не видел.
trigger_af
12.08.2016 10:47Как раз любой протокол — это то, что связывает бекенд и фронт. По-моему говорить, что протокол реализует только веб-сервер, некорректно. Как минимум есть ещё один опонент — браузер. В большинстве случаев, действительно всё делает браузер и веб-сервер. Но бывает, что нужно более детально разбираться, банальный пример — нужно прочитать заголовки ответа сервера/послать свои.
dab00
11.08.2016 11:10-1Фронтэнд разработчик может разбираться в чем угодно, и рассказывать об этом где угодно и сколько угодно, но если в вашем проекте он должен разбираться в чем-либо кроме фронтэнд разработки — вопрос к менеджементу проекта.
Jesus05
11.08.2016 11:10Не увидел в статье чего-то экстраординарного.
Как и любой другой разработчик он должен разбираться в:
методологиях разработки, системах сборки, тестировании, производительности.
Как и любой другой разработчик связанный с сетями он должен понимать как они работают.
Как и любой другой разработчик в окружении которого есть БД должен уметь делать с ней базовые вещи, никто от него не требует полноценного администрирования баз.
Ну а остальное вытекает просто из специфики конкретного места т.е. фронэнда.
Max2UP
11.08.2016 12:53Вот это все должен знать front-end freelancer который занимается внедрением сайтов полного цикла. Это уже фактически full-stack. Людей на это способных мало, результаты, которые они выдают, будут далеки от качество на которое они способны, если бы специализировались в одной области и не думали о другом. Плюс, часто страдает скорость, т.к. катастрофически проваливается на обязанностях для которых у человека вроде есть знания, но нет постоянной практике.
В нормальной команде процентов 50 от выше перечисленного можно выкинуть и дать фрондендщику совершенствоваться в его непосредственных обязанностях. Да, в ходе работы они могут получить новые знания вне своей области, т.к. работают в команде и видят опыт других специализаций. Но это не должно быть обязательным требованием.
Nargus
11.08.2016 12:53Уважаемые комментаторы, разумеется, front-end не обязан этого всего знать, но вот претендующий на звание Senior и Lead — да.
DKurilo
11.08.2016 13:49+1WebGL забыли. Он уже даже на iPhone работает.
Современному FrontEnd разработчику надо понимать, что такое shader.
Про Tessellation shader'ы пока можно не знать. Но остальные хотя бы использовать, но надо уметь.
На самом деле, Web с каждым годом становится все сложнее.
Вот интересно бы еще порассуждать на тему, как Web разработчику своевременно обновлять багаж знаний, выкидывая отжившие свое hack'и времен IE6 и планируя, что надо изучить нового.
vtrushin
11.08.2016 15:03-2Frontend-разработчик должен разбираться в базах данных
Больше 10 лет во фронтенде и толком не знаю ничего о базах данных. И вот как-то даже не нуждался
banger
11.08.2016 16:50+1То есть даже основ никаких в голове нет? Не нужно ведь все знать на уровне бога баз данных. Хватит быть специалистов в одной — двух — трех-x областях, а в остальных иметь хотя бы представление, чтобы в будущем знать как это найти в гугле.
vtrushin
12.08.2016 13:43-1Ну SQL-запрос не напишу. Я не пойму, почему минусуют. Одно дело всесторонняя развитость, но другое — требования к разработчику (= должен разбираться/уметь). Много кто из фронтендеров работал с не долгоживущим WebSQL?
pragmader
11.08.2016 15:30+2Мне кажется есть большое заблуждение в индустрии, которое выражается в вещах типа «back-end/front-end/mobile/etc developer». Если ты в Software Engineering, то ты должен быть инженером-разработчиком и не ограничивать свой скоуп чем-либо, должен понимать как работает все чего ты касаешься и пробовать/изучать новое при возможности. С того момента как человек говорит «я – x-developer, мне не важно что у вас там происходит» для меня это значит, что человек не инженер и не разработчик, а просто умеет кодить, используя определенный инструментарий не имея понятия, что происходит вокруг его части проекта. С таким человеком мне лично неприятно работать и, как мне кажется, такого человека нанимать опасно, ведь технологии не вечны, фокус может сместиться, а такой человек не захочет выходить за свои рамки и двигаться с компанией или командой.
Посыл в статье хороший, но я бы не стал адресовать это front-end разработчику, а в целом software engineer. Что-то вроде «Не ограничивайте себя чем-то одним, будьте открыты ко всему и понимайте как работает все вокруг вас».
А то получается как:
ymatuhin
11.08.2016 23:27+3На картинке если эти 2 парня начнут помогать, то они утонут быстрее. А так сидят для противовеса хоть.
copist
11.08.2016 16:10+3Оригинальная статья «A Front End Developer is Aware» переведена слишком прямолинейно, нет неуловимой мягкости 50 оттенков модальности английского. К примеру «A front end developer is aware of design» = «Фронтенд разработчик знает о дизайне». Когда и как он это узнал — за кадром. Хорошо или плохо знает — за кадром.
Оригинальная статья была ориентиром. «Дружок, тебе было бы неплохо ориентироваться в A,B,C». А перевод получился приговором: «должен A, должен B, должен C». И рядом идут пункты законов, по которым он что то должен.
Через полгода-год начинающий фронт глянет на то, что пройдено, на то что должен, оценит результаты, оценит перспективы и застрелится :( Если бы меня так испугали на заре карьеры, я бы уже того…
Пожалейте новичков.
ximility
11.08.2016 16:50+3(Комментирую как fullstack-разработчик .net, angular, ms sql в прошлом, сейчас в основном занимаюсь фронтенд разработкой)
на какой… фронт-енд-разработчик — (далее ФР), знать как работает БД!
Пф!
Да, согласен —
frontend-разработчик должен уметь работать с тем, что приходит ему из этой самой базы данных..
но это разве понимается как знание БД, разве ФР на клиенте пишет/должен писать sql-запрос? это ж ужс!
-Frontend-разработчик должен разбираться в настройке веб-серверов
и комментарий автора мне нравится… Но по сути это не за чем. Это удел админа или на край бекенд-разраба.
Некоторые моменты действительно наивны,
— Frontend-разработчик должен разбираться в работе сетей, Frontend-разработчик должен разбираться в производительности,
— Frontend-разработчик должен разбираться в производительности
— rontend-разработчик должен разбираться в методологиях разработки
любой уважайющий себя web-программист обязан хоть немного знать что такое TCP/IP, DNS… принципы работы сети — ну это перебор ребята, КОНЕЧНО ЖЕ он должен разбираться в сетях, это же его область деятельности в принципе. Производительность, это уже опыт, практика, методология разработки — нуууууу, согласен, но все таки — это не аргументы, чтоб считать ФР центральным лицом разработки.
Раньше что-то особо не парились ФР или бекенд,… ВЕБ-программист — вот оно, ВСЕ!!! этот чудо человек знает все! — как получить кучку записей из бд, как красиво написать бизнес логику, как это вывести на страницу с рюшечками и тенями и анимациями, как асинхронно подгрузить данные (ajax-ом).
Видимо, менеджеры проектов хотят максимально разделить круг задач разработки( чтоб максимально уместно раздавать чудотворные люля специалисту, который тормозит)
этот занимается дизайном,
этот — версткой, js-скриптами, ajax/json
этот пишет бэкенд,
этот проектирует базу данных,
— ну вроде логично!
ну а раз идет разделение ролей — то выше описанное как по мне перебор.
по сути тогда и кассир-операционист должен знать как ведется учет персонала, бухгалтерия, ведь он работает с деньгами!
Эти все знания будут полезны, но не входит в обязанности специалиста.
RomanYakimchuk
11.08.2016 20:08Признаюсь, статью полностью не прочитал, но добавлю от себя — без понимания полного цикла работы программы (с сервером, и прочими системами), возможности анализа проблем программы, и разработки технических решений затрагивающих несколько сторон проекта, ограничены.
Возможно, мыслю со своей колокольни, потому что работаем при помощи обычного JavaScript с далеко не базовыми вещами, такие как спутниковое и кабельное вещание, 3G сеть, вещание потоков, и прочее.
Toshiro
12.08.2016 01:48+1Ребят, вы с ума посходили? Вы себе вообще представляете сколько по времени занимает «знать все»? Году к 2046 ты наверное выучишь все, что вышло на 2016-й год, и будешь способен использовать… ну а когда наверстывать прошедшие с 2016 десятки лет? Годам к 90-100? А доживешь? А когда наверстывать все, что выйдет снова за следующие годы? Напомню, что все это время вам еще нужно как минимум получать зарплату чтобы не сдохнуть с голода.
И главное — кому ты после этого нафиг нужен весь такой? Да у тебя знаний как у целого ИТ подразделения. Но по массе причин любая фирма наймет себе целый отдел вместо того, чтобы платить миллионы тебе. Потому что ты один — это чудовищный во всех отношениях риск.copist
13.08.2016 09:28Предполагаю ответ HR — мы не можем предоставить вам работу в рамках вашей компетенции. Вам тут будет скучно :(
D01
12.08.2016 11:23Каждый участник проекта должен знать проект в общем, связанные со своим участком куски — досконально.
Иначе такая фигня получается…
flerka_m
12.08.2016 17:51+1Мне кажется фронтендщикам немного сложнее чем серверным разработчикам. Для фронтенда постоянно появляется куча методологий, языков, фреймверков, библиотек и тд — и им нужно успевать за всем этим следить/изучать или хотя бы ознакамливаться, что бы быть в курсе. Мне кажется если серверный разработчик отойдет от дел, скажем, на год, то ему будет намного проще наверстать чем фронтендщику.
AndreyRubankov
14.08.2016 12:36+1Если инженер (фронт, бек) отойдет от дел на 1 год — он забудет как код пишется в принципе. Даже 1 месяц пропустить — это очень много для ИТ мира.
Да, фронтенду сейчас сложнее, но не из-за того, что постоянно появляется что-то новое, а из-за того, что постоянно кто-то тянет одеяло в свою сторону и не хочет придерживаться стандартов ни для HTML, ни для CSS, и даже для JS не хотят.
Если раньше были «браузерные войны», то сейчас это можно расценивать как «холодная война браузеров»: с одной стороны и придерживаются стандартов, но с другой — вводят новый функционал, который есть только у них и больше ни у кого. Или придумывают одну и ту же фичу, но делают ее по-разному.
В бекэндах в этом плане проще. Не гнаться за чужими маркетинговыми причудами (хотя это тоже присутствует: то все на рельсы кинутся за рубинами, то на js бекенды писать начнут, то в Go начнут играть). В бекендах все по стандартам и по спецификациям коих несметная гора.
ps: Фронтенду нужно гнаться за тем, что сейчас популярно, а бекенду нужно изучать тонны материалов, которые уже существуют.DKurilo
15.08.2016 00:54+1Если инженер (фронт, бек) отойдет от дел на 1 год — он забудет как код пишется в принципе
Нет. Это не так. Это даже полезно на какое-то время заняться чем-то другим. Вы сами удивитесь, как быстро восстанавливаются умения. На самом деле, каждый новый виток делает разработку проще. Освоил инструмент и можешь забыть о куче сопутствующей работы, которую делал раньше. Вон сейчас иной раз даже не поймешь, на каком сайте находишься из-за того, что все освоили bootstrap.
Скорее, как мне кажется, наоборот сложно. Если вы начали работу с FrontEnd с самых последних технологий, то чтобы перейти на более низкий уровень придется очень много доизучить.
Да, порой появляются принципиально новые технологии, для изучения которых, что для «старика», что для «молодого» (в кавычках, т.к. вообще не связано с возрастом), одинаково времени потребуется (типа SPDY или HTTP/2). Но и там и там достаточно RFC прочесть. Ну это если все знания на готовых инструментах не построены.
И опять же, незнание чего-то сейчас не блокирующий фактор, а снижающий эффективность.
Немного поясню. Раньше человек делал страничку в Word или FrontPage и гордо звался Web master. Потом те, кто не захотел развиваться просто ушли с рынка, превратившись в кого-то другого. Теперь есть набор инструментов, которые позволяют создавать стили толком не понимая, что делается в CSS (bootstrap, например), писать скрипты не думая, что с этим всем делает браузер (любой framework), разрабатывать сайт не понимая, как это будет работать на сервере, т.к. development server теперь есть везде, и в gulp и в symfony и в Django и в Rails и т.д… И при смене чего-то на более глубоком уровне кто-то за вас поменяет все инструменты так, чтоб они работали с новыми технологиями. Разве что придется рекомендации почитать и перестать использовать спрайты и inline картинки в CSS.
Это не хорошо и не плохо, это движение к тому, чтоб разработчик мог сконцентрироваться на своих непосредственных обязанностях. Но это же дает возможность выпасть из отрасли, а потом вернуться в нее, как будто и не прошло года.
Как иллюстрация из современного мира — уже упомянутый мной выше WebGL. Те, кто столкнутся с ним сейчас, изучат что такое WebGL и будут изучать его с каждым новым изменением все глубже. Лет через 5-7 человек получит сильно улучшенный three.js и начнет делать то, что сейчас не представляется возможным. При этом, если технология не изменится на 100%, например не станет WebDirectX'ом, то человек, начинавший сейчас и год занимавшийся… ловлей рыбы, например, вернется, быстро просмотрит изменения и начнет что-то делать. Возможно пару месяцев он будет делать недостаточно эффективно, т.к. не знает всего набора новых инструметов и не имеет наработок. Но через 2-3 месяца он станет даже более эффективен, чем начавший с инструментов, т.к. понимает, что же там происходит внутри.
И насчет гнаться — я бы это не назвал гнаться. Но вот способ обновлять знания — было бы неплохо найти. Для себя я решил, что время от времени надо смотреть, что делают молодые команды, даже если все во мне кричит, что я сделал бы лучше. Просто потому что они не имеют кирпич опыта, тянущий ко дну, и многие вещи делают просто, даже не знаю, что когда-то так просто было нельзя.
В тоже время я ни разу не чистый FrontEnd (хм, даже чисто программистом уже сложно назваться), так что возможно для кого-то все не так, как для меня выглядит.
shoomyst
Хипсторы должны быть в теме всего. У ребят уже реально крышу сносит