Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Я по характеру не фанатик. Если это работает - прекрасно. Я двадцать лет писал код на Си. Но с точки зрения сбережения времени программистов эффективнее использовать более современный язык, который будет безопаснее, удобнее и выразительнее. Обычно время программиста куда ценнее компьютерного времени. Но это не обязательно так, если одна и та же программа запускается на тысячах машин. И есть программы, где целесообразно использовать менее безопасные языки, дающие нам большую скорость. Сегодня, как мне кажется, в смысле экономии компьютерного времени нет особой разницы, на каком языке писать ту или иную программу. Если кто-то говорит, что его
Но в смысле экономии времени программистов разница есть. Прежде всего, более современные языки свободны от многих типов ошибок. Во-вторых, в них есть прекрасные наборы инструментов, позволяющие сделать работу программиста более эффективной. Все это отчасти обусловлено тем, что именно эти языки люди учат в школе, - но также и их базовыми инженерными харктеристиками. Например, если в языке есть макрогенератор, писать для него хорошие утилиты намного сложнее. Парсинг C++ куда более непростое дело, чем парсинг Java.
В Google сейчас немалая часть кода пишется на Java - гораздо больше, чем раньше. Точных данных назвать не могу, но, думаю, мы уже едва ли не перегнули палку. И есть большой разрыв между тем, сколько строк кода у нас написано на различных языках, и тем, сколько процессорных циклов выполняется на том или ином языке. Было бы большой глупостью, по-моему, писать внутренние циклы индексирующих серверов на Java. Если вы, скажем, создаете компанию, то можете писать коды на Java или на другом современном языке с хорошими параметрами безопасности, а потом отказаться от него, если нужно. Но что касается Java, тут есть вся необходимая инфраструктура - библиотеки, средства контроля и так далее, В случае их применения Java будет если не идеальным, то вполне надежным партнером. Когда я только пришел в Google, это было не так.
Компании очень рано выстраивают свою ДНК. Это может принести им громадный успех, но потом очень трудно отказаться от той архитектуры, когда она перестает отвечать потребностям. Помню, когда я был начинающим специалистом в исследовательском центре IBM, в Йорктаун-Хайтсе. Это было году в 1982-м, и там вовсю применялась пакетная обработка данных. Даже применяя разделение времени, они мыслили в терминах виртуальных считывателей карт и виртуальных перфораторов. Везде записи в 80 колонок! В DEC так и не смогли мыслить иначе как в терминах разделения времени. Ну, а что касается Microsoft, то еще вопрос, смогут ли они держать в уме что-то иное, помимо настольного персонального компьютера.
Сейбел: А через двадцать лет скажут, что компания Google навсегда ушиблена он л айн-рек ламой.
Блох: Конечно. В Google так или иначе господствует стереотип, что Java - язык медленный и ненадежный. И понятно, почему: версия Blackdown Java, созданная для Linux около 1999 года, была медленной и ненадежной. Старые предрассудки очень живучи. Но по правде говоря, Google использует Java в очень важных с деловой точки зрения случаях, к примеру для рекламы.
Так что в определенной степени там не считают этот язык медленным и ненадежным. Но основной поиск в Google, занимающий наибольшее число машинных циклов, основан на C++, и ясно, что это имеет историческое обоснование. Это будет продолжаться еще какое-то время.
Сейбел: Какими инструментами вы сегодня пользуетесь для программирования?
Блох: Ждал этого вопроса. Да, я старпер, и гордиться тут нечем. Команды Emacs навсегда
Для больших программ я использую IntelliJ, так как вся моя группа работает с ней, но у меня выходит неважно. Да, она производит впечатление - мне нравится то, как эти утилиты делают за вас статический анализ. Кое-кого из поклонников таких инструментов, как IntelliJ, Eclipse, NetBeans и FindBugs, я привлекал для выверки текста книги “Java Puzzlers”. Многие ляпы были найдены автоматически с помощью этих программ. Просто здорово.
Сейбел: Стали бы вы работать продуктивнее, если бы потратили месяц для подробного изучения IntelliJ?
Блох: Да. Современные интегрированные среды разработки отлично справляются с масштабным рефакторингом. Брайан Гетц заметил, что сегодня программисты пишут более качественный код, потому что раньше не могли делать такой рефакторинг, как сейчас. Они полагаются на эти инструменты, чтобы вносить сквозные изменения, не затрагивающие работу кода.
Сейбел: Как насчет прочих инструментов?
Блох: С утилитами для программирования у меня не очень хорошо - а жаль. Инструменты сборки и системы управления версиями изменяются сильнее, чем хотелось бы, и мне трудно следить за ними. Поэтому, сталкиваясь с новой средой, я всегда пристаю к коллегам, более привычным к таким инструментам. Я вечно спрашиваю: “А как сегодня это делается?” Коллеги закатывают глаза и помогают мне, а я пользуюсь средой, пока она окончательно не откажет.
Гордиться тут нечем. Разработчики программ могут быть искусны в одном и малоискусны в другом. Кое-кто утверждает, что это не так, что разработчики взаимозаменяемы, что каждый может и должен уметь все. Но на практике это не так. И если заставлять каждого разработчика делать все, результат будет никудышным.
Я говорю прежде всего о тех, кто, по выражению Кевина Бурильона, “лишен гена эмпатии”. Нельзя создавать хорошие API или языки, не представив себя в шкуре рядового программиста, который пользуется ими. Однако есть люди, создающие хорошие API и языки. И есть знатоки технической стороны проектирования языка, которые говорят: “Это сделает все несовместимым с LALR(l), надо сделать по-другому”. Это крайне полезное знание. Но оно не заменяет гена эмпатии — такой знаток может создать кошмарный язык, не пригодный для использования.
Есть и другие - способные выжать из языка все, что возможно, ради большей эффективности. Надо найти им нужное применение - они будут счастливы и принесут пользу вашей компании. Вообще, необходимо знать сильные места ваших разработчиков и пользоваться этим. Это я так оправдываюсь за свое плохое знание инструментов. Слабое оправдание, понятно.
Сейбел: Поговорим об отладке. Можете ли вы назвать худшую ошибку из тех, что вам встречались?
Блох: Мне сразу приходит в голову один кошмарный и в то же время любопытный случай. Это было в начале 1990-х, я тогда работал в питт-сбургской компании Transarc. Мне пришлось заниматься реализацией транзакционной разделяемой памяти при очень плотном графике. Проектирование и реализацию я закончил в срок и даже успел написать несколько библиотечных компонентов. Но я нервничал из-за того, что произвел много нового кода в спешке.