sergei-grigorev

Сам занимаюсь разработкой под Java EE для крупных корпоративных веб-приложений. Могу сказать, что тут полно всяких требований к самому приложению. его расширению и масштабированию. Т.е. для крупных корпоративных приложений это нормально, ведь к ним предлагаются более высокие требования надежности. Но если идти тем же путем для простых сайтов, то вы в значительной степени увеличите сроки сдачи. Вероятно по этому для простой веб-разработки смысла в Java EE мало (куда быстрее написать на более простом фреймворке), а вот для крупных веб-приложений она в значительной степени более восстребована, чем указанные вами Ruby и Python.

А почему-бы не сделать это в виде системы контроля версий? Например, git, mercurial, svn. Тогда и отслеживать можно будет кто именно обновил файл, и какие изменения сделал (может поменяли чисто заголовок и поэтому можно объединить изменения)

Для сборки под разные платформы или версии можно написать задание для систем сборки (и затем запускать их, к примеру 'Ant was' — сборка под IBM WebSphere, или 'Ant tomcat' — сборка для Apache Tomcat).

Чтобы проверить работу кода под разные платформы, исправление ошибок для разных поддерживаемых версий — пишите unit тесты, которые воспроизводят ошибку в коде, либо интеграционный тест для более сложных ошибок. Соответственно если поправили ошибку только на одну платформу, то автотесты провалятся под другой платформой.
Еще можно ставить хаки на систему контроля версий, которые не будут пропускать коммиты с комментарием # в текущую ветку, пока не будут закрыты ошибки на других сопровождаемых ветках (хотя этот вариант мне не нравится, он использовался в некоторых компаниях, где я работал).

Если брать во внимание, что вам нужно именно в виде отдельных веток управлять отдельными фичами (хотя на мой взгляд, лучше что-то с самим продуктом сделать, быть может разделить его на модули), то в голову пришло вот такое простое решение:
* мигрируете с svn на git (я не знаю, есть ли в svn функция, аналогичная rebase в git)
* в нем делаете отдельные ветки, которые все исходят от master-ветки
* затем при доработке или исправлении бага, после его проверки, вы заносите его в master
* во всех ветках для регионов, использующих эту функциональность, делаете rebase относительно ветки master (в этом случае, она возьмет свежую версию кода из master, и уже поверх них наложит ваши новые. В этом случае, багфикс применится ко всем веткам автоматически благодаря rebas. Если нет накладок в коде, конечно же, а иначе — придется помержить ручками).

Решение абсолютно не идеальное, просто ход мыслей, оформленный в виде ответа (:

за то, что они закрывают глаза, когда я вместо того, чтобы заниматься непосредственно «реализацией новой фичи продукта», занимаюсь рефакторингом, оптимизацией ядра, или автоматизации процесса сборки, деплоя. Я не говорю, что это происходит постоянно, просто иногда это действительно нужно, и менеджер может позволить затратить пару дней на это, не донимая вопросами «К какому сроку будет готова новая фича?».

Не забудьте сделать, как на википедии — кнопчку, вроде «Перейти на обычную версию сайта». Мне порою не нравится, когда меня пересылают на мобильную урезанную версию, когда я могу и полную версию сайта нормально посмотреть прямо на дисплее смартфона.

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

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

Если хранить как поле=значение, то появляется недостаток в обработке вложенных свойств. Например, у приложения есть окна, и в каждом окне может быть применен свой стиль. Естественно, что все, что принадлежит данному окну, группируется «в виде дерева». В данном случае удобен XML. Недостаток такого метода думаю ясен — приходится загружать полностью все поле, а затем его обрабатывать. Но достоинство — все красивенько сгруппировано, не сложно обрабатывать и не сложно отобразить в каком-либо отчете

Идти в ВУЗ нужно, как минимум ради таких предметов, как Теория Вероятности, Моделирование систем и пр. (в-общем математика). Они даже если и не пригодятся (как может показаться поначалу), то помогут развить мышление.