как слабая связанность (coupling) и сильная связность (cohesion).
• Прогон модульных тестов демонстрирует, как ведет себя код. Он позволяет обнаружить присутствие (или отсутствие) характеристик времени выполнения, желательных для приложения, например устойчивости и корректности.
• С помощью доски и карточек можно сделать прогресс наглядным и конкретным. Можно увидеть, что задачи находятся в состоянии Не начата, В процессе и Завершена, и при этом не придется заходить в неочевидную систему управления проектом и не придется упрашивать программистов составлять фиктивные отчеты о состоянии проекта.
• Итеративная разработка повышает наглядность прогресса (или его отсутствия), поскольку чаще фиксируются факты того, что разработка ведется. Создание программного обеспечения, готового к выпуску, отражает реальное положение вещей, в отличие от оценок.
Лучше всего разрабатывать программы, имея многочисленные наглядные показатели. Наглядность дает уверенность в том, что прогресс является реальным, а не вымышленным; спланированным, а не непреднамеренным; воспроизводимым, а не случайным.
Передача сообщений улучшает масштабируемость параллельных системРассел Уиндер
Уже на первых лекциях по информатике программистов учат, что конкурентные вычисления — и в особенности параллельные как особый подвид конкурентных — вещь трудная, и что лишь лучшим дается надежда справиться с этой задачей, и что даже лучшие не справляются. При этом неизменно уделяется большое внимание потокам, семафорам, мониторам и трудностям организации потоковой безопасности при одновременном доступе к переменным.
Сложных проблем здесь действительно много, и решать их бывает очень трудно. Но в чем корень проблем? Общая память. Практически все проблемы конкурентных вычислений, о которых постоянно приходится слышать, касаются общей памяти с изменяемыми данными: состояние гонки (race conditions), взаимная блокировка (deadlock), активная блокировка (livelock) и т. п. Кажется, ответ очевиден: забудьте о конкурентности либо держитесь подальше от общей памяти!
Отказ от конкурентности почти наверняка не вариант. Количество ядер в компьютерах возрастает чуть ли не каждый квартал, поэтому достижение настоящего параллелизма становится все важнее. Мы не можем больше полагаться на непрерывный рост тактовой частоты процессоров как основу производительности приложений. Производительность может вырасти только за счет параллелизма. Конечно, можно не заботиться о производительности приложений, но едва ли это понравится пользователям.
Так можно ли отказаться от общей памяти? Определенно, да.
Вместо потоков и общей памяти можно воспользоваться процессами и передачей сообщений. Под процессом здесь понимается защищенное независимое состояние исполняющегося кода, а не обязательно процесс операционной системы. Такие языки, как Erlang (а до него occam), показали, что процессы — весьма удачный механизм программирования конкурентных и параллельных систем. В таких системах меньше проблем синхронизации, чем в многопоточных системах с общей памятью. Кроме того, существует формальная модель взаимодействующих последовательных процессов (Communicating Sequential Processes, CSP), которую можно применять при разработке таких систем.
Можно пойти дальше и организовать вычисления в виде системы, управляемой потоком данных (dataflow system). В такой системе нет явно запрограммированного потока управления. Вместо этого создается направленный граф операторов, соединенных путями передачи данных, а затем в систему подаются данные. Контроль вычислений осуществляется по готовности данных внутри системы. И никаких проблем синхронизации.
При этом для системной разработки применяются главным образом такие языки, как C, C++, Java, Python и Groovy, о которых программистам говорят, что они служат для разработки многопоточных систем с общей памятью. Как же быть? Решение в том, чтобы использовать — или создавать, если их не существует, — библиотеки и среды, которые предлагают схемы процессов и пересылки сообщений, полностью исключающие применение общей изменяемой памяти.
В итоге отказ от общей памяти в пользу передачи сообщений станет, скорее всего, наиболее удачным методом реализации систем, эффективно использующих параллелизм, получивший сегодня повсеместную прописку в компьютерном железе. Занимательно выходит — процессы как единица конкурентного исполнения появились раньше потоков, но в будущем, по-видимому, потоки станут использоваться для реализации процессов.
Послание потомкамЛинда Райзинг
Возможно, дело в том, что в большинстве своем программисты — умные люди, но за многие годы моего преподавания и тесной совместной работы с ними у меня сложилось впечатление, будто сложность задач, над которыми они бьются, оправдывает для них создание решений столь же сложных (возможно, и для них самих спустя несколько месяцев после написания кода) для понимания и сопровождения.
Помню один случай с Джо, слушателем моего курса по структурам данных, который пришел показать мне результат своего труда.
— Держу пари, вы не догадаетесь, что делает этот код! — радостно воскликнул он.
— Ты прав, — согласилась я, не слишком вглядываясь в его текст и думая, как донести до него важную мысль. — Уверена, ты хорошо потрудился над этим примером. Боюсь, правда, ты упустил нечто важное. Скажи, Джо, у тебя есть младший брат?
— Да, конечно! Его зовут Фил, и он слушает ваш вводный курс. Он тоже учится программировать! — гордо объявил Джо.
— Это замечательно, — отвечала я. — Интересно, сможет ли он понять этот код?
— Ни за что, — сказал Джо, — это сложная штука!
— Давай предположим, — продолжила я, — что это реальный рабочий код и что через несколько лет Филу предложат работу по внесению изменений в этот код. Что ты сделал для Фила?
Джо моргал, глядя на меня.
— Мы знаем, что Фил — толковый парень, верно?
Джо кивнул.
— И не хочу хвастаться, но я тоже довольно толковая!
Джо ухмыльнулся.
— Итак, мне нелегко понять, что ты тут сделал, и твоему очень способному младшему брату тоже. Скорее всего, придется поломать над этим голову. В таком случае, что можно сказать о написанном тобой коде?
Как мне показалось, Джо увидел свой код в новом свете.
— Представим себе дело так, — сказала я, стараясь как можно лучше играть роль доброго наставника. — Каждая строка твоего кода — это послание человеку будущего, которым может оказаться твой младший брат. Попробуй объяснить этому умному человеку, как решить эту трудную задачу. Так ли ты видишь это будущее? Что этот умный программист увидит твой код и воскликнет: «Ничего себе! Как здорово! Мне совершенно понятно, что здесь происходит, и я поражен элегантностью — нет, красотой — этого кода. Надо немедленно показать его коллегам по команде. Это же шедевр!»
— Джо, можешь ли ты написать код, который решает эту задачу, но притом прекрасен, как песня? Да, как запавшая в память мелодия. Я думаю, что тот, кто сумел найти такое сложное решение, как предложенное тобой сегодня, может также написать что-нибудь красивое. Гм-м… Не начать ли мне выставлять оценки за красоту? Как ты считаешь, Джо?
Джо забрал свою работу и посмотрел на меня. Легкая улыбка пробежала по его лицу.
— Я все понял, профессор. Пойду улучшать мир для Фила. Спасибо.
Упущенные возможности применения полиморфизмаКирк Пеппердин
Полиморфизм — одна из грандиозных идей, лежащих в фундаменте ООП. Это слово, заимствованное из греческого языка, означает множество (poly) форм (morph). В контексте программирования полиморфизм означает многообразие форм некоторого метода или класса объектов. Но полиморфизм — это не просто альтернативные реализации. Уместное применение полиморфизма создает миниатюрные локализованные контексты исполнения и позволяет обойтись без громоздких блоков if-then-else. Находясь в контексте, мы можем напрямую выполнять нужные действия, тогда как, находясь вне этого контекста, мы вынуждены сначала воссоздать его и лишь затем выполнять нужные действия. Аккуратное использование альтернативных реализаций позволяет выделить контекст, а значит, решить ту же задачу через меньший объем более удобочитаемого кода. Лучше всего продемонстрировать это на примере. Возьмем следующий код для (нереально) простой корзины покупок:
public class ShoppingCart { private ArrayList- cart = new ArrayList
- ();
public void add(Item item) { cart.add(item); } public Item takeNext() { return cart.remove(0); } public boolean isEmpty() { return cart.isEmpty(); } }Допустим, некоторые товары в нашем интернет-магазине можно скачать из сети Интернет, а другие требуют доставки. Создадим другой класс, который поддерживает эти операции:
public class Shipping { public boolean ship(Item item, SurfaceAddress address) {… } public boolean ship(Item item, EMailAddress address) {… }}Когда клиент рассчитался, нужно доставить покупки:
while (!cart.isEmpty()) { shipping.ship(cart.takeNext(), ???);}Параметр ??? — это не какой-то очередной оператор Элвиса;[21] это неразрешенный вопрос о том, как нужно доставить товар — электронной или обычной почтой. Контекста для ответа на этот вопрос уже нет. Можно было сохранить метод доставки в виде boolean или enum, а затем использовать