+1 за Redmine
работал с JIRA/RedMine/Mantis/Trac/«какя-то самописная хреновина»…
JIRA — все вроде круто, но платно.
Mantis — аляповатый, и, вроде, не было интерграции с разными VCS.
Trac — не совсем понятный интерфейс для «нормальных людей», долго настраивать, без плагинов малопригоден, но если есть желание — можно собрать любой космолёт ;) для питонистов — почти без вариантов ;)
Redmine — из каробки имеем почти идеальный багтеркер + wiki + forum + управление проектами + всякие приятные мелочи. интерфейс весьма приятен даже базовый (а шкурку можно менять).
P.S. если вы ухитрялись работать без багтрекера, то либо вы делали не большие/краткосрочные проекты, либо кто-то очень хотел быть незаменимым ;)
«TDD—это вовсе не silver bullet для поиска ошибок» — это 5! :)
как-нибудь полистайте такую книженцию — Фредерик П.Брукс. Мифический человеко-месяц или как создаются программные системы.
там человек лет 20 назад (или уже больше? 8-0 ) в главе 17 приходит к выводу — «Серебряной пули нет» :)))) короче это книга — классика — советую хотя бы полистать… теперь про TDD — это же набор практик — никто не заставляет применять их все (ага мы же помним — серебряной пули нет), но юнит тесты при наличии сложных расчетов необходимы! более того они прекрасно ложатся на логику без гуи… естественно, есть проблемы — где брать контрольные точки по частям алгоритма, необходимость обновлять все это барахло при изменении алгоритма,… сам был в такой ситуации — писал числодробилку, формулы были мабуть попроще, но их несколько раз меняли — уточняли модель…
после каждого такого изменения тихо матерясь лезем, обновляем тесты, меняем логику, но после этого за любой рефакторинг я брался спокойно — тесты не дадут сломать логику (естественно, при соответствующем покрытии)… за примерно 500 часов разработки и 3-4 изменения формул тесты мне стрельнули всего пару раз… но, время, сэкономленное на тестировании после каждой итерации, не сравнить с временем поддержки актуальности тестов — выгода во много раз!
более того, данные для юнит тестов можно готовить автоматически/полуавтоматически. когда мне за месяц 2-ды поменяли формулы и я столько же раз обновил тесты — я тут же задумался над этим ;) вам, похоже, тоже стоит ;)
вы не вчитались в статью ;) я упомянул, что эти фильтры МОЖНО использовать использовать без cxGrid. а фильтры, которые есть в гридах:
во-первых — работаю локально (а не всегда нужно/можно вытянуть все записи)
во-вторых используют те же механизмы (если TcxFilterControl цепляем к гриду) что и сам грид, т.е. его можно использовать для визуализации заданных на самом гриде условий и им же их задавать…
форма рабочего проекта, с которой делались скрины к статье справа содержит таки cxGrid :), фильтры которого продолжают работать для локального поиска, а TcxFilterControl, который на картинке, используется для отбора из базы, т.е. всему свое место — и гридам и фильтрам :)
в принципе, поднят актуальный вопрос ;)
но бывают случаи несколько запущеннее — например, у нас сохранение/загрузка результатов работы программы реализована сериализацией сложного класса с подклассами и вложенностью, скажем, 3-4 уровня… Потом пришло новое ТЗ и после всех доработок и рефракторинга часть свойств сменили тип (некоторые, как в топике — на списки), часть свойств, в том числе, и объектные вообще выкинули, а часть добавили…
И тут сюрприз — надо загружать старые результаты ;) попробовав нечто вроде описанного варианта, выбрал более брутальный ;)
Был сделан парсер dfm формата (сериализация идет в текстовом виде) со всеми возможными преобразованиями в более новый формат. Преобразования идут от самого старого формата к более новому и при очередных изменения требуется только дописать 1-2 метода. В результате, несмотря на неоднократную смену формата сохранения, программа дает открывать пользователям данные даже первой версии с сохранением всего, что можно перенести.
P.S. согласен с r3code — спорный заголовок — «проблема скорее в чтении данных и обеспечении обратной совместимости»
работал с JIRA/RedMine/Mantis/Trac/«какя-то самописная хреновина»…
JIRA — все вроде круто, но платно.
Mantis — аляповатый, и, вроде, не было интерграции с разными VCS.
Trac — не совсем понятный интерфейс для «нормальных людей», долго настраивать, без плагинов малопригоден, но если есть желание — можно собрать любой космолёт ;) для питонистов — почти без вариантов ;)
Redmine — из каробки имеем почти идеальный багтеркер + wiki + forum + управление проектами + всякие приятные мелочи. интерфейс весьма приятен даже базовый (а шкурку можно менять).
P.S. если вы ухитрялись работать без багтрекера, то либо вы делали не большие/краткосрочные проекты, либо кто-то очень хотел быть незаменимым ;)
как-нибудь полистайте такую книженцию — Фредерик П.Брукс. Мифический человеко-месяц или как создаются программные системы.
там человек лет 20 назад (или уже больше? 8-0 ) в главе 17 приходит к выводу — «Серебряной пули нет» :)))) короче это книга — классика — советую хотя бы полистать… теперь про TDD — это же набор практик — никто не заставляет применять их все (ага мы же помним — серебряной пули нет), но юнит тесты при наличии сложных расчетов необходимы! более того они прекрасно ложатся на логику без гуи… естественно, есть проблемы — где брать контрольные точки по частям алгоритма, необходимость обновлять все это барахло при изменении алгоритма,… сам был в такой ситуации — писал числодробилку, формулы были мабуть попроще, но их несколько раз меняли — уточняли модель…
после каждого такого изменения тихо матерясь лезем, обновляем тесты, меняем логику, но после этого за любой рефакторинг я брался спокойно — тесты не дадут сломать логику (естественно, при соответствующем покрытии)… за примерно 500 часов разработки и 3-4 изменения формул тесты мне стрельнули всего пару раз… но, время, сэкономленное на тестировании после каждой итерации, не сравнить с временем поддержки актуальности тестов — выгода во много раз!
более того, данные для юнит тестов можно готовить автоматически/полуавтоматически. когда мне за месяц 2-ды поменяли формулы и я столько же раз обновил тесты — я тут же задумался над этим ;) вам, похоже, тоже стоит ;)
во-первых — работаю локально (а не всегда нужно/можно вытянуть все записи)
во-вторых используют те же механизмы (если TcxFilterControl цепляем к гриду) что и сам грид, т.е. его можно использовать для визуализации заданных на самом гриде условий и им же их задавать…
форма рабочего проекта, с которой делались скрины к статье справа содержит таки cxGrid :), фильтры которого продолжают работать для локального поиска, а TcxFilterControl, который на картинке, используется для отбора из базы, т.е. всему свое место — и гридам и фильтрам :)
но бывают случаи несколько запущеннее — например, у нас сохранение/загрузка результатов работы программы реализована сериализацией сложного класса с подклассами и вложенностью, скажем, 3-4 уровня… Потом пришло новое ТЗ и после всех доработок и рефракторинга часть свойств сменили тип (некоторые, как в топике — на списки), часть свойств, в том числе, и объектные вообще выкинули, а часть добавили…
И тут сюрприз — надо загружать старые результаты ;) попробовав нечто вроде описанного варианта, выбрал более брутальный ;)
Был сделан парсер dfm формата (сериализация идет в текстовом виде) со всеми возможными преобразованиями в более новый формат. Преобразования идут от самого старого формата к более новому и при очередных изменения требуется только дописать 1-2 метода. В результате, несмотря на неоднократную смену формата сохранения, программа дает открывать пользователям данные даже первой версии с сохранением всего, что можно перенести.
P.S. согласен с r3code — спорный заголовок — «проблема скорее в чтении данных и обеспечении обратной совместимости»