Сергей Протько

конфликты мерджей очень сильно тормозят

1) Дробите задачи, делайте ветки короткоживущими
2) Хорошая идея делать ребейз принятых веток
3) Попробуйте адаптировать под себя git-flow, как альтернатива хорошо себя показывает feature-toggles вместо feature-branches

Да и бд экспорт/импорт постоянно приходится делать.

1) Миграции
2) Старайтесь делать миграции так, что бы они не ломали предыдущие релизы. Ну мол если вам надо добавить колонку, хорошей мыслью будет в первом релизе сделать ее nullable что бы старая версия приложения еще могла работать с новой версией базы, и потом уже следующим релизом добивать этот кусок. Основная идея - желательно что бы две последние версии приложеньки могли работать с последней версией базы данных. Если у вас база нормализована нормально, то проблем с этим быть не должно.

Если второй пункт соблюдается то вакатка новых релизов будет происходить по такому алгоритму:

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

При таком сценарии даунтайм будет минимальным.

вопрос с выкатыванием новых релизов

Вот вам варианты в порядке сложности и мощности (от простого к сложному).
- capistrano/capifony
- ansible/puppet/chief/etc
- docker + docker-machines + docker-compose

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

Да, а приведенный вами код - аутентификация

p.s. надеюсь вы используете password api для хэширования паролей а не какой-нибудь там md5.

статическое наследование - наследование статических членов классов.

денег на разработку нет

Вы проиграли в этом месте. Если вы делаете проект просто так, идеи ради, выложите где идею на каком стартаб хабе или еще где тусуются всякие предпримчиые люди. А если же денег ради, то тогда идите в банк и получайте кридит, копите и т.д.

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

А в чем смысл подобного сравнения? И да, выбранные вами параметры весьма условны. Время написания уж точно выкиньте, это только ваша скорость и она не дает объективной оценки. Количество кода - так же весьма условная штука. наличие паттернов - они так и так будут, просто реализованы чуть подругому. Это так же не показатель.

Показателями могут быть, соблюдается ли принцип подстановки барбары лискоу при написании модулей. принцип единой ответственности, принцип инверсии зависимости и т.д. Короче пройтись по SOLID. И стоит думать именно в том контексте, позволяют ли выбранные инструменты писать вам код так, что бы соблюдались эти принципы.

Есть довольно распространенные практики по сбору метрик кода, оценивающих сложность и качество архитектуры, но они оценивают именно ваш код и плохо будут показывать насколько все плохо. Из инструментов по сбору этих метрик могу выделить только scrutinizer-ci.

ну мы имеем простенький DSL с довольно простой структурой. Сначала мы должны распарсить строку. Ваш пример можно попробовать распарсить регулярками. Если регулярками сложно - можно попробовать написать посимвольный парсер. Ну и еще неплохой идеей будет воспользоваться генераторами парсеров: pegjs.org

Из строки собираем детали задачи. Что-то в духе:

var task = {
    site: 'http://site.ru',
    find: 'selector', // селектор у вас не стандартный, придется парсить и его еще отдельно ..
    result: '' // и описание результата тоже 
}

Ну а дальше уже выполнять таску.