Блох: Да. Вы говорили о двух несхожих между собой сообществах Java-программистов. Для тех, кто создает библиотеки, компиляторы, фрейм-ворки, намного важнее математика. А для создания веб-приложений на базе фреймворков требуются навыки словесного и визуального общения. Я прихожу в бешенство, когда веб-сайт заставляет меня что-то делать неправильно. Ясно, что человек не подумал о том, как с его сайтом будут взаимодействовать пользователи. Истина в том, что программирование находится в точке пересечения многих дисциплин. Смотря по тому, что вам знакомо лучше, вы достигнете успеха в создании тех или иных приложений. Но библиотеки, компиляторы и фреймворки также должны быть читаемыми и легкими в поддержке. И если у вас неважно с написанием текстов, вам будет нелегко добиться этого.

Сейбел: Каков ваш подход к проектированию программ? Что вы делаете — запускаете Emacs, начинаете писать код, вертите его по-всякому, пока он не примет нужный вид? Или садитесь на диван со стопкой бумаги?

Блох: Несколько лет назад на конференции по объектно-ориентированному программированию я делал доклад «Как создать качественный API и почему это важно». Несколько его вариантов есть в Сети. Там я подробно объясняю свой подход.

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

Ничто не может быть дальше от истины. Это не только переговоры — это также процесс понимания. Некоторые клиенты излагают вам не задачу, а свое решение. Например, клиент говорит: «Мне нужна поддержка для 17 атрибутов этой системы». И вы начинаете расспрашивать, что он собирается делать с системой, какой видит ее и так далее Вы какоето время мечетесь туда-сюда, пока, наконец, не осознаете реальную потребность клиента. Это сценарии использования.

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

Хуже всего — а я сталкивался с такими случаями — это когда вы сажаете в офисе команду смышленых парней, которые через полгода выдают вам 247-страничную спецификацию, толком не понимая, что они разрабатывают. Через полгода это будет программа с подробной спецификацией — программа, которая может оказаться бесполезной. Часто можно услышать: «Мы столько потратили на эту спецификацию, что должны ее реализовать». В итоге получается бесполезная система, которая никому не нужна. Вот что ужасно. Если нет сценариев использования, вы создаете нечто, а потом пытаетесь написать что-то очень простое и тут говорите себе: «Черт, ведь чтобы распечатать XML-документ, нужно много страниц стандартного кода». Это ужасно.

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

На этой стадии нужна гибкость: придайте интерфейсу форму ровно настолько, чтобы вы могли реализовать сценарии использования на этом новорожденном API и понять, соответствует ли он задаче. Любопытно: по прошествии времени все кажется простым, но при создании API обычно ошибаешься, даже держа в уме сценарии использования. При написании кода для сценариев вы замечаете, что у вас слишком много классов, какие-то нужно объединить, какие-то выкинуть. К счастью, ваш интерфейс умещается на странице, и его легко поправить.

Чем больше вы полагаетесь на свой API, тем больше вы к нему добавляете. Но основное правило вот какое: сначала напишите код, использующий API, а потом уже код его реализации. Иначе вы можете потратить впустую время, написав код, который не будет использоваться. На самом деле код, использующий API, надо писать даже до подробной разработки спецификации — иначе можно потратить время на детальную спецификацию чего-то в корне неработоспособного. Вот такой у меня подход к проектированию.

Сейбел: Какие здесь особенности у Java-коллекций, представляющих собой особый вид автономных API?

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

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

Надо, правда, учитывать, что программирование — обширная сфера. Если вы пишете на HTML и только, то это не лучший образ действий, но для многих видов программирования — действительно лучший.

Сейбел: Итак, вы стоите за модули, которые сцепляются между собой не слишком тесно. Сегодня на этот счет есть две точки зрения. Сторонники первой призывают, как и вы, проектировать межмодульные API в самом начале работы. Защитники другой заявляют: «Делайте простейшую вещь из всех возможных» и «Беспощадный рефакторинг!».