Задачи, плохо поддающиеся рефакторингу
Можно ли вносить в систему все проектные решения путем рефакторинга, или же все-таки существуют некоторые вещи, которые настолько всепроникающи, что добавить их впоследствии будет очень и очень сложно? В настоящий момент ортодоксы ХР утверждают, что все можно добавить позже, а именно тогда, когда оно понадобится. Поэтому принцип YAGNI может быть применен в любой ситуации. Я все же, сомневаюсь, нет ли здесь исключений из правила. Возьмем, к примеру, поддержку нескольких языков (локализацию). Может быть, если работать над ней с самого начала, можно избежать мучений по поводу того, как ее внести в систему на более поздних стадиях разработки?
Я могу легко назвать еще несколько вещей, которые попадут в ту же категорию. Однако в действительности у нас еще очень мало информации. Если вам нужно внести в систему что-то новое (например, локализацию), то непосредственно перед добавлением вы сможете адекватно оценить, каких усилий это потребует. Вы не сможете оценить это, если будете вкладывать усилия в локализацию на итерациях, предшествующих той, в которой она понадобится. Вы также не сможете адекватно оценить, какие усилия вам понадобятся, чтобы исправить ошибку, которую вы вполне могли допустить в начале работы (в таком случае, вам опять-таки понадобится рефакторинг).
Принцип YAGNI частично оправдывается тем, что очень многие из таких потенциально необходимых задач, в конце концов, оказываются вовсе не так уж необходимы. По крайней мере, не в том виде, в котором вы ожидали. Вам потребуется гораздо меньше усилий на то, чтобы не выполнять пока такие задачи, чем на исправление ошибочных решений и рефакторинг.
Кроме того, всегда стоит учитывать знание проблемы. Если вам уже приходилось несколько раз заниматься локализацией, то вы наверняка будете применять в работе некие паттерны, а значит, у вас больше шансов сделать все правильно с самого начала. Если вы опытный специалист, то, наверное, будет лучше разработать некие предварительные структуры (чего никак нельзя порекомендовать новичкам).
Я бы сказал, что те, кто знает, как это делается, могут сами судить о затратах, которые нужны для выполнения такой задачи. Однако, если вы никогда раньше не занимались такими проблемами, вы не только не можете верно оценить задачу, но и скорее всего, будете допускать ошибки в ее решении. В таком случае, лучше будет внести нужные дополнения в систему позже. Если же вы так и поступили, а теперь испытываете массу трудностей, то поверьте, вам было бы куда тяжелее, начни вы работать над этой задачей с самого начала. Теперь ваша команда уже более опытна, вы лучше понимаете предметную область и требования к системе. Часто, оглядываясь назад, вам будет казаться, что раньше это было бы сделать намного проще. Смею вас уверить, все могло быть гораздо сложнее, если бы начали работать над этим в начале проекта.
Эта проблема связана с вопросом порядка выполнения требований пользователя (user stories). В книге Planning XP
мы с Кентом ясно обозначили наши разногласия. Кент считает, что единственным фактором, определяющим порядок работ над задачами, должна быть их важность для заказчика. Теперь на такую же точке зрения встал и Рон Джеффриз, который раньше придерживался другого мнения. Я, все же, не могу с ними согласиться. Мне кажется, что должен существовать некий баланс между важностью задачи и техническим риском. Так, если использовать наш пример, то я стал бы заниматься локализацией раньше, чем это потребовалось бы, именно чтобы снизить риск. Впрочем, это было бы оправдано, только если локализация должна была бы присутствовать уже в первом выпуске системы. Выпустить программу как можно раньше - одна из жизненно важных задач. Все, что не нужно в первом выпуске, нужно вносить в систему после него. Впечатление, которое производит на заказчика работающий программный код, просто неописуемо. Первый выпуск программы заставляет его сосредоточиться на проекте, повышает уровень доверия к разработчикам, и кроме того, является мощным источником новых сведений. Делайте все от вас зависящее, чтобы этот день наступил как можно быстрее.Даже если вы знаете, что затратите больше усилий, если внесете новую функциональность позже, все равно лучше будет сделать это после первого выпуска системы.
(Недавно опубликованная статья Джима Шо
(Jim Shore) описывает некоторые ситуации, включая добавление в систему локализации и поддержки транзакций. Оказалось, что описанные здесь потенциальные проблемы вовсе не являются непреодолимым барьером).
