а. Математика и программирование чертовски близки. Поэтому держите глаза открытыми и будьте готовы применять найденные идеи в других местах.
Сейбел: Знакомы ли вам выдающиеся программисты, которые не очень любят математику или плохо ее знают? Нужны ли сейчас программисту математический анализ, дискретная математика и тому подобное? Или все зависит от склада ума, которым можно обладать даже без соответствующего образования?
Блох: Полагаю, так думают те, кто этого всего не изучал. Но знание математики, само собой, помогает в работе. Я работал с парнем по имени Майк Макклоски. Он мыслил математически, не зная теорию чисел. Он переписывал Biglnteger. Раньше она была надстройкой над Си-библиотекой, но Майк переписал ее на Java так, что потери в скорости не было. Недавно он завершил свою работу, в процессе освоив теорию чисел. Без математического склада ума он этого не сделал бы, но выучи он эту теорию до того, ему не пришлось бы осваивать ее в ходе работы.
Сейбел: Но он решал сугубо математическую задачу.
Блох: Да, пожалуй, не слишком удачный пример. Но даже при решении задач, прямо не имеющих отношения к математике, математическое мышление все равно нужно программисту. Например, доказательство по индукции так тесно связано с рекурсивным программированием, что одно без другого не понять. Вы можете не знать такие термины, как «база индукции» и «индукционный переход», но должны понимать их суть для написания хороших рекурсивных программ. Так что даже если задача программиста не связана с математикой, без знания математических понятий ему придется туго.
Матанализ, мне кажется, не так важен. С годами произошло кое-что любопытное. Обычно считалось, что если вы образованный человек и закончили колледж, то должны знать матанализ. И он содержит массу прекрасных идей — хорошо, когда понимаешь, как обращаться с понятием бесконечности.
Но есть дискретный и непрерывный способ осознать понятие бесконечности. И я считаю, что для программиста важнее овладеть дискретным. Я только что упоминал индуктивное доказательство. Можно доказать то, что будет верным для всех целых чисел. Просто волшебно! Доказываешь что-то для одного числа, потом доказываешь, что одно число влечет за собой другое, — и вот доказательство верно для всех целых чисел. Думаю, это важнее для программиста, чем, скажем, иметь понятие о пределах.
К счастью, нам не нужно выбирать. Можно освоить и то и другое. Даже если вы не собираетесь использовать матанализ так активно, как дискретную математику, все равно знать их нужно. Но дискретный подход все равно полезнее непрерывного.
Сейбел: Вы говорили о том, что у программирования много общего с написанием прозы. Обычно с компьютерами и программированием всегда была тесно связана именно математика. Но если говорить о веб-фреймворках или веб-приложениях на их основе, требуют ли они скорее писательских навыков?
Блох: Да. Вы говорили о двух несхожих между собой сообществах Java-программистов. Для тех, кто создает библиотеки, компиляторы, фрейм-ворки, намного важнее математика. А для создания веб-приложений на базе фреймворков требуются навыки словесного и визуального общения. Я прихожу в бешенство, когда веб-сайт заставляет меня что-то делать неправильно. Ясно, что человек не подумал о том, как с его сайтом будут взаимодействовать пользователи. Истина в том, что программирование находится в точке пересечения многих дисциплин. Смотря по тому, что вам знакомо лучше, вы достигнете успеха в создании тех или иных приложений. Но библиотеки, компиляторы и фреймворки также должны быть читаемыми и легкими в поддержке. И если у вас неважно с написанием текстов, вам будет нелегко добиться этого.
Сейбел: Каков ваш подход к проектированию программ? Что вы делаете — запускаете Emacs, начинаете писать код, вертите его по-всякому, пока он не примет нужный вид? Или садитесь на диван со стопкой бумаги?
Блох: Несколько лет назад на конференции по объектно-ориентированному программированию я делал доклад «Как создать качественный API и почему это важно». Несколько его вариантов есть в Сети. Там я подробно объясняю свой подход.
Главное — понимать, что именно вы строите, какую проблему решаете. Важность анализа требований трудно переоценить. Некоторые думают, что это просто — идешь к клиенту, тот говорит, что ему нужно, и готово.
Ничто не может быть дальше от истины. Это не только переговоры — это также процесс понимания. Некоторые клиенты излагают вам не задачу, а свое решение. Например, клиент говорит: «Мне нужна поддержка для 17 атрибутов этой системы». И вы начинаете расспрашивать, что он собирается делать с системой, какой видит ее и так далее Вы какоето время мечетесь туда-сюда, пока, наконец, не осознаете реальную потребность клиента. Это сценарии использования.
На этом этапе самое важное — иметь обширный набор сценариев использования. А от них уже можно отталкиваться в своих поисках решения. Нужно тщательно, не жалея времени, обдумать его, потому что если решение неправильное, все ваши дальнейшие усилия пойдут прахом.
Хуже всего — а я сталкивался с такими случаями — это когда вы сажаете в офисе команду смышленых парней, которые через полгода выдают вам 247-страничную спецификацию, толком не понимая, что они разрабатывают. Через полгода это будет программа с подробной спецификацией — программа, которая может оказаться бесполезной. Часто можно услышать: «Мы столько потратили на эту спецификацию, что должны ее реализовать». В итоге получается бесполезная система, которая никому не нужна. Вот что ужасно. Если нет сценариев использования, вы создаете нечто, а потом пытаетесь написать что-то очень простое и тут говорите себе: «Черт, ведь чтобы распечатать XML-документ, нужно много страниц стандартного кода». Это ужасно.
Поэтому берите сценарии использования и создавайте набросок API — совсем небольшой. Обычно он помещается на одной странице. Предельной точности тут не требуется. Нужны описания пакетов, классов и методов, а если не совсем понятно, что они должны делать, напишите об этом — по одной строке для каждого вида элементов. Но это не та вылизанная документация, которую вы потом будете распространять.
На этой стадии нужна гибкость: придайте интерфейсу форму ровно настолько, чтобы вы могли реализовать сценарии использования на этом новорожденном API и понять, соответствует ли он задаче. Любопытно: по прошествии времени все кажется простым, но при создании API обычно ошибаешься, даже держа в уме сценарии использования. При написании кода для сценариев вы замечаете, что у вас слишком много классов, какие-то нужно объединить, какие-то выкинуть. К счастью, ваш интерфейс умещается на странице, и его легко поправить.
Чем больше вы полагаетесь на свой API, тем больше вы к нему добавляете. Но основное правило вот какое: сначала напишите код, использующий API, а потом уже код его реализации. Иначе вы можете потратить впустую время, написав код, который не будет использоваться. На самом деле код, использующий API, надо писать даже до подробной разработки спецификации — иначе можно потратить время на детальную спецификацию чего-то в корне неработоспособного. Вот такой у меня подход к проектированию.
Сейбел: Какие здесь особенности у Java-коллекций, представляющих собой особый вид автономных API?
Блох: Могу сказать, что это не настолько специфично, как можно подумать. Программирование любой сложности требует проектирования API, поскольку большие программы строятся по модульному принципу, и надо конструировать межмодульные интерфейсы.
Хорошие программисты стараются делать вещи, работающие автономно, по нескольким причинам. Первая состоит в том, что вы, возможно неосознанно, создаете модули, пригодные для повторного использования. Если строить монолитную систему, а затем, когда она разрастется, разбивать ее на части, то у вас не будет четких границ, и вы получите кучу мусора, который невозможно поддерживать. Поэтому то, о чем я говорю, есть просто самый разумный подход к программированию, и неважно, ощущаете вы себя проектировщиком API или нет.
Надо, правда, учитывать, что программирование — обширная сфера. Если вы пишете на HTML и только, то это не лучший образ действий, но для многих видов программирования — действительно лучший.
Сейбел: Итак, вы стоите за модули, которые сцепляются между собой не слишком тесно. Сегодня на этот счет есть две точки зрения. Сторонники первой призывают, как и вы, проектировать межмодульные API в самом начале работы. Защитники другой заявляют: «Делайте простейшую вещь из всех возможных» и «Беспощадный рефакторинг!».
Блох: Мне кажется, они не исключают друг друга. В каком-то смысле я говорю о разработке через тестирование и рефакторинге применительно к API. Как тестировать API? До начала реализации пишутся сценарии использования. Я не могу запустить их, но это разработка через тестирование. Я тестирую качество API, реализуя в коде сценарии использования, чтобы понять, насколько мой API отвечает поставленной задаче.
Сейбел: Значит, вы пишете клиентский код, использующий API, потом смотрите на него и спрашиваете себя: «Это в самом деле тот код, который мне нужен?»
Блох: Именно так. Иногда даже не доходит до того, чтобы взглянуть на клиентский код. При попытке начать его писать происходит одно из двух: или ты не можешь его написать, так как чего-то не хватает в API, или можешь его написать, но понимаешь, что ошибся в подходе.
Неважно, насколько хороший вы программист, — вам не создать нормальный API, пока вы не начали писать код для него. Вы проектируете что-то, пытаетесь это использовать и замечаете: что-то здесь совсем не так. Если же сделать это вначале, вы не потратите время впустую на создание всех лежащих ниже слоев — это большой плюс. Я говорю, как видите, о разработке через тестирование и о рефакторинге API, а не о рефакторинге кода реализации ниже слоя API.
Насчет простейшей вещи из всех возможных — я «за» обеими руками. Основная аксиома проектирования API такова: «Сомневаешься — выкидывай». Простейшая вещь должна быть достаточно велика, чтобы соответствовать всем намеченным сценариям использования. Это вовсе не означает, что надо склеивать воедино сырые фрагменты кода. На этот счет есть куча афоризмов. Мой любимый — тот, что ошибочно приписывают Телониусу Монку: «Сделать просто — непросто».