ОК, я был слишком краток ссылаясь на Википедию. На самом деле там есть ссылки на статьи которые объясняют почему это считается антипеттерном. К слову, я специально написал «считается» вместо «является».
Во времена написания «GoF» синглтон был актуальным шаблоном. В настоящее время подходы к разработке изменились. Модульные тесты являются практически стандартной инженерной практикой. При написании тестов Синглтоны оказываются проблемой. Заменить mock'ом без модификации его практически не возможно.
Вторая неприятность с Синглтоном — он делает зависимости неочевидными. Глядя на интерфейс класса, невозможно узнать увидеть все его зависимости. Для этого нужно смотреть реализацию медодов.
Проблема, которую он решает Синглтон — это убедиться, что в системе существует один, и только один экземпляр ресурса. В подовляющем большинстве случаев эту проблему можно решить другим способом — используя Dependency Injection.
Синглтон имеет право на существование, и нужно занать как его правильно реализовать. Но каждый раз, когда вы собираетесь его использовать, вы должны доказать себе и тому, кто будет мейнтейнить Ваш код, что в этой ситуации Синглтон действительно необходим.
For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use.
Согласен с Вами, он автоматизирует простую вещь. Все это можно делать руками.
Все что он делает — это задает общие правила для команды:
— работаем в develop,
— морозим фичи в release
— при релизе мержим в production, ставим тег
— после релиза все изменения из релизной ветки мержим обратно в develop
— бранчи с фичами делаем только от develop
— бранчи с хотфиксами делаем только от продакшн кода
— называем бранчи единообразно, чтобы было понятно другим
Это вполне логичные правила, которые используются большинством команд.
Они позволяют навести порядок и избежать ошибок типа:
— в продакшене баг пофикили, забыли смержить назад в рабочую ветку
— перед релизом все протестировали, а при релизе в продакшн попал лишний коммит, который все поломал
Я использую git-flow довольно продолжительное время и искренне не понимаю откуда у большинства комментаторов сложилось мнение, что git-flow — это сложно. Создается впечатление, что никто статью не прочитал.
В git-flow ВСЕГО команды:
git flow <тип бранча> start <название бранча>
git flow <тип бранча> finish <название бранча>
С помощью всего двух этих команд гит флоу автоматически:
— создает префиксы для бранчей
— мержит бранчи в зависимости от типа
— ставит теги на релиз
Если внимательно перечитать статью, то станет очевидно что:
1. Гит-флоу спрашивает вас какую ветку использовать для production. Ссать против ветра нет необходимости
2. Гит-флоу не использует rebase.
3. Не смотря на то, что картинка выглядит сложно, сама схема проста и близка к той, что Вы используете:
— используются 2 постоянные ветки — develop и production.
— Периодически (перед релизом) создается дополнительная релизная ветка, в которой заморожен код
— после релиза ветка мержится в продакшн и назад в девелоп
Все что делает гит-флоу — это автоматизирует рутинные операции по управлению этими 3 бранчами и сводит к минимуму ошибки
Большинство корпоративных приложений в мире пишутся на Java. Десктоптные в том числе. Скорее всего Вы их не видите потому, что они тоже в корпоративном секторе.
Первое, что пришло на ум из десктопных приложений — Eclipse, IntellyJ IDEA, NetBeans, Lotus Notes
Хабр ценен не только статьями, но и комментариями к ним.
Про грамматику пишите автору в личку.
Когда он исправит ошибки, Ваши комментарии потеряют ценность для будущих читателей.
Еще одна жертва:
Уважаемые пользователи системы! Информируем Вас, что с 1 ноября 2008 года на неопределённый срок будет приостановлено выполнение всех платёжных требований пользователей системы. Приносим наши извинения за предоставленные неудобства. С уваженим администрация Ukrmoney
Во времена написания «GoF» синглтон был актуальным шаблоном. В настоящее время подходы к разработке изменились. Модульные тесты являются практически стандартной инженерной практикой. При написании тестов Синглтоны оказываются проблемой. Заменить mock'ом без модификации его практически не возможно.
Вторая неприятность с Синглтоном — он делает зависимости неочевидными. Глядя на интерфейс класса, невозможно узнать увидеть все его зависимости. Для этого нужно смотреть реализацию медодов.
Проблема, которую он решает Синглтон — это убедиться, что в системе существует один, и только один экземпляр ресурса. В подовляющем большинстве случаев эту проблему можно решить другим способом — используя Dependency Injection.
Синглтон имеет право на существование, и нужно занать как его правильно реализовать. Но каждый раз, когда вы собираетесь его использовать, вы должны доказать себе и тому, кто будет мейнтейнить Ваш код, что в этой ситуации Синглтон действительно необходим.
Получается что разработчки ГитХаба не делают релизы. Многим проектам их модель не подходит.
Все что он делает — это задает общие правила для команды:
— работаем в develop,
— морозим фичи в release
— при релизе мержим в production, ставим тег
— после релиза все изменения из релизной ветки мержим обратно в develop
— бранчи с фичами делаем только от develop
— бранчи с хотфиксами делаем только от продакшн кода
— называем бранчи единообразно, чтобы было понятно другим
Это вполне логичные правила, которые используются большинством команд.
Они позволяют навести порядок и избежать ошибок типа:
— в продакшене баг пофикили, забыли смержить назад в рабочую ветку
— перед релизом все протестировали, а при релизе в продакшн попал лишний коммит, который все поломал
Единственное отличие — хот фикс бранч, который по сути является релизным бранчем, только создается от продакшн ветки
В git-flow ВСЕГО команды:
git flow <тип бранча> start <название бранча>
git flow <тип бранча> finish <название бранча>
С помощью всего двух этих команд гит флоу автоматически:
— создает префиксы для бранчей
— мержит бранчи в зависимости от типа
— ставит теги на релиз
На мой взгляд ничего сложно в этом нет
1. Гит-флоу спрашивает вас какую ветку использовать для production. Ссать против ветра нет необходимости
2. Гит-флоу не использует rebase.
3. Не смотря на то, что картинка выглядит сложно, сама схема проста и близка к той, что Вы используете:
— используются 2 постоянные ветки — develop и production.
— Периодически (перед релизом) создается дополнительная релизная ветка, в которой заморожен код
— после релиза ветка мержится в продакшн и назад в девелоп
Все что делает гит-флоу — это автоматизирует рутинные операции по управлению этими 3 бранчами и сводит к минимуму ошибки
usr, etc, mnt, proc?
Первое, что пришло на ум из десктопных приложений — Eclipse, IntellyJ IDEA, NetBeans, Lotus Notes
Влюбом случае Вы правы — JEE перевешивает десктоп
Про грамматику пишите автору в личку.
Когда он исправит ошибки, Ваши комментарии потеряют ценность для будущих читателей.
Уважаемые пользователи системы! Информируем Вас, что с 1 ноября 2008 года на неопределённый срок будет приостановлено выполнение всех платёжных требований пользователей системы. Приносим наши извинения за предоставленные неудобства. С уваженим администрация Ukrmoney
http://trac.edgewall.org/
http://cruisecontrol.sourceforge.net/
Trac = SVN + wiki + Bag tracker
СruiseСontrol - для сборки, запуска тестов и пр.