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

позволить себе выделить на это время или средства. Самое надежное — самому позаботиться о своем образовании.

Вот перечень способов продолжать учиться. Многое из перечисленного можно бесплатно получить в Интернете:

• Читайте книги, журналы, блоги, ленты Twitter и веб-сайты. Если вы хотите глубже освоить какой-то предмет, можно зарегистрироваться в списке рассылки или группе новостей.

• Если вы хотите по-настоящему изучить новую технологию, необходима практика: напишите немного кода.

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

• Используйте виртуальных наставников. Ищите в Интернете авторов или разработчиков, которые действительно вам интересны, и читайте все, что они пишут. Подпишитесь на их блоги.

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

• Сделав ошибку, разобравшись с дефектом или столкнувшись с проблемой, постарайтесь до конца разобраться в происшедшем. Вполне возможно, что кто-то уже сталкивался с такой проблемой и описал ее в Сети. Google вам в помощь.

• Хороший способ изучить какой-либо предмет — это учить ему других или рассказывать о нем. Если вам предстоит выступать перед другими людьми и отвечать на их вопросы, это даст вам серьезную мотивацию изучить предмет. Попробуйте организовать небольшой семинар для коллег за обедом либо выступить перед специализированной группой пользователей (user group) или на местной конференции.

• Запишитесь в группу изучения какой-либо технологии (типа сообщества для обсуждения вопросов применения паттернов проектирования — patterns community) или сами организуйте такую группу. Это может быть группа изучения языка, технологии или предмета, который вас интересует.

• Участвуйте в конференциях. Если нет возможности поехать на конференцию, в Интернете можно найти бесплатные видеозаписи выступлений, которые публикуют организаторы многих конференций.

• Долго ехать на работу? Слушайте подкасты.

• Вы пользуетесь средствами статистического анализа кода? Читаете предупреждения, выдаваемые вашей IDE? Разберитесь в сообщениях этих программ и причинах их появления.

• Следуйте советам книги «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) и установки часто откладывают до этапа завершения проекта. В некоторых проектах создание средств установки возлагается на выпускающего продукт инженера, который воспринимает эту задачу как