Реальная практика программирования представляет собой отнюдь не решение задач, которые дал вам кто-то другой. Конечно, в учебном классе вы должны были решать задачу двоичной сортировки, полученную от преподавателя. Но в реальном мире лучшие архитекторы заняты не решением сложных задач, а поиском для них обходных путей. Их искусство проявляется в умении проложить границы между разнотипными и расплывчатыми задачами, чтобы сделать их четко определенными и автономными.
Архитектор вникает в мешанину концепций, данных и процессов и разбивает их на меньшие фрагменты. Важнейшим качеством таких фрагментов является четкая определенность задачи, что позволяет решить их законченными и четко определенными фрагментами системы. Основные свойства фрагментов задачи таковы:
• Внутренняя связность: фрагмент является концептуально цельным, то есть все его задачи, данные и функциональные возможности связаны друг с другом.
• Изолированность: фрагменты концептуально нормализованы, то есть практически не перекрываются друг с другом.
Подобно человеку с хорошей ориентацией на местности, который подсознательно знает, где находится в данный момент, человек, в совершенстве владеющий методом фрагментирования задачи, может даже не осознавать, что использует его, — ему просто кажется разумным разбить задачи, данные и функциональные возможности так, чтобы сформировать удобную логическую границу или интерфейс. (Естественно, речь идет не об интерфейсах из объектно-ориентированных языков, а о границах системы.)
Например, реляционная СУБД имеет очень хорошую границу. Она работает практически с любыми данными, которые могут быть преобразованы в поток байтов, обеспечивая структурирование, поиск и выборку этих данных. Все просто.
Здесь интересно то, что решение четко определенной задачи неизменно. Возможно, через пять лет к нему будет приделан веб-интерфейс, а через пятьдесят — телепатический, но ядро системы изменять не понадобится. Система стабильна, потому что четко определена решаемая с ее помощью задача.
Конечно, код сам по себе должен быть простым и понятным, но при решении хорошо формализованной задачи этого проще добиться благодаря отсутствию всевозможных «исключительных случаев». Аккуратный код хорош прежде всего тем, что его проще тестировать и анализировать, а это естественным образом ведет к весьма высокому качеству реализации. Если у вас нет проблем с кодом, вы сможете направить усилия на то, что обычно остается невидимым для пользователя, например на реализацию надежного механизма передачи сообщений, распределенные транзакции или повышение производительности за счет применения многопоточности (и даже низкоуровневых языков, например, ассемблерных вставок). Так как задача остается неизменной, вы можете сосредоточиться на совершенствовании реализации до того уровня, на котором качество станет отличительной чертой вашей системы.
Стабильность задачи позволяет вам создать систему со стабильным дизайном; стабильность дизайна позволяет создавать приложения высочайшего качества.
Биография автора приведена ранее.