Разработчик предлагает PHP и MySQL для веб-приложения — это уже прошлый век или вполне норм?

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

В договоре с исполнителем сразу пропишите: 1) исходный код хранится в корпоративном Git-репозитории и права на него принадлежат вам, 2) таблицы базы данных спроектированы со связями (реляционная модель), 3) по окончании передается документация по развертыванию и структуре БД. Систему хоронит не язык, а отсутствие этих базовых вещей.

Сам PHP нормальный, тут дело в руках разработчика. Если он пытается впарить вам свой самодельный движок десятилетней давности — это беда. Ни один нормальный спец потом в этом ковыряться не захочет, либо влетите на консультации по 80 GBP в час.

Мы 4 года назад именно на PHP и MySQL подняли складскую панель. За сервер платим меньше 15 фунтов в месяц. Пашет как часы, ни одного падения. короче не ведитесь на хайп, сбережете бюджет.

исправление: ошибся в цифре, было чуть меньше.

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

В Британии почасовая ставка фрилансеров на редких языках крутится в районе 60-90 GBP, а толкового PHP-разработчика можно найти за 40-65 GBP. Когда решите прикрутить новые функции, на дистанции это сэкономит вам кучу денег.

Успех проекта зависит не от языка, а от грамотного бизнес-анализа. Если все бизнес-процессы описаны точно, настроена безопасность данных и автоматические бэкапы, связка PHP и MySQL полностью закроет ваши потребности.

а если мы потом захотим прикрутить к этому делу мобильное приложение PHP не станет помехой? не придется все с нуля переписывать?

edit: исправил несколько опечаток.

Верно. Когда пытаешься изменить всё сразу, ничего не приживается.

Проверено опытом.

У нас так же.

Не знал об этом.

Позвольте подвести итог сказанному выше. Если не зафиксировать это письменно с самого начала, потом возникнут споры.

Оставлю как заметку, пригодится.

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

График платежей должен быть привязан к этапам работ, а не к датам. Удачи.

Нужно идти по порядку. Чем сложнее отменить решение, тем медленнее его принимайте.

Конечно, если ваша ситуация отличается, всё меняется.

Вы правы. Внедрение процесса управления изменениями не замедляет работу, а ускоряет её.

Это мое мнение, не утверждаю, что оно единственно верное.

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

Исправьте, если я ошибаюсь.

Вы правы, я сам проходил через это. Без измерений мы всегда приходим к одному и тому же.

Если напишете результат здесь, это поможет и другим.

Мои сомнения развеялись, спасибо.