x
 
Марат
30 мая 2013

Расскажите, как правильно организовать взаимодействие разработчиков фронтенда и бэкенда?



Лучше всего, когда команда применяет «вертикальную» разработку. Все технологи знают серверный язык программирования и фреймворк, умеют верстать, писать Яваскрипт и выполняют работу под ключ. Сегодняшний уровень абстракции программирования позволяет быстро прокачаться до нужного уровня. Более того, хороший технолог ценен не только своим опытом и знаниями, но ещё и способностью быстро получить недостающие. Например, спросить у сведущего коллеги или почитать «Стэк оверфлоу».

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

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

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

Как проработать верстальщиком всю жизнь

Разумеется, такой подход подразумевает высокую квалификацию и готовность тесно общаться со всеми участниками. Постарайтесь исключить конфликты типа «опять они тут наверстали» и «опять они тут напрограммировали», сосредоточтесь на результате и не забывайте про ФФФ.

Бюрошная вакансия хорошего технолога

P. S.
Это был совет о разработке веб-интерфейсов. Хотите узнать всё об умной вёрстке, правильных скриптах, грациозной деградации, трюках и работе технолога с дизайнером? Присылайте вопросы.

Поделиться
Отправить

Комментарии

Максим Борзов
7 июня 2013

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


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

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

Вот такой веб 2.0.

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




Недавно всплыло

2 Как подружить иконки. Цвет 1 Как сделать нагляднее таблицу перфорированных лотков? Часть вторая 5 Как написать хорошее резюме? 7