Исследование, проведенное Гэри Кляйном на материале аварийно-спасательных служб
и армейских подразделений, показало, что при осуществлении любой деятельности люди на
местах должны понимать конечные цели операции, иначе они не в состоянии правильно реа-
гировать на непредвиденные проблемы.
Центральная часть impact map должна отвечать на самый важный вопрос: зачем мы это
делаем? Это цель, которую мы стремимся достичь.
Может показаться, что стремление в самом начале проекта получить ясный ответ на этот
вопрос – всего лишь проявление здравого смысла. Однако мой опыт показывает, что лишь
немногие из разработчиков точно знают, какие бизнес-цели преследует заказчик. Иногда их
описывают в каком-либо формальном документе, но чаще всего бизнес-цели существуют лишь
в головах заинтересованных лиц. Даже в тех редких случаях, когда бизнес-цели доводятся до
разработчиков, они зачастую сформулированы весьма смутно.
Гойко Оджич «Impact Mapping»
Карты эффектов InUse скорее ориентированы на содействие инновационному дизайну продуктов и дизайну пользовательского опыта. Однако наиболее распространенными проблемами в компаниях, с которыми я работаю в качестве консультанта, являются недостатки в применяемых методах разработки, расползание границ проекта, тенденция упускать из вида общую картину, недостаточная ориентация разработчиков на достижение бизнес-целей. Эти организации бесполезно тратят массу времени и усилий на создание не того программного обеспечения, которое им нужно. Impact mapping представляет собой фантастический способ свести эти страдания к минимуму.
Гойко Оджич «Impact Mapping»
Большой комок грязи — это беспорядочно структурированные, растягивающиеся, неряшливы, джунгли спагетти-кода из клейкой ленты и проволки. Такие системы демонстрируют явные признаки нерегулируемого роста и неоднократного целесообразного ремонта. Информация распределяется между удаленными элементами системы беспорядочно, часто до такой степени, что почти вся важная информация становится глобальной или дублируется.
Общая структура системы, возможно, никогда не была четко определена.
Если бы это было так, возможно, оно стерлось до неузнаваемости. Программисты, обладающие хоть каплей архитектурного чутья, избегают этих болот. Только те, кто безразличен к архитектуре и, возможно, довольны инерцией повседневной рутинной работы по заделке дыр в этих разрушающихся плотинах, довольны работой с такими системами.
Брайан Фут и Джозеф Йодер, Большой шар грязи. Четвертая конференция по шаблонам языков программ (PLoP ’97 / EuroPLoP ’97) Монтичелло, Иллинойс, сентябрь 1997 г.
Иногда я сохраняю старый метод, но для обработки в нем привлекается новый метод. Это полезно, если метод объявлен с модификатором видимости public, а изменять интерфейс других классов я не хочу.
Мартин Фаулер
Стоит ли заниматься переименованием? Без сомнения, стоит. Хороший код должен ясно сообщать о том, что он делает, и правильные имена переменных составляют основу понятного кода. Не бойтесь изменять имена, если в результате код становится более ясным. С помощью хороших средств поиска и замены сделать это обычно несложно. Строгий контроль типов и тестирование выявят возможные ошибки.
Запомните:
