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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тот мир ушел или уже уходит. Но в целом потребность в креативных программистах так же велика, как и всегда. Мы хотим получать удовольствие от нашей работы. Мы хотим преимуществ от безопасных языков и одновременно - скорости вручную отлаженного ассемблерного кода. Кто-то ведь должен создавать виртуальные машины и сборщики мусора, придумывать чипы - хотя это “железо”, но в то же время программные произведения.

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

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