Организуем процесс верстки большого проекта 18.06.2016

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

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

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

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

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

by 18.06.2016