Итак, хотя технологические дебаты «X против Y» бушуют на многих форумах, все это пустая забава. Их основой часто служат отнюдь не принципиальные расхождения в техническом исполнении, а более тонкие отличия, которым пользователи отдают предпочтение при отсутствии «козырной карты» в виде определяющего контекста.
Ваша команда должна освободиться от стремления к идеалу. Начните с анализа контекста и используйте его как отправную точку для поиска самых простых решений.
Биография автора приведена ранее.
Гномы, эльфы, волшебники и королиЭван Кофски
В романе Нила Стивенсона «Cryptonomicon»[28] Рэнди Уотерхауз излагает свою классификацию рас, с которыми ему доводилось встречаться. Гномы — трудяги, корпящие над произведениями искусства во мраке своих пещер. Они повелевают огромными силами, способными перемещать горы и преображать ландшафт, и славятся своим мастерством. Эльфы отличаются изысканностью и высочайшей культурой; они проводят свои дни за созданием новых прекрасных волшебных предметов. Они до такой степени талантливы, что даже не сознают, насколько сверхъестественными представляются эти предметы другим расам. Волшебники наделены огромной силой, но, в отличие от эльфов, много знают о магии, разбираются в ее природе и возможностях и применяют ее максимально действенно и эффектно. Однако существует и четвертый тип, о котором Уотерхауз упоминает кратко, не останавливаясь для подробного описания. Это короли — мудрые правители, которые знают, как управлять всеми прочими.
Архитектор в некотором роде относится к «королевскому роду». Он должен хорошо понимать все остальные «расы» и позаботиться о том, чтобы в архитектуре для всех них были выделены подходящие роли. Архитектура, спроектированная с учетом только одной «расы», привлечет к проекту представителей именно этой «расы». И даже если в составе команды будут самые умелые «гномы», или самые талантливые «эльфы», или самые могущественные «волшебники», однобокий подход к решению задач будет серьезно ограничивать возможности команды.
Хороший король ведет все «расы» подданных к великой цели и помогает им трудиться бок о бок, чтобы достичь ее. Без великой цели у команды не будет видения, а ее работа в конечном итоге превратится в партизанские вылазки. Без представителей всех «рас» команда сможет решать проблемы только одного типа и остановится у первой же преграды, не соответствующей этому решению.
Архитектор указывает цель, принимая в расчет особенности всех «рас». Тогда архитектура становится руководством по поиску таких задач, которыми смогут заниматься члены команды из разных «рас», пока будут больше узнавать друг о друге. Когда проект столкнется со сложностями, команда уже будет знать, как подходить к их преодолению, потому что архитектура дала команде возможность стать одним целым.
Эван Кофски (Evan Cofsky) — программист, музыкант-любитель и заядлый мотоциклист. Он увлекся музыкой и компьютерами в колледже и продолжает увлеченно заниматься ими до сих пор. В настоящее время является штатным экспертом по языку Python в компании Virgin Charter, где в должности ведущего разработчика возглавляет команду исключительно талантливых и разносторонних людей.
Учитесь у архитекторов зданийКейт Брайтуэйт
Архитектура — социальный акт и материальный театр человеческой активности.
Сколько найдется архитекторов программного обеспечения, считающих свою роль исключительно (или в первую очередь) технической? Разве не должны они в действительности быть посредниками и арбитрами для воюющих фракций среди заинтересованных в проекте сторон? Сколькие из них рассматривают свою работу с чисто интеллектуальной точки зрения, не уделяя должного внимания человеческому фактору?
Архитектор становится великим благодаря не столько уму, сколько чистому, чуткому сердцу.
Что в большей степени присуще архитекторам вашей организации: необузданная интеллектуальная мощь и способность помнить мельчайшие технические детали или хороший вкус, изысканность и душевная щедрость? В какой атмосфере предпочли бы работать вы сами?
Врач может похоронить свою ошибку, архитектор — разве что обсадить стены плющом.
Не является ли «сопровождение унаследованных систем» лишь подрезкой этого плюща? Хватит ли вам как архитектору силы духа уничтожить собственное неудачное творение? Или вы предпочтете просто прикрыть его? Райт сказал также, что лучшим другом архитектора является кувалда. А что вы разбили ею за последнее время?
Архитекторы не только верят, что сидят по правую руку от Бога, но и считают, что если Бог встанет, то они займут его место.
Замените «Бог» на «заказчик».
В архитектуре, как и во всех остальных прикладных видах искусства, конечная цель управляет действием. Конечная цель — хорошо построенное здание. Такое здание обладает тремя свойствами: Удобство, Прочность и Эстетичность.
Когда вам в последний раз попадался на глаза программный продукт, архитектура которого доставила вам эстетическое удовольствие? А вы сами стремитесь к тому, чтобы ваши работы были эстетичными?
Человек, не являющийся великим скульптором или художником, не может быть архитектором. Если он не скульптор, не художник, то сможет быть только строителем.
Занимает ли эстетика достойное место в вашей архитектуре? Движет ли вами в ходе объединения компонентов при построении систем художественный интерес к формам и текстурам, скульптурное чувство баланса и стремление к передаче движения либо ощущение важности отрицательного пространства?
И наконец, высказывание, не требующее комментариев, — верное средство от самого разрушительного синдрома в работе архитектора:
Это выглядит фантастическим парадоксом, но тем не менее является важнейшей истиной: абсолютно совершенная архитектура не может быть действительно великой.
Биография автора приведена ранее.
Боритесь с повторениямиНиклас Нильссон
Приходится ли вашим разработчикам выполнять однообразные задания, над которыми почти не нужно думать? Попадаются ли в коде почти одинаковые фрагменты? Замечаете ли вы код, написанный методом «скопировать-вставить-изменить»? Если ответы положительные, то ваша команда работает медленнее, чем могла бы, и, как ни странно, причиной тому можете быть именно вы.
Прежде чем пускаться в объяснения, давайте договоримся о двух истинах, касающихся разработки программного обеспечения:
• Дублирование — это зло.
• Повторяющаяся работа замедляет разработку.
Вы как архитектор задаете тон. Вы лучше всех представляете себе систему в целом, и, скорее всего, именно вы задали направление работы, создав полный вертикальный срез системы — пример, который к настоящему моменту был неоднократно скопирован. Каждая операция копирования (копирует ли разработчик несколько строк кода, XML-файл или класс) свидетельствует о том, что в системе что-то можно упростить или выкинуть. Чаще всего копируется не логика предметной области, а инфраструктурный код, обеспечивающий ее работу. По этой причине очень важно, чтобы вы четко представляли себе возможный эффект от своих примеров. Любые фрагменты кода, любые примеры конфигурации в ваших примерах станут основой для десятков, сотен и тысяч других частей системы. Следовательно, вы обязаны следить за тем, чтобы ваш код был понятным, хорошо передавал ваши намерения и не содержал ничего, кроме самого существенного — логики предметной области. Как архитектор вы должны быть крайне чувствительны к любым повторам, потому что все, что вы пишете, будет повторено.
В вашей системе такого не происходит, правда? А теперь взгляните на этот конфигурационный файл: что потребует изменения, если применить его к другой части системы, а что останется прежним? Или возьмите типичный метод уровня бизнес-логики: нет ли в нем шаблона, который проявляется и в других методах с такими операциями, как обработка транзакций, легирование, аутентификация или аудит? А как насчет уровня доступа к данным? Часто ли встречаются одинаковые фрагменты, отличающиеся только именами сущностей и полей? Смотрите на вещи шире. Попадаются ли вам две-три строки кода, которые всегда идут рядом и воспринимаются как одно целое, хотя и работают с разными объектами? Все это примеры повторения. Со временем разработчики учатся отсеивать и игнорировать повторения при чтении кода, обращая внимание лишь на интересные отличия. Но даже при наличии такого навыка чтение кода тормозится. Такой код подходит для выполнения компьютером, но не для чтения разработчиками.
Ваша прямая обязанность — избавиться от повторений. Возможно, для этого вам придется освоить новую инфраструктуру, создать более совершенные абстракции, обратиться к специалистам для создания аспектной инфраструктуры или написать несколько небольших генераторов кода. И все же повторения никуда не исчезнут, пока кто-то специально не позаботится об этом.
И этот кто-то — вы.
Биография автора приведена ранее.
Добро пожаловать в реальный мирГрегор Хоп
Технари любят точность — особенно программисты, живущие в мире нулей и единиц. Они привыкли работать с двоичными решениями: один/ноль, истина/ложь, да/нет. Всё четко и последовательно, от неожиданностей защищают ограничения внешних ключей, атомарные транзакции и контрольные суммы.