Кодеры за работой

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

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

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

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

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

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

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

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

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

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

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

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

Блох:

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

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

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

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

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