LINUX.ORG.RU

История изменений

Исправление Stanson, (текущая версия) :

Почему же «говно-»?

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

За такие деньги можно найти фрилансера, минимально знакомого с концепциями БД, и его руками сделать структуру табличек.

Да, тоже вариант. Причём если фрилансер объяснит что он делает какому-нибудь вменяемому сотруднику, то сотрудник и сам сможет запиливать какие-то нужные по ходу дела штуковины.

Загадка века — почему битрикс и SAP безбожно тормозят. Причем, даже в интерфейсе, а не в запросах к базе. Такое ощущение, что чем больше капитализация проекта, тем хуже техническое исполнение.

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

Загляните в EspoCRM и сравните с битриксом. Обе написаны на похапе/SQL/JS. Разница просто огромна.

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

Исправление Stanson, :

Почему же «говно-»?

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

За такие деньги можно найти фрилансера, минимально знакомого с концепциями БД, и его руками сделать структуру табличек.

Да, тоже вариант. Причём если фрилансер объяснит что он делает какому-нибудь вменяемому сотруднику, то сотрудник и сам сможет запиливать какие-то нужные по ходу дела штуковины.

Загадка века — почему битрикс и SAP безбожно тормозят. Причем, даже в интерфейсе, а не в запросах к базе. Такое ощущение, что чем больше капитализация проекта, тем хуже техническое исполнение.

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

Загляните в EspoCRM и сравните с битриксом. Обе написаны на похапе/SQL/JS. Разница просто огромна.

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

Исходная версия Stanson, :

Почему же «говно-»?

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

За такие деньги можно найти фрилансера, минимально знакомого с концепциями БД, и его руками сделать структуру табличек.

Да, тоже вариант. Причём если фрилансер объяснит что он делает какому-нибудь вменяемому сотруднику, то сотрудник и сам сможет запиливать какие-то нужные по ходу дела штуковины.

Загадка века — почему битрикс и SAP безбожно тормозят. Причем, даже в интерфейсе, а не в запросах к базе. Такое ощущение, что чем больше капитализация проекта, тем хуже техническое исполнение.

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

Загляните в EspoCRM и сравните с битриксом. Обе написаны на похапе/SQL/JS. Разница просто огромна.

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