На примере Rails проекта по умолчанию при создании проекта есть файлы
config/application.rb
config/environments/development.rb
config/environments/production.rb
config/environments/test.rb
это порождает то что в разных окружениях будут разные настройки когда придерживаемся единообразия, то больше шансов обнаружить проблемы своевременно и съэкономить на издержках
в таком случае мы можем избавить от папки environments
и перенести все настройки в application.rb
самый простой путь для начала перенести все без изменений, обернув в проверки по окружениям
if Rails.env.test?
...
elsif Rails.env.development?
...
end
это все приводит к тому что настройки для разных окружений оказываются в одном файле, но не обеспечивает единообразия
в идеале избавить по максимум от специальных настроек, и проверок по окружениям
но неизбежные отличия, уже будет необходмо вынести в отдельные файлы, снова, но уже будет меньше отличий к этому будет придти сложнее, и можно откладывать, пока не получится использовать один билд в разных окружениях и лишь потом менять конфиги, например при деплое в разные окружения, что сократит время расскатки и упростит правки конфигов при работах
При создании проекта, от функционала надо оставлять даже меньше чем просто MVP, если не получается организовать архитекутуру легко. То есть нормально если первая версия даже будет не релизной, так как надо заложить правильное ядро. Проблема функционала что важное выпадает из фокуса и сложно его организовать.
Есть популярное мнение что комментари писать плохо, код должен быть понятен без комментариев, здесь соглашусь, это в 2 раза лучше но сформулирую так, если заменить комментариии логами, вот тогда код станет 4 раза лучше