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

Но бывают и совсем другие дедлайны. Которые от безграмотного менеджмента и неуважения к разработчикам. Когда проект у людей висит уже не первый месяц, они что-то там возились, оптимизировали и даже разрабатывали функциональность, потом забрасывали на какое-то время, потом вдруг, скажем, под вечер в среду присылают письмо с архивом (!) проекта, частично даже без исходников (precompiledWeb), мол, ребята, вы там причешите в стиле (***) – в общем, нашего предыдущего большого проекта. Всё это без описания функциональности и без документации на сам проект, типа вы же такие умненькие, разберётесь. Типа, там же только таблицу стилей подредактировать. Запускаю проект (ага, без исходного кода, без связей, ещё повозиться надо, чтобы он вообще запустился, чтобы вообще хоть как-то увидеть интерфейс глазками, покликать по функциональным элементам), и тихо млею от того, насколько безграмотно организовано филе… больше сотни .aspx страниц, без шаблонов, с кошмарнейшим html кодом – доктайп не прописан ни в одной из, сплошные незакрытые или закрытые ошибочно теги (открыт параграф, закрыт спан), зато всё оформление прописано атрибутами в самих тегах. Да и значения атрибутов в одном теге то в двойных кавычках, то в одинарных, то совсем без оных. Встроенный в редактор валидатор кода зашкаливает, и это естественно – он подчёркивает всё, где видит неправильность, т.е. его использовать для правки смысла не имеет. А ещё часть функциональных элементов (сложных гридов, к примеру, с сортировками/фильтрами/настройками внутри, или календарик для фильтра по датам) вообще собираются js скриптом полностью – т.е. те же теги и атрибуты тегов – шрифты, цвета, фончики, извиняюсь. Какой css?? Ну и, повторюсь, весь этот хлам без сопроводительной документации. И даже тот факт, что запускающая для проекта страница называется Test.aspx, разработчики должны были понять сами ага.

Отписываютсь заатлантическим – ребята, тут недели на две кропотливой работы… А они мне… нет двух недель. У нас презентация в пятницу (помним, что проект пришёл в среду вечером). Вы уж там постарайтесь. Ну и как это называется? Это как раз и называется дедлайн безграмотный. А я так собиралась на следующий день отволынить от офисной работы вообще – планировала пойти на конфу по интернет-маркетингу… Я, кстати, там всё-таки побывала, целых три часа удалось выделить; правда только один доклад из тех, которые хотела послушать, застала. Остальные были либо до того, как я приехала, либо после трёх, когда я уже уехала на работу. Править этот срочный проект, до пятницы, до презентации. В ходе работы старалась не сильно злиться на тех разработчиков, которые сочиняли этот безграмотный код —я написала про незакрытые теги и кучу атрибутов в них, но ещё можно добавить 75% избыточного кода – бесполезных таблиц, вложенных друг в друга. Без них ничего не испортилось, зато можно уже было как-то заниматься “причёсыванием” интерфейса, но ведь даже на удаление всего этого избыточного кода тратилось время, большая часть времени.

Вспомнился недавний не очень лицеприятный коммент от читателя *ATimofeev* к одному из последних постов – “Почему увольняют дизайнеров?“:

Я, конечно, дико извиняюсь, но по моему, в большинстве случаев, какие-то завышенные и неоправданные требования предъявляются.
Про верстку вообще ни в какие ворота. *человек доказывал, что его вёрстка — супер, кроссбраузерная, а валидация* – про валидацию согласен, пусть меня заплюют, но во многом считаю ее не нужным мифом, который придумали верстальщики, а вот суперкроссбраузерность во многом качественный показатель, за который ругать или не учитывать как минимум странно.
*начинаю одного за качество кода отчитывать и заставлять перевёрстывать* – а какое качество должен иметь код? По моему самое главное – это чтобы везде и всегда работало как положено, без косяков, тогда пока результата не будет можно придираться. Или Вам принципиально, чтобы теги елочкой строили? )

Теги ёлочкой — это понты дешёвые, это можно и специальным тулзом перестроить, если есть желание. Хотя я не понимаю, почему нельзя сразу форматировать как-то вменяемо, чтобы парные теги (если они есть, потому что в присланном проекте местами даже ссылки не закрывались) можно было бы найти достаточно быстро, но это мелочи и не к ним придираюсь. Да, качественный код — это прежде всего работающий код, с этим не буду спорить. Но есть много примеров безграмотного кода, который В ОПРЕДЕЛЁННЫХ СИТУАЦИЯХ визуализирует страницу так, как требуется по заданию и В ОПРЕДЕЛЁННЫХ СИТУАЦИЯХ не сбивает функциональность сервиса, и на момент тестирования в самом деле жить не мешают. Но это не означает, что его можно не исправлять. И если сервис планируется дорабатывать и развивать, оформлять и презентовать, то говорить о том, что безграмотный код можно допустить в работу – не правильно. Да, разумеется, определив доменному диву положенный ему по стилю фончик и бордюрчик (выше написала, что постановка задачи по визуалу – сделать так, как на предыдущем проекте, типа новый сервис – небольшое ответвление его же), и сразу увидела, что фон уехал не туда, и нашла, где контейнеру нужно быть закрытым. Да, и так по всем незакрытым тегам. А ведь это можно было найти валидацией документов, и не списывать всё на временно кроссбраузерное отображение страниц. Да, поудаляла все атрибуты в тегах и вынесла всю отрисовку в css. Да, прошлась практически по всем страницам проекта, свела к минимуму (но не вычистила полностью) всю муть, прописала доктайпы, “причесала”. Да, опять по 12 часов трудотерапии. Но суть переработки была не в сложности задачи, а именно от безграмотного менеджмента + безграмотного кода, написанного, кстати, не программистом-разработчиком, а очень даже дизайнером-верстальщиком, который просто считает, что такой код – это то, что можно себе позволить (начальство проверяет в браузере, а не в редакторе, начальство к валидации не придирается).

Я могу понять верстальщиков, которые держатся за свой кривой код и не считают, что нужно что-то оптимизировать и вообще о чём-то думать. Ведь есть целая ниша веб-разработки, где это совсем не важно: это дорвеестроительство, это небольшие малобюджетные 5-страничные сайты-визитки для малого и среднего бизнеса, делающего свои первые шаги в сети. Это простенькие сайты, где жизненный цикл разработки – нарисовал, заверстал (пусть даже и безграмотно), вывесил. И всё. Нет развития, нет необходимости обращаться к коду для чего-бы то ни было – таких сайтов полно и в рунете, и везде. Их никто не будет доделывать – их проще убить и сделать заново ©. Но ведь совсем другая ситуация, когда верстальщика привлекают в большой интересный сервис, где не только валидация имеет значение. Где имеет значение логика макета. Где нужно планировать и оптимизировать макет. И хорошей вёрстке нужно учиться, на многих проектах, живых.

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