• Следуйте советам книги «The Pragmatic Programmer: From Journeyman to Master»[8] и каждый год изучайте какой-нибудь новый язык. Или хотя бы новую технологию, или инструмент. Такое горизонтальное расширение знаний даст новые идеи для той связки технологий, которую вы используете сейчас.
• Новые знания не обязательно должны ограничиваться технологиями. Глубже изучите свою предметную область; это позволит лучше понимать технические требования и поможет решать бизнес-задачи. Еще один полезный вариант — изучить способы повышения личной продуктивности.
• Снова поступите в университет.
Было бы замечательно, если бы мы могли, как Нео в «Матрице», просто записать необходимую информацию в свой мозг. Но это невозможно, а потому получение знаний требует времени. Необязательно посвящать учению каждую свободную минуту. Отвести для него немного времени, скажем раз в неделю, — уже лучше, чем ничего. Существует жизнь (как минимум должна существовать) и вне работы. Технологии меняются быстро. Не отставайте.
Удобство — не атрибут качестваГрегор Хоп
О важности и сложности проектирования хороших API (интерфейсов прикладного программирования) сказано много. Трудно все сделать правильно с первого раза и еще труднее изменить что-либо в пути; это похоже на воспитание детей. Опытные программисты уже поняли, что хороший API предлагает одинаковый уровень абстракции для всех методов, обладает единообразием и симметрией, а также образует словарь для выразительного языка. Увы, знать принципы — это одно, а следовать им на практике — другое. Вы же знаете, что есть сладкое вредно.
Но перейдем от слов к делу и разберем конкретную «стратегию» проектирования API, которая встречается мне постоянно: проектировать API так, чтобы он был удобным. Как правило, все начинается с одного из следующих «озарений»:
• Почему клиентские классы должны выполнять два вызова, чтобы выполнить одно действие?
• Зачем создавать еще один метод, если он делает почти то же самое, что уже существующий? Добавлю простой switch.
• Слушайте, это элементарно: если строка второго параметра оканчивается на «.txt», метод автоматически понимает, что первый параметр является именем файла, так что не нужно создавать два метода.
Намерения благие, но приведенные решения чреваты снижением читаемости кода, использующего ваш API. Следующий вызов метода
parser.processNodes(text, false);несет смысловую нагрузку только для того, кто знает, как метод реализован, либо прочел документацию. Этот метод создавался скорее для удобства автора, а не пользователя: «Я не хочу заставлять программиста делать два вызова» на практике означало «Мне не хотелось писать два метода». В принципе нет ничего плохого, если удобство используется как средство против монотонности, громоздкости и неуклюжести. Но если вдуматься, противоядием для этих симптомов служат эффективность, элегантность, последовательность — и не обязательно удобство. API предполагают сокрытие внутренней сложности системы, поэтому вполне резонно ожидать, что проектирование хорошего API требует некоторых усилий. Вполне возможно, что удобнее написать один большой метод, а не тщательно продуманный набор операций, но каким из вариантов проще пользоваться?
В таких ситуациях более удачные архитектурные решения могут основываться на метафоре API как естественного языка. API должен предлагать выразительный язык, обеспечивающий вышележащему уровню словарь, которого достаточно, чтобы задавать полезные вопросы и получать на них ответы. Это не значит, что каждому возможному вопросу будет сопоставлен лишь один метод или глагол. Обширный словарь позволяет передавать оттенки смысла. Например, мы предпочитаем говорить run (бежать), а не walk(true) (идти), хотя можно рассматривать эти действия как одну и ту же операцию, выполняемую с разной скоростью. Последовательный и хорошо продуманный словарь API способствует выразительности и прозрачности кода более высокого уровня. А что еще важнее — словарь, допускающий сочетания слов, дает возможность другим программистам использовать API способами, которые вы не предвидели, — и это действительно большое удобство для его пользователей! Когда у вас в очередной раз возникнет соблазн сложить в один метод API сразу несколько операций, вспомните, что слова ПрибериКомнатуНеШумиИСделайДомашнееЗадание нет в словарях, хотя оно пришлось бы весьма кстати для такой популярной операции.
Развертывание приложения: раннее и регулярноеСтив Берчук
Отладку процедуры развертывания (deployment) и установки часто откладывают до этапа завершения проекта. В некоторых проектах создание средств установки возлагается на выпускающего продукт инженера, который воспринимает эту задачу как «неизбежное зло». Промежуточные демонстрации приложения проводятся в специально подготовленной среде, чтобы все работало, как надо. В результате команда не получает опыта работы с процессом и средой развертывания до того момента, когда времени для внесения изменений уже может не остаться.
Процедура развертывания или установки — первое, что видит заказчик, и если она проста, это первый шаг к надежной (или хотя бы простой в отладке) производственной среде. Развертываемое программное обеспечение — это то, чем будет пользоваться клиент. Если вы не обеспечите правильное развертывание приложения, у ваших клиентов появятся вопросы еще до того, как они приступят к плотной работе с вашими программами.
Начиная проект с процедуры установки, вы получаете время на ее совершенствование по ходу цикла разработки продукта и возможность вносить изменения в код приложения с целью облегчить его установку. Периодический запуск и тестирование процедуры установки в чистой среде позволит также проверить, не осталось ли в коде зависимостей от среды разработки или тестирования.
Задвигая развертывание на последнее место, вы можете тем самым усложнить процесс развертывания, ведь вам придется искать обходные маршруты для допущений, сделанных в коде. То, что казалось удачной идеей в IDE, где имеется полный контроль над средой, может значительно усложнить процедуру развертывания. Обо всех компромиссах лучше узнать заранее.
Может казаться, что «способность развернуть приложение» на ранних стадиях не имеет большой ценности для бизнеса по сравнению с возможностью увидеть, как приложение работает на компьютере разработчика. Однако нужно учесть тот простой факт, что реальную ценность для бизнеса представляет лишь конечный продукт, способный работать в среде клиента. А это в любом случае невозможно на начальном этапе и еще потребует значительной работы. Если вы откладываете создание процедуры развертывания, считая ее тривиальной, следует тем более решить этот вопрос сразу, раз решение настолько дешево. Если же процедура слишком сложная или в ней слишком много неясного, нужно работать с ней так же, как с кодом приложения: экспериментировать, оценивать и переделывать по мере необходимости.
Процедура установки или развертывания критически важна для успешной работы ваших клиентов или вашей сервисной команды, поэтому необходимо постоянно тестировать и совершенствовать ее. Тестирование и совершенствование исходного кода происходят на всем протяжении проекта. Развертывание приложения заслуживает такого же отношения.
Отличайте исключения в бизнес-логике от техническихДэн Берг Джонссон
Есть, в общем-то, две главные причины возникновения ошибок времени выполнения (runtime errors): технические проблемы, препятствующие работе приложения, и бизнес-логика, препятствующая использованию приложения неверным способом. Большинство современных языков, таких как LISP, Java, Smalltalk и C#, сигнализируют о возникновении ситуаций обоих типов при помощи исключений. Но эти две ситуации настолько различны, что их следует тщательно разделять. Представлять их посредством единой иерархии исключений — не говоря уже об одинаковых классах исключений — значит создавать возможность путаницы в будущем.
Ошибка программирования может породить неразрешимую техническую проблему. Например, если пытаться получить 83-й элемент массива размером 17 элементов, программа сойдет с рельс и сгенерирует исключение. Более тонкий вариант — вызов кода библиотеки с недопустимыми аргументами, приводящий к тому же результату, но внутри библиотеки.
Было бы ошибкой пытаться на месте разрешать все подобные ситуации, возникшие по нашей вине. Вместо этого мы даем возможность исключениям всплыть на самый верхний уровень архитектуры, где некий общий механизм обработки исключений сделает все возможное, чтобы привести систему в безопасное состояние, например откатит транзакцию, отразит событие в файле журнала и известит администратора, а также вежливо сообщит о произошедшем пользователю.
Вариант этой ситуации встречается при обращении к вашей библиотеке, когда вызывающий нарушил контракт метода, например, передав совершенно неприемлемый аргумент или не настроив должным образом связанный объект. Это ситуация того же типа, что с обращением к 83-му элементу из 17: вызывающий должен был проверить, и это ошибка программиста на стороне клиентского кода. Правильная реакция — генерировать техническое исключение.
Иная, но тоже техническая ситуация возникает, когда программа не может продолжить работу из-за проблем с окружением, например из-за недоступности базы данных. В такой ситуации следует предположить, что инфраструктура сделала все возможное, чтобы решить проблему — попыталась восстановить соединение должное число раз, — и не справилась. Даже если истинная причина в другом, положение для вызывающего кода аналогичное: он мало чем может исправить ситуацию. Поэтому мы сообщаем о ситуации посредством исключения, которое дойдет до универсального механизма обработки исключений.
С другой стороны, случаются ситуации, когда вызов не может быть завершен по логике предметной области. Это исключительная ситуация, иначе говоря, необычная и нежелательная, но в ней нет странности или ошибки программирования (примером может служить попытка снять со счета больше средств, чем на нем находится). Иными словами, такая ситуация является частью контракта, а генерация исключения — это