Как вы пересматриваете свой код?

Question

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

Answer 1

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

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

В общем, хороший рефакторинг часто означает выброс старого кода.

UPDATE Современные инструменты позволяют легко выполнять множество операций автоматически (например, изменение имен, пакетов). Эксперты рекомендуют, чтобы методы были короткими, поэтому всякий раз, когда вы обнаруживаете, что ваш метод растягивается на две страницы, он превращается в более короткие. Но бывают случаи, когда инструменты не помогают, и вам приходится создавать код, который временно не работает. В этом случае убедитесь, что у вас (а) запущены модульные тесты на рабочей версии (б) зафиксировать его. Легко войти в сложную операцию рефакторинга и понять, что вы сломали ее настолько сильно, что вам нужно вернуться назад. Если у вас есть пользователи, которые зависят от вашего кода, убедитесь, что вы продолжаете предоставлять API, который они знают. Например, предположим, что у вас есть подпрограмма под названием

Date date = getLastUpdate();

и вы решаете (как я и многие другие), что java.util.Date отчаянно сломлен. Вы решаете сменить его на Joda DateTime, но в процессе это будет сложно. Вам, вероятно, нужно выделить время, чтобы завершить его за один проход. Не меняйте API на

DateTime date = getLastUpdate();

Создать новый интерфейс, такой как

DateTime date = getLastDateTimeUpdate();

Затем отметьте оригинал как @Deprecated

Вы не должны удалять более раннюю версию, пока не решите сделать новую версию (динамическое изменение API теряет друзей)

Answer 2

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

Даже если вы неопытны из-за грязных рук, написания и тестирования кода, вы будетепоправляйся.

Answer 3

Я бы сказал, что это здорово, и посчитал бы это хорошей практикой.Рефакторинг имеет решающее значение для хорошей базы кода, если ваши тесты хороши.

В TDD цикл:

• Красный
• Зеленый
• Refactor

Answer 4

Переход по коду - это хорошо ... просто убедитесь, что вы проверите его, если измените его (было бы неплохо настроить автоматические регрессионные тесты).

Также, если вы используете тот же бит кодаво многих местах поместите его в библиотеку классов, чтобы иметь его только в одном месте (и поэтому любые улучшения необходимо выполнять только один раз).

Это нормально?- Да (если это не отнимает слишком много времени у других проектов)

Как часто вы пересматриваете свой код?- Всякий раз, когда я снова работаю с этим кодом и у меня есть время, чтобы посмотреть на него

Пишут ли хорошие программисты один раз и не нужно ничего менять?- Существует более одного способа снятия шкуры с кошки, так что это субъективно.