1. Фирма имеет малый штат. Условно назовём стартапом. Работа с заказчиком происходит практически полностью через менеджера.
Логично. Если с заказчиками будут общаться разработчики... сегодня один, завтра другой... то заказчик сбежит.
Менеджер имеет лишь базовые представления о разработке. Большей частью не более чем знание что такое HTML. Менеджер своими словами описывает функциональность В ОБЩИХ СЛОВАХ, тыча пальцем в экран. Гораздо реже показывает снимки экрана или эскизы.
Должно быть описание продуктов, их функциональных возможностей, дизайна, преимуществ и пр. Менеджеру будет значительно проще работать с заказчиками, отвечать на их вопросы, готовить презентации... Помимо этого неплохо бы собирать отзывы и пожелания от заказчиков, которые уже приобрели продукты фирмы. Эти пожелания должны передаваться руководству фирмы, чтобы планировались изменения с учётом мнения заказчиков.
Функциональность меняется постоянно, буквально изо дня в день (по очередному изъявлению желания заказчика или же менеджеру, которого заказчик убедил в важности некоторых прибамбасов). Поэтому спецификаций НЕТ. Техническую документацию я веду сам для себя. Другим это неинтересно и не нужно. Нет единого стиля программирования. Каждый пишет как ему угодно. Потом довольно тяжело разбирать чужой код.
Довольно типичная ситуация для фирм, которые провели несколько удачных продаж. Если продажи упадут, фирма рассыпется, если вырастут, то... тоже рассыпется... или поумнеет.
Если Вы опишите функциональность продуктов, то можно подумать над тем, почему она меняется так часто... Причина, в принципе понятна, она связана с недостаточной проработанностью исходной модели. Но детали обсудить пока невозможно.
2. Код пишется на Ruby на фреймворке Ruby on Rails.
Что касается View, то это длинная история и её нужно рассказывать частями.
Отражаемый на экране текст в большинстве случаев определяет программист (тексты оповещений, ошибок). Английский является базовым языком интерфейса, но он не является родным для программистов. На основе английского производится перевод с помощью схожего с gettext способа (inline).
Например:
"Dear #{user.name}, you have to select at least one option.".t
Такие строки встречаются и в коде и в вёрстке - всюду. Часто программист исправляет орфографические и синтаксические ошибки как свои, так и чужие. И, при этом, вносит другие. Любое исправление переводимого текста требует обновление базы данных перевода. А поскольку эти изменения часты, то перевод сплошь и рядом отсутствует. Хоть переводом программист не занимается - и то хорошо.
Строки с текстом можно вынести в отдельные файлы, каждому сообщению присвоить идентификатор (константу), который остаётся стабильным независимо от языка общения. Соответственно, переводчики должны поддерживать согласованность всех разноязычных файлов, а программисты пополняют изменяют только файл на своём (русском, например) языке. При этом у каждого разработчика может быть свой вариант файла и свой диапазон идентификаторов.
HTML View (embedded Ruby):
Пример кода я не комментирую.
Пример я привёл с головы, для общего представления. Эти конструкции типичны в нашем коде.
Здесь видно, что несмотря на то, что используется парадигма MVC, код очень быстро засирается сложными конструкциями, состоящими из смеси Ruby/HTML/JavaScript/Ruby Javascript (RJS-Ajax). Вся логика лежит на технологиях нескольких языков и технологий в разных местах.
Для того, чтобы аккуратно разнести это "вавилонское столпотворение", необходимо разобраться с моделью программного обеспечения, эту модель и разделить по интерфейсам в зависимости от возможностей того или иного средства разработки...
4. Хотелось бы, чтоб текстами и вёрстками HTML занимались отдельные редакторы, графики или просто компетентные люди.
Да, это правильное желание. Если оно неосуществимо, то эти функции можно разделить между разработчиками. Так чтобы вопросы дизайна/вёрстки (внешнего представления) решал кто-то один, графику разрабатывал кто-то другой, тексты сочинял третий и т.д. Такое разделение труда иногда кажется избыточным, но ростом объёма работы, оно позволит работать быстрее, а само программное обеспечение выглядит более однородно и эргономично. А главное... каждый специалист подумает над тем, чтобы облегчить свою участь... и, возможно, предложит простые инструменты, способные позволить решать текущие задачи быстрее и в одном стиле. Но если объёмы работ небольшие, то затраты на разработку инструментов не окупятся.
К сожалению, у меня нет влияния на наше руководство, поэтому нет смысла ждать от них чуда. Поэтому нужно придумать способ отделения данных, вёрстки от кода. Желательно, чтобы основной код был сосредоточен в одном месте и мог быть с лёгкостью изменён, повлияв на генерацию остального кода/шаблонов.
Я постоянно нахожусь в процессе поиска приемлемого решения данной проблемы с тем, чтобы его приняли и другие разработчики. То есть оно должно помочь нам снизить трудозатраты при небольших усилиях.
Вы думаете в правильном направлении, но начинать надо с модели...