×Закрыть

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

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

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

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

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

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

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

  • Избегайте отвлечения внимания. Отвлечение внимания плохо для многих видов работы, но особенно плохо для программирования, потому что программисты часто ведут дело на предельном уровне деталей, с которым они в состоянии справиться.Опасность не в том, насколько долго ваше внимание отвлекается, но в том, насколько это отвлечение путает ваши мысли. Программист может выйти из офиса и съесть бутерброд не теряя картины кода в голове. Но «неправильный» вид отвлечения может очистить всю картину за 30 секунд.Странно, но запланированные отвлечения внимания могут быть хуже, чем незапланированные. Если вы знаете, что собрание состоится через час, вы даже не начинаете работу над чем-то действительно сложным.
  • Работайте длинными периодами времени. Так как есть фиксированные затраты каждый раз, как вы начинает работу над программой, более эффективно работать в несколько длинных интервалов, чем в большое количество коротких. Конечно, рано или поздно вы почувствуете, что начинаете глупить потому что устали. Для разных людей этот момент наступает в разное время. Я слышал, что есть люди, способные программировать 36 часов кряду, но мой собственный максимум около 18 часов, а лучше всего мне работается блоками не более чем по 12 часов.Оптимальное значение не равно физическому пределу. Есть также и положительные моменты в прерывании работы. Иногда, когда вы возвращаетесь к проблеме после отдыха, вы обнаруживаете, что ваше подсознание приготовило для вас готовый ответ.
  • Используйте выразительные языки программирования. Более мощные языки программирования означают более короткие программы. И программисты часто думают о программах хотя бы частично на том языке, на котором они пишутся. Чем более компактен язык, тем короче программа и тем легче удержать ее в голове.Вы можете усилить эффект мощного языка используя так называемый стиль разработки «снизу вверх», когда вы пишите программу на множестве уровней и более нижние уровни выступают своеобразным языком программирования для более верхних уровней. Если вы все сделали правильно, вам потребуется держать в голове только самый верхний уровень.
  • Продолжайте переписывать программу. Переписывание программы часто приводит к более ясному дизайну. Но это имело бы смысл в любом случае: вам понадобится полностью понять программу, чтобы переписать ее, так что нет лучшего способа «загрузить» ее в голову.
  • Пишите читабельный код. Все программисты знают, что писать читабельный код это хорошая практика. Но вы сами являетесь самым главным читателем. Особенно в начале; прототип представляет собой разговор с самим собой. И когда вы пишите для себя у вас другие приоритеты. Если вы пишите для кого-то, вы можете захотеть не писать слишком «плотно». Некоторые части программы могут быть легче для понимания, если вы «развернете» код, как в учебнике. Тогда как если вы пишите, чтобы иметь возможность быстро «загрузить» программу в голову, лучшим может быть писать «плотно».
  • Работайте небольшими группами. Когда вы ловко обращаетесь с программой в своей голове, ваше понимание часто останавливается на границе кода, который написали лично вы. Другие части программы вы не понимаете так же хорошо и, что более важно, не можете допускать такого же вольного обращения по отношению к ним. Так что чем меньше программистов, тем более глубоко проект может меняться. Если программист всего один, как это часто бывает в начале, вы можете выполнить самый радикальный редизайн.
  • Не допускайте нескольких человек к редактирования одного участка кода. Вы никогда не будете понимать чужой код так же хорошо как свой собственный. Не важно насколько внимательно вы прочли его, вы его только лишь прочли, а не написали. Так что если участок кода пишется несколькими авторами, никто из них не понимает его так, как это мог бы сделать единственный автор.И конечно вы не можете спокойно выполнять редизайн чего-то, над чем сейчас работают другие люди. Дело даже не в том, нужно или нет просить на это разрешение. Вы даже не позволяете себе думать о таких вещах. Редизайн кода несколькими авторами похоже на изменение законов; редизайн кода, у которого один автор похоже на поиск другой интерпретации неясной картины.

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

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

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

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

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

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

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

  • Популярное

23 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

> Якщо правильно спроектуватиПан теорехтетик?

Треба динамiчно завантажувати в моцк необхiднi функцii програми що потребують обробки в пам’ятi моску та розвантажувати уже оброленi функцii та кешувати важливi результати з попереднiх iтерацiй.

Необхідність завантажувати в моцк ВСЮ програму означає погану початкову архітектуру. Уявіть собі завантаження ВСЬОГО MS Office або ВСІЄЇ Visual Studio! Уявили? Сумніваюсь.Якщо правильно спроектувати — реалізація (точніше «кодання» ) буде набагато більш тривіальним процесом.Якщо під статтю підпадає якась міні-утилітка або алгоритм — це інша справа, але про серйозний софт тут явно не йдеться. Відповідно вислів «вся програма» поняття занадто глобальне враховуючи можливу глибину, ширину, граничні умови, комбінації...Взагалі — якісно одночасно можна вирішити тільки одну конкретну проблему (нехай вона і зачіпає всю програму) яка є конкретним куском програми (нехай двома, трьома але не цілою прогою).

При рассмотрении картины в целом однозначно решение будет более оптимальным и быстрым чем при декомпозиции на модули. Очевидно не все могут удерживать большие программы в голове целиком, но это уже вопрос таланта разработчика и размера программы, а не того что «декомпозиция» однозначно лучше, а статья «ЛМАО». Не стоит экстраполировать весь мир по своей личности и частным случаям практики;) Вероятно вы никогда не решали олимпиадные математические задачи...

Цікаво, автор знайомий зі словом «декомпозиція» і з поняттям «модульне тестування»? Якщо так, то для чого тримати щось в голові крім маленької функціональної частинки над якою зараз йде робота?! Відповідно

Вы удерживаете всю программу в голове и вы можете манипулировать ее по своему желанию.

не вартує коментарів / доцільності читати текст до кінця.Короткий підсумок публікації = ЛМАО

Сэр ремесленник или просто никогда не ваял ничего стоящего?; -P> Кроме програмного кода есть множество прекрассных вещей!!! Да, но и программирование может быть прекрасно. Просто всему стоит знать меру.

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

Спасибо. Покрутил так и сяк, но идти на paulgraham было уже вломм.:)

Миша: в оригинале «a market as a degenerate case». Возможно, стоило написать «свободный рынок», чтобы не было путаницы.

Макс, там упоминается «рынок» — если в оригинале был bazaar, а не market, то лучше «базар», это типа ключевое слово получается. [b] Alex [/b] > я ходил на семинары по [...] психологии> нужно себя искуственно [...] будет само собой... Без принужденийОтчёркнутого достаточно, или на этих семинарах конкретно пудрили мозги? Могу поделиться другим вариантом — не беритесь за неинтересную вам работу. Вообще. При этом либо в этом мире полно нужной другим и интересной, либо пора расширять свой кругозор.Проверено на себе, вместе с практикой «я не собираюсь лишний раз менять работу, но не боюсь это делать» — до сих пор приводит только к положительным результатам: зарабатываю как минимум не меньше, а в итоге больше, и главное — получается заниматься чем-то интересным.Тут уже другая крайность оказывается опасной — уработаться или разорваться, если сильно интересно слишком много всего:) > И не нужно делать из себя робота...Да вот на таких тренингах да семинарах и делают именно биороботов. Одна из наиболее характерных черт — привитие веры в себя, свои способности и дальше «мы их прокачаем». Итог видан много раз (и, кстати, нередки самоубийства). [b] Вячеслав Колдовский [/b] > кто-то говорил, что разница между умным, но бедным и умным богатымЗдесь есть нюанс: по второй дорожке несложно превратиться в богатого самодура, а вот этого некоторым и не хотелось бы.Мне кажется, что там есть граница между теми, кто становится и кто умудряется быть при богатстве, но не вляпавшись во все тяжкие — и она в смысле делаемого, «для себя» оно («против других») или «для других». Не знаю, как это более по-другому сказать.

Статья очень правильная — как неожиданные, так и ожидаемые перерывы в работе катастрофически снижают производительность. И вопрос не в том, используется ООД или нет — как правило ломать голову приходится над достаточно сложными вещами, независящими от используемых подходов при разработке.Мой преподаватель высшей математики — доктор наук, профессор, который очень сильно любил эту науку говорил, что если хочешь решить задачу, то надо уметь концентрироваться на ней, непрерывно целыми днями думать только о ней — тогда рано или поздно решение появится.Кстати, хочу добавить по поводу концентрирования — научиться концентрироваться на задаче можно, даже если она не будет интересной. Ключевое слово здесь — «научиться». Человек, который умеет это делать готов работать даже над неинтересной задачей, если осознает, что она важна. Кажется, кто-то говорил, что разница между умным, но бедным и умным богатым состоит в том, что первый занимается только тем, что ему интересно, а второй — готов заставить делать себя даже неинтересные, но важные вещи.Хотя, конечно, не спорю, научиться все нужные задачи видеть интересными — наверное, самый лучший вариант, вот только сдается мне, что задачка эта посложнее будет, чем просто не лениться и заставлять себя работать:)

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

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

Очень точное описание, хотя как говорит СВ у всех по разному... Да и задачи разные бывают. Некоторые действительно только писать надо.Хорошая статья!

Хорошая статья. Примеряя на себя — почти все подходит: -).Но только насчет длительных периодов программирования по 12−18 часов — у меня например, наоборот часто выходит — не вставая за компом могу только часа 1.5−2 — обязательно надо встать, походить, чайку попить -, а потом возвращаюсь к проблеме — и как бы «свежим взглядом» осматриваю написанное за последний заход — очень часто нахожу какие-то улучшения или более изящный ход. Но это только когда «креатив» прет — когда рутина (уже все понятно в голове и в кодах задел сделан — что куда и как — осталось недостающий код повбивать да и отладить его грамотно) — так можно и 6−8 часов не вставать: -).

Появилась возможность сравнить два перевода и коменты к ним. Сравниваем: $self$thisДолжен признать, что это, по моему мнению два оригинальных перевода. Перевод Макса мне больше нравится.

Да действительно, порой помнишь не только имена всех ключевых переменных, обьектов и их аттрибутов, но и несколько ключевых справочников из дб, практически наизусть:) Ну, а насчет советов... Так их и так все знают. И в любой литературе по проектированию встречаются все без исключения.В общем повторенье — мать ученья

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

5+! Статья из серии «познай себя, разработчик софта». Я бы трактовал"Еще более удивительно количество официально одобренных проектов, которым удается нарушить все восемь пунктов"как "Еще более удивительно количество официально УСПЕШНЫХ проектов, которым ЯКОБЫ удается нарушить все восемь пунктов«в том смысле, что некоторые ПМы думают что все получилось благодаря следованию некоторому установленному процессу и жестким правилам, хотя на самом деле все получилось потому, что группе девелоперов удалось «выполнить все восемь пунктов благодаря случайности».

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

А насчет программистов — я бы посоветовал еще посмотреть (тем, кто еще не видел) доклад Ашманова на РИТ 2007. С более, чем 80% из того, что он сказал там — я согласен и очень часто так и есть и дело не в том, что программисту не дают «подумать»...

Не знаю. Я бы не рекомендовал программировать больше 8 часов в день — выходит слишком много ошибок в результате — лучше писать меньше, но с меньшим количеством ошибок.

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

Здається навпаки відбувається набагато частіше (чи це тільки в Україні?).

Хорошая статья, бывает проблема к концу рабочего дня не решена, но все равно потом ходишь еще часа 3 в голове программируешь:) Как обычно решение приходит на утро.

Подписаться на комментарии