Отраслевое финтех СМИ
129,81
рейтинг
9 апреля 2015 в 15:22

Разработка → 10 заповедей программирования без эго перевод

image«Программирование без эго» — перевод понятия egoless programming. Смысл в том, что разработчик осознанно отодвигает эго на второй план ради эффективности в работе. При разработке Web-payment.ru — сайта о платежных системах с каталогами и мониторингом обменников — мы стараемся руководствоваться этими принципами. Если кто-то благодаря этому посту тоже начнет применять их в своем проекте, мы будем очень рады, ведь они помогают избежать конфликтов и несут в себе добро. Перевод и редактура moigagoo.

О программировании Стивен начал говорить с отцом за 2 недели до его смерти. Стивену было 22, он изучал графдизайн в колледже и почти получил степень бакалавра. Его отцу было 62 — больше, чем большинству отцов. Когда он только начинал программировать в Теннессийском техническом университете в 60-е, то писал код на Фортране на перфокартах. Знал он очень много.

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

Когда Стивен приехал домой на каникулы, отец рассказал ему про 10 заповедей программирования без эго. Он распечатал их, и вдвоем со Стивеном они обсудили каждый пункт. Из-за внезапной смерти отца Заповеди стали одной из немногих программистских тем, которые Стивен успел обсудить вместе с ним. Возможно, именно поэтому они ему так запомнились.

Итак, вот 10 заповедей программирования без эго, из книги 1971 года «Психология программирования»:

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

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

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

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

  5. Относитесь к людям, которые знают меньше вас, с уважением, почтением и терпением. Люди, напрямую не связанные с IT, но которым часто приходится иметь дело с разработчиками, считают нас в лучшем случае зазнайками, а в худшем — нытиками. Не кормите стереотипы гневом и нетерпеливостью.

  6. Единственное, что в мире постоянно — это перемены. Будьте готовы к переменам и принимайте их с улыбкой. Взгляните на изменения в требованиях, платформе или инструменте как на вызов, а не как на неудобство, которое надо побороть.

  7. Единственный истинный авторитет дают знания, а не положение. Знание порождает авторитет, а авторитет порождает уважение. Хотите уважения в среде, где нет места эго — культивируйте знания.

  8. Боритесь за то, во что верите, но непринужденно признавайте поражение. Поймите, что иногда ваши идеи будут отклонять. Даже если вы и правы, не надо мстить и говорить «А я предупреждал, что так будет». Никогда не превращайте отвергнутые идеи в мученический стон или боевой клич.

  9. Не становитесь «тем кодером в углу». Не будьте человеком в темном кабинете, который выходит только за колой. Кодера в углу не видно, с ним сложно связаться, его сложно контролировать. У такого человека нет голоса в открытой, кооперативной среде. Включайтесь в беседы и будьте частью сообщества своего офиса.

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

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

Чтобы узнать больше об отце Стивена, читайте книгу Вклад Фрэнка Буша в IT-профессию, составленную его коллегами по ТТУ.
Автор: @vladislavPetushkov Stephen Wyatt Bush
Web-payment.ru
рейтинг 129,81
Отраслевое финтех СМИ
Реклама помогает поддерживать и развивать наши сервисы

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

Комментарии (37)

  • +11
    Правило №13 пишите код так, будто бы его будет читать крайне неуравновешенный и жестокий человек, который знает где вы живёте, знает код от домофона и умеет открывать замки.
    • +2
      Ну а так так многие люди сочли бы разумной стратегией работы с «крайне неуравновешенным и жестоким человеком, который знает код от домофона и умеет открывать замки» отказ от такой работы, то это правило преобразуется до еще более простого — не пишите код.

      • 0
        тогда уж еще проще: "не пишите"
        • 0
          Нет, писать надо. Писать хорошо, а хорошо писать ещё лучше. ©
          • –3
            Ударение на каком слоге?
        • +1
          Не делайте
    • +4
      Пишите код так, будто бы его будет читать крайне неуравновешенный и жестокий человек, который знает где вы живёте, знает код от домофона и умеет открывать замки


      Если вдуматься, то ничего хорошего в этом совете нет.
    • +1
      Всегда бесил этот «перл» своей бессмысленностью. Псевдоостроумная версия фразы «Пишите код хорошо», которая не дает ровным счетом никакого совета, как именно надо писать.
  • –20
    Стивен стал «более хорошим программистом», а его подруга Света — более лучше одеваться.
    • +12
      Если на то пошло, то «хороший» — это не сравнительная форма, поэтому «более хороший» — вполне легальная конструкция. «Лучше» — это сравнительная форма от «Хорошо» и это, вообще-то, наречие, так что здесь двойной промах.
      • +5
        Да-да, я еще подумал об этой фразе и понял, что не прав. Но все это предложение с более хорошим как-то режет слух. Похоже, что только мне.
        В оригинале там It has already helped me be a better programmer. Он уже помог Стивену стать лучше в программировании, как вариант.
        • –2
          не, не вариант, совсем колхозно смотрится
        • +9
          Я не понимаю… ЗАЧЕМ пытаться сохранить конструкцию максимально близко к оригиналу? Можно же перефразировать:
          Благодаря этому списку Стивен достиг новых высот в программировании.
          или
          С помощью этого списка Стивен улучшил свой навык программирования.
          • 0
            1. Ненужная «художественность» 2. Опять кривое калькирование

            Единственный нормальный вариант «Стивен стал лучше программировать/писать код». «Лучше в программировании» — кривость по типу «сумки от Армани»
            • 0
              Ваш вариант тоже плох — на причину ничто не указывает… А с причиной — всё будет калькированием…
              • 0
                Я просто опустил эту часть, потому что она неизменна: «Благодаря этому списку Стивен стал лучше программировать/писать код». Однако это привело к написанию двух лишних комментариев, значит зря опустил.
                • 0
                  Именно поэтому перевод — это весьма не просто… И после технического перевода лучше проходиться и слегка «охудожествлять».
      • 0
        К.О. говорит, что это дословная цитата из одного видео.
        • 0
          [спасибо, Капитан Очевидность]
          • 0
            О, вот ещё одному человеку нечего делать, как было мне.
            После прочтения комментария на который я отвечал, мне показалось, что его автор протестует против использования «более лучше одеваться». Спустя некоторое время я конечно понял, что протест был против сравнения «стал более хорошим программистом» с «более лучше одеваться», но комментарий менять было уже поздно. На вашей картинке КО можно заменить на Слоупока.
  • +6
    Наш препод на 1м курсе любил говорить примерно так: «когда пишете код, пишите его так, чтобы ваш сосед мог не только сдуть его у вас, но понять и объяснить каждую строчку, каждую функцию и процедуру...».
    При этом, в универе я делал (из эгоистичности) делал ровно обратное…
    • +3
      … а еще позже я понял что чтение кода это такой же навык как и написание, поэтому учитесь не только писать код но и читать любой даже самый самый плохой…
      • +2
        Часто чтение чужого кода, да и перечитывание своего занимает достаточно много времени. Поэтому понятно написанный код и умение читать код могут значительно увеличить производительность труда. (Капитан Очевидность гордился бы мной )
      • +2
        Черт, это же неизведанная область!
        Сейчас столько всего написано о том, как правильно писать хороший код, и практически ничего о том, как читать плохой. Срочно организовать курсы по чтению плохого кода и срубить денег.
  • +7
    Периодически встречаю подобные вещи и удивляюсь — зачем об этом говорить, если оно и так понятно?
    Ан нет, всё время забываю, что люди не такие, как я, что все разные и думают по разному.
    Согласен с правилами, спасибо за статью.
    • +3
      Аналогично. Я думал, что заповеди будут гораздо более жесткими. А так, если кто-то нарушает даже это — то ему следует задуматься, подходит ли его характер к выбранной профессии вообще.

      Тем не менее сама идея верная. Думаю, что заповеди надо ужесточать и добавить к ним следующее:

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

      2) Действие п.1 сохраняется даже в случае, если готовая библиотека стоит серьезных денег. Решение должно приниматься ответственным руководителем предприятия. Если вы простой разработчик — оставьте решение директору. Если вы одиночка и сам себе директор — считайте выгоду по деньгам и рискам, умножая в 2-3 раза оцениваемые временные затраты, а не исходя из тщеславия.

      3) Соблюдайте стандарты. Не изобретайте велосипед в виде форматов файлов, интерфейсов компонентов, протоколов обмена и т.п., если есть стандартные решения.
      • +4
        Программирование — не всегда бизнес. Ваши «заповеди» касаются чисто бизнеса и мало имеют отношения к программированию как таковому.
        • 0
          Профессиональные программисты, по определению, зарабатывают этой деятельностью себе на жизнь. Они прямо или косвенно продают результаты своего труда другим людям, а не только пользуются ими сами. А где есть продажа — там есть рынок. И там есть бизнес. Игнорировать его законы — это путь к неприятностям либо для себя, либо для работодателя.

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

          Ну, а если вы занимаетесь любительским программированием ради самого процесса — то там, конечно, никаких ограничений нет. Ваяйте в свое удовольствие что угодно и как угодно. Но я бы не сказал, что любительское программирование в настоящее время преобладает над профессиональным. Все-таки больше программ (и количественно, и качественно) разрабатывается профессионалами. Поэтому ваша фраза: «мало имеют отношения к программированию как таковому» не верна.
          • 0
            Создавать продукт и продавать его — две разные профессии. Обычно программист продает не результат труда, а труд.
            • 0
              Труд, который не приносит результатов, никому не нужен. Поэтому продается только тот труд, который их приносит — это раз. Во-вторых, некоторые программисты продают именно результаты труда (готовые продукты). В-третьих, если фирма, нанимающая программиста, получает прибыль за счет продажи его разработок — то речь идет о косвенной продаже результатов, о которой я в комментарии упомянул. Это справедливо и для случаев, когда программист разрабатывает продукты сугубо для внутреннего использования работодателя, если эти продукты как-то влияют на получение работодателем прибыли или грантов.
        • 0
          Цель чего-либо — конечный продукт, а программирование просто инструмент.

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

          В конечном счете, вся цель хорошего кода в в 90% заключается в том, чтобы сделать его дешевле в долгой перспективе.
      • +3
        П1. весьма спорный (если код не opensource или не крупной фирмы типа Oracle). На эти грабли неужели не наступали? Нужно сделать мелкое изменение или найден критичный баг, а производителя уже нет или он вас игнорирует или запрашивает безумные деньги за изменение/исправление бага… и т.д. и т.п.
        А соотношение кода, например, 1/10 (1- стронняя библиотека, 10 — ваш код.)

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

        Так что не стоит из этого делать догму.
        • 0
          Если в проекте используется десятка два сторонних библиотек, то в 2-3 из них обязательно найдутся баги. Обычно просто неприятные, реже — критичные. Но про остальные библиотеки вы даже не вспомните — все время существования проекта они будут просто работать. Но в памяти останутся только библиотеки с багами.
      • 0
        Стороннюю библиотеку нужно брать всего лишь в двух случаях:

        1. Если вы можете сами написать ее — значит у вас займет меньше времени исправить готовую библиотеку, чем написать полностью свою.

        2. Если вы не можете сами написать ее — значит в написанной с нуля библиотеке будет больше ошибок, чем в уже готовой.
  • –5
    «Критикуйте код, а не людей. Будьте добры к людям, но не к коду»

    Когда человек в стопятьсотый раз пишет спагетти становится очень трудно сохранять доброту
    • +3
      Никто не обещал, что жизнь — это просто. Вам есть к чему стремиться.
  • +6
    0. Удаляйте! Лучший код — несуществующий код.

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

Самое читаемое Разработка