В каких случаях стоит переписывать сайт с нуля?

Question

[Айрат Кадырмаев]

Добрый день!

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

Есть ли советы по таким ситуациям.

Answer 1

[Ярослав]

1. 99.9% программистов жалуются на код, написанный его предшественниками.
2. 99.9% программистов жалуются на код wordpress
3. 99.9% программистов хотят все переписать по своему. И часто это самопис.

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

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

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

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

Answer 2

[sergealmazov]

Взять чистый WordPress.
Все, что можно перенести - перенести.
Все, что нельзя перенести - переписать.

Comments

[Quber]

согласен

[Роман Кокарев]

Возьму фреймворк точёный, срублю WordPress дрочёный

Answer 3

[Liny_li]

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

Comments

[Айрат Кадырмаев]

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

[Liny_li]

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

[Айрат Кадырмаев]

трудно найти спеца

[Liny_li]

Верно, но найти спеца, который сделает хороший самопис, еще труднее.

[Айрат Кадырмаев]

согласен)

[Айрат Кадырмаев]

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

Answer 4

[Влад Животнев]

> дорабатывали и делали разные мастера
Ни в коем случае на самопис не соглашайтесь. Вам ещё больше костылей насадят разные разработчики.

Answer 5

[FanatPHP]

Критерий прост. Если команда в состоянии написать лучше, чем на WP - переписывать. Если нет - оставить, как есть.
Что-то мне подсказывает, что в данном случае лучше не надо.

Answer 6

[GM2mars]

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

Answer 7

[Евгений Елчев]

Не так давно делал правки на сайте с WP, там та же ситуация что и у вас, куча кастомизированных решений (плагинов, да и ядро пилили). Тоже делала куча кодеров.Что в итоге мы имеем:
1) обновить нельзя ничего, так как нет гарантии что кастомный код не сломается, а найти его не просто
2) Лезут проблемы с совместимостью (в основном это jQuery) старые плагины требуют старую версию библиотеки, новые требуют новую.
3) Как разработчику мне действительно не удобно со всем этим работать.

Но я не рекомендовал заказчику переписать все с 0, потому что:
1) Рано или поздно ситуация повториться, и его новый проект обрастет кастомными правками.
2) Легче переписать один новый плагин, что бы он работал со старыми библиотеками, чем весь проект.
3) Зачем ломать то что работает.

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

Comments

[Айрат Кадырмаев]

ок спасибо)