Держим всю программу в голове

Пол Грэм [http://www.paulgraham.com/bio.html] (оригинал — Holding a Program in One's Head) [http://www.paulgraham.com/head.html]

Август 2007

Хороший программист, интенсивно работающий над своей программой, может держать её полностью в памяти так же, как математик держит в уме всю задачу, над которой работает. И они делают ещё бóльшее в уме – они пытаются понять пространство задачи достаточно хорошо, настолько, что могут перемещаться в ней так, как вы мысленно можете ходить по дому, в котором выросли. Самое лучшее программирование – такое же. Вы держите программу в уме и можете манипулировать ею по вашей воле.

Это особенно ценно в начале проекта, когда самое важное – мочь поменять то, что вы делаете. Не просто решить проблему другим путём, а поменять задачу, которую решаете.

Ваш код – это ваше понимание задачи, которую вы исследуете. Поэтому только когда она у вас в голове, вы действительно понимаете задачу.

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

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

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

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

Звучит странно, но запланированные отвлечения могут быть хуже, чем незапланированные. Если вы знаете, что через полчаса у вас встреча, то даже не начнёте интенсивно работать над чем-то.
Работайте длинными отрезками. Поскольку вы несёте постоянные издержки, начиная работать, эффективнее работать несколько длинных отрезков времени, чем много коротких. Конечно, наступит момент, когда вы отупеете от усталости. Тут у каждого своя норма. Я слышал про людей, «хачивших» 36 часов к ряду, но максимум, которого мне удалось когда-либо достичь – 18, а лучше всего я работаю отрезками не больше 12.

Оптимальная длина – это не то, сколько вы физически выдержите. В том, чтобы бросить работу есть не только издержки, но и выгоды. Иногда вернувшись к задаче после отдыха, вы обнаруживаете, что ваше подсознание оставило вам решение.
Используйте лаконичные языки. Самые сильные [http://www.paulgraham.com/power.html] языки программирования делают программы короче. А программисты, хотя бы отчасти, думают о своих программах на языках, на которых пишут. Чем лаконичнее язык, тем короче будет программа, и тем проще загрузить и держать её в уме.

Эффект от мощного языка можно усилить, пользуясь стилем, который называется «программирование снизу-вверх», в котором вы пишете программу в несколько слоёв, где нижние слои играют роль языка программирования для более высоких. Если вы будете делать это правильно, вам нужно будет держать в голове только самый верхний слой.
Продолжайте переписывать программу. Переписывание программы часто приводит к более чистой модели. Но даже если и не так, нужно понять программу полностью, чтобы переписать её, поэтому нет лучшего способа загрузить её в сознание.
Пишите читаемый код. Все программисты знают, что писать читаемый код хорошо. Но вы сам – самый важный читатель. Особенно в начале пути. Прототип – это разговор с самим собой. Когда вы пишете для себя, у вас другие приоритеты. Если вы пишете для других, не нужно писать слишком плотный код. Некоторые части программы было бы проще всего читать, если раскидать куски, как в учебнике вводного курса. Но когда вы пишете код так, чтобы его было проще вспомнить, лучше всего придерживаться лаконичного стиля.
Работайте в маленьких группах. Когда вы манипулируете программой в голове, вы не можете выйти за пределы вашего собственного кода. Другие части вы не понимаете и, что более важно, не можете быть в них свободными. Поэтому чем меньше число программистов, тем больше проект может изменяться. Если программист всего один, как часто бывает в начале, вы можете делать всеобъемлющие перепроектировки.
Не давайте большому числу людей редактировать один кусок кода. Вы никогда не поймёте чужой код так же хорошо, как ваш собственный. Неважно как тщательно вы его прочитали, вы его только прочитали, не написали. Поэтому если кусок кода пишет множество авторов, ни один из них не понимает его так, как понимал бы один единственный автор.

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

Если вы хотите чтобы несколько человек работали над проектом, разделите их по компонентам и дайте каждую одному человеку.
Начинайте с малого. Программу легче держать в голове по мере того, как вы знаете её всё лучше. Можно работать с частями программы как с чёрными ящиками как только вы уверены, что изучили их полностью. Но когда вы только начинаете работать над проектом, вам приходится видеть всё. Если вы начали со слишком большой задачи, вам может никогда не хватить времени на то, чтобы охватить её. Если нужно написать большую, сложную программу, лучший способ начать – не писать спецификацию, а написать прототип, который будет решать подмножество задачи. Какие бы ни были преимущества планирования, они часто перевешиваются преимуществами держания программы в уме.

Поразительно, как часто программисты умудряются случайно выполнить все восемь пунктов. У кого-нибудь есть идея для нового проекта, но поскольку тот официально не разрешён, ему приходится заниматься проектом в свободное время – что в свою очередь означает более продуктивную работу, потому что ничто не отвлекает. Движимый энтузиазмом, он работает по несколько часов подряд. Поскольку изначально это просто эксперимент, вместо «производственного» языка он использует «скриптовый» - который на самом деле намного мощнее. Он полностью переписывает программу несколько раз. Это было бы неоправданно для официального проекта, но это просто работа ради удовольствия, и ему хочется, чтобы она была сделана идеально. И поскольку никто кроме него не видит её, он ничего не комментирует, оставив лишь пометки для самого себя. Он в силу обстоятельств работает в маленькой группе – потому что не сказал никому, либо потому что никому больше не разрешено работать над проектом. Даже если есть группа, большое количество людей не может редактировать один и тот же код, потому что он меняется слишком быстро. И проект начинает с малого, потому что сама идея мала в начале. Ему просто хочется попробовать применить крутой хак.

Ещё более потрясает число официально одобренных проектов, в которых умудряются делать все восемь пунктов неправильно.

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

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

Может мы могли бы определить новый тип организации, которая бы соединяла усилия индивидов, не пытаясь сделать их взаимозаменяемыми. Вероятно рынок – такая форма организации, хотя корректнее было бы определить рынок как вырожденный случай – это то, что вы получаете по умолчанию, когда организация невозможна.

Возможно лучшее, что мы можем сделать – это своего рода хак, например, чтобы программистские подразделения в организации работали иначе, чем остальные. Возможно оптимальное решение для больших компаний – не пытаться разрабатывать программы внутри компании вовсе, а просто покупать [http://www.paulgraham.com/hiring.html] их. Но независимо от того, каким будет решение, первый шаг, который нужно сделать – это осознать, что есть проблема. В самой фразе «компания-разработчик ПО» (разговорное «софтовая компания») есть противоречие. «Компания» и «разработчик ПО», как лебедь и щука, тянут в разные стороны. Любой хороший программист в большой организации будет с ней в разногласии, потому что организации сделаны, чтобы предотвращать то, за что борются программисты.

Хорошим программистам удаётся сделать многое в любом случае. Но часто для этого им практически приходится устраивать бунт против организаций, которые их нанимают. Возможно, было бы лучше, если бы люди понимали, что поведением программистов движут требования работы, которую они делают. Вовсе не от безответственности они работают запоем и забывают про все другие обязательства, погружаются прямо в программирование вместо того, чтобы сначала написать спецификации, и переписывают код, который уже работает. Вовсе не из-за недружелюбия они предпочитают работать в одиночку и рычат на человека, который появился в двери, чтобы сказать привет. У всей этой, на первый взгляд случайной, коллекции раздражающих привычек есть простое объяснение: сила держания программы в своей голове.

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

Пол Грэм, август 2007
Перевод Дмитрия Лебедева (http://ryba4.com [http://ryba4.com] detail@ngs.ru), 20.04.2008