Почему «сайт на коленке» лучший вариант, если не уверен в успехе проекта?

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

Что значит «сайт на коленке»?

Это сайт с минимальным необходимым функционалом и наименьшей придирчивостью к архитектуре кода.

Есть два способа решения задач, которые стоят перед программистом:

Несколько лет назад на собеседовании у меня спросили, как я буду решать одну банальную задачу. Задача состоялась в следующем — подключаться к API погоды, оттуда тянуть данные, обрабатывать и выводить.

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

Вариант интервьюера достаточно правильный. Давайте разберемся для чего он нужен.

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

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

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

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

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

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

Я считаю, что сразу невозможно написать хороший код. Хороший код — результат постоянного рефакторинга. В течение развития проекта в любом случае меняется архитектура кода.

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

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

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

В сообществе Code Guru в ВК вы найдете больше интересных и полезных статей о веб-разработке. Подпишитесь, чтобы не пропустить новые материалы.