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

В таких ситуациях более удачные архитектурные решения могут основываться на метафоре API как естественного языка. API должен предлагать выразительный язык, обеспечивающий вышележащему уровню словарь, которого достаточно, чтобы задавать полезные вопросы и получать на них ответы. Это не значит, что каждому возможному вопросу будет сопоставлен лишь один метод или глагол. Обширный словарь позволяет передавать оттенки смысла. Например, мы предпочитаем говорить run (бежать), а не walk(true) (идти), хотя можно рассматривать эти действия как одну и ту же операцию, выполняемую с разной скоростью. Последовательный и хорошо продуманный словарь API способствует выразительности и прозрачности кода более высокого уровня. А что еще важнее — словарь, допускающий сочетания слов, дает возможность другим программистам использовать API способами, которые вы не предвидели, — и это действительно большое удобство для его пользователей! Когда у вас в очередной раз возникнет соблазн сложить в один метод API сразу несколько операций, вспомните, что слова ПрибериКомнатуНеШумиИСделайДомашнееЗадание нет в словарях, хотя оно пришлось бы весьма кстати для такой популярной операции.

Развертывание приложения: раннее и регулярное Стив Берчук

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

Процедура развертывания или установки — первое, что видит заказчик, и если она проста, это первый шаг к надежной (или хотя бы простой в отладке) производственной среде. Развертываемое программное обеспечение — это то, чем будет пользоваться клиент. Если вы не обеспечите правильное развертывание приложения, у ваших клиентов появятся вопросы еще до того, как они приступят к плотной работе с вашими программами.

Начиная проект с процедуры установки, вы получаете время на ее совершенствование по ходу цикла разработки продукта и возможность вносить изменения в код приложения с целью облегчить его установку. Периодический запуск и тестирование процедуры установки в чистой среде позволит также проверить, не осталось ли в коде зависимостей от среды разработки или тестирования.

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

Может казаться, что «способность развернуть приложение» на ранних стадиях не имеет большой ценности для бизнеса по сравнению с возможностью увидеть, как приложение работает на компьютере разработчика. Однако нужно учесть тот простой факт, что реальную ценность для бизнеса представляет лишь конечный продукт, способный работать в среде клиента. А это в любом случае невозможно на начальном этапе и еще потребует значительной работы. Если вы откладываете создание процедуры развертывания, считая ее тривиальной, следует тем более решить этот вопрос сразу, раз решение настолько дешево. Если же процедура слишком сложная или в ней слишком много неясного, нужно работать с ней так же, как с кодом приложения: экспериментировать, оценивать и переделывать по мере необходимости.

Процедура установки или развертывания критически важна для успешной работы ваших клиентов или вашей сервисной команды, поэтому необходимо постоянно тестировать и совершенствовать ее. Тестирование и совершенствование исходного кода происходят на всем протяжении проекта. Развертывание приложения заслуживает такого же отношения.

Отличайте исключения в бизнес-логике от технических Дэн Берг Джонссон

Есть, в общем-то, две главные причины возникновения ошибок времени выполнения (runtime errors): технические проблемы, препятствующие работе приложения, и бизнес-логика, препятствующая использованию приложения неверным способом. Большинство современных языков, таких как LISP, Java, Smalltalk и C#, сигнализируют о возникновении ситуаций обоих типов при помощи исключений. Но эти две ситуации настолько различны, что их следует тщательно разделять. Представлять их посредством единой иерархии исключений — не говоря уже об одинаковых классах исключений — значит создавать возможность путаницы в будущем.