Расползание функциональности ( feature creep)

Когда требования изменяются и добавляются по ходу проекта и нет четких спецификаций, описывающих, что должна делать система, велик риск расползания функциональности, т.е. добавления в систему новых возможностей, которые не планировались изначально. Чтобы закончить проект в срок и не сделать его убыточным для разработчиков, нужно применять feature cut, т.е. отменять или откладывать реализацию тех функций, которые оказались заказчику менее важны, чем новые. Важность тех или иных функций, разумеется, должен определять заказчик. Менее важные возможности системы можно затем оформить как отдельные доработки к системе.

Иногда новые функции придумываются разработчиками. К сожалению, не всегда то, что кажется разработчикам красивым и удобным нравится и нужно клиенту. Можно предлагать клиенту варианты, но только за отдельную плату.

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

Другие применения идей гибких методологий

Подход постепенного и естетсвенного развития применим не только в программировании, но и в других сферах жизни. Например, известно что Курчатов при строительстве института, не стал сразу асфальтировать дорожки, а подождал пока сотрудники протопчут трапинки на территории института и только потом положил асфальт по уже готовым маршрутам. В результате и газон цел и ходить удобно.

Многих учили в школе, что перед написанием сочинения нужно составить план, а потом по нему писать текст. Если писать на бумаге, этот подход еще как-то оправдан. Но когда вы пишете на комьютере, лучше просто сесть и начать писать с того места, с которого хочется. После этого перемещать куски, выделять разделы, написать вводную и заключительную часть. Тект получается намного лучше и органичнее. Иногда структура текста видна сразу и можно сразу набрасать основные разделы, но совсем не обязательно заполнять их строго по порядку.

При внедрении каких-то организационных правил в компании или различных практик в своей жизни также лучше начать с простых вещей и вводить их постепенно.

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

 

 

Рефакторинг

Распространенной ошибкой является ситуация, когда уже к написнному программному коду никогда не возвращаются, не читают его и не улучшают. При этом новые части системы подстраиваются под уже написанную часть системы, даже когда проще немного изменить уже существующую часть. Часть системы, написанная с нуля без последующей корректировки, по сути, является черновиком (даже если она не задумывалась таковой), поэтому качество кода в ней, как правило, не так хорошо, как могло бы быть. Многие вещи вообще очень сложно увидеть, пока код не написан.

Качество новой функциональности, которая пристраивается к уже готовой части, зачастую получается даже хуже чем у основной части, по двум причинам. Во-первых, новую функциональность приходится подстраивать под существующую. Во-вторых, видя качество функциональности, с которой приходится работать, программист некачественно делает свою часть системы. Это напоминает образование стихийных помоек, когда один человек бросил бумажку, другой увидел эту бумажку и ему уже намного легче намусорить рядом, поскольку не он все это начал. В результате образуется помойка. То же самое происходит и с программой. Со временем она напоминает кое-как сколоченную конструкцию с кучей подпорок, которая вот-вот развалится и что-то к ней добавлять становится все сложнее и сложнее.

Избежать этих неприятностей, позволяет рефакторинг - пересмотр и совершенствование уже написанного кода. Мартин Фаулер дает следующие определения рефакторинга:

Refactoring (сущ.), рефакторинг: изменение, применяемое ко внутренней структуре программного обеспечения, без изменения его видимого поведения, чтобы сделать это ПО проще для понимания и удешевить дальнейшие изменения.

Refactor (гл.), выполнять рефакторинг: реструктурировать программное обеспечение путем применения набора рефакторингов без изменения видимого поведения ПО.

Рассмотрим основные ситуации, которые требуют улучшения кода: