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