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

Как улучшить качество кодовой базы

Сделайте свою кодовую базу лучшей версией себя.

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

3 года назад

30.05.2022

Автор:

AppTractor

Ищете быстрые способы улучшить качество кода?

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

⚠️ Отказ от ответственности: хороший код не пишется по набору правил. Вы не станете мастером программного обеспечения, изучая списки.

Содержание

Зачем заботиться о качестве кода

Помните, что все дело в экономии времени ⏰

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

Вот почему люди используют шаблоны проектирования — они уже знают, как они работают (например, шаблон Делегирования, Синглтон), поэтому они быстрее понимают концепцию кода.

Зачем вообще писать «хороший» код? Потому что хороший код означает, что вашей команде придется тратить меньше времени на его чтение, а значит, обслуживание будет проще. Время = деньги, поэтому вашей компании придется тратить меньше, а вам не придется утомлять себя чтением сложного кода. Вы можете использовать эту нерастраченную энергию, чтобы создавать новые технологии, улучшать себя и повышать уровень счастья. Я называю это опытом разработчика (Developer Experience), который является побратимом пользовательского опыта (User Experience).

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

Как улучшить качество кодовой базы

Количество свойств

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

Блочная вложенность

Максимальная вложенность блоков вычисляет, насколько глубоко вложена самая глубокая инструкция в одной функции. Если вы используете последовательный отступ, вы можете визуализировать это как строку с самым правым отступом в теле функции. Глубокая вложенность показывает сложную конструкцию со слишком сложным управленческим потоком (в случае вложения if/else), вычислительной сложностью (в случае вложенных циклов for) или их комбинацией.

Цикломатическая сложность

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

Знаете ли вы, что всякий раз, когда вы добавляете оператор if, вы автоматически добавляете 2 к цикломатической сложности? Вот почему полиморфизм считается хорошей альтернативой ;)

Строки кода

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

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

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

Аналогичный код

Одна из самых опасных проблем в кодовой базе. Принцип DRY (Don’t Repeat Yourself, не повторяйтесь) гласит, что каждая часть знания должна иметь единственное, недвусмысленное, авторитетное представление в системе.

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

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

Арность

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

Время сборки

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

Хорошим инструментом для отслеживания времени сборки является XCMetric, разработанный Spotify 💚

Как отслеживать показатели качества

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

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

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

Дублирование библиотеки Firebase

Вот как это выглядит на Github

Стоит отметить, что есть и другие платформы, вроде CodeBeat, например, SonarQube.

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

1. Будьте последовательными

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

Почему legacy код трудно читать? Потому что сообщество, вероятно, больше не использует его.

2. Не переусложняйте код

Теперь вы можете сказать, как я пойму, что я переусложняю?! Этот навык придет к вам с опытом и чтением чужого кода. Если вы делаете что-то, о чем никогда в жизни не читали, велика вероятность, что вы переусердствуете.

3. Любите свой код

Каждый раз, когда вы используете свой код, вы должны делать его лучше, чем раньше (спойлер: модульные тесты очень помогут вам в этом). Удалите шум или заброшенные файлы в своем коде и постарайтесь быть как можно более прямолинейным (это также известно, как принцип KISS).

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

4. Уважайте своих товарищей по команде

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

Разделите работу на более мелкие коммиты и делайте их чаще.
Коммит — это форма публикации. Не публикуйте мусор (вместо этого используйте функцию fixups).
Пишите хорошие сообщения для коммитов (≤ 50 символов).
Добавьте описание в свой PR вместе с тикетом Jira (используйте шаблон PR для своей команды).
И самое главное — общайтесь с товарищами по команде и будьте добры. Помните: «Люди забудут, что вы сказали, люди забудут, что вы сделали, но люди никогда не забудут, что вы заставили их чувствовать».

Бонусный подарок для тех, кто дочитал до этого места.

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