Информационный портал за 60 000 usd.

А мерседес в ответ: мы проводили опрос в салонах и выяснили, что люди в источнике информации о машине/покупке почти не указывают интернет 😂 Удивительно, но это факт. Интернет никак не сказывается на покупках машин.

Записи таких переговоров надо бережно хранить, дабы потом в суде компании с киберсквоттерами они сыграли роковую роль... :D

Это что-то вроде новотеки и ридми планируется? Если да, то хватил вполне. Если же самостоятельный портал, то может и не хватит на оплату уникальных материалов. Уникальный материал это не так уж и сложно, но можно быстро и дорого, а можно долше и дешевле (и порой менее качественно)

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

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

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

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

А комментарии в проекте на 12-15 тыс строк кода - просто пустая трата времени т.к. никто комментарии в коде читать не будет. Максимум - блок комментариев в начале функции или процедуры.

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

А насколько оправдано в подобной ситуации строить систему например на Битриксе и уже в процессе развития проекта навешивать дополнительный функционал?

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

Давайте я попробую, наверное уже в 1000 раз описать свое видения преимуществ и недостатков солянки и заказухи.

Солянка

Преимущества:

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

2. Низкий бюджет.

Недостатки:

1. В Солянке не бывает 100% интеграции подсистем.

2. Наличие нескольких админок для каждой из частей

3. Невозможность интегрировать в систему некоторые нужные Вам компоненты в силу "заплаточности" архитектуры системы.

4. Сложность с управлением дизайном ( изменения в дизайн вносятся в каждой компоненте отдельно )

5. Проблемы с безопасностью: т.к. каждая из компонент содержит свои "дыры" вероятность вскрытия системы увеличивается с увеличением количества компонент.

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

7. Сложность с обучениеп мерсонала управлению системой.

8. С повышением количества компонент в системе стоимость владения системой растет экспоненциально.

Заказняк:

Преимущества:

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

2. Единое управление

3. Заточенность системы именно под Ваши задачи

4. Документированность.

5. Возможность интеграции с Вашими уже существующими системами.

6. Относительно низкая стоимость владения крупными проектами.

Недостатки:

1. Сроки у заказных работ существенно выше.

2. Стоимость

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

4. Нужна поддержка команды разработчиков ( При правильной документации и настроенном цикле разработки этот пункт несущественен )

Это вкраце. более подробно можно посмотреть здесь

Что же касается Битрикса или другой конкретной CMS, то надо сначала сделать ТЗ, безотносительно системы, а потом уже примерять его на конкретную CMS. При этом желательно иметь 2 ТЗ - "Минимальное" - то, что будет реализовано на первом этапе и "максимальное" - то что хотите получить в результате.

Вопрос в тему : Для Битрикса нужен отдельный серв или сойдет и обычный хостинг?

Вроди Битрикс слишком навароченный движок) лучше писать свой он будит быстрее и доступнее

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

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