Почему программистов не учат «чистописанию»?

Мартин Фаулер сказал золотую фразу: «Any fool can write code that a computer can understand, good programmers write code that humans can understand». Прошли годы, а воз и ныне там. Большинство разработчиков забывают о том, что 80% времени они читают свой код и код своих коллег. Статья — попытка заставить подумать о проблеме качества кода.

Об авторе

Мысли вслух

А вы помните свои первые дни на работе в роли программиста? Вы помните свои первые незаданные вопросы?

Я прекрасно помню. Это не были вопросы, посвящённые выбору фреймворка, принципам обработки ошибок и увеличению производительности базы данных. Самый главный вопрос, который меня постоянно заботил — как же правильно назвать класс, метод, переменную. Мне всегда было крайне сложно дать чёткое и однозначное название переменной: стоит или нет зашить тип в название (descriptionString), использовать или нет притяжательную форму (updateUsersList), чем removeItem отличается от deleteItem?

И никогда не понимал, почему переменную, которая будет отвечать за подсчёт количества попыток называют с, count, в лучшем случае, counter, вместо того чтобы дать простое и понятное имя triesCounter.

Я уже не говорю про те случаи, когда методы называют с использованием транслитерации:

void sortirovka(String klienty)

Ещё больше вопросов возникало у меня при написании комментариев, о важности которых мне постоянно рассказывали преподаватели на занятиях по ООП. Но я хоть убей, не понимал, зачем нужен javadoc комментарий в таком куске кода:

/**
* Returns the day of the month.
* @return the day of the month.
*/
public int getDayOfMonth() {
    return dayOfMonth;
}

А сколько времени было убито мной на нажатие Tab и Ctrl+Tab для форматирования текста? Почему мне никто долгое время не говорил, что любая более-менее вменяемая IDE имеет встроенный code beautifier и по нажатию одной комбинации весь код будет сиять своей «отформатированостью».

Смешно? Но я бы на вашем месте не смеялся, а взял бы и посмотрел на код ваших junior-ов и на то, как они работают. Поверьте мне, они пишут точно также как и я когда-то. За 10 лет особо ничего не поменялось. Но им всё таки повезло больше. В 2008 году на свет появилась книга Clean Code, которую просто обязан прочитать каждый разработчик. Эта книга сделает вашу жизнь как разработчика намного красивее, гармоничнее и чище.

В тот момент, когда я прочёл шедевр Uncle Bob-а, меня уже заботили совершенно другие вопросы: как использование dependency injection поможет мне при разработке, как разрабатывать многопоточные приложения, как избежать влияния junior-ов на стабильность работы приложения, над которым трудится 20 человек. И так мой взор пал на статические анализаторы кода, которые помогают автоматически выполнить огромное количество проверок, уменьшают трудозатраты на ревью кода и повышают качество конечного продукта.

На сегодняшний день, благодаря таким инструментам, как Sonar, FindBugs, Checkstyle, Cobertura, FxCop, StyleCop, PHP_Depend, мы можем получить много полезной информации о нашем коде, и раз и навсегда избавиться от детских ошибок.

Мне, как говорится, за эту тему очень болит, и мне очень жаль, что «чистописанию кода» не учат с первых курсов в институтах, наряду с рефакторингом и юнит-тестированием и подходами в работе с системами контроля версий (я говорю не про checkout-update-commit). Поэтому я хочу, чтобы как можно больше людей узнало, что такое «чистый код» и приглашаю всех желающих выступить с докладом (20-30 минут) или поучаствовать в дискуссиях на тему качества кода на третьем собрании «Клуба анонимных разработчиков».

P.S. Особенно интересно узнать, как обстоят дела с качеством кода в динамических языках программирования — Ruby, Python, PHP.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU