Кодеры за работой. Размышления о ремесле программиста

Так, например, если у вас есть два потока и оба прибавляют значения для счетчика, они должны выполняться параллельно. Они могут обращаться к одному и тому же участку памяти, но при этом не конфликтуют в логическом плане. Если один поток считывает значение счетчика, а другой увеличивает его, то есть конфликт. Но ведь у вас может быть множество потоков, которые считывают значения, и других, увеличивающих их. Я пока не видел систем, которые могли бы справляться с такими вещами самостоятельно. Может быть, мой пример несколько искусственный, но часто физические ограничения намного суровее логических.

Вторая проблема с транзакционной памятью в том, что внутри нее осуществляются не все операции, например операция ввода/вывода. А вот третья проблема: некоторые виды транзакционной памяти позволяют «обреченным транзакциям» видеть память в неустойчивых состояниях — потенциально это крайне опасно. С этими проблемами мы уже сражались, когда строили транзакционные системы общего назначения. Решения есть, но все они усложняют систему или снижают скорость работы.

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

Сейбел: Сменим тему. Каков ваш стиль работы в команде?

Блох: Я довольно уживчив, предпочитаю «приятельское программирование» — когда работаешь вместе с кем-то, но не за одной клавиатурой. Вы пишете разные части программы, обмениваетесь кодом. Можно вообще пребывать в разных полушариях. Мы с Дугом Ли таким образом плотно работали несколько лет. Один писал интерфейс, другой говорил: «Все отлично, но я поправил там кое-что, вот погляди».

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

Мне нравится сидеть с кем-нибудь за одним терминалом и работать над кодом, но таким образом я сделал не много программ с нуля. Обычно это случается, когда я делаю ревизию кода; если вижу, что код надо сильно править, то предлагаю человеку посидеть вместе. Это полезно во многих отношениях, например как средство обучения, способ передать знания старшего поколения младшему.

А работать совсем в одиночку мне не нравится. Когда я пишу программу и обдумываю какое-нибудь сложное проектное решение, мне нужно с кем-то советоваться. Везде, где я работал, рядом был кто-нибудь, с кем я мог поделиться. Для меня это очень важно — обратная связь.

Сейбел: Так что же важнее — обратная связь или просто шанс проговорить задачу вместе?

Блох: И то и другое. Мы делаем очень хитрые вещи — часто есть не одно правильное решение или одно, но которого никто до тебя не нашел. Надо полагаться на свой инстинкт, но иногда полезно выслушать того, кто смотрит на вещи по-другому.

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

Сейбел: Еще один вечный вопрос — кажется, его еще в 1970-е поднимал Вайнберг в «The Psychology of Computer Programming», — дискутируется и сейчас: должен ли кодом владеть один человек, и только он и должен с ним работать, — или им должны владеть все, кто работал над проектом, и всем должно быть разрешено вмешиваться в него?

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

Конечно, для компании плохо, если кодом владеет один человек. А если он покинет компанию? Поэтому важно, чтобы сразу несколько программистов знали каждый фрагмент кода и могли с ним работать. Но мечтать о том, чтобы все владели всем кодом, по-моему, не стоит.

Это возвращает нас к теме сфер компетенции. Писать код, перемалывающий биты, способны немногие, и если вы оказываетесь внутри кода, работающего с битами, поговорите с тем, кто умеет обращаться с ним, если сами не умеете. Умелые программисты это любят. Они могут днями работать над тем, чтобы сократить последовательность инструкций на одну или доказать какую-нибудь идентичность, чтобы ускорить вычисления. Но испортить код очень легко. И очень легко написать что-нибудь, что станет хорошо работать, скажем, при 2³² — 1 из 2³² потенциальных вариантов ввода. Модульный тест может выявить, что ваше решение не работает с этим одним значением, а может и не выявить. И тогда вы будете виноваты в том, что испортили код.

Сейбел: Если говорить о запутанном коде, я заметил вот что: у слишком умных — в определенном смысле, по крайней мере — программистов получается самый плохой код. Они держат все у себя в голове, и в итоге получается не код, а тарелка спагетти.

Блох: Согласен. Те, кто способен делать сложные вещи и лишен нужной эмпатии в отношении других, часто становятся жертвой такого подхода. «Я понимаю это и могу этим пользоваться, значит, это годится», — вот их логика.

Сейбел: А есть ли в программировании нечто, привлекающее людей именно с таким внутренним складом?

Блох: Конечно! Всяческие головоломки — наша страсть. Но эта страсть должна сдерживаться пониманием того, что мы решаем реальные проблемы реальных людей. Если же это не так, то мы занимаемся самоудовлетворением и все. Думаю, первая компания, в которой я работал, разорилась именно из-за этого. Надо было понять, что наша цель — не разработка программ сама по себе.

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

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

Сейбел: Разве сейчас возможности для такого программирования не сокращаются? Многие из таких вот низкоуровневых программ уже реализованы в вашей виртуальной машине или параллельных библиотеках. И для многих программирование теперь означает склеивание блоков воедино.

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