Для кого эта статья?
Html кодерам – начинающим кодерам поможет повысить
свой профессиональный уровень; оценить текущую ситуацию
в проектах, предупредить негативное течение проекта.Тем, кто
ещё только определяется «быть или не быть» больше вкурить
о профессии html кодер. Те же, кто в кодинге давно врятле
найдут в статье что-то новое для себя, а некоторые вещи
даже могут показаться не достойными внимания. Однако стоит
помнить, что очевидные вещи для одного — это неизвестный
мир для другого, а ваш опыт хорошей практики может быть
выходом из сложной сложившейся ситуации для кого-то.
Руководству – узнать, какие мероприятия стоит провести
в компании для улучшения рабочего процесса, повышения
опыта работников, уменьшения издержек (за счёт уменьшения
перерасхода проектного времени и учёта не просчитанных
ранее активностей) и повышения качества.
Руководителям проектов (Project managers) – поможет
учесть некоторые специфические риски проекта: узнать о
неизвестных ранее поглотителях проектного времени и не
запланированных активностях; узнать о реальных трудозатратах
по некоторым активностям; оценить и улучшить текущий уровень
ведения проектов.
Другим участникам web разработок – поможет больше
узнать о трудовых буднях своих коллег.
Изначально статья была в табличном виде, что соответствовало
семантике материала. Однако опубликовав статью в ЖЖ и
получив ряд не только бесценных комментариве (аля «неасилил»,«многа
букафф» ), но и практический совет переделать материал
без таблиц решил ему последовать. Работа над ошибками
проделана — статья приведена в блогоподобный (какие слова
порождает наше время) вид и выставлена на обозрение хабрасообществу.
Сгруппированные факторы
![](http://www.amazedev.com/files/html_d.gif)
Работа HTML кодера
1. Исходные данные и материал для вёрстки.
1.1 Вёрстка дизайна
Худший вариант:
Клиент присылает некачественный материал для вёрстки.
Материал в форматах pdf, ppt, jpg либо psd со склеенными
слоями, растеризованными шрифтами, шрифтами со сглаживаниями;
шрифтами, не входящими в поставку Windows. Требования
описаны словесно («сделайте красным», «сделайте, как здесь»).
Хорошая практика:
Материал для вёрстки должен быть в формате PSD (не исключён
другой популярный формат, поддерживающий слои). В PSD
используемые слои названы соответственно своему содержимому.
Шрифты, не входящие в стандартную поставку Windows, используются
только для картинок.
Влияние:
Склеенные слои, растеризованный текст и другие не соблюдённые требования к исходному материалу приводят к увеличению времени вёрстки.
Пример: в дизайне используется кнопка в виде картинки. Необходимо сделать похожую по аналогии. При дизайне, каким он должен быть, это займёт около 10 минут. При плохом качестве может занять и 2 часа.
Действия:
1. PM: На этапе выяснения требований дать клиенту
ознакомиться с документом по требованиям к графическому
материалу. (Содержащему примеры требований. Желательно
со скриншотами и пояснениями к каждому пункту).
2. PM: Вовлечь клиента в процесс контроля за соблюдением
требований при приёмке у сторонних дизайнеров. Объяснить,
что качество графического материала, прежде всего, влияет
на чувство доверия и отношения его будущих клиентов (пользователей)
сайта, а также на качество работы html кодера. (Важно
различать качественный дизайн и красивый дизайн: это не
тождественные вещи).
1.2 Редизайн
Худший вариант:
Клиент присылает или сообщает ссылки (что ещё хуже) на
страницы со свёрстанным дизайном плохого качества (без
типовых элементов, содержащим проблемы кроссбраузерности,
невалидный код).
Хорошая практика:
Клиент присылает свёрстанный код. HTML кодер, PM и другие
участники проверяют его качество и наличие необходимых
элементов.
Влияние:
Если факт плохого качества страниц не озвучен перед клиентом
или PM’ом, то за все вытекающие баги ответственность перекладывается
на HTML кодера. Тем самым увеличивается время незапланированного
фиксинга багов.
В случае со страницами, расположенными в Интернете, прежде
чем приступить к вёрстке, кодеру необходим этап переподготовки
для создания сайта локально. Это время следует учесть
при оценке.
Пример: Чтобы воссоздать локально сайт, где все
картинки прописаны в CSS, верстальщику надо отследить
путь каждой, прописать его в адресной строке, чтобы скопировать
каждую картинку на локальный диск. Количество прописанных
в CSS картинок не ограничено.
Действия:
1. PM: На этапе выяснения требования подчеркнуть
важность качества входящего материала и последствия плохого:
технические (баги, перерасход проектного времени, плохая
расширяемость) и негативное влияние на чувство доверия
и отношение будущих клиентов (пользователей).
2. PM: Просить клиента прислать свёрстанный код
вместо публикации на сайте (если нет FTP доступа). Это
позволяет HTML кодеру сразу же работать с кодом «как есть»,
не занимаясь переподготовкой. Важно отметить, что это
ещё и позволяет предотвратить тихое добавление клиентом
новых элементов под видом того же плана работ.
3. HTML кодер: Известить PM’а о возможных проблемах,
ошибках и качестве материала. Написать, каких элементов
не достаёт в новом дизайне. Попросить провести сравнительный
анализ нового и старого дизайна (выяснить, что меняется,
что добавляется, что убирается и т. д.).
2. Требования к вёрстке (DIV, table, смешанная).
2.1 Вёрстка на дивах
Худший вариант:
Проекты с требованием блочной вёрстки (семантическая вёрстка
с использованием DIV) выполняются кодерами, не имеющими
необходимого опыта, или используется блочная вёрстка там,
где она не обоснована.
Хорошая практика:
Блочную вёрстку стоит применять в тех местах, где это
применение обосновано (субъективное мнение), если:
— необходимо соблюдение стандартов;
— это единственно-возможный способ реализации;
— это требования клиента или платформы;
— это способ уменьшить количество багов у web-developer’oв
при работе с HTML кодом;
— необходимо упростить места соприкосновения клиента с
кодом
Умение «верстать на дивах» (и править достаточное количество
нетривиальных багов) требует наличия подобного опыта у
HTML кодера.
Менее изящная, но стабильная табличная вёрстка покрывает
основные запросы к вёрстке в 80% типовых задач.
Смешанная вёрстка — компромисс и способ вобрать лучшее
из двух вариантов.
Влияние:
Блочная вёрстка привносит вероятность несуществующих при
табличной вёрстке багов, таких как:
— неправильный рендер браузером;
— неправильное или непредсказуемое поведение вёрстки при
изменении размера окна, шрифта, размера текста и т.д.;
— сложные баги кроссбраузерности.
Подобные баги исправляются достаточно сложно, часто с использованием
хаков и незадокументированных возможностей. Решения не
всегда кроссбраузерны, расширяемы и надёжны.
Действия:
1. PM и HTML кодер: В начале проекта обсудить вопросы,
касающиеся типа вёрстки.
2 PM и HTML кодер: Воспользоваться консультантом,
попросить консультации у коллег.
2.2 Требуется табличная вёрстка, а исходный материал на
блочной
Худший вариант:
Для редизайна проектов, которые были на табличной вёрстке
клиент предоставил версию, полностью выполненную в DIV
вёрстке.
Хорошая практика:
Если предоставленный заказчиком материал выполнен на DIVах,
а существующая реализация — на таблицах, то необходимо
использовать смешанную вёрстку, а также учесть возможные
проблемы адаптации при временной оценке.
Влияние:
Если тип вёрстки не совпадает то, надо понимать, что переделывание
на новый тип — это уже не редизайн, а фактически создание
всего оформления с нуля, что в реальности приведёт к огромному
количеству багов, несоответствий и непредвиденных ситуаций.
Тот же результат (создание практически с нуля, а не переделка),
если заказчик прислал вёрстку не подходящую для используемой
платформы.
Действия:
1. HTML кодер: Использовать смешанную вёрстку (процесса
адаптации и багов на стыках двух типов не избежать, однако
это минимизирует расход времени в сравнении с созданием
с нуля).
2. PM: Понимать и учитывать при оценке, что в подобной
ситуации дизайн не берётся как есть. Конечный результат
представляет собой симбиоз прошлого решения и клиентского
варианта. Любое нововведение чревато багами, множащимися
в геометрической прогрессии.
3. Знание проекта (структуры папок, элементов, генерирующих
дизайн).
Худший вариант:
HTML кодер не знает проект.
Хорошая практика:
HTML кодер знает проект.
Влияние:
Незнание проекта приводит к тому, что на разбирательство
с особенностями реализации системы тратится время, выделенное
на выполнение самого задания. Следующая статья значительной
траты времени – баги и недоделки, произошедшие из-за незнания
системы (неучтённые страницы, разное отображение при разных
условиях и т.д.).
Действия:
1. Рабочий процесс: Изучение используемых платформ
в свободное от проектов время. Таск на ознакомление с
системой перед началом проекта. Проведение обязательной
аттестации на знание системы.
2. Рабочий процесс: Использовать в проекте консультанта
с таском «Консультирование» (кроме этого таска он в проекте
может не участвовать).
3. PM и HTML кодер: Воспользоваться консультантом,
попросить консультации у коллег.
4. Степень зависимости от программно- аппаратной части.
Худший вариант:
Высокая зависимость от программно- аппаратной части.
Хорошая практика:
Автономная, параллельная работа.
Влияние:
Примеры зависимостей, которые отражаются на времени:
— зависимость от аппаратной части ПК (Photoshop (несколько
одновременно открытых PSD), Dreamweaver (2-3 окна), TopStyle
(2-3 открытых файла), проводник (или коммандер), 2-3 открытых
браузера (FireFox, IE, Opera) и иногда программа для работы
c PHP – вот вполне типовой пример рабочий области).
— зависимость от аппаратной части и интернетHTML кодеру
в работе требуется видеть моментальный результат своих
действий, т.к. иногда вёрстка строится на предположении
и результатах того, как ведёт себя дизайн в определенных
изменяющихся условиях. Время ожидания результата иногда
превышает время на его создание. Когда, даже чтобы увидеть
результат самых небольших изменений, необходимо дождаться
долгой перегрузки всей страницы (а перезагружает страницу
кодер за проект достаточно много раз).
— зависимость от действий программиста и программ, связанных
с рабочим процессом. Несмотря на то, что SVN (и другие
системы контроля версий) призвана не только сохранить
код, но и распараллелить разработку, временами приходится
вместо разработки возиться с обновлением SVN и восстановлением
работоспособности своего хоста после обновления. Это связано
с тем, что параллельный разработчик меняет что-то радикальное,
скрывает или добавляет часть функциональности влияющей
и на работу HTML кодера.
Действия:
1. Рабочий процесс (проектная команда): Обсудить
влияние друг на друга и исходя из этого предложить порядок
тасков.
2. Рабочий процесс: Приемлемые мощности ПК и скорость
интернет.
5. Стадия вступления в проект.
Худший вариант:
Кодер вступает в проект, когда ещё не готова часть ключевой
функциональности или часть, влияющая на визуальное отображение.
Возможны вмешательство или доработки в уже проработанных
страницах. Остались не выясненными до конца части сайта.
Хорошая практика:
Проект проходит таким образом, что кодер и девелопер работают
либо параллельно, либо кодер после девелопера.
Влияние:
Регрессии необоснованно забирают время, которое не может
быть просчитано в начале.
Действия:
1. Рабочий процесс (проектная команда): Обсудить
влияние друг на друга и исходя из этого предложить порядок
тасков.
2. Рабочий процесс: Эффективные коммуникации по
ходу проекта позволяют избежать регрессий или снизить
их количество, избежать багов.
3. PM: Контролирует проект на промежуточных стадиях.
Отсутствие контроля со стороны PM в ходе проекта выльется
в регрессии, переделку и аврал в конце. Если в начале
идёт девелопмент, потом кодинг и натяжка, то перед натяжкой
следует проверить результаты девелопмента на соответствие
требованиям спецификации и своим представлениям. Как показала
практика, отсутствие этого приводит к следующим ситуациям:
— время на девелопмент израсходовано, и нет возможности
привлечь ресурс для доработки. Приходится отвлекать занятых
на другом проекте людей.
— нормальный процесс HTML кодинга нарушается. Из-за недоработок
приходиться переделывать и доделывать куски проекта, по
которым, как казалось, работа завершена.
— авральная работа, перерасход рабочего времени, баги.
6. Коммуникации и выяснение возникающих вопросов по ходу
проекта с участниками проекта.
Худший вариант:
Коммуникации затруднены (между клиентом и PM или участниками
команды).
Хорошая практика:
С коммуникациями никаких проблем.
Влияние:
Затруднение обсуждения оперативных вопросов ведёт к неоднозначному
пониманию требований. Если у вас был вопрос, который вы
решили самостоятельно, и его решение не совпало с видением
клиента, то это приведёт к переделке => потери проектного
времени.
Внутрикомандные коммуникации тоже влияют на процесс. Например,
использование IM при обсуждении оперативных вопросов часто
замедляет общение, т. к. некоторые вещи достаточно тяжело
и долго объяснять, и также приходиться делать это сразу
с несколькими людьми в нескольких окнах.
Действия:
1. Рабочий процесс: Один из неявных примеров улучшения
коммуникаций — словарь рабочего сленга в Wiki. Новый сотрудник
без труда может прочитать и понять используемые слова
из лексикона коллег. Участники проектной команды должны
проявлять инициативу в улучшении коммуникаций (использовать
как логические инструменты, так и технические средства).
2. Рабочий процесс: Для проектной группы лучше использовать
общий чат, где все участники проекта будут в курсе обсуждения
проекта.
7. Условия и ограничения используемой платформы или проекта.
Худший вариант:
Проектная команда не знает требований системы или работы
компонентов, отвечающих за дизайн. Приходится переделывать
под вновь узнанные требования.
Хорошая практика:
Вёрстка учитывает требования системы при натяжке.
Влияние:
Появляющиеся новые требования в виде ограничений и условий
системы приводят к переделкам и адаптации, что влечёт
трату незапланированного времени.
Пример 1: Не всегда есть возможность скачать текущую
версию сайта клиента, поэтому для работы локально приходиться
вырывать какие-то части и ставить их на локал. Ещё чаще
приходится делать сначала локально, потом после проверки
проделывать те же действия на клиенте. Незапланированное
время — это повтор тех же действий на клиенте и время,
потраченное на устранение разницы (закачка/скачка на/с
клиента).
Пример 2: Open Source сильно подвержен ограничениям
и условиям. Так в системе OsCommerce содержание категории
товаров генерируется жёстко в коде, что может повлечь
не только переделку HTML, но даже переделку PHP.
Действия:
1. Рабочий процесс (проектная команда): Обсудить
узкие места, изучить систему до старта проекта.
2. PM и HTML кодер: Воспользоваться консультантом,
попросить консультации у коллег.
3. Рабочий процесс: Конспектировать решение проблем
или сами проблемы в Wiki, создавая базу знаний.
8. Квалификация и опыт. Способность идентифицировать проблему,
решить и «законспектировать».
Худший вариант:
HTML кодер использует нестабильные решения, не заинтересован
в улучшении качества работы, безразличен ктенденциям и
техникам.
Хорошая практика:
HTML кодер совершенствует технику, интересуется тенденциями.
Знакомится с чужим опытом и создаёт собственные наработки.
Влияние:
Опытный специалист — ключ к решению любой задачи.
Действия:
1. Рабочий процесс: Популяризировать пользу базы
знаний. Культивировать и централизировать материал. Освещать
и доводить до сведения, вовлекать.
2. HTML кодер: Использовать прочтённое на практике,
не боятся экспериментировать, наблюдать результат. Знакомиться
и изучать смежные области знаний, накапливать и синтезировать
знания. Предлагать внедрение обкатанных и обдуманных вариантов.
3. HTML кодер: 70% проблем с которыми сталкиваешься
в процессе работы уже решал кто-то. Задокументированное
решение позволит не только не вспоминать судорожно, как
это решалось в прошлый раз, но и избавить от таких мыслей
коллег.
Продолжение следует…
Источник: Блог о web-разработке
и способах её улучшения