Хороший разработчик мудр, а не гениален

Автор оригинала: Ravi Shankar Rajan
  • Перевод


Одним из самых важных уроков, которые я постиг в качестве разработчика 15 лет назад, была эта простая мысль:


Хороший код выразителен, а не впечатляющ.

Я помню, как услышав это спросил «А в чём разница?», и получил ответ.


«Выразительный» — понятный, однозначный и конкретный. А раз так, написание выразительного кода потребует работы с конкретной задачей. Вложение сил и времени в его создание служит конкретной цели, а результат соответствует ожиданию.


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


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


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


Программирование — не работа в ЦРУ, вам не нужно быть смекалистым.

И мудрые разработчики не делают ничего смекалистого. Они пишут скучный и простой код, который легко понять. Ни больше, ни меньше.




Вот ещё несколько принципов мудрых разработчиков.



Они предпочитают простоту


Мартин Фаулер однажды сказал:


Любой дурак может писать код понятный компьютеру. Хороший разработчик пишет код понятный человеку.

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


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


Когда эго начинает потихоньку вас искушать во время программирования, спрашивайте себя: «Если я вернусь к работе с этим кодом через 2 месяца, смогу ли я вспомнить, что конкретно тут происходит?» Если ответ — «да», то дерзайте. Помните, однако, о своих коллегах, которым когда-нибудь придётся с этим кодом работать.


Код — он как анекдот. Если его нужно объяснять, он плох.

Они знают, когда (не)нужно оптимизировать код


Эдсгер Дейкстра однажды верно заметил:


Хороший разработчик сосредоточивается на том ДЛЯ ЧЕГО, а не на том С ПОМОЩЬЮ ЧЕГО при написании кода.

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


Но прежде чем начать что-то улучшать, они следуют золотому правилу «не навреди».


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


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


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

Они предпочитают использовать, а не создавать код


Вик Гундотра попал в яблочко, как-то сказав:


Вы начинаете с написания кода. Я начинаю с поиска решения.

И мудрые разработчики следуют его примеру. Они начинают с поиска уже готового кода. Хотя некоторым и кажется, что они-то сейчас всё сделают с нуля «как правильно», большинство заканчивает банальным изобретением велосипеда.


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


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


Они стараются быть лучше


Аристотель сказал однажды:


Если вы работаете над чем-то, что уже умеете, вы не станете лучше.

Мудрые разработчики стараются усовершенствовать себя, а точнее свой код при каждой возможности. Они достаточно скромны, чтобы сознавать, что свой лучший код они ещё не создали.


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


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


Они не боятся просить помощи


Сократ произнёс:


Если бы мы постоянно помогали друг другу, никому бы не понадобилась удача.

Как разработчикам, нам нравится думать о себе как об умных людях. К тому же, среди нас и правда есть гении. Но мы так же склонны считать, что должны знать всё на свете. И правда, кому приятно сказать перед коллегами: «Я не знаю»? Кто захочет признаться, что новая технология для него — набор иероглифов?


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


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


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


Как однажды заметила Кюбра Саит:


Положительные изменения начинаются с вопросов.

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    +2

    Статья хорошая, но как это бывает с подобными статьями — в них не бывает примеров кода. А потому выглядит достаточно неконкретно. Поэтому мудрость приходится постигать набивая собственные шишки. (

    • НЛО прилетело и опубликовало эту надпись здесь
      +7
      По поводу признания своего незнания и просьбы подсказать — тут большую роль играет человеческий фактор. Пример прям с моей работы — у нас есть ведущий программист и начальник отдела. Они много знают и могут подсказать с решением, и объяснить. Но! Но сначала ты пройдёшь через насмешки. Возможно они и не со злым умыслом «поглумятся» над твоим незнанием, но осадочек это оставит на душе. И в следующий раз спросить у них помощи — будет последним, а не первым, в списке поиска решения.
        +4

        С одной стороны это боль для новичка.
        Даже если новичку 35 лет и он пришел из веб который как цирк с конями (js,php,webpack,babel) в DataAnalyse с R/python/Haskell или JavaEE с Spring.


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

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

          Только часто она решена в виде стороннего коробочного софта или еще лучше в виде SaaS сервиса и то и другое стоит как крыло от боинга, первое стоит так сразу а второе скрывает свои затраты размывая их по времени...

            0

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

            +2
            Google Driven Development! :-)
              0
              А ведь почему бы и не парадигма. Лет через сто сколько будет уже написано кода) И хорошего и плохого, но он одинаково полезен, я считаю
                –1
                Скорee Full StackOverflow Developer.
                  –1
                  Это типа «никаких новых фесбуков гуглов»? все уже написано, и нефиг напрягаться, просто погугли?

                  Печальненько.
                –1
                Вот как раз только подготовил свой вариант на эту тему.
                  +1
                  > Сократ произнёс: Если бы мы постоянно помогали друг другу, никому бы не понадобилась удача.

                  что-то не нахожу источника
                    0

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

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

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