Самописный сайт или CMS: что выбрать компании

За какую особенность стоит писать свою систему

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

Индивидуальный дизайн ещё не делает сайт самописным. На готовой CMS тоже можно изменить внешний вид и разработать дополнительные функции. Различие проявляется в том, сколько логики придётся создавать, документировать и поддерживать самостоятельно. Для каталога услуг с обычной формой своя система редактирования потребует отдельного обоснования. Если готовая платформа решает нужные действия без тяжёлых обходов, она предпочтительнее: компании выгоднее оплачивать своё отличие, чем заново создавать уже доступное управление текстами.

Причину выбора можно показать действием

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

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

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

Что получит следующий разработчик

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

Сборка отличается от копии готовой страницы

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

Для выбранного примера документация npm описывает package.json и запись зависимостей проекта. Зависимости — готовые программные части, которые использует сайт. Их состав объясняет, что потребуется для сборки и что будет нуждаться в обновлении. Читателю не нужно редактировать файл: название стоит в перечне передачи, а исполнитель объясняет его назначение и показывает, что перечень относится к передаваемой версии сайта.

Точный состав установленного набора фиксирует package-lock.json. По справке npm он позволяет повторно получить одинаковое дерево зависимостей, несмотря на промежуточные обновления пакетов. Это полезное различие для заказчика: общий список допустимых версий и снимок реально использованного состава отвечают на разные вопросы. Если новый разработчик сразу получил иной набор, часть ошибок может относиться к окружению, а не к его новой правке.

Паспорт передачи

• Исходники: место хранения, доступ компании и обозначение переданной версии.
• Состав: язык, среда, зависимости и необходимые внешние сервисы.
• Запуск: инструкция и демонстрация работы на отдельной площадке.
• Данные: где находятся записи и файлы, как их сохраняют и восстанавливают.
• Доступы: рабочие роли, владелец и порядок передачи секретов.
• Изменение: путь от задачи до испытания, выпуска и возврата предыдущей версии.

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

Почему поддержка входит в сравнение до запуска

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

Уникальность не освобождает от обновлений

Готовые части используют и в своей разработке. Их обновления оценивают по влиянию на сайт. Автоматически менять всё до самой новой версии опасно, а навсегда оставить исходный набор означает отказаться от исправлений и поддержки. Нужен ответственный. Он получает сведения об изменениях, оценивает срочность и выпускает подготовленный результат после испытания важных действий. Для компании предмет приёмки остаётся понятным: обращение приходит, редактор меняет текст, выбранный расчёт даёт ожидаемый результат.

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

Восстановление требует и программы, и данных

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

В документации PostgreSQL для экспорта описаны разные форматы. Plain представляет SQL-сценарий. Custom — архив, для восстановления которого предназначен pg_restore. Заказчику полезно знать не команду, а связь файла и способа его применения: полученный архив проверяют совместно с инструкцией и нужной версией инструмента. Выбор регулярного резервирования специалист обосновывает отдельно, с учётом объёма и допустимой потери новых данных.

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

Сможет ли компания сменить команду

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

Самопроверка перед выбором подхода

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

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

Свою разработку стоит выбирать, когда она закрывает нужное отличие и компания готова владеть её поддержкой. Если то же действие проще получить на готовой платформе, самостоятельная система управления станет дополнительной обязанностью без понятной пользы. Решение остаётся у владельца бизнеса. Для разговора с ШТАБ ИТ достаточно описать особую операцию и подготовить паспорт: тогда можно сравнить объём разработки и будущую передачу на одном результате.