Pull to refresh

5 советов IT-специалисту на примере вёрстки

Reading time 5 min
Views 2.7K
Эпидемия советов по вёрстке добралась и до меня (спасибо Юре Артюху) — с удовольствием ими поделюсь. Данные советы довольно общие и в принципе применимы к многим IT-специальностям, — вёрстка здесь используется просто как пример.

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, за которые начальник вас всё время пинает — всё равно дерзайте. Потеря энтузиазма означает в конечном счёте потерю квалификации. Наличие — постоянное самосовершенствование и великолепные результаты.

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

update: передаю эстафету с расширением тематики (эта уже приелась немного) — abstractioneer'у пять советов по Ruby/Rails, dobrych — по Python/Django, ld100 — по управлению проектами.
Tags:
Hubs:
+47
Comments 107
Comments Comments 107

Articles