Тут можно целую книжку написать. Все практики являются сугубо индивидуальными, и могут перениматься только частично. Начал бы свое повествование с банальностей для любого менеджера, но сложностей для 95% работников. Кодер является работником, который должен выполнять много рутиной работы. Эффективность труда зависит от ряда подходов. Есть ортодоксы-табличники, которые разумом своим остались в 90-х годах. Есть фанатики-стандартисты, которые доводят свое отношение к стандартам до маразма и этим и гордятся. Есть третий тип людей, которые всю работу расценивают с точки зрения экономической эффективности. Себя я отношу к последним. Почему именно экономическая эффективность? Потому что это залог успешной работы как кодера, так и всей компании. Есть два варианта работы над проектом - удешевить начальную разработку и удешевить изменения и дополнения. Большинство работает по первому принципу, и проигрывает. Проигрывает не сразу, а годика через три. Приведу простой пример. Вы беретесь за создание сайта-визитки, состоящем из 5-ти страниц. Оплата мизерная - 300 американских рублей. Один день вы тратите на то, чтобы найти темплейты, еще один день на то, чтобы перерисовать какие-то цвета и фоны, и день на наполнение сайта контентом. Ура, проект сдан, заказчик доволен, вы получаете 100 ар в день, и простой математический подсчет вам говорит, что при 100% загрузке вы сможете заработать аж целых 2.4 килоамериканских рублей в месяц. Неплохо, правда? Все хорошо ровно до того времени, пока заказчик не вернется к вам с расширением. Он помнит, что вы за три дня сделали ему неплохой сайт, и у него со временем возникли идеи по расширению структуры сайта. Вы с относительной легкостью добавляете пару страниц в текущий дизайн, и берете за работу, например, 20 ар. На добавление вы тратите пол дня. Ваш заработок в день составляет уже не 100ар, а всего 40. Идем дальше. Заказчик приходит к вам еще с десятком страниц. Если вы выставите ему счет в 100ар, он будет приятно удивлен, почему создание сайта стоит 300, а добавление десятка страниц - треть? Максимум, на что он согласится, так это на 30ар. 10 страниц потребуют переработки дизайна, кода и прочих радостей. Вы потратите три дня на разбор кода, переделки и наполнение контентом. Ваш заработок составит всего 10ар в день. Вы или теряете данного заказчика, или работаете себе в убыток. Теперь берем другую ситуацию, когда вы тратите на 2 дня больше, и прикручиваете простую ЦМС-инку для этого сайта. Да, однодневный заработок будет меньше, зато наполнение контентом или расширение структуры у вас будет занимать мизер времени, и вы можете вести вполне прибыльную деятельность в среднем. Аппетиты у клиентов растут постоянно, и в итоге вы сможете в конце-концов сожрать кусок пирога больше, чем сможете откусить. Теперь возвращаемся к кодингу. Закладывая чуть больше универсальности в код, вы сможете легко и быстро менять потом данную структуру. Не решайте задачу в лоб, как любят делать 95% людей на данном форуме, это путь в никуда. Как это реализуется на практике? Например, я для себя выработал стратегию минимального количества типов тегов в странице. Всякие "семантически-правильные" разметки в HTML считаю атавизмом и старьем. Язык HTML ограничен определенным количеством тегов, которые почти не отражают современные тенденции разметки страниц, и больше востребованы для текстового оформления, чем для оформления всей страницы. XML позволяет создавать свои теги, строить реально правильные семантические структуры, но есть огромная проблема в распространении данного языка в виде Microsoft и их гегемонией на рынке браузеров. Я выкрутился из этой ситуации простым способом, я перенес логическую разметку на классы. Вместо <ul><li>... я использую <div class="mainMenu"><a class="menuItem">. Становится практически неважными названия тегов, становится важным имя класса. Фанатики-стандартисты подымут бучу, что я нарушаю логику HTML, и списки нужно делать тегом списков, хотя на самом деле меню не является списком в том значении, который был вложен в UL в самом начале развития HTML. Для меню даже свой тег придумали в свое время - MENU, но потом от него отказались. В итоге в моей верстке используется с два десятка тегов. Дальнейшее развитие удешевления разработки - использование фиксированных имен классов для множества проектов, которые делают одну и ту же работу. Например, hiddenBlock, invisibleBlock, w100, w50, etc. Следующий этап - классовые константы. Например, сначала идет container, потом block, потом box, потом content. Или класс list, в котором есть item. Чтобы было понятнее, приведу простой пример <div class="menuList"><a href="#" class="menuItem">Menu item</a></div> <div class="newsList"><a href="#" class="newsItem">News list item</a></div> Или <div class="loginBlock"><div class="loginBox">...</div></div> <div class="pageContentBlock"><div class="pageContentBox"><div class="pageContent">...</div></div></div> Классы достаточно хорошо структурируются, и без особых усилий решается задача идентификации нужного блока. Следующий прием - модификаторы. Есть базовый класс, например menuItem, но этому элементу нужно добавить некую иконку как фоновое изображение. Добавляем этому элементу модификатор, например в виде класса redPoint, который будет делать только уникальную часть для этого элемента. Это можно делать инлайн-стилями, нужно смотреть по ситуации. Еще один действенный прием, который кажется идиотским, но он по своему работает. В нем есть смысл, доказано было не раз на реальных примерах. Я называют некий стиль по имени того модуля или той страницы, где он встречался впервые. Например, есть newsList, который неким образом оформляет список статей. Если на сайте нужно будет не в новостях применить список статей, то я использую базовый класс newsList, и потом применяю, если нужно, класс-модификатор. Теперь я точно знаю, что при дальнейшей модификации класса newsList, мне нужно пойти в раздел новостей и проверить, а не поломал ли я там чего. При полных абстракциях в именах классов придется пересматривать куда большее количество страниц, чтобы убедиться, что работа сделана без ошибок. Приучите себя не пользоваться линейкой для вымеривания точных расстояний между элементами. Я 80% размеров ставлю на глаз. Особенно это касается margin'ов и padding'ов. Ну и самое последнее, прежде чем приступать к порезке, внимательно изучите материал, который вы будете резать. Лучше час потерять на стадии планирования порезки, чем потом день на исправление и перепиливания лобзиком ошибок порезки. Пипетка и направляющие должны быть первым вашим инструментом.
