Верстальщики и программеры.
Сержусь. На дотнет, микрософт, билагейтса и ленивых программеров. Можно сколько угодно говорить о валидной вёрстке, с умным видом вещать о том, что таблицы в гипертексте используются для табличных данных, а макет, все контейнеры документа, весь этот дизайн – для этого есть другие теги, что избыточность в вёрстке – это дурной тон, код должен быть оптимальным и совершенным, как алмазная призма. А потом с таким старанием размеченный шаблон верстальщик отдаёт программеру, и на стерильность можно забить уже через пять минут (и, кстати, не первый раз на эту тему пишу).
Из простейшей (на первый взгляд) странице с редактированием профайла юзверя только что убила четыре (!) избыточные одноячеечные таблицы. Одна обрамляющая контент, одна – для блока с общими данными юзера, одна – для Change Password если юзер кликнул сменить пароль и одна – на Confirmation, если всё прошло успешно. На четвёртой не сдержалась, подзываю программера, мол, шо за дела? Мы же договаривались – ты вообще никакую вёрстку на странице не делаешь, кидаешь свои контролы в линейном порядке, я сама разрулю, как они должны ОТОБРАЖАТЬСЯ! А он мне отвечает… я, говорит, и не добавлял никакую разметку… оно, говорит, само. Он в студии, в режиме дизайн за один клик просто добавляет целый блок (размеченную форму) для, к примеру, смены пароля – со всеми необходимыми тегами, айдишниками и прочими атрибутами. Охренительная экономия времени! И вот при таких вот автоматизированных для ускорения работы программера действиях и добавляется, автоматически же, “контейнер” в виде одноячеечной таблицы, обрамляющей этот блок.
Спрашиваю – а что, у нас программеры уже напрочь ручками код перестали писать? Или вся работа верстальщика должна заключаться в том, чтобы каждую страницу при доработке сначала долго вычищать от избыточного кода, самодобавляющегося при пользовании программистами режимом “дизайн”, от самопрописавшихся атрибутов width и height, которые появляются, когда программер в том же блин режиме “дизайн” случайно где-то что-то дёрнет? Или – ещё хуже, когда программист, утомившись программировать, вместо того, чтобы пойти чайку попить садится, и начинает “оформлять” созданные им только что формы.
И вот я вышкаливаю пару талантливых юных верстальщиков. Ругаю за ошибки при анализе сетки. Если позволяет проект – заставляю перевёрстывать, объясняю, что вёрстка веб-страниц – это как раз та отрасль, где уместно применять свои способности к анализу. Потому что на самом деле это так, прежде чем вырезать из эскиза первую картинку, прежде чем написать первую строчку кода, первый контейнер, имеет смысл потратить время на то, чтобы понять макет, продумать для него его модульную структуру; и если на недовёрстанной ещё первой странице макета появляется необходимость какому-то классу переназначить правила с помощью ! important – значит, недопроанализировал, значит – всё заново (ага, и как раз пару дней назад такое было) перевёрстывать, благо есть возможность. В отличие, к примеру, от тех ситуаций, когда приходит сюда давно свёрстанный проект на доработку программерам, и спустя месяц вспоминают про дизайн (ой-ё, Таня, тут бы поправить бы), и ты прекрасно понимаешь, что поправить “честно” не выйдет. Или вместо 30 минут надо затребовать 3-4 дня на перемакетирование и перевёрстку всего этого разросшегося уже проекта, или – переназначение доменных правил, увы. Но если есть возможность – давайте продумывать макет изначально так, чтобы не было необходимости во всех этих important`ах.
И вот они, такие продвинутые верстальщики, откроют свой проект через какое-то время, когда уже динамика, посмотрят на код страниц… На все эти самодобавившиеся и саморасплодившиеся таблицы. На разъехавшиеся контейнеры из-за самопрописавшихся в их содержимом ширин и высот. И спросят меня – Таня, а к чему был весь этот предварительный цирк с логичной и валидной вёрсткой? И я не буду знать, что им ответить. Или – как мне сегодня программер посоветовал – посоветую им так же написать гневное письмо Биллу Гейтсу, или разработчикам Visual Studio, чтобы они укротили свой сервис с такими полезными автоматическими решениями. И режим “design” в Visual Studio прибили нафиг, навсегда. О. И Visual Studio тоже прибить, и тоже навсегда. Пусть на Java переучиваются, ибо нефиг.
О да, это беда. Программеры действительно постоянно портят работу верстальщиков.
В данном случае скорее о тулзе, который “помогает” программерам усложнить работу верстака. Как дела, Паш? Редко пишешь.
ну и программеры тоже частенько руками не лучшие вещи вставляют в код верстки. Дела в принципе неплохо. Мы с Сергеем зарегистрировали таки ООО “Ловата груп” =). Сейчас много работы, плюс открывались, а сейчас офис ищем. Вот и писать стал мало. Обещаюсь исправиться =).
Ну, когда я (программер) подхожу к верстальщику и говорю “мне тут нужно в макете вот такое вот (много размахиваний руками)” — а мне отвечают “так ты же и сам можешь это сделать”…
Да, могу. Да, это будет валидно и будет работать.
Но я не верстальщик, я программист… И я не хочу тратить свое время как программиста на то, чтобы делать изменения в верстке…
Вот как с этим поступать?
Не понятная проблема. А разве у него нет обязанности заниматься вёрсткой этого проекта?
Как тут поступать… Каждый должен заниматься своим делом. Если не хочет – нужно уточнять должностные обязанности у руководителя подразделения.
О, ещё один глюк протестила. Мда.
Да, когда говоришь людям про светлое, чистое и валидное, берёшь на работу, обещаешь поэзию… а потом сталкиваешься с программерами из середины 90-х, которым, по большому счёту, пофиг… хочется кого-то сильно стукнуть.
И тем более трудно общаться с программерами, когда он тут же показывает, как автоматом добавляет на страницу контрол, а Visual Studio сама обрамляет его таблицами, такими вот, бессмысленными одноячеечными, и он недоумевает, мол как же – такие авторитетные разработчики создали этот механизм – что же здесь может быть неправильного?
А про мою фразу “а что, у нас программеры ручками код больше не пишут?” тут ещё долго обсуждали…
А фраза мне нравится…
Прочитав все, конечно хочется сказать много чего… но как один из ушедших скажу одно: вопрос не в том, кто чем пользуется – вопрос в том как достигается результат и какой ценой.
А учить хорошему стилю web-developers надо, иначе не быть им таковыми
ЗЫ Наумову привет, я кстати кран в состоянии и сам починить
рад за Вас, а я вот нет. не умею. т.е. могу конечно если уж сильно припечет, но результат…
а все лишь потому что идеал..это лишь предел мечтаний.
и либое стремление к нему не может быть достигнуто.
ну естесвенно помогает в этом “универсализм”… всякие самопрописывающиеся штуки и.т.д
это еще одна проблема, причиной которой является не поставленный процесс девелопмента. куча вопросов. почему программисты считают свою работу важнее и лучше работы кого-то еще? почему код вычищают дизайнеры, а не тот, кто в него нагадил? почему лидеры командр разработчиков позволяют подчиненным подобные вольности? с каких пор применение визуальных средств разработки UI стало разрешено?
собственно ответы на эти вопросы помогут в том числе и тебе, Таня, понять что именно не так.
Случайно попал в этот блог и почитал то, что пишут в полях обсуждения и чесно говоря шокирован!
Я веб-программист и работаю удаленно на фирму из России. Кроме своей работы веб-программиста иногда из-за нехватки рук приходиться делать и верстку по утвержденному psd исходнику, и правка Флеш-роликов (иногда не только тексты, а и AS). Все это делается только руками, никакого визуального редактора! И это не требование фирмы, это требование к себе самому, как к специалисту. Если пользоваться визуальными редакторами, то простите, вопрос сам всплывает на поверхность: “Вы плохо знаете теорию?” Ведь проше написать за час код руками, чем за 5 минут “сворганить” его в визуальном редакторе и потом часами вычищать его от мусора и подгонять каждый раз под нормальную реализацию во всех браузерах!
Лично бы я, увидев раз что пользовались визуальным редактором – сделал бы замечание и предупреждение, а второй раз – “закрыть двери с обратной стороны и больше их не открывать”.
Жестоко скажите? Нет, не жестоко! Если вы профессиональный водитель автомобиля то это не значит что пробив колесо нужно или ждать приезда помощи или злясь на механика открутить пробитое колесо и запаску “тяпь-ляп” наживить двумя болтами и погнать снова по трассе!
Удивлен я Вашим обсуждением, кто прав а кто нет. Визуальными редакторами пусть пользуются школьники и начинающие, а не ВЫ профессионалы своего дела.
да, Сергей, я плохо знаю теорию. я не смогу завтра получить сертификат Sun Certified Java Programmer. я ужасно знаю теорию. поэтому я не работаю в МИИКе, в ТимДеве, в Зорал, в БитЛаб… и несть им числа. хотите я набросаю Вам 10 пунктов, почему я не возьму на работу человека, который отлично знает теорию? знание теории не делает человека профессионалом. профессионалом человека делает умение применять свои знания и не знания на практике.
теперь о визуальных средах. в своем предыдущем комментарии я о них отзывался негативно, я действительно противник визуальных сред разработки, как единственного и конечного иструмента обработки дизайна. я изменю свое мнение, когда узнаю о визуальном редакторе, который верстает валдный HTML, хотя бы на уровне layout. в случае, когда “болванка” вестается в визуальной среде, а потом дотачивается напильником — не имею возражений. но это в любом случае ручная верстка. хотя если кому-то так удобнее и эффективне — мне все-равно.
p.s. кстати, я генератор от радиатора отличаю только потому, что мой отец закончил ХАДИ и чинит свою машину сам с 1993 года, когда она у него появилась. и краны я менять тоже не умею, мне для этого сантехник нужен. и не тот, который 30 лет в ЖЭКе проработал, а тот, который сделает так чтобы не текло.
хм. а чего стоит “умение применять свои знания на практике” без собственно самих знаний ?
Тут возникает вопрос, кого считать профессионалом, а кого нет… А эта тема достаточно сложная…
Да, позвольте уточнить — вы случайно не в “Блокноте” это все делаете?
Ага, правильно, пускай программисты и за тебя работу делают, а ты будешь просто зарплату получать.
А это Евгений, молодой человек, который не умеет читать.
Со всем согласен, только никак не пойму, причём тут Visual Studio как инструмент и какое преимущество Java даст при неразрушительной начинке функциональностью?
Это же всё только руки: затаскивая контрол в размётку (проще на мой взляд IntelliSense использовать, но это неважно) я всегда делал это в режиме кода и ни разу не замечал ни таблиц ни прочей ерунды. Конечно режим Design – для домохозяек, но всё же, суть-то не в инструменте. Каждый выберет меру своей испорченности.
Кстати, использование AJAX и массированного кода на клиентской стороне вообще делает почти невозможной использование какой-то одной готовой разметки. Всё же придётся разбивать на кирпичи и отрисовывать динамически, создавая на клиенте. Это можно будет сделать в начале, а вот когда оно вырастет и заживёт… Вызов дизайнеру.
У нас в основном именно такие проекты, правда все предыдущие (которые казались сложными), на самом деле были разминкой перед тем, который в разработке и совершенствовании уже пол года. с конца августа. Здесь очень сложно. 90% кода – можно посмотреть визуализацию только в зависимости от условий, верстать-отлаживать очень сложно, а на подпроекте этого проекта вообще возможно только при коннекте к реальной базе + при проведении реальной транзакции.
А про режим дизайн. У меня не находится слов, чтобы объяснить нашим программерам (не верстальщикам!) всё зло этого режима, так же не могу убедить ТД сделать корпоративным правилом использование только режима code. Он-то не криворукий, у него подобных сбоев не бывало. И он просто не видит проблему, которую порождают остальные.
Верстальщики и программеры, продолжение: [...] прошлого поста о верстальщиках и программерах могло сложиться (и у некоторых, судя по переписке, [...]
Хороший код пишется только руками.
И не имеет значения – идет речь о верстке или программировании.
Естественно, всегда используется какой то инструментарий.
Но чем он проще – тем, как правило, лучше для проекта.
Например, я использую в качестве редактора emeditor – блокнот с нормальной поддержкой кодировок, поиском по регулярным выражениям, подсветкой синтаксиса и нумерацией строк.
Все.
Больше мне для результативной работы от инструмента ничего не нужно.
И верстка, как и код, у меня выходят достаточно неплохие.
Если человек использует визуальную среду разработки это признак того, что:
1. Человек не достаточно разбирается в том, что пытается сделать и “облегчает себе таким образом жизнь”.
2. Человек готов пожертвовать качеством кода для ускорения процесса разработки.
3. Человеку просто все равно какой результат он выдает. Лишь бы работал как то… С визуальными средствами разработки то легче. А руками писать – лень.
P.S. Если программер сетует на майкрософт а не на свои руки, то надо гнать такого программера.
Кроме блонота и визуальных сред есть еще IDE. (Но они совмещены с визуальными обычно) И использование имено IDE весьма сильно повышает производительность.
И причин этому – море.
1. Подстветка синтаксиса.
2. Поиск ошибок.
3. Подсказки в параметрах функции.
4. Автодополнение переменных/констант/имён функций.
5. Поддержка проектов.
И если разработчику придётся пересесть за блокнот (достал уже KWrite) вместо нормальной среды (От zend на работе пришлось отказаться, а Eclipse тормозит жутчайше..
) то он будет также писать код, вот только уже без всяких удобств.
Да, об этом как раз (в общем) и писала в следующей заметке, в продолжении.
про код согласен, с признакми — нет. для построения десктопного GUI визуальные среды исключительно хороши. более того, там можно минимально обрабатывать руками полученный результат — он все-равно эффективнее работать не станет.
когда я еще работал со Swing, меня очень сильно доставала необходимость перезапускать приложение при изменении позицонирования одного из элементов формы. правда это было очень давно….
Первый раз наткнулся на нормально статью в блоге веб-разработчика(верстака, не важно).
По проблеме – одноячеечное обрамление не так страшно. Страшней когда код при добавлении контрола вообще перестает быть валидным. Если первое все переживут, то второе уже нет.
Сами контролы можно поправлять вручную, плохой контрол значит. В идеале должно быть так, использовать для отступов либо стиль, либо ячейки, и в зависимости от нужды правильно формировать свойства добавляемого контрола. Но повторюсь, это не должно ни увеличивать размер и оптимальность кода, и, прежде всего, не лишать код валидности.