97 этюдов для архитекторов программных систем

Боритесь с повторениями Никлас Нильссон

Приходится ли вашим разработчикам выполнять однообразные задания, над которыми почти не нужно думать? Попадаются ли в коде почти одинаковые фрагменты? Замечаете ли вы код, написанный методом «скопировать-вставить-изменить»? Если ответы положительные, то ваша команда работает медленнее, чем могла бы, и, как ни странно, причиной тому можете быть именно вы.

Прежде чем пускаться в объяснения, давайте договоримся о двух истинах, касающихся разработки программного обеспечения:

• Дублирование — это зло.

• Повторяющаяся работа замедляет разработку.

Вы как архитектор задаете тон. Вы лучше всех представляете себе систему в целом, и, скорее всего, именно вы задали направление работы, создав полный вертикальный срез системы — пример, который к настоящему моменту был неоднократно скопирован. Каждая операция копирования (копирует ли разработчик несколько строк кода, XML-файл или класс) свидетельствует о том, что в системе что-то можно упростить или выкинуть. Чаще всего копируется не логика предметной области, а инфраструктурный код, обеспечивающий ее работу. По этой причине очень важно, чтобы вы четко представляли себе возможный эффект от своих примеров. Любые фрагменты кода, любые примеры конфигурации в ваших примерах станут основой для десятков, сотен и тысяч других частей системы. Следовательно, вы обязаны следить за тем, чтобы ваш код был понятным, хорошо передавал ваши намерения и не содержал ничего, кроме самого существенного — логики предметной области. Как архитектор вы должны быть крайне чувствительны к любым повторам, потому что все, что вы пишете, будет повторено.

В вашей системе такого не происходит, правда? А теперь взгляните на этот конфигурационный файл: что потребует изменения, если применить его к другой части системы, а что останется прежним? Или возьмите типичный метод уровня бизнес-логики: нет ли в нем шаблона, который проявляется и в других методах с такими операциями, как обработка транзакций, легирование, аутентификация или аудит? А как насчет уровня доступа к данным? Часто ли встречаются одинаковые фрагменты, отличающиеся только именами сущностей и полей? Смотрите на вещи шире. Попадаются ли вам две-три строки кода, которые всегда идут рядом и воспринимаются как одно целое, хотя и работают с разными объектами? Все это примеры повторения. Со временем разработчики учатся отсеивать и игнорировать повторения при чтении кода, обращая внимание лишь на интересные отличия. Но даже при наличии такого навыка чтение кода тормозится. Такой код подходит для выполнения компьютером, но не для чтения разработчиками.

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

И этот кто-то — вы.

Биография автора приведена ранее.

Добро пожаловать в реальный мир Грегор Хоп

Технари любят точность — особенно программисты, живущие в мире нулей и единиц. Они привыкли работать с двоичными решениями: один/ноль, истина/ложь, да/нет. Всё четко и последовательно, от неожиданностей защищают ограничения внешних ключей, атомарные транзакции и контрольные суммы.

К сожалению, реальный мир не столь упорядочен. Клиенты оформляют заказы, а через секунду отменяют их. Чеки отклоняются, письма теряются, платежи задерживаются, а обещания нарушаются. Ошибки ввода данных происходят чаще, чем нам хотелось бы. Пользователи предпочитают «плоские» («shallow») интерфейсы, которые предоставляют одновременный доступ ко многим функциям, а не длинный и узкий коридор «процесса» ввода данных, который проще реализуется и кажется многим разработчикам более «логичным». Ходом выполнения программы управляет уже не стек вызовов, а пользователь.

Распределенные системы только усугубляют положение, потому что в игру вступает уйма новых несогласованностей. Службы бывают недоступны, изменяются без предварительного уведомления и не предоставляют транзакционных гарантий. При выполнении приложения на тысячах компьютеров вопрос уже не в том, произойдет ли сбой, а в том, когда он произойдет. Такие системы обладают слабой связанностью (loosely coupled), асинхронностью и параллелизмом и не соответствуют традиционной транзакционной семантике… Не желаете принять синюю таблетку?!

Дивный новый мир компьютерных технологий трещит по швам — так что же нам делать? Как это часто бывает, осознание проблемы становится первым важным шагом к ее решению.