Авторизация

5 советов верстальщику

1. Не ищите лёгких путей при решении проблем.

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

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

Если же отложить результат и потратить время на то, чтобы действительно разобраться, почему именно так произошло, в каких еще случаях появляется этот баг, какие вообще есть способы его решения (все, а не один), в сотнях подобных ситуаций в дальнейшем этот баг (во всех его проявлениях, а не только в этом конкретном) скорей всего просто не возникнет, потому что вы обладаете нужными знаниями для его легкого предотвращения. А если и возникнет - его можно будет моментально решить. С опытом при таком подходе начинаешь писать код, который сходу работает во всех браузерах, практически на автомате, не задумываясь - спросите у знакомых гуру, они подтвердят.

То же касается выбора решений. Не копируйте слепо кусок кода после того, как вы нашли решение Гуглом - уделите пару минут, чтобы найти и объяснение того, почему это работает.

И еще - это всё не значит, что вам придётся нарушать сроки ради профессионального развития. Просто научитесь учитывать это время при соглашении сроков с заказчиком.

2. Не бойтесь пробовать новые решения.

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

Если в решении конкретной задачи (например, image replacement или multi-column layout) вас устроил один конкретный метод - не останавливайтесь на нём. Продолжайте пробовать другие. Читайте в блогах о новых и применяйте их тоже. Вы получите ценный опыт и обретёте в своём деле гибкость. А гибкость - умение адаптироваться к меняющимся условиям - крайне важное профессиональное качество, которое в конечном счёте выиграет вам немало времени.

В частности, кстати, это касается выбора JavaScript-фреймворка. Холивары по этому поводу разводят аматоры - хороший front-end программист же легко сможет применить любой из них, поскольку благодаря своему опыту знает особенности каждого и принципы, по которым они создаются и работают. (Еще стоит заметить отдельно от совета, что конкретно в этом вопросе намного важнее понимать сам язык программирования JavaScript - он куда мощнее и интереснее, чем кажется на первый взгляд.)

3. Не подчиняйтесь инструментам. Пользуйтесь ими.

Возьмём в качестве примера web-стандарты и семантику. Это не нерушимые заповеди, - это инструменты, созданные для конкретных целей. Если вы ими одержимы только потому, что об этом вам твердят коллеги, - не разобравшись досконально, зачем, чему и в каком случае необходимо соответствовать - вы не сможете их правильно применить на практике.

Скажем, человек сделал многоуровневые выпадающие меню CSS-only и хвалится тем, что это сделало меню доступным (accessible) - теперь им смогут воспользоваться люди с отключённым джаваскриптом и пользователи screen reader'ов. При этом он не осознаёт, что скринридеры вопреки распространённому мифу вполне поддерживают JavaScript и на CSS тоже в определённых случаях реагируют (например, многие из них не видят элементов, скрытых с помощью "display: none"), и что этим решением не смогут воспользоваться как пользователи скринридеров, так и все другие люди, осуществляющие навигацию не с помощью мыши (например, только с клавиатуры) - все решения CSS-only dropwdown menu жёстко завязаны на события мыши. Мало того - отсутствие задержки при появлении и исчезании меню доставит немало хлопот людям с плохим зрением или нарушениями двигательной функции (например, болезнью Паркинсона) - фиг наведёшь на нужный пункт. Вот вам и доступность.

Обратный пример: разработчик тратит кучу времени на то, чтобы сделать навороченное веб-2.0-приложение идеальным с точки зрения семантики, не понимая, что для людей с отключённым CSS или JavaScript оно вообще никогда не будет представлять никакой пользы в виду его специфики, а поисковикам закрыт доступ на индексирование потому, что страницы доступны только зарегистрированным пользователям.

Еще пример: валидация HTML/CSS. Сама по себе валидность согласно определённому Doctype'у не приносит никакой пользы проекту, не делает его более доступным и семантичным и вообще ничего не говорит о качестве вёрстки. Это просто инструмент, и им нужно уметь пользоваться, а не слепо подчиняться. Скажем, лично я свои проекты привожу в соответствие с XHTML 1.0 Strict, но не потому, что это круто, возвышает меня над другими разработчиками и даёт хороший повод для критики, а просто потому, что лично мне так удобно по определённым соображениям (а вот Ване Сагалаеву такой вариант не нравится и он тоже совершенно прав). К сожалению, очень часто наблюдаю обратное. К слову: статья на эту тему.

Вникайте в суть инструментов, которыми пользуетесь. Знайте, когда нужно их применить, а когда - не нужно. Если применяете - знайте хорошо, зачем.

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

Если ваш заказчик (или начальник, или менеджер) предъявляет совершенно дурацкое требование, не нужно выполнять его, сцепя зубы и матерясь под нос. Потратьте время на аргументированное объяснение того, почему данное решение неэффективно.

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

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

5. Умейте находить побольше хорошего в выбранном деле и уделяйте ему основное внимание.

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

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

Источник: хабра

[ Saitadmin.ru || с 2006 по текущий год || Санкт-Петербург || Антон Панченко ]