Как справиться с пошаговой рефакторией некоторых интенсивно используемых библиотек?

Question

У меня есть несколько библиотек, нацеленных на несколько платформ, некоторые из которых в реальном времени имеют / не имеют приличную поддержку STL, не говоря уже о tr1 или C ++ 11. Это означает, что все используют собственные классы библиотеки string / array / list / younameit. Теперь от этих платформ отказываются в пользу «чистого» C ++ 11 и STL (за что я очень очень рад: последняя библиотека, которую я сделал, является первой с новым стандартом, и время разработки сильно сократилось, в то время как код качество повысилось).

Теперь я хочу, чтобы новые проекты не зависели от пользовательских классов string / array / ..., и я планирую перейти к пошаговой рефактории: всякий раз, когда мне нужен какой-то класс, создайте дубликат (хорошо не полный дубликат; все же это больно, но есть ли другой вариант?), который использует вместо этого STL. В начале это может означать, что целое дерево классов может нуждаться в изменении сразу. В то же время оригинальный код должен продолжать работать в течение следующих 4 лет или около того.

Практически главный вопрос, с которым я сейчас сталкиваюсь, это: куда я могу поместить эти новые классы? Например

A\A.h depends on B\B.h and string.h

должно стать

a new A.h depending on a new B.h and <string>

Создать новый класс NewA и вставить в A.h? Или создать класс A в новом пространстве имен и сохранить его в A\newA.h? Или я могу создать совершенно новую структуру подкаталогов, такую ​​как new\A\A.h и new\B\b.h?

Я знаю, что уже есть пара похожих вопросов, с отличными ответами, но я хотел бы получить еще один практический совет, а не "читать Эффективная работа с устаревшим кодом". Хотя это, с разумной стороны, хороший ответ, меня больше интересует, что вы практически сделали в подобной ситуации?

изменить некоторые уточнения:

• Большинство текущих приложений также будут портированы для использования STL вовремя, поскольку все они будут работать на новой платформе (все еще сомневаются в RTX или InTime, но в одном из них).
• Я использую VCS, git и почти все, что имеет значение, покрыто юнит-тестами. Иначе это было бы безумием.
• Нет настоящей команды, и я сам по себе (к сожалению, я не могу считать своего коллегу членом команды, когда дело доходит до таких вещей, хотя, будучи почти в два раза старше меня, его уровень программирования меньше половины моего, и Я даже не такой опытный.

Answer 1

Не дублируйте классы. Пусть ваш старый проект запустится, и где-нибудь раскошелиться. Конечно, используйте юнит-тестирование и контроль исходного кода.

Тогда я бы пошел на глубинный подход, понемногу. Изменяйте по одному классу за раз, чтобы адаптировать его к новым стандартам кодирования и устранять все возникающие ошибки компилятора. В частности, это означает, что для интересующего вас класса вы сначала избавляетесь от старого string.h, изменяете интерфейс и реализацию (классы строки / вектора ничем не отличаются друг от друга) и создаете проект. , Пусть ошибки компилятора скажут вам, куда идти дальше.

В зависимости от размера проекта, вы можете начать с наименее или наиболее часто используемого класса. Удаляйте неиспользуемые строковые / векторные классы только после преобразования всех других классов.

Вероятно, это будет довольно простая (хотя и трудоемкая) операция (следовательно, отличающаяся от рефакторинга), и, вероятно, она может быть достаточно хорошо обработана несколькими разработчиками одновременно, если вы используете хорошую систему контроля версий с хорошей поддержкой слияния и юнит-тестирование. Используйте юнит-тестирование и контроль версий. Действительно делать.

Конечно, вы не будете приспосабливать весь свой код к STL и C ++ 0x, и вы должны сначала стремиться к пользовательским классам строк / контейнеров и добавлять умные указатели, где они принадлежат. Вашей среднесрочной целью должно быть удаление всех вхождений delete во всей вашей кодовой базе.