Каковы особенности разработки самописного сайта для заказчика?

Question

[gmann12]

Здравствуйте! Хочу спросить совета у профессионального сообщества.
Суть вопроса в чем - нужно создать сайт, с перспективой на несколько региональных доменов, с уникальными калькуляторами, формами и прочими фишками. Страниц и разделов будет довольно много, но не интернет-магазин, около 500 страниц. У меня нет опыта с заказом сайтов, написанных на собственном ядре. Обычно делали на Wordpress.
Поэтому и не знаю, какие адекватные рамки стоимости (рассчитываю около 200 т.р., может чуть больше), какие есть подводные камни при этом, как выбрать разработчика? И может вообще, не нужно делать самописный сайт, а достаточно работать на какой то cms для этих целей?
Основные требования - скорость загрузки, чистый код, чтобы ничего не мешало seo продвижению, масштабировалось на поддомены, удобная админка.
Заранее всем спасибо.

Answer 1

[index0h]

Главный подводный камень: исполнитель привязывает вас к себе. В случае разрыва контакта - вероятно, дешевле будет переписать полностью, чем доделывать.

Comments

[Игорь]

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

[Никита]

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

[index0h]

Игорь
В целом действительно не всегда, но как правило. Писать на самописном движке имеет смысл, если ваш самописный движок и так популярный, например тот же Symfony и вы Фабьен, либо для решения очень узкоспециализированых задач, для которых впринципе движков нет.
Если исполнитель использует только свои наработки, просто потому что - скорее всего он хочет сделать то, что я написал в ответе автору вопроса.

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

[Игорь]

index0h: Ну тесты это конечно очень хорошо, но можно и без них. Имхо по степени важности (от максимальной и ниже)
1. качество кода и архитектуры
2. какая-никакая высокоуровневая документация (т.е. не по коду, а по ТЗ - что и зачем сделано, как развернуть)
3. VCS
и с этим вполне уже можно переносить между командами.
Но, в целом, я могу только повторить - хороший специалист сделает хорошо, плохой - плохо. Что с фреймворком или ещё чем, что без него. Если кто-то пишет на самописном, но код стройный и аккуратный - какие будут проблемы? Да никаких.
Я правда тут не беру во внимание, что самописный фреймворк может быть с ограниченной лицензией или закрытым кодом, это уже другое дело.

[Игорь]

index0h: "Вы часто встречаете проекты, как описал автор вопроса но с реализацией, что вы привели в пример?"
Ну наши все проекты такие (кроме тестов, тут зависит). Можно легко передать кому-то. Но от нас никто и не уходит.
Проекты, которые нам передают, да, там проблема. Поэтому и передают. Нередко даже VCS нету. Ну и качество кода почти всегда низкое. Но, с другой стороны, как много хороших разработчиков? Поэтому и не удивляет такая ситуация, работаем и всё.

[index0h]

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

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

[Игорь]

index0h: Хороший специалист тем и отличается от плохо, что работает так, чтобы экстремальных ситуаций было как можно меньше (планирование там, настройка процессов...). Нет автодеплоя в продакшен? Каждое обновление будет экстремальным. Нет тестов и хорошего QA? Рефакторинг становится экстремальным. Нет VCS и коммиты не привязаны к тикетам? Команда жаждет адреналина!

1. Чем больше проект, как правило, тем меньше ему подходит стандартный фреймворк, он вместо того, чтобы помогать, всё больше мешает. И тогда начинают что то дописывать, как то хатчить сам фреймворк. В результате получается своя версия фреймворка, и обновить её - малореально. Тогда либо едят и колются (куча ресурсов уходит), либо забивают на фреймворк.
2. Если у вас большой проект, скажем там 1кк строк бизнес логики, то всё равно основная сложность начинает концентрироваться именно там, а не в самописном фреймворке.

[awdemme]

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

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

Ну а наколенное решение, сделанное одним разработчиком, без какого либо отчета/плана/схемы/документации - безусловно, тут вы правы.

[awdemme]

index0h:

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

Хороший - так же не уберет за собой. Это зануда - уберет, из принципа.

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

[index0h]

Игорь

планирование там, настройка процессов...

Неа, этим занимается PM.

Чем больше проект, как правило, тем меньше ему подходит стандартный фреймворк, он вместо того, чтобы помогать, всё больше мешает.

Вообще говоря нет. Недальновидно выбранный фреймворк - мешает.

И тогда начинают что то дописывать, как то хатчить сам фреймворк.

Очень вероятно потому, что не смогли в фреймворк. Хотя... если это какой-то сборник антипрактик, типа laravel - вполне ожидаемо. Правда править код фреймворка - все равно очень плохая идея.

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

Верно, но за решенные задачи, типа DI, ACl, Router, ORM,.. смысла браться нет, так как это уже сделано сообществом.

Нет VCS и коммиты не привязаны к тикетам? Команда жаждет адреналина!

Ну, это вы вообще про какое-то дно говорите))

Хороший - так же не уберет за собой. Это зануда - уберет, из принципа.

Ну, это как плевать в колодец)) Не убрав за собой на это же наткнешься

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

Согласен

[Игорь]

index0h:
Ничосе, какой некропост вы забабахали. Пришлось перечитать ветку, чтобы понять про что речь))

планирование там, настройка процессов...

Неа, этим занимается PM.

У пиэма свои процессы и планирование, у разрабов - свои. Даже уборщице необходимо настраивать свои процессы и планировать свою работу.

Вообще говоря нет. Недальновидно выбранный фреймворк - мешает.

Про какие дальновидные выборы может идти речь в нашем мире lean стартапов и т.д.? Можно говорить про очевидно фиговый выбор, ну тут очевидно. В остальном - мы не знаем будущего. Да и YAGNI. Бесконечно гибких фреймворков не существует.

И тогда начинают что то дописывать, как то хатчить сам фреймворк.

Очень вероятно потому, что не смогли в фреймворк. Хотя... если это какой-то сборник антипрактик, типа laravel - вполне ожидаемо. Правда править код фреймворка - все равно очень плохая идея.

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

Верно, но за решенные задачи, типа DI, ACl, Router, ORM,.. смысла браться нет, так как это уже сделано сообществом.

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

Нет VCS и коммиты не привязаны к тикетам? Команда жаждет адреналина!

Ну, это вы вообще про какое-то дно говорите))

Встречаем такое довольно часто.

Answer 2

[Игорь]

Поэтому и не знаю, какие адекватные рамки стоимости

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

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

И может вообще, не нужно делать самописный сайт, а достаточно работать на какой то cms для этих целей?

Сильно зависит от того, что у вас за проект. Это уже должен решать профессионал в каждом отдельном конкретном случае. CMS - это инструмент, выбор инструментов - работа для профессионала.

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

Плохой специалист плохо сделает и на CMS и без неё. Хороший - и с CMS и без сделает хорошо, вот и всё.

Никаких волшебных ответов в вашем случае нет.

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

Answer 3

[blugamire]

Неделю назад сделал мелкий самопис за 25 000.
Уже 6-й год пилю крупный самопис. Там уже к миллиону подходит.

Answer 4

[iBird Rose]

гуглишь популярные фреймворки и ишешь разработчиков на них. они уже стали почти на ровне с cms. тот же Yii к примеру. чуть ли не половина php программистов на нем пишут. а значит и проблем в дальнейшем не будет.
p.s. еще бы посоветовал битрикс, но тогда ты профита не получишь в плане денег, потому что битрикс программисты возьмут много больше чем те же Yii программисты, причем просто потмоу что они битрикс программисты, а не в плане профессионализма или скила)

Comments

[WebDev]

еще бы посоветовал битрикс

когда же это говно уже уйдет с рынка...

[Игорь]

Посоветовал битрикс?? Наверное вы с ума сошли.

[iBird Rose]

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

[Игорь]

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

1кк руб - это в лучшем случае средний проект (нижняя граница), никак не крупный, даже по российским меркам.

[Алексей Скобкин]

тот же Yii к примеру. чуть ли не половина php программистов на нем пишут

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

Надо только оговориться, что и то и то популярно исключительно в России. В остальном мире популярнее более адекватные технологии типа Symfony и Magento.

Answer 5

[Egor Nedbailo]

MODx вам в руки, лучше не придумать. Привыкание к админке в течении получаса-часа, код чище не бывает, стоимость разработки в неск. раз ниже Битрикса (не считая стоимости лицензии, кот. еще увеличивает разрыв), в общем сплошние плюсы.

Answer 6

[jenovas]

Каждый кулик свое болото хвалит. Ответов море. И я очень удивлен что никто еще вордпресс не посоветовал. битрикс, кстати неплох, но нужно уметь готовить, да и с поддоменами намучаетесь. К тому же бюджет небольшой, а лицензия дорогая. Хотя если не магазин, то практически все можно сделать на младшей редакции. Для сильно кастомного проекта я бы всетаки предложил фреймворк. Можно, кстати расширить рамки и выбирать не только из пхп, а обратить внимание еще на pyton с его Джанго. Говорят достаточно быстрая штука, да и сам язык приятен, давно хочу заняться его изучением. Но что самое главное вам для начала нужно четко сформулировать задачу, а под нее уже выбирать инструмент. За более чем 10 лет в вебе я стал очень скептически относиться к людям которые громко кричат что один продукт какашка, а второй отличная штука. А на самом деле просто с одним инструментом разобрались, а со вторым нет.

Comments

[Ильдар Гизетдинов]

Последние 2 предложения, в самую точку

Answer 7

[bnytiki]

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

И, кстати, как вы оцениваете 200 000 для технологии, на которой еще не работали?
Может, там все 800 000 будет?

Answer 8

[xmoonlight]

CMS Joomla! и всё это - можно реализовать.
Только НУЖНО ЗНАТЬ! эту CMS!
А не так, что:
"Joomla, да, слышал! конечно будет работать!",
а потом:
"...делали на CMS Joomla! - оказалось полное гумно :("

Comments

[Adamos]

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

[xmoonlight]

Adamos: нужно грамотно защищать.

Answer 9

[Александр Шаповал]

Laravel. Огромное сообщество, тысячи дополнительных пакетов, всё интуитивно.
Это что касается фреймворка. На счет CMS я бы рекомендовал посмотреть October CMS. Это тоже самый laravel, только с толстым слоем кода который позволяет достаточно быстро поднять любой сайт с нуля. Плюс из коробки уже есть админ панель. Разумеется тут полная совместимость с laravel

Comments

[Александр Шаповал]

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

Answer 10

[Вася Петров]

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

Comments

[awdemme]

эффектом неуловимого Джо.

А еще закрытым кодом.

Answer 11

[awdemme]

В мелких проектах так:

Если ты разработчик - тебе интересно создавать самопис.

1. Это творчество, это опыт.
2. Заказчик к тебе привязан.

Если ты заказчик - тебе не интересно чтобы был самопис.

1. Непонятный результат.
2. Жесткая привязка к разработчику.

Однако в больших и одновременно очень нестандартных проектах все не так.

1. Самопис в итоге работает шустро, в том время как на базе CMS еле ворочится.
2. Стоимость разработки под CMS чего-то очень нестандартного будет очень велика.
3. Процесс разработки контролируется, процесс разработки ведется несколькими людьми, нет зависимости от разработчика.

200 тыс. рублей - это очень плохой самопис.
Это дешево.
Если у вас такой бюджет - делайте на CMS.