Как Вы осуществляете рефакторинг класс, который постоянно редактируется?
Сделать это на основе Date, используя разбиение строк для месяца и getFullYear для года:
const [year, month] = [new Date().getFullYear(), new Date().toString().split(" ")[1].toLowerCase()]
const path = `/${year}/${month}.php`;
console.log(path);12 ответов
Необходимо сделать старый вызов метода новым методом. Затем со временем изменяйте ссылки на старый метод для вызова нового метода вместо этого. После того как все клиентские ссылки изменяются, можно удалить старый метод.
Для получения дополнительной информации см. Метод Перемещения в классике Martin Fowler, Осуществив рефакторинг.
Одна вещь, которую можно сделать, состоит в том, чтобы временно оставить методы прокси в классе монстра, который делегирует к новому методу. Приблизительно после одной недели, после того как Вы уверены, весь код использует новый метод, затем можно безопасно удалить прокси.
Я не уверен, какой язык Вы используете, но в .NET можно создать предупреждения компилятора, которые позволят Вам оставлять старые ссылки какое-то время так, чтобы они функционировали как ожидалось, но поместили предупреждение для Ваших других разработчиков видеть.
Я обработал это прежде путем хождения вперед и рефакторинга кода, но затем добавления методов, которые соответствуют старой подписи, которые переводят вызовы к новому методу. Если Вы добавите "Устаревший" атрибут к этим временным методам, то Ваш код все еще создаст и со старыми вызовами метода и с новыми вызовами метода. Затем со временем можно возвратиться через и обновить код, который называет старый метод. Различие здесь - то, что Вы заставите "Предупреждения" во время сборки помогать Вам найти весь код, для которого нужно обновление.
Сохраните старый метод и передайте новому методу (как другие сказали), но также и отправьте сообщение журнала в передающем методе, чтобы напомнить себе удалять его.
Вы могли просто добавить комментарий, но это слишком легко для пропавших без вести.
Разработайте свои изменения в ответвлении. Вспыхните подмножество кода к новому классу, внесите изменения через клиентуру, протестируйте полностью и затем объединитесь назад.
Это концентрирует поломку к тому, когда Вы объединяетесь — не весь цикл разработки.
Объедините это с предложением Patrick, чтобы сделать, чтобы монстр позвонил маленьким монстрам. Это позволит Вам легко вернуться, если Ваш объединенный клиентский код повредит изменения в том клиенте. Как Patrick говорит, Вы сможете удалить методы монстра (теперь тупики), после того как Вы доказываете ничье использование его.
Я также повторяю совет нескольких плакатов выставить вспыхнувшие классы непосредственно — не через монстра. Почему применяют только половину средства исправления? С тем же усилием Вы могли применить полное средство исправления.
Наконец: запишите модульные тесты. Запишите много модульных тестов. О, мальчик, сделайте Вам нужны модульные тесты для безопасного осуществления этого. Я упоминал, что Вам нужны модульные тесты?
Предложите использовать инструмент, такой как nDepend для идентификации всех ссылок на методы класса. Вывод от nDepend может использоваться, чтобы дать Вам лучшее представление о том, как сгруппировать методы.
var monster = new Monster();
var timeToOpen = monster.TimeKeeper.OpeningTime.Subtract(DateTime.Now);
Я не уверен, что divvying это и просто создание частей его публично доступный немного лучше. Это нарушает закон диметра и может привести к боли NullReference.
Я предложил бы подвергнуть хронометриста людям, не вовлекая монстра.
Если что-либо, Вы были бы хорошо от анализа API и наблюдения, что можно сократить и инкапсулировать в монстре. Конечно, давая игрушки монстра для проигрывания с в противоположность тому, чтобы заставлять монстра сделать вся сама работа является хорошим вызовом. Основное усилие определяет потребности монстра игрушек упростить его работу.
Не осуществляйте рефакторинг его.
Запустите и следуйте закону диметра. Создайте второй класс монстра и запуститесь с нуля. Когда второй класс монстра будет закончен и работа, затем замените случаи первого монстра. Выгрузите его. Надо надеяться, они совместно используют интерфейс, или можно заставить это произойти.
И вместо этого: "монстр. TimeKeeper. OpeningTime. Вычтите (DateTime. Теперь)"
Сделайте это: монстр. SubtractOpeningTime (DateTime. Теперь). Не уничтожайте себя с записью через точку (следовательно диметр)
Я посмотрю на первое использование частичного класса для разделения единственного класса монстра по многим файлам, группируя методы в категории.
Необходимо будет остановить любого редактирующего класс монстра, в то время как Вы разделяете в на файлы.
С тех пор Вы, вероятно, получите меньше конфликтов слияния, поскольку будет меньше редактирований в каждый файл. Можно затем изменить каждый метод в классе монстра, (один метод на регистрацию) для вызова новых классов.
Несколько человек предоставили хорошие ответы относительно оркестровки осуществления рефакторинг себя. Это является ключевым. Но Вы также спросили о координировании изменений между несколькими людьми (который я думаю, было затруднение Вашего вопроса). Какое управление исходным кодом Вы используете? Что-либо как CVS, SVN, и т.д. может обработать входящие изменения от нескольких разработчиков сразу. Ключ к тому, чтобы заставлять это пойти гладко - то, что каждый человек должен сделать их фиксации детализированными и атомарными, и каждый разработчик должен часто вытягивать фиксации других людей.
Такой огромный класс является действительно проблемой. Так как это стало настолько большим, и никто не чувствовал себя неловко, должно быть что-то не так с политиками проекта. Я сказал бы, что Вы должны разделить на пар и действительно соединяете программирование. Создайте ответвление для каждой пары программистов. Работа в течение 1-2 дней на рефакторинге. Сравните свои результаты. Это поможет Вам избежать ситуации, когда рефакторинг пошел бы от запуска в неправильное направление и наконец который приведет к потребности перезаписи класса монстра с нуля.