Удерживая программу в голове

(перевод статьи Пола Грэма Holding a Program in One’s Head)

Хороший программист, напряженно работающий над своим кодом, может удерживать программу в голове точно как математик удерживает в голове проблему, над которой он работает. Математики не находят ответы на вопросы, «расписывая» их на листке бумаги, как этому учат школьников. В большей степени они делают это «в уме»: они пытаются понять проблему настолько, чтобы можно было «пройтись» по ней также, как вы можете по памяти пройтись по всем углам дома, где вы выросли. И в своем лучшем виде программирование очень на это похоже. Вы удерживаете всю программу в голове и вы можете манипулировать ее по своему желанию.

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

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

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

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

• Избегайте отвлечения внимания. Отвлечение внимания плохо для многих видов работы, но особенно плохо для программирования, потому что программисты часто ведут дело на предельном уровне деталей, с которым они в состоянии справиться.Опасность не в том, насколько долго ваше внимание отвлекается, но в том, насколько это отвлечение путает ваши мысли. Программист может выйти из офиса и съесть бутерброд не теряя картины кода в голове. Но «неправильный» вид отвлечения может очистить всю картину за 30 секунд.Странно, но запланированные отвлечения внимания могут быть хуже, чем незапланированные. Если вы знаете, что собрание состоится через час, вы даже не начинаете работу над чем-то действительно сложным.

• Работайте длинными периодами времени. Так как есть фиксированные затраты каждый раз, как вы начинает работу над программой, более эффективно работать в несколько длинных интервалов, чем в большое количество коротких. Конечно, рано или поздно вы почувствуете, что начинаете глупить потому что устали. Для разных людей этот момент наступает в разное время. Я слышал, что есть люди, способные программировать 36 часов кряду, но мой собственный максимум около 18 часов, а лучше всего мне работается блоками не более чем по 12 часов.Оптимальное значение не равно физическому пределу. Есть также и положительные моменты в прерывании работы. Иногда, когда вы возвращаетесь к проблеме после отдыха, вы обнаруживаете, что ваше подсознание приготовило для вас готовый ответ.

• Используйте выразительные языки программирования. Более мощные языки программирования означают более короткие программы. И программисты часто думают о программах хотя бы частично на том языке, на котором они пишутся. Чем более компактен язык, тем короче программа и тем легче удержать ее в голове.Вы можете усилить эффект мощного языка используя так называемый стиль разработки «снизу вверх», когда вы пишите программу на множестве уровней и более нижние уровни выступают своеобразным языком программирования для более верхних уровней. Если вы все сделали правильно, вам потребуется держать в голове только самый верхний уровень.

• Продолжайте переписывать программу. Переписывание программы часто приводит к более ясному дизайну. Но это имело бы смысл в любом случае: вам понадобится полностью понять программу, чтобы переписать ее, так что нет лучшего способа «загрузить» ее в голову.

• Пишите читабельный код. Все программисты знают, что писать читабельный код это хорошая практика. Но вы сами являетесь самым главным читателем. Особенно в начале; прототип представляет собой разговор с самим собой. И когда вы пишите для себя у вас другие приоритеты. Если вы пишите для кого-то, вы можете захотеть не писать слишком «плотно». Некоторые части программы могут быть легче для понимания, если вы «развернете» код, как в учебнике. Тогда как если вы пишите, чтобы иметь возможность быстро «загрузить» программу в голову, лучшим может быть писать «плотно».

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

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

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

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

Управляемый своим энтузиазмом к новому проекту, он работает над ним помногу часов подряд. Так как изначально это всего лишь эксперимент, вместо «промышленного» языка программирования используется «скриптовый» язык — который в реальности оказывается гораздо более продуктивным. Он полностью переписывает программу несколько раз; это было бы недопустимо в «настоящем» проекте, но так как это плод любви программист желает совершенства. И так как никто больше не увидит код, он не пишет комментарии, за исключением пометок для себя. Он работает маленькой группой в силу сложившихся обстоятельств, так как либо никто больше о идее проекте не знает, либо она недостаточно привлекательна, чтобы кому-то еще разрешили над ней работать. Даже если и есть группа, они не могут позволить себе иметь несколько авторов для одного участка кода, так как код для этого меняется слишком быстро. И проект начинается небольшим потому, что и идея, стоящая за ним, поначалу небольшая; просто какой-то интересный трюк, который хочется испробовать на практике.

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

Не правильно говорить, что организациям не нравится идея быть зависимым от гения индивида, это тавтология. Это заложено в самом определении слова «организация». Ну или по крайней мере, нашего теперешнего понимания этого слова.
Возможно мы может дать определение новому типу организации, который соединит усилия индивидуумов без того, чтобы требовать от них взаимозаменяемости. Возможно рынок и есть такой вид организации, хотя более аккуратно было бы назвать рынок вырожденным случаем — то, что вы получаете когда создание организации невозможно.
Вероятно, лучшее, что мы сделаем это какой-нибудь трюк, например дав возможность программистам работать не так, как остальная часть организации. Возможно оптимальное решение для больших компаний даже не пытаться придумывать идеи in-house, но просто покупать их. Но вне зависимости от того, каким будет решение, первым шагом должно стать понимание того, что проблема существует. Есть противоречие в самой фразе «софтверная компания». Эти два слова «тянут» в противоположных направлениях. Любой хороший программист в большой организации будет чувствовать себя не комфортно, так как организации задуманы таким образом, чтобы не допускать то, чего так хотят программисты.

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU