Yuri Shilyaev. Blog.

Повсеместное использование веб-стандартов — это один из путей развитии сети. Мне хотелось бы, чтобы мы все пошли по нему.
«Мы» — это разработчики всего мира, которые уже говорят на одном понятном и простом языке веб-стандартов.
Пока я не видел ни одной достойной альтернативы этому немного идеалистичному замыслу, поэтому я с w3c и людьми, которые по-настоящему _развивают_ сеть.

http://icant.co.uk/webstandardsforbusiness/
Wiki аргументов и контраргументов в пользу веб-стандартов.

Один, из обязательных, к заполнению, пунктов, как раз “Для кого выгодно?”.

Думаю, вам будет полезно почитать.

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

Как инженер, я не вижу большой разницы между стандартами на болты и гайки и веб стандартами. Единственное различие, что в вебе «исторически сложилось» полное отсутствие стандартов, как таковых. (Думаю, что причиной тому — скорость развития технологий) С этим, по моему успешно, борятся сознательные инженеры и неосознанные фанатики.

Даже в “эпоху наращивания сетей передачи данных” есть маломощные каналы и клиенты. Есть и будут всегда. По мне так это аргумент на все времена. Всегда найдется чем занять канал кроме кривого кода.

Сам вопрос вроде правильный. У сознательного специалиста это будет от зубов отскакивать. Главное чтобы спрашивающий определился наконец кому специалист должен отвечать: инженеру, менеджеру или инвестору? А то из заметки я так этого и не понял

Но вот что если специалист не знает других методов кроме стандартных? Человек не выбирает, как работать прямо или криво, он всегда работает прямо. Если человек не подкован в холиворах и не привык убеждать других, что белое - это белое. Выглядит как налог на сознательность. Специалист по веб-стандартам не обязан быть агитатором, с готовым аргументом для каждого. Вон, те кто работает как попало, себя такими вопросами не утруждают. И обычно просто отмахиваются от спрашивающего.

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

Компания в комментах подобралась отменная. Только Макса Россомахина не хватает.

Так вот на счет инженеров и инженерного подхода. Да, для инженеров также важно, как и для простых людей, чтобы инструменты, которые они используют были удобны и практичны. Тут спору нет. Но когда вы решаете задачу, то должны выбрать для ее решения какой-то вариант.
Вот возьмем плотника. Ему удобно забивать гвозди молотком. Действительно удобный иснстумент и значительно более удобный, нежели камень. Но это плотник. Он не инженер. Что делает инженер, когда сталкивается с задачей забивать гвозди? Он создает молоток с прорезиненной ручкой, продумывает эргономику? Нет! Он создает пневмолоток.
Я уверен, что в W3C сидят инженеры, которые не только из удобства эти стандарты создают, но смотрят дальше.
Пока все, что я слышу это разговоры про правильно и не правильно. А ответ от людей хочу слышать: необходимо или возможно.
Возможно забить 10.000 гвоздей обычным молотком? Возможно, но лучше воспользоваться пневмомолотком или же вообще чем-то принципиально другим.

Я уже здесь.

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

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

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

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

Со временем всё устаканится. Сеть не минует стандартизация.

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

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

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

А-а! Так может нужны эффектные примеры? Более эффектные чем просто качественный код. Технологии типа style-switshing-a (default, accessibility, print), типа RSS и микроформатов… Я в правильном направлении думаю?

Юра. Решил и я свои 5 копеек вставить. Но не совсем по поводу “за” и “против”. Это ты от меня каждый день в офисе слышишь =). Я хотел бы сделать уточнение по поводу твоего примера. Он некорректен.

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

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

А классический пример с dvd плеером и dvd-диском который мы не можем проиграть на нем, просто потому что существует 3 стандарта записи dvd? (или те же болты)
Вот, imho, и есть причина стандартов…
Пускай лучше все используют, даже не до конца понимая.

Я читаю комменты и у меня складывается такое ощущение, что меня пытаются убедать в том, что задавать такой вопрос разработчикам запрещено. :))) Т.е. спрашивать понимание почему вы работаете именно так — это видимо как табу.
Может быть я отстал от тенденций развития этого мира, но мне всегда казалось, что лучше играют те музыканты, которые знают ноты. И художники рисуют лучше со знанием перспективы, а не только набора красок. А вы знаете, что можно рисовать с обратной перспективой? А знаете картины, которые так нарисованы и почему? Понимание. Понимание. И еще раз понимание.
Про молоток пример совершенно правильный и корректный. Паша, для интереса возьми и почитай, например, ТРИЗ — там дается отличная школа как ставить задачи. Постановка задачи — минимум половина ее решения.
Я у людей спашиваю про решения задач, а мне тут почти все говорят о том, что всем станет лучше, всем станет веселей. Я про килограммы, вы про километры.

ЗЫ. В частности под один текущий проект мы придумали, как с помощью использования веб-стандартов снизить нагрузку на сервер в несколько раз. По сравнению с неиспользованием стандартов. Вот это пример ИНЖЕНЕРНОЙ задачи, которые решает ПРОГРАММИСТ.
ЗЫ2. Я тут походу в словах напутал. Я не имел в виду, что разработчики не должны использовать веб-стандарты Я хотел сказать, что у них может не быть понимания использования. Поправил сейчас в заметке.

А разве “меньшие затраты времени на верстку” и “простота поддержки” не есть инженерная прибыль?
Либо кодер будет вносить правку в 200 страниц вручную либо в один ЦСС (утрирую) - разница в 5 часов.
Теперь так сформулировано? Полная аналогия с сервером - кодер(сервер) успеет сделать(обслужить) 4 проекта(сессии) вместо 1.

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

Мифы.
1. Про меньшие затраты на верстку не поверю. Приходит дизайн от некого художника, а потом верстальщик ломает голову, как это сделать по стандартам. Делать по-правильному как правило дольше, нежели фигачить.
2. По поводу простоты поддержки, то речь надо вести больше про структуру системы, а не про стандарты верстки как таковой. Если код раскидан по 100 шаблонам, то работы предстоит много по любому. Что касается полного выноса всего и вся в css, то тут пардон должен оговориться. Это красиво в теории, на практике дело обстоит куда сложнее. Не видел за свою практику еще ни одного сайта, которому бы потребовалась переделка дизайна исключительно через css. Эта модель использования работает только в блогах типа ЖЖ и подобных. В коммерческих проектах вместе с дизайном меняется ВСЕ.
Кстати… кажется еще со времен изобретения SSI никто уже в 200 страниц правки не вносит.

Про меньше затрат на вёрстку:
Погодите маленько, буквально в этом году появятся и распиарятся css-фрэймворки.
По сути это будут наборы совершенно базовых вещей, решений задач, которые делаются часто.
Такие есть уже, но они пока ужасны по удобству использования. У yahoo есть, по-моему.

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

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

Блин, далеко не сразу сообразил, где тут форма комментария.

“Делать по-правильному как правило дольше, нежели фигачить.” - очень спорный на самом деле вопрос. Скажем, зафигачить IE-only-страничку и больше к коду никогда не возвращаться - может быть. Только в реальных проектах, как правило, на сам процесс вёрстки тратится очень малый процент общего времени, в то время как остальное - на поддержку кода - это не только редизайн, а включает в себя и бесконечные правки, внесение улучшений, исправление багов, приведение к единому виду на всех браузерах и платформах и т.д. Здесь архитектурные решения, несомненно, играют роль, но далеко не такую значительную, как сама вёрстка, если речь идёт о ёё поддержке.

Не видел за свою практику еще ни одного сайта, которому бы потребовалась переделка дизайна исключительно через css

Почему ты решил, что поддержка осуществляется исключительно через CSS? То, что вмешательство в HTML минимально, не значит, что оно вообще не осуществляется. Дело ведь не в том, чтобы всё вырвать из рук одной технологии и осуществить с помощью другой, а в том, как реализовать их гармоничное взаимодействие. Поверь, время на поддержку кода с правильным использованием как HTML, так и CSS (не по отдельности, а в одном целом) сокращается в несколько десятков раз по сравнению с тем, что просто “фигачится”.

Опять 25…
Почему вы мне пытаетесь объяснить то, с чем я сталкиваюсь каждый день?
Вопрос по поводу фигачить и делать правильно не спорный. Делать по стандартам всегда было дольше и сложнее, нежели сделать “по-быстрому”. Кстати, Макс Россомахин выше уже писал об этом. Делать по стандартам окупается в поддержке. Да, но иногда надо просто “сфигачить”.
Что касается поддержки, то я как раз и писал не про CSS, а про поддержку всего кода. Зачастую HTML код раскидан по массе шаблонов, иногда осободеятельным программистом задействован внутри каких-то модулей. В итоге разработчик на поддержке сидит в 20 файлах правит, пытаясь понять какой кусок кода за что отвечает. Потому что документацию делать — это дорого, потому что верстать по стандартам — это дорого, потому что проектировать предварительно — это дорого. В результате в подавляющем количестве проектов, которые реализуются в вебе: программист пишет систему “по-правильному”, верстальщик — верстает “по-правильному”, а в результате тот же хоас, который всегда был. Почему? Потому что люди как раз НЕ понимают связки технологий. Тут по-умному сделано, тут по-умному, а в результате 150 костылей, чтобы вся эта чудная конструкция держалась и не падала.
Я занимаюсь управлением проектами, я об этих проблемах знаю очень хорошо.

Тю. Задаешь вопрос об одном, а клонишь в совсем иную степь. Изначально речь шла о применении веб-стандартов, а сейчас говоришь о проблемах управления проектами. “Дорого это”, “дорого то” - это уже проблема недостатка мозгов у руководителей, а не правильного применения web-стандартов разработчиками.

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

>Уметь стучать молотком и понимать зачем это делать резко отличают двух специалистов и попробуйте доказать обратное.

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

За разговор и заметку спасибо! Есть над чем подумать.

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