Понимание собственного кода

    Перевод статьи Эли Бендерски — Understanding your own code.

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

    Позвольте мне немного прояснить мое мнение по этому поводу: неспособность понять код, написанный неделю назад или год назад, абсолютно недопустима для профессионального программиста. Так как я это сказал, то позвольте мне объяснить. Мой серьезный опыт в области программирования уже около 15 лет. И в какой-то момент (довольно рано), я освоил некоторые практики, которые использую и по сегодняшний день. Я до сих пор легко могу понять код, который написал год назад, два года назад и даже двенадцать лет назад. Код, написанный на различных языках и охватывающий различные области. Алгоритмы, парсеры, Web-приложения, встроенные контроллеры, скрипты, линкеры и еще много чего в этом роде. Даже если я смотрю на более ранний код, который мне более трудно понять, то все равно могу распознать проявление некоторых общих особенностей.

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

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

    Было бы неправильным завершить этот пост даже не попытавшись объяснить, как такой подвиг может быть достигнут. Честно говоря, это не так просто описать словами, но я все же попробую.

    Я уверен, что такой же трюк используют писатели (и, вероятно, представители других творческих профессий). Сразу после того, как написали кусок кода (чем меньше, тем лучше), Вы должны остановиться и оценить его читабельность и разборчивость. Читайте и перечитывайте его несколько раз. Постарайтесь отстраниться от понимания проблемы, представляя, что кто-то читает этот код без того полезного контекста, который уже есть у Вас в голове, потому что Вы пишете этот код. Поймет ли этот человек написанное? Если нет, то почему? Не стесняйтесь использовать трюки “читабельного кода” из таких книг, как “Code Complete”, пока Вы не будете уверены, что код понятен.

    И как только будете довольны результатом, перечитайте его еще раз. И еще раз через несколько дней. Этот процесс напоминает мне написание более глубоких научных статей для этого блога. Сначала я пишу текст, потом перечитываю двадцать предложений и переписываю пять из них. Часто это справедливо и для кода, который я пишу. Совершенство может быть либо подаренным Вам через гены, либо через безжалостную практику и повторение. Так, как я не был одарен предыдущим я придерживаюсь последнего.

    И наконец, бесстрашно рефакторьте и улучшайте код. Если Вы столкнулись с куском кода, который мог бы быть яснее, то перепишете его яснее. Улучшение качества кода является одной из тонких побочных задач нашей профессии. Это то, пользу от чего часто нельзя оценить количественно, но после того, как поучаствуете в многолетних мега проектах с большой командой, понимание этого придет к Вам подсознательно.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 21

      –20
      Готов платить за то, что программист просто пишет свой код, до тек пор пока код работает.
        +3
        Ведь на самом деле есть такие компании, готовые платить за просто работающий код. Работал в такой.

        Проблемы возникали крайне редко и их с лихвой покрывала экономическая выгода от такого подхода к разработке. Действительно, кода было очень много. Люди работали сразу над несколькими проектами и держали всё это в голове. Главный (да что там, практически единственный) критерий качества — работает и покрыт тестами.
        Лично для меня, как «творца», ненадобность красивых архитектурных решений была одной из причин заняться другими проектами. Но с точки зрения эффективности, думаю, это работало.

        А иногда вообще дешевле и проще slap shit together and deploy силами неопытных разработчиков, которые просто не умеют делать сразу красиво, «проверить бизнес-модель» и потом всё заново переписать.
        +19
        Очередная статья призыв писать хороший код. 90% процентов объяснения как это важно, что и само собой понятно, и несколько строк, как это может быть достигнуто.

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

        Это можно делать, когда у вас куча времени. Если у программиста достаточно времени, чтобы перечитывать свой код по несколько раз, то проблемы удобства чтения кода никогда не возникнет, так как любой программист любит перерефакторивать свой код, как только это становится возможным. Только очень редко в реальных проектах достаточно времени на такие вещи. И в таком случае у программиста должен быть инстинкт написания хорошего кода без оглядки, без продумывания по десять минут названия функции.
          +5
          Если у программиста нет времени перечитать свой код, то у проекта большие проблемы.
            +11
            Мне вот тоже очень непонятно становится, когда я сталкиваюсь с образом программиста, вся работа которого в том, чтобы бешено стучать по клавиатуре. Для меня программист — это инженер. Представьте себе инженера, который говорит «мне некогда смотреть, что я тут начертил, мне надо дальше чертить». Да работа инженера вообще не чертить (писать код) — работа инженера в том, чтобы думать. Придумывать и проектировать технические решения. Код — как и чертеж, как техническая спецификация — это описание результата работы по проектированию, а не сама работа. Сама работа делается в тот момент, когда человек в полоток смотрит отрешенным взглядом.

            Конечно, не все думают смотря в потолок. Кому-то (мне в том числе) удобнее думать уже в процессе написания «отчета о проделанной работе», вперемешку с его написанием — так, зачастую, проще фокусироваться. Но это не отменяет того факта, что бОльшая часть времени уходит на раздумья, и лишь меньшая — на сам процесс описания результата. Даже когда я был джуниором на первой своей работе, и задачи у меня были самые наипростейшие — даже тогда где-то треть-половина времени уходила на анализ/проектирование/планирование. А я ведь и язык еще знал фигово, да и слепым методом набора не владел, да и тогдашние IDE нынешним не чета — т.е. была куча чисто технических причин, почему написание кода требовало тогда больше времени. Со временем задачи становятся все сложнее — а код пишется все легче. Сейчас, думаю, процентов 80-90 времени моей работы это именно придумывание решения, увязывание его с контекстом. Мне кажется, это совершенно естественный процесс — за что человеку с опытом платят больше, за умение быстрее текст набирать или за умение глубже думать? Если за второе, то очевидно, что доля этого, второго, в работе должна повышаться — разумно больше делать то, за что больше платят ведь?

            И вот теперь такой вопрос: если каждый час когда я пишу «отчет от проделанном проектировании» (==код) стоит 8-9 часов проектирования — так, может, имеет смысл потратить чуть больше времени на то, чтобы этот «отчет» был написан ясным и понятным языком и аккуратно оформлен, а? Как-никак стоимость-то у него немаленькая…
              0
              Я только за, но я пока не встречал работодателей, которые бы давали на это время. Возможно, это проблема моего личного опыта, но пока мне везде приходилось в бешеном темпе стучать по клавишам.
                +1
                Не бешено стучать по клавиатуре, а срочно выкатить результат. Бывает такое, что твой начальник мечется по офису и каждые две минуты спрашивает, когда будет готово. Ему всё равно что и как ты там напишешь — главное чтоб работало, хотя бы как нибудь. А если тебе это так важно, то переписывать и рефакторить будешь «потом», когда время появится. Во-первых, такая работа отбивает желание в этот код даже заглядывать, а во-вторых «потом» время так и не появляется, а потому в следующий раз ты, скорее всего, правишь этот код в аналогичной ситуации.

                Примерно так, в таких ситуациях, может рождаться самый страшный вид говнокода — спагетти: в условиях постоянного цейнтнота некоторые люди выбирают самое простое быстрое из возможных решений. Именно так появляется SQL в GUI. Именно так появляется GUI посередине сетевого протокола.
                  +1
                  Согласен, но я тут поразмыслил и пришел к заключению, что от многих ошибок в таком случае спасает правильная архитектура. Если вначале проекта много времени потрачено на правильное планирование архитектуры, то потом вы все же будете ей следовать. Да, узкие места будут, кое-где будет дублирование, легкий говнокод и пр., но все же это спасет от таких вот фундаментальных ошибок. Так что, в проекте главное, чтобы был хороший тимлид для придумывания архитектуры и разруливания узких мест, и тогда график может быть сколько угодно сжатый, качество кода все-равно будет кое-как поддерживаться.
              +8
              Мой серьезный опыт в области программирования уже около 15 лет… Я до сих пор легко могу понять код, который написал… двенадцать лет назад.


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


                1. Противно не значит непонятно
                2. Совершенно не факт что должно быть противно.

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

                … уж точно не должно хотеться использовать снова

                Если какая-то задача уже хорошо была решена 10 лет назад — зачем решать её еще раз, когда можно использовать уже готовое решение? Особенно если она решена понятно и при необходимости это решение легко можно будет поправить под новые ньюансы.
                +12
                Мне всегда понятно, что я написал какое угодно количество времени назад, но не всегда, почему я написал именно так. Какие-то вещи, которые кажутся очевидными в контексте и не требующими комментариев, потом иногда совершенно забываются, к сожалению.
                  +5
                  Кстати, оптимальные комментарии — это как раз комментарии про «почему».
                • UFO just landed and posted this here
                    +7
                    Извините, но «перевод» ужасен, а тема посредственна.
                      0
                      Буду признателен, если укажите на ошибки. Большая просьба в ЛС.
                      +3
                      Попробую встать на защиту и обосновать гордость программиста, которого знает Эли Бендерски.

                      Код, который мы читаем, можно классифицировать:

                      1) Чужой код.
                      2) Код, который я написал сейчас.
                      3) Код, который я написал давно.

                      Чужой код оценить легко. Либо все понятно и красиво, либо я написал бы лучше (чаще всего второе). Мы легко видим недостатки чужого кода: архитектурные оплошности, неудачные идентификаторы, непонятные комментарии, и т.д.

                      В нашем коде между 2 и 3 пунктом лежит временной интервал. Насколько он длинен? Должно пройти время, пока мы забудем то, что писали, и будем относиться к коду как к чужому. Выполнять рефакторинг можно будет тогда, и только тогда, когда произойдет отстранение от своего кода. До этого момента мы к своему коду относимся предвзято. Именно этим и гордится этот программист — тем, что он может беспристрастно анализировать свой код уже через неделю.
                        +1
                        Врядли вы сможете легко понять и прочитать код, который был написан вами 12 лет назад т.к. ваши умения, навыки, стиль и техника, которые вы используете значительно изменились за такой большой промежуток времени.
                          0
                          Изменились, но не в худшую сторону.
                          +1
                          Если у вас, дорогой читатель, достаточно времени, можете попробовать метод Франклина (о котором вроде бы даже упоминали на хабре, вот только лень искать). Заключается метод в том, что предмет творческого труда — в данном случае код — оставляют в темном сухом месте на 3 дня. По прошествию этого времени, предмет извлекается из места хранения и внимательно, с критической точки зрения, изучается. При выявлении непотребщины — исправить и повторить итерацию.
                          Чем лучше простого самоконтроля сразу по написанию кода — «замыленый взгляд» успевает отдохнуть, а мозг — выработать на уровне подсознания альтернативный подход к решению проблемы.
                            0
                            Или забыть о таковой. Время для выработки решения без забывания подбирается под каждого программиста индивидуально.
                            0
                            Читать свой код десятилетней давности вредно. У меня в нём обнаружилась давно забытая игрушка, на которую в итоге убил весь вечер.
                            А про понимание кода — было одно место, в котором разобраться сразу не удалось. Программа, судя по всему. решала японские кроссворды нечёткой логикой — так центральной функции алгоритма по своему коду мне понять не удалось. То ли там ошибка, то ли я тогда был умнее. В остальном читается нормально…

                            Only users with full accounts can post comments. Log in, please.