Как я вижу правильную методологию веб-разработки

Начало

Было время когда я работал в notepad++ и напрямую кодил на сервере, очень часто по живому сайту в продакшене. Потом я подрос и стал подозревать, что так делать очень и очень не хорошо. Особенно, если сайт посещаемый. И я развернул локальный сервер, чтобы стремные куски кода сначала тестировать локально, а уж потом вываливать на хостинг. Но когда сайт уходил в релиз, все еще приходилось критические и срочные изменения вносить по живому. И вот однажды я пришел к мысли, что я живу не правильно. Бросил работу, уехал жить в сибирь, чтобы стрелять пушнину и топить снег. Но возвращаясь в реальность, хочу порассуждать о том, как делать правильно, что можно внедрить или уже используется в моей практике и какие инструменты могут помочь.

Разработка

Я не буду касаться вопроса согласования ТЗ, обсуждения нюансов с заказчиком, и т.д. Во-первых, непосредственно к  разработке это не имеет отношение, а во-вторых, у меня мало опыта в этой сфере. Представим, что у нас уже есть готовое ТЗ, дизайн и структура проекта, мы спокойно запускаем любимую IDE и начинаем работать. Допустим, что я буду выполнять так называемую full-stack разработку (не уверен, что в данном контексте это верное определение): т.е. полная разработка проекта — верстка, back-end, притягивание верстки к бэку.

Про бэкапы

Самое главное правило, которому научила меня правда жизни — работа должно бэкапиться. Сейчас речь только про разработку, про продакшн поговорим позднее. Для верстки я завел на гитхабе небольшой репозиторий, где лежит стандартная заготовка, которая не очень часто, но пополняется миксинами или новыми идеями. Клонирую репозиторий, удаляю папку .git, и заново инициализирую локальный git-репозиторий. В идеале тут же его отправить куда-нибудь в облака, хоть тот же github, но он не дает бесплатные приватные репы, поэтому я базируюсь на bitbucket. Один бэкап у нас уже есть, но мне этого мало, к тому же я бываю ленивой жопой и не создаю удаленный репозиторий, но при любом раскладе вся работа лежит у меня в облачной папке. Сейчас много неплохих облачных хранилищ помимо Dropbox, хоть та же Мега. Например, я верстку храню в дропе, а что-то большое в меге, т.к. дропбокс не дает много места за красивые глаза =) И тот, и тот умеет хранить версии файлов до 30 дней, так что теоретически, если например винт (давно уже ssd, но винт звучит круче) прикажет долго жить, то хоть какая-то последняя версия из облаков можеть быть реанимирована. По итогу, при идеальном раскладе у меня 2 бэкапа.

Система

Конечно, тут каждый сам волен решать как делать правильно, но! Обычно после этих слов начинают навязывать свою точку зрения, и я не буду исключением =) Считаю, что разрабатываться любая система должна в том же окружении, в котором будет работать в продакшене. Собственно вот и вся мысль. Большинство веб-серверов работает под управлением Linux, не обязательно устанавливать серверную версию, все линуксы плюс-минус одинаковые. Если не хочешь при деплойменте (выгрузке на боевой сервер) встретить нежданчик, то что делать я сказал: «Надо ставить Linux». Это не так страшно как может показаться. Дополнительным плюсом может быть попутное изучение устройства системы. Мне достаточно часто помогают навыки работы в консоли линукс. Хотя у нас в офисе только я работаю в Ubuntu, все остальные спокойно работают под виндой.

Непосредственно написание кода

Пользуйся теми инструментами, которыми умеешь, умеешь notepad++ — работай в нем, sublime text — пожалуйста. Когда станет мало их возможностей, перейдешь на что-то более тяжеловесное.

Если ты занимаешься только версткой, то дальше этот подраздел для тебя не имеет смысла, но я не встречал чистого фронт-ендщика, поэтому почитай не ленись. Очень желательно (читай ОБЯЗАТЕЛЬНО) установи локальный веб-сервер. Под винду есть стопицот веб-серверов, начиная от мертвого денвера и заканчивая чистыми apach+php+mysql. На моей практике установка под windows бывает не всегда безболезненная, но я в тебя верю! гугл еще никто не отменял, пользоваться разрешается =)

Нужно не забывать тестировать. Я знаю, что всегда очень лень тестировать то, что сам написал, лучшим вариантом будет специально обученные люди, которые будут заниматься тестированием, но если ты работаешь один, то научись писать тесты (кстати, я сам нахожусь в начале этого пути, так выпьем же за то, чтобы пройти этот нелегкий путь до конца!). Давай посмотреть на работоспособность своего кода другим людям, это не обязательно должны быть кодеры, но если ваша форма должна отправлять сообщение на email, то пусть кто-нибудь попробует что-нибудь отправить, используя её.

Релиз

После релиза не нужно удалять сайт с локального сервера, чтобы потом не было мучительно больно заново разворачивать его. Не бывает так, что после релиза все заработало как надо (на моей практике такого не случалось), тем более, что специального отдела тестирования у вас нет. Понятно, что велик соблазн дизайнерские изменения вносить по живому: шрифты поменять, логотип подвигать — это не нарушит работу ресурса. Но если вы что-то делаете по коду, то сначала нужно это проверить локально и только потом отправлять на боевой сервер. Соблазн изменить одну константу в продакшене очень велик, но сколько раз бывало, что изменив одну строку на выходе получал 500 ошибку с вариациями. Откатить никогда не поздно, но даже эти 3 секунды могут кому-то испортить впечатление. Это как оставить машину по середине дороги во дворе, чтобы забежать на 30 секунд домой за сумкой или ключами от офиса, когда выйдешь через несчастные полторы минуты, позади тебя будет как минимум один недовольный водитель, который прождал тебя целую минуту своей жизни. О чем это я? Херачить изменения на бою ни-ни. Сначала проверим локально, потом отправляем на сервер, даже если это всего лишь подвинуть логотип на 10 пиков вправо.

Командная работа

Достаточно скользкая тема. Самое главное, договорись со своими коллегами, как вы будете писать код и взаимодействовать, чем больше моментов и нюансов будет обговорено, тем меньше выкриков в стиле: «Да, *******! Кто так пишет?!». Заведите какое-нибудь письменное соглашение, обязательно нужно его закрепить как памятку, чтобы: а — можно было самому подглядеть, и б — новым участникам команды можно было его передать для ознакомления и не тратить время на лекции. Еще из обязательного, считаю, нужно завести общий репозиторий, хоть в облаках, хоть на своем сервере поднимите какой-нибудь гитлаб. Про систему контроля версий не вижу смысла писать, если ты работаешь в команде, и команда не использует систему контроля версий, мне вас жаль, желаю вам терпения и душевного здоровья и не забывайте про бэкапы, они вам точно пригодятся. Конечно, бэкапы все равно рано или поздно пригодятся, даже если используешь Git.

Стоит определить зоны ответственности. Не обязательно всё вешать на одного, можно разграничить одинаковые полномочия на разных людей по проектам, например, в продакшен в проекте А выкатывает только участник №1, а в другом проекте, участник №2.

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

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

Итоги

Многобукв про идеал, к которому нужно стремиться. Хочется верить, что наша команда сможет выполнять хотя бы 80% из вышеописанного.

Всем рок!