Что каждому разработчику следует знать с самого начала

Original author: Ryland Goldstein
  • Translation
Как разработчик, вы услышите много сумасшедших, невероятных теорий о значении «строк кода». Не верьте ни одной. Строки кода — нелепая метрика. В очень редких случаях она что-то говорит, обычно — ничего. Использование строк кода для принятия решений похоже на оценку качества книги по количеству страниц.

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

  • Код должен быть последовательным
  • Код должен быть информативным
  • Код должен быть хорошо документирован
  • Код должен использовать стабильные современные функции
  • Код не должен быть излишне сложным
  • Код не должен быть неэффективным (не пишите намеренно медленный код)

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

Языки не обязательно «хорошие» или «плохие»


Кроме php, конечно (шутка). Источник

Я вижу, что люди говорят такие вещи всё время:

  • C лучше X из-за производительности
  • Python лучше X из-за лаконичности
  • Haskell лучше X из-за инопланетян

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

Не поймите меня неправильно, между языками определённо есть различия. Просто практически не существует «негодных» языков (хотя есть много устаревших/мёртвых). У каждого языка свой уникальный набор компромиссов. В этом отношении они похожи на набор инструментов. Отвёртка может сделать то, что не может молоток, но кто-нибудь скажет, что отвёртка лучше молотка?

(Очевидно же, что молоток лучше)

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

Вот по порядку основные аспекты, которые, по-моему мнению, должны влиять на выбор языка (без конкретных метрик):

  • Плотность доступных онлайн-ресурсов (плотность StackOverflow)
  • Скорость развития
  • Предрасположенность к ошибкам
  • Качество и охват пакетной экосистемы (да, npm, речь о качестве)
  • Производительность (больше точек)
  • Возможность трудоустройства (извини, COBOL)

Некоторые важные факторы вне вашего влияния. Если вы работаете в области науки о данных, то реально нужно использовать Python, R или Scala (возможно, Java). Если это хобби-проект, используйте то, что вам нравится. У меня есть только одно неоспоримое правило. Я отказываюсь использовать языки, если большинство возможных проблем с этим языком не решены уже на StackOverflow. Дело не в том, что я не могу их решить, просто это не стоит времени.

Читать чужой код тяжело


Читать чужой код трудно. Роберт К. Мартин говорит об этом в «Чистом коде»: «На самом деле соотношение времени на чтение и написание кода, значительно превышает 10 к 1. Мы постоянно читаем старый код, когда стараемся написать новый. ...[Поэтому] то, что упрощает его чтение, упрощает и его написание».

Долгое время я полагал, что просто слаб в чтении чужого кода. Со временем я понял, что с этой проблемой ежедневно сталкивается почти каждый программист. Чтение чужого кода напоминает чтение текста на иностранном языке. Даже если вас устраивает выбор языка программирования автора кода, вам всё равно придётся приспосабливаться к различным стилям и вариантам архитектуры. Это также предполагает, что автор написал последовательный и надёжный код, что может быть правдой или нет. Это действительно трудно. Есть несколько вещей, которые мне ОЧЕНЬ помогли.

Ревью чужого кода значительно улучшит ваши навыки. За последние два года я сделал довольно много ревью для пул-реквестов на Github. С каждым новым я чувствую себя немного более уверенно в чтении чужого кода. Пул-реквесты GitHub особенно полезны по следующим причинам:

  • Здесь ревью можно проводить в любое время, достаточно найти проект с открытым исходным кодом, в который вы хотите внести свой вклад.
  • Чтение в ограниченном контексте (отдельная функция или баг).
  • Требуется внимание к деталям, что заставит вас оценить каждую строчку.

Второй приём, который поможет читать чужой код, немного более уникален. Это придуманная мной техника, и она действительно уменьшила количество времени, которое мне требуется, чтобы чувствовать себя комфортно в чужой кодовой базе. Посмотрев на стиль кода, который я хочу прочитать, я сначала открываю vi и начинаю писать код в таком же стиле. Когда вы пишете код в новом стиле, это также улучшает ваши навыки его чтения. Стиль станет менее чужеродным, когда вы сами испытали его. Даже если я просто смотрю случайный проект на Github, я по-быстрому применяю этот приём. Попробуйте сами.

Вы никогда не напишете «идеальный» код


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

Это то, о чём я раньше очень беспокоился. Как только я присоединился к команде, быстро стало понятно, что никто не пишет «идеальный» код. Но код, входящий в систему, почти всегда был «идеальным». Каким образом? Ответ: код-ревью.

Я работаю с командой действительно блестящих инженеров. Это одни из самых компетентных, уверенных в себе программистов, которых можно купить за деньги. У каждого члена нашей команды (включая меня) начнётся настоящая паническая атака, если кто-то когда-либо предложит закоммитить код без ревью. Даже если вы думаете, что вы следующий Билл Гейтс, вы обязательно будете делать ошибки. Я даже не говорю о логических ошибках, я говорю о опечатках, пропущенных символах. То, что ваш мозг просто не замечает. То, для чего нужен ещё одна пара глаз.

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

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

Работа программиста не означает 8 часов программирования в день


Это очень распространённый вопрос, но люди никогда не дают чёткого ответа. Сколько средний разработчик или «отличный» разработчик тратит на написание кода каждый день?

Очень немногие кодируют более четырёх часов в день

Не согласные с этим — либо исключения из правила, либо работают в компаниях, которые их слишком эксплуатируют. Программирование — это умственно истощающая, интенсивная задача. Совершенно неразумно ожидать, что кто-то будет писать код по 8 часов в день, пять дней в неделю. Бывают случаи, когда вам нужно уложиться в срок или сделать немного больше за сессию, но их немного и они встречаются редко. Когда я говорю «редко», я имею в виду почти никогда. Не допускайте рабочего процесса, который злоупотребляет вами и заставляет вас работать сверхурочно из-за плохого планирования/нехватки кадров.

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

Просто для ясности, я не предлагаю вам работать только четыре часа в день. Остальные четыре часа, как правило, лучше потратить на:

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

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

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

Similar posts

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

More

Comments 17

    +1
    Как разработчик, вы услышите много сумасшедших, невероятных теорий о значении «строк кода».

    Мне кажется, автор преувеличивает с самого начала. Я как разработчик, конечно, иногда что-то слышал про метрики, основанные на строчках кода, но уже только в контексте рассказов про то, какие в природе бывают идиотские метрики. Вживую в работающем ИТ-бизнесе не сталкивался ни разу, и не видел, кто бы сталкивался.
      0
      Безусловно это не основные метрики, а скорее дополнительные/косвенные.
      Больше кода — дольше читать и сложнее разбираться.
      Если исправление достаточно простого дефекта вместо 3-4 строк в одном файле требует изменений 5-6 строк кода в 10-ти файлах — то это вполне может быть поводом задуматься о рефакторинге, например.
      Сами по себе строки кода не так интересны, как необходимые на исправления затраты по времени и сложности работы (но это сложно считать).

      Строки, коммиты, изменения очень легко измерять, составлять всякие красивые отчёты и рисовать диаграммы. Некоторым нравится подобная бюрократия, она создаёт красивую картинку «контроля», ни одно одно изменение не прошло незамеченным, каждая строчка посчитана :)
        0
        А есть абстрактный программист Вася, который за эти две недели написал 10 строк кода, а за последующие два дня 500…
      0
      С самого начала чего? Профессии, проекта, жизни, устройства на работу? Какие только заманухи не напишут, чтобы народ зашёл почитать.
        +1
        В оригинале явного «самого начала» не было, но заголовок действительно «завлекательный»:
        What Every Developer Should Learn Early On

        «Чему каждому разработчику стоит научиться по-раньше» — не сильно лучше :)
        0
        Очень немногие кодируют более четырёх часов в день
        Довольно спорное заявление. Когда тебе еще не 40, карьера на подъеме, руководство ждет результатов «вчера» и проекты относительно увлекательные, то вполне нормально кодить и по 10 часов в день годами. Чем еще заняться на работе? За 4 часа даже не успеешь нормально в поток войти, это не серьезно.
          +1

          Странно про код ревью — искать им опечатки, пропуски… Линтеры, тесты, CI. Зачем этим заниматься вручную мне неясно.
          На мой взгляд, ревью важный инструмент, если в команде есть недавно нанятые программисты. И для того, чтобы пройти по списку требований в задаче и сличить их со списком новых тестов и затем с кодом. Большего делать не стоит. А если делается, то надо искать способ автоматизировать эти действия.

            0
            Просто для ясности, я не предлагаю вам работать только четыре часа в день. Остальные четыре часа, как правило, лучше потратить на:

            Исследования, как связанные с работой, так и не связанные


            Ой, по острию ножа ходите. Совет, конечно, хороший, но лучше не вслух )))
              –1

              Типа гуру втирал дуру

                0
                Наверное странно будет выглядеть, если я встану в середине дня по середине опенспейса и начну делать зарядку :)
                Хотя, одна девочка у нас переодически делала упражнения возле туалета. Но что-то бросила
                  0
                  Наверное, если вам странно, то можно попробовать выбрать другое место. Я в своё время спускался, выходил из БЦ и заходил за угол, там практически никогда никого не было.
                  0
                  Некоторые могут сказать, что чем меньше строк кода в приложении, тем легче его читать.

                  Интересно, те кто это говорят когда-нибудь видели J?
                    0
                    Код не должен быть излишне сложным
                    Код не должен быть неэффективным (не пишите намеренно медленный код)

                    как начинающим изучать программирование, которые не владеют в нужной степени матчастью, соблюдать эти правила?
                      0
                      Пришли джуны, открывают конфлюенс, читают требования к коду и там: «не пишите намеренно медленный код»!!!
                      Все понятно, не будем.
                      0
                      • Код должен быть информативным
                      • Код не должен быть излишне сложным

                      Самая весёлая часть написания кода — это баланс и приведение к нему своего стиля написания программы. А вот он уже достигается планированием. Лично мой образ мышления (который я никому не навязываю) — спланируй поведения кода максимально большими по содержанию абстракцией. Потом по мере необходимости дели этот образ на составляющие. И запомни, между абстракцией A и абстракцией B всегда есть некая абстракция C, которую можно заметить только после первого применения программы на «боевой ситуации». Но именно она и будет твоей «Ахиллесовой пятой». А автор статьи правильно написал — Вы никогда не напишете «идеальный» код». Именно по этому всегда храни исходники на «всякий случай».
                        0

                        Выходит из третьего пункта, но все же — учить что либо связанное с проектом исключительно в рабочее время, а не дома, если конечно вас не прет от изучения очередного фреймворка или недоязыка. Я к примеру отказался в свое свободное время учить Coffee Script, предложил либо сходить искать фрилансера для задачи, либо скомпилить и работать с js.
                        Если у вас в резюме чего-то не было и вас взяли на работу, то все что сверх изучено — должно быть оплачено.

                          0
                          Если у вас в резюме чего-то не было и вас взяли на работу, то все что сверх изучено — должно быть оплачено.

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

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