Как писать хороший и понятный код: 3 простых способа для программиста



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

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

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

    Skillbox рекомендует: Двухлетний практический курс «Я — веб-разработчик PRO».

    Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

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

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

    Порой вам нужна… резиновая уточка

    Концепция резиновой уточки впервые была предложена Дином Паркером в его посте об ораторском искусстве. Паркер говорит о том, что для того, чтобы стать хорошим оратором, нужно постоянно упражняться в произнесении речей. И лучший способ избавиться от страха перед слушателями, одновременно обучаясь выражать свои мысли складно и внятно, — это выступать во время «ораторских тренингов» перед резиновой уточкой. Она как раз и заменяет собой слушателей.

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

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

    Cоздание многократно используемых компонентов — не перманентная необходимость

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

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

    You Aren’t Gonna Need It

    Оригинальная английская аксиома звучит как “YouArentGonnaNeedIt (YAGNI)”. Понимать это следует следующим образом: «Используйте определенные инструменты лишь тогда, когда вы в них действительно нуждаетесь, а не просто думаете, что они вам могут пригодиться».

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

    Упрощайте все до необходимого минимума

    У «экстремального программирования» есть два золотых правила для создания простого кода.

    Во-первых, самый простой способ ввести новую функцию — сделать так, чтобы она «просто работала». Не нужно создавать шикарные суперструктуры, нечто высокотехничное. Просто сделайте так, чтобы функция работала. Но не забудьте и того, что код должен пройти Unit Tests.

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

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

    Когда вы застрянете в следующий раз, попробуйте уточку

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

    Если вы где-то застряли и ничего не работает, попробуйте уточку.

    Можно не представлять ее себе, а купить. И неважно, будет ли это обычная уточка для ванной или утка-пират, — главное, чтобы вам было комфортно с ней, чтобы она соответствовала вашей индивидуальности.

    И после этого можно начать разговор с уточкой. Говорите с ней, задавайте вопросы, объясните вслух проблему, с которой вы работаете. Результат вас удивит.

    Крис Пайн был прав, говоря: «Программирование — это не то, что вы знаете, это то, что вы можете узнать».
    Skillbox
    381,00
    Онлайн-университет профессий будущего
    Поделиться публикацией

    Комментарии 22

      +7
      You Aren’t Gonna Need It

      Категорически нет.
      В 90% случаев возможности заложенные код лично мне потом упрощали жизнь.
      Исключение — прототип. И то, надо быть точно уверенным что прототип потом не пойдет в продакшн.
      Задел на будущее — гарантия успеха. Иначе потом придется лоскутное одеяло шить.

      <sarcasm=«on»>
      Теперь понятно почему индусский код такой дешевый и такой плохой.
      <sarcasm=«off»>
        +2
        YAGNI работает именно тогда, когда нет объяснений, почему он не должен работать. Проще говоря, если некий абстрактный джун в вакууме не может объяснить, зачем ему та или иная зависимость или конструкция в коде — её следует выкинуть без сожалений. Если может — уже совсем другое дело.

        А по мере роста опыта разработки программист так или иначе начинает закладывать больше потенциала на вырост. И при этом может прекрасно объяснить, почему это всё нужно.
          +1
          В тексте написано не так.
          когда вы в них действительно нуждаетесь, а не просто думаете, что они вам могут пригодиться
            0
            Скажем так, отквоченное вами можно читать и по-вашему, и по-моему. Вопрос в точной трактовке «нуждаетесь» и «пригодится».
              0
              нуждаетесь — это здесь и сейчас.
              То что может пригодится позднее очевидно к классу необходимого не относится. В силу определения.
                0
                нуждаетесь — это здесь и сейчас.

                Но это очевидно неправда. Нуждаться можно и в будущем.

                То что может пригодится позднее очевидно к классу необходимого не относится.

                То, что может пригодиться — это такое, в чем нет полной уверенности на некотором уровне (разработчика, ПМ, итд). Со всеми вытекающими проблемами, когда на разных уровнях уверенность различная.
                  –2
                  Нуждаться можно и в будущем.

                  Нельзя. Это глагол настоящего времени.
                  dic.academic.ru/dic.nsf/dmitriev/2901

                  В любом случае если речь идет о «то в чем вы будете нуждаться позднее», то так и писать/переводить надо было.
                  Сейчас значение текста совершенно не такое.
                    0
                    Ну да, я открыл оригинал, и полностью с вами согласен — там действительно о том, что если сейчас не надо, то и не делайте. В таком разрезе — в топку это.
                      +1

                      В оригинале YAGNI, а не YANI, то есть как раз однозначное указание на будущее время.

                        –1
                        Указание на будущее время оригинала — оно как раз о том, что то, что вам понадобится в будущем — не имеет значения сейчас. Весь XP — он про то, чтоб выкатывать что-то показывабельное максимально быстро, про качество и стройность кода там речь идёт только в формате «выкатили? теперь можно и порефакторить».
                          –1
                          Указание на будущее время оригинала — оно как раз о том, что то, что вам понадобится в будущем — не имеет значения сейчас.

                          Тогда как раз на будущее бы никто не указывал.

              0

              Если вы можете обосновать, почему оно вам потом понадобится, то это укладывается в "нуждается", которое изначально подразумевалось.
              Смысл именно в том, чтобы было конкретное четкое объяснение — зачем.

                +1
                Ну во первых не «понадобится», а «скорее всего понадобится».
                А «скорее всего понадобится» уж точно под нужду не попадает.
                Ну и четкое объяснение всегда почти одно и тоже «когда захотим Х — бьудет проще сделать.»
                  0
                  Ну и четкое объяснение всегда почти одно и тоже «когда захотим Х — бьудет проще сделать.»

                  Так это как раз не объяснение, если только вы не обоснуете, что вы действительно захотите Х (ну, то есть вам будет нужно Х, "хочу" — очевидно, не причина ни для чего), причем в актуальном горизонте планирования. Если никаких причин захотеть Х сформулировать не удастся — отменить, ведь почти наверняка вы в реальности Х не захотите.

                    0
                    Я в реальности не захочу ничего. Захочет заказчик.
                      0

                      Ну вот поскольку он, почти наверняка, не захочет — то делать заранее не надо.

                        0
                        В этом и заключается одно из преимуществ квалификации — знать за заказчика что он захочет.
                          0

                          Тогда, очевидно, вы сможете назвать причину, почему это надо сделать. Не может же он что-то захотеть просто так? Есть причина.

                            0
                            Ну да. Буду сидеть над каждой строчкой кода и обдумывать вероятность.
                            Просто есть хорошие решение учитывающие будущие правки и есть плохие решения для «здесь и сейчас».
                              0
                              Буду сидеть над каждой строчкой кода и обдумывать вероятность.

                              Зачем? При чем тут каждая строчка, если мы говорим об архитектурных вопросах?


                              Просто есть хорошие решение учитывающие будущие правки

                              И, конечно, все эти решения можно без труда обосновать.

            +1
            В 90% случаев вам вероятно сообщали о будущих возможностях. YAGNI как раз говорит нам о том что не надо выдумывать то чем бизнес никогда не воспользуется.
            Задел на будущее делается по ТЗ и роадмапу. А задумывать к примеру алиэкспресс по ТЗ обычного интернет-магазина это такая себе идея :)
              0
              В 90% случаев вам вероятно сообщали о будущих возможностях.

              Конечно же нет.
              Заказчик не знает нифига. А для меня вполне понятно что и почему он захочет.
              Нормальное ТЗ и нормальный RoadMap — это из мира фантазий. Как правило заказчики «передумывают» с завидной регулярностью.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое