Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Профессия "Front-end архитектор"

Профессия "Front-end архитектор"

69bb6b30cd7b682ba5d5a1f352e6862a?s=128

Andrey Okonetchnikov

April 13, 2007
Tweet

Transcript

  1. Профессия «front-end архитектор» © Андрей Оконечников, 2007

  2. Слово.

  3. Слово.

  4. Слово.

  5. spacer.gif

  6. И началась эпоха веб-дизайнеров.

  7. Дизайнер- ремесленник

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

    целях и задачах.
  9. Cайтом должны пользоваться люди,

  10. искать и находить,

  11. делать покупки,

  12. читать новости,

  13. участвовать в обсуждениях.

  14. Стремление быть оригинальными приводит

  15. к необычным результатам...

  16. None
  17. None
  18. None
  19. None
  20. None
  21. Дизайн ради дизайна

  22. не ради пользователей

  23. не ради их целей и задач

  24. не ради удовлетворенности продуктом или услугой

  25. 10 фишек

  26. Почему так происходит?

  27. Очень часто дизайнеры думают...

  28. результат их работы — самый важный.

  29. Это не так!

  30. Графический дизайн — лишь один из аспектов веб-разработки.

  31. Такой же, как

  32. usability,

  33. accessibility,

  34. семантика,

  35. и контент.

  36. Немногие дизайнеры пишут код разметки страниц.

  37. Поэтому...

  38. После создания макетов, дизайнер выводится из проекта,

  39. а реализацией занимаются другие люди...

  40. Дизайнер теряет контроль над конечным продуктом.

  41. None
  42. None
  43. Можно относиться к дизайну как к искусству,

  44. но это имеет мало общего с реальным миром и его

    потребностями.
  45. +

  46. Низкое качество разметки страниц

  47. =

  48. Source: http://www.accessibility.nl/files/images/tag-soup2-035.jpg

  49. Source: http://andyhiggs.co.uk/blog/images/162.jpg

  50. Веб-стандартист

  51. Появились люди, называющие себя «веб-стандартисты» и выступающие…

  52. создание семантического и валидного кода

  53. разделение представления и содержания

  54. использование безтабличной верстки

  55. Веб-сообщество приняло их как реальное решение накопившихся проблем.

  56. Дизайнеры заявляют:

  57. «Веб-стандарты, не являясь выразительным средством коммуникации, мешают их творческой работе»

  58. Графический дизайн не зависит от веб-стандартов!

  59. Source: http://www.uwsp.edu/geo/faculty/ritter/images/maps/ocean_currents.jpg

  60. Source: http://www.photos-screensaver-maker.com/screen/images/scr-ocean.jpg

  61. Выверенный и хорошо выполненный графический дизайн действует на пользователей лишь

    через визуальный канал.
  62. Семантическая разметка, на которую «наложена» графическая составляющая, будет взаимодействовать с

    технологиями и механизмами Веба.
  63. Создать уникальный графический дизайн и реализовать его, используя веб-стандарты, —

    это реальная задача.
  64. Кроме того...

  65. хорошая разметка ускоряет разработку веб-приложений.

  66. Source: http://www.webdimension.co.uk/

  67. Время front-end архитекторов

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

  69. None
  70. None
  71. призваны упрощать и ускорять разработку и отладку веб-приложений.

  72. Усложняется логика работы приложений.

  73. Растут объемы данных.

  74. Это сделало стандартом «де-факто» наличие в проектах системного архитектора.

  75. системный архитектор

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

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

    его объектной модели
  78. нежели о деталях реализации под различными браузерами и платформами.

  79. Но!

  80. Результат работы фреймворка не всегда идеален и зачастую должен быть

    откорректирован.
  81. None
  82. C развитием серверных фреймворков, становятся все более сложными и фронт-енд

    технологии.
  83. и динамическое изменение страниц, Ajax

  84. drag & drop

  85. визуальные эффекты

  86. сложные элементы пользовательского интерфейса

  87. +

  88. user experience

  89. usability

  90. accessibility

  91. современные задачи уже не могут быть решены лишь с помощью

  92. HTML & CSS

  93. безтабличной версткии

  94. умением писать валидный код

  95. Front-end архитектура

  96. Учитывая то количество различных технологий и способов решения тех или

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

    использовать в данном конкретном случае.
  98. — Использовать CSS или JavaScript для создания выпадающих меню?

  99. — Использовать текстовые, графические или sIFR загловки?

  100. Каждый из способов имеет свои плюсы и минусы, которые могут

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

    и владеть ситуацией.
  102. Для принятия правильного решения

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

    факторов:
  104. usability

  105. accessibility

  106. серверную реализацию

  107. задачи пользователей

  108. бизнес-цели

  109. Разметка страниц

  110. Основой фронт-енда является HTML разметка страниц.

  111. — Какой doctype стоит использовать?

  112. — Каким (x)HTML элементом кодировать тот или иной блок на

    странице?
  113. — Использовать атрибут id или class?

  114. Это зависит от...

  115. Какой серверный фреймворк будет использоваться?

  116. Какая функциональность будет на страницах?

  117. Потребуется ли менять внешний вид страниц?

  118. CSS

  119. CSS является презентационным уровнем фронт-енд модели приложения.

  120. — Как организовать CSS документы?

  121. — Создавать имена классов или привязать к элементам DOM?

  122. — Использовать наследование или писать дублирующий код?

  123. Это зависит от...

  124. Насколько крупное создается приложение?

  125. Будет ли меняться разметка страниц в процессе разработки?

  126. Как взаимосвязана функциональность страниц?

  127. JavaScript

  128. JavaScript & DOM scripting — это логика фронт-енд приложения.

  129. — Использовать onclick или “unobtrusive” обработчики событий для элементов?

  130. — Реализовать валидацию на стороне клиента или сервера?

  131. — Назначать стиль отображения inline через JavaScript или использовать className?

  132. — Организовать код через namespaces или использовать global scope?

  133. Это зависит от...

  134. Что решает эта функциональность?

  135. Как именно она должна работать?

  136. Поддерживают ли данную реализацию необходимые браузеры?

  137. Существуют определенные практики, знание и владение которыми позволит избежать множества

    проблем при использовании JavaScript.
  138. Ajax

  139. Полный Ajax!

  140. — Использовать Ajax или стандартный механизм с обновлением страницы?

  141. — Какой из вариантов наиболее удобен для пользователей в контексте

    решаемой задачи?
  142. — Как это отразится на доступности приложения?

  143. — Смогут ли использовать эту функциональность пользователи мобильных устройств?

  144. Это зависит от...

  145. Если отключен JavaScript, то Ajax функциональность перестанет работать.

  146. Этот недостаток можно обойти, но это потребует дополнительных усилий.

  147. И снова требуется кто-то, кто сможет дать рекомендации по использованию,

  148. кто сможет принять решение о необходимости Ajax в конкретном случае.

  149. Front-end архитектор

  150. front-end архитектор

  151. None
  152. None
  153. None
  154. None
  155. None
  156. Какими знаниями и навыками должен обладать фронт-енд архитектор?

  157. XHTML & CSS

  158. Кросс-браузерная и кросс-платформенная совместимость

  159. JavaScript разработка (DOM scripting, Ajax, UI)

  160. Flash & ActionScript

  161. Progressive Enhancement & Graceful Degradation

  162. Accessibility

  163. Usability

  164. Информационная архитектура

  165. Дизайн пользовательских интерфейсов

  166. Визуальный дизайн

  167. Логика генерации страниц (ASPX, Rails Views, etc.)

  168. Бизнес-логика

  169. • XHTML & CSS • Кросс-браузерная и кросс-платформенная совместимость •

    JavaScript разработка (DOM scripting, Ajax, UI) • Flash и ActionScript • Progressive Enhancement & Graceful Degradation • Доступность использования (Accessibility) • Удобство использования (Usability) • Информационная архитектура • Дизайн пользовательских интерфейсов • Визуальный дизайн • Логика генерации страниц (ASPX, Rails Views, etc.) • Бизнес-логика
  170. +

  171. Уметь общаться на языке разработчиков и принимать критические интеграционные решения.

  172. Хороший клиентский код — это часть задачи.

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

  174. Фронт-енд архитектор должен

  175. владеть ситуацией на высоком уровне

  176. уметь оценить преимущества и недостатки

  177. руководствуясь множеством факторов.

  178. None
  179. Умение писать код,

  180. проектировать пользовательские интерфейсы,

  181. владеть современными технологиями,

  182. следить за их развитием

  183. обязательные качества специалиста.

  184. Будущее профессии

  185. Пусть этим занимаются системные архитекторы?

  186. Системные архитекторы поглощены техническими аспектами разработки.

  187. Когда такие профессионалы будут востребованы?

  188. Вчера!

  189. Обязательно ли это связано с интернетом и «социальными» или «Веб

    2.0» сервисами?
  190. Отнюдь!

  191. Российский рынок труда

  192. Компании не доверяют многопрофильным специалистам и предпочитают нанимать узконаправленных фронт-енд

    специалистов:
  193. графических дизайнеров,

  194. кодировщиков HTML/CSS,

  195. JavaScript разработчиков.

  196. Но!

  197. они не смогут решить 100% возникающих проблем.

  198. Спрос на фронт-енд архитекторов появится в ближайшее время.

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

    конечный результат.
  200. А что сейчас?

  201. В настоящий момент явного спроса на фронт-енд архитекторов в России

    не существует.
  202. «Многостаночник» не может хорошо владеть всеми заявленными знаниями.

  203. Относительная дороговизна таких сотрудников.

  204. Не уделяется должного внимания вопросам usability, user experience, accessibility...

  205. Подводя итог

  206. Современному фронт-енду требуются свои архитекторы.

  207. Чем более сложные приложения будут разрабатываться,

  208. тем больше эта потребность будет расти.

  209. Отреагировать на изменения рынка — задача сегодняшних специалистов.

  210. Спасибо за внимание.

  211. Андрей Оконечников andrej.okonetschnikow@gmail.com © Андрей Оконечников, 2007