== Изменения кода проекта
Если копнуть глубже, то существуют всего 4 причины для изменения кода в проекте:
. Добавить новую link:https://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D1%87%D0%B0[фичу] . link:https://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B3[Зафиксить баг] . Улучшить дизайн . Оптимизировать что-то
=== Добавление фичи и устранение бага Добавление новой фичи кажется самым простым изменением, которое мы можем сделать. Допустим программа ведет себя одним образом, а пользователи говорят, что должна вести себя по другому.
Давайте, предположим, что мы работаем над веб-приложением, и менеджер говорит нам, что он хочет сдвинуть логотип сайта с лево на право. Обсудив это с ним, мы понимаем, что на самом деле это не так просто. Хотя менеджер просит передвинуть только логотип, на самом деле он хочет еще некоторых изменений. Может быть он захочет добавить анимации в следующем релизе? Нужно понять - это фиксинг бага или добавление новой фичи? Это зависит от вашей позиции…
С точки зрения заказчика - он абсолютно определенно просит вас решить конкретную проблему. Может быть менеджер посмотрел на сайт и собрал митинг с людьми из своего отдела, и они решили изменить положение логотипа, поэтому и запросили данную фичу.
С точки зрения разработчика, изменение вполне может выглядеть, как новая фича. В некоторых компаниях сдвиг логотипа рассматривают как баг фикс, несмотря на тот факт, что команда собирается делать достаточно много новой работы. На самом деле все это очень субъективно. Кто-то видит это как багфикс, кто-то как фичу.
Грустно, то что во многих компаниях багфиксы и фичи учитываются отдельно из-за требований всяческих отделов качества и тестирования. На человеческом уровне можно до бесконечности спорить является ли добавляемое изменение фичей или багофиксом, но это в конечном итоге это всего лишь изменение кода и исходников. Технически, для нас важно изменение поведения: большая разница между добавлением нового поведения и изменения старого.
Поведение - это одно из главных понятий в разработке программного обеспечения. Это то, от чего зависят пользователи программы. Пользователи любят, когда мы добавляем новое поведение(если они его очень хотели), но если мы убираем или изменяем поведение программы(пытаясь починить какие-то баги), то пользователи перестают верить нам.
В нашем примере про логотип, давайте попробуем понять - мы добавляем новое поведение? Да, после нашего изменения система будет отображать логотип с другой стороны страницы. Избавляемся ли мы от какого либо поведения? Да, мы не хотим, чтобы логотип был слева. Давайте копнем немного глубже. Предположим,что заказчик хочет добавить логотип в правую часть страницы, но слева еще нет логотипа. Да, мы собираемся добавить новое поведение, но заменяем ли мы какое-то старое? Так что мы изменяем, добавляем или оба действия сразу?
Получается, что нужно четко определить различие между этими действиями - это полезно для разработчика. Если мы должны изменить код, мы можем изменить поведение. Если мы только добавляем код и вызываем его откуда-то, мы всегда добавляем новое поведение. Давайте взглянем на другой пример: [source,java]
public class CDPlayer { public void addTrackListing(Track track) { … } … }
Добавим новый метод: [source,java]
public class CDPlayer { public void addTrackListing(Track track) { … } public void replaceTrackListing(String name, Track track) { … } … }
Когда мы добавили новый метод, добавили ли мы новое поведение или изменили старое? Ответ: нет. Добавление нового метода не меняет поведение пока этот новый метод где-то не вызван. Давайте сделаем другое изменение. Добавим новую кнопку в интерфейс CD плеера. Кнопка дает пользователям возможность заменить играющий трек. Тем самым мы добавили новое поведение, которое содержится в методе replaceTrackListing(), но также мы очень тонко изменили поведение. Пользовательский интерфейс отобразится совершенно по другому при нажатию на кнопку. Возможно, UI будет отображаться на микросекунду дольше. Кажется невозможным добавить новое поведение без изменения его в какой-то степени.