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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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