Шаблоны разработки

Опубликовано в Общее о программировании

Что делает легче жизнь разработчиков? Много разных вещей, к примеру, шаблоны.

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

Но в самом процессе создания шаблонов могут возникать некоторые проблемы. Нами были использованы несколько способов. Рассмотрим это на примере верхнего фиксированного меню:

1) В первую очередь мы подумали о том, чтобы писать все с нуля. Так как то, что создано своими силами намного приятнее использовать.

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

Теперь протестируем работу в различных браузерах и устройствах, находим баги (анимация где-то не доработана, где-то съехали якоря, где-то меню не фиксируется). Начинаем править. Снова делаем проверку и приступаем уже к правке мелких ошибок, проверяем и получаем неплохой результат.

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

2) Пытаемся найти похожие решения на других интернет-ресурсах, смотрим на  реализацию, повторяем.

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

А затем нас ждет еще и дебаггинг, что вовсе не является приятным, но в отличие от первого пункта действий, теперь он занимает больше времени.

Мы снова не довольны результатом.

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

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

Вывод:

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

Похожие записи:

  • Нет ничего похожего
 
Скрыть/Показать

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


 
Скрыть/Показать
Август 2017
Пн Вт Ср Чт Пт Сб Вс
« Мар    
 123456
78910111213
14151617181920
21222324252627
28293031  
Связаться со мной
Скрыть/Показать
Чат со мной - Обратится к нам в Skype
Архив записей
Скрыть/Показать
Скрыть/Показать
 
Скрыть/Показать

uptime узнать