| Рефакторинг, первый пример | Страница 6 |
Несмотря на это, программа работает. Может, это чисто эстетическое суждение или неприязнь к корявому коду? Только до тех пор, пока нам не понадобится внести изменения в систему. Компилятору всё равно, ужасный здесь код, или нет. Но когда приходится вносить изменения, то работает человек, и ему это уже не безразлично. Плохо спроектированную систему трудно модифицировать. Трудно, хотя бы потому, что сложно понять, где нужно вносить изменения. И если трудно определить, что именно надо менять, то возникает большая вероятность, что разработчик ошибётся.
В нашем случае пользователи хотели бы видеть кое-какие изменения. Во-первых, им нужны отчеты в формате HTML, готовые для публикации на WWW и должным образом украшенные. К чему же приведут эти изменения? Взглянув на исходный код, Вы обнаружите, что части существующего метода statement не удастся повторно использовать для печати отчета в HTML. Придётся написать полностью новый метод, дублирующий большую часть метода statement. Разумеется, в данном случае это не очень обременительно. Можно просто скопировать старый метод и поменять всё, что требуется.
Но что, если после этого изменятся правила расчёта задолженности? Вам потребуется внести изменения в оба метода, statement и htmlStatement, а после этого приверить и убедиться, что изменения соответствуют друг другу. Проблема с дублированием кода приходит тогда, когда возникает необходимость этот код поменять. Конечно, если Вы пишете программу, котрую не планируете менять в дальнейшем, то подобное копирование подходит замечательно. Но если программа будет жить долго и, вероятно, будет изменяться, то этот подход опасен.
Помимо отчётов, пользователи хотят измененить классификацию фильмов, но пока ещё не решили, как именно. Это повлияет как на расчёт задолженности, так и на расчёт бонуса. Будучи опытным разработчиком, Вы можете быть уверены, что вне зависимости от того, что они поменяют, через полгода им понадобится опять внести изменения в класификацию.
В методе statement задолженность расчитывается согласно правилам и классификации фильмов. Однако, если мы скопировали этот метод в htmlStatement, мы должны убедиьтся, что все изменения полностью совпадают. Более того, с усложнением правил становится сложнее определить, где вносить изменения, и сложнее избежать ошибок при внесении этих изменений.
Возможно, Вы соблазнитесь внести несколько изменений в программу; после этого она даже будет работать. Помните старую поговорку: "если не сломано, то не стоит чинить". Программа может быть и исправной, но причинять неприятности. Она сделает вашу жизнь более трудной, потому что Вам будет тяжело вносить изменения, нужные пользователям. Вот тут и приходит время для рефакторинга.
Когда обнаруживается, что в программу нужно добавить некую функциональность, но её код не структурирован удобным образом для добавления этой функциональности, то сначала стоит произвести рефакторинг программы, чтобы упростить внесение изменений, и только после этого вносить эти изменения.
Оглавление | << страница 1 | страница 7 >>