Программирование

Три быстрых совета из «Чистого кода», которые сделают вашу команду на 50% эффективнее

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

Опубликовано

2 года назад

20.09.2022

Автор:

AppTractor

Если бы мне пришлось выбрать один пункт из «Чистого кода», библии лучших практик разработки программного обеспечения, я бы выбрал главу “We Are Authors”. Соотношение времени чтения и написания кода превышает 10 к 1. Прочтите это еще раз. Медленно. Мы постоянно читаем свой старый код, поскольку это необходимо для написания нового кода.

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

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

Содержание

1. Используйте хорошие имена

1.1. Раскрытие намерений: имя переменной, функции или класса должно говорить вам, почему они существуют, что делают и как используются. Если имя требует комментария, то имя не раскрывает своего намерения.

1.2. Делайте значимые различия: не пытайтесь удовлетворить компилятор. Если имена должны быть разными, они также должны означать что-то другое. Представьте, что у вас есть класс Product. Если у вас есть другой, называемый ProductInfo или ProductData, вы сделали имена другими, но они не означают ничего другого.

2. Избегайте побочных эффектов функций

Функция должна выполнять только одну операцию. Она должна выполнять ее хорошо. И ничего другого она делать не должна.

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

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

3. Комментируйте только при необходимости

3.1. Объясните себя в коде, а не в комментариях. Одна из наиболее распространенных причин написания комментариев — плохой код. Что бы вы предпочли увидеть?

Это:

Или это?

Еще несколько примеров плохих комментариев, которые попадают в категорию «попытка исправить плохой код»:

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

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

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

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