Введение
Уже не в первый раз мне задают связанные вопросы:
«Зачем ты делаешь так много функций?»;
«Зачем ты выносишь, однократно используемый, код в функции?»;
«Остальные не знакомы с твоими правилами именования функций. Как они будут с этим работать?». Поэтому опишу свое видение проблемы. Ну а сообщество подскажет, к чему же стоит стремиться.
Ситуации
В процессе работы встречается разный код. Его надо сопровождать, исправлять в нем ошибки, добавлять новый функционал. Также пишется новый код, с которым предстоит работать в дальнейшем другим. Опишу несколько ситуаций:
Ситуация №1 Код делает слишком много
В классе есть доминирующий метод размером чуть меньше самого класса, при этом он содержит в себе всю логику и инфраструктурный код;
Ситуация №2 Логика кода понятна только после его изучения
Код хоть и невелик, но что он делает понять достаточно сложно;
Ситуация №3 Добавляется новый функционал
Имеется достаточно сложный код, в который необходимо добавить новые функции;
Ситуация №4 Пишется новый код
Код должен иметь низкую связность, хорошее покрытие тестами, сопровождаемость и пр;
Причины
В каждой из этих ситуаций, я стараюсь сделать минимальный рефакторинг. Делаю код более понятным и простым.
Чаще всего выношу код в метод. Если позволяет API, то делаю более сложные рефакторинги. Условные выражения, если они сходу не понятны, стараюсь вынести в метод с понятным названием.
Всегда руководствуюсь правилом: «код необходимо читать, а не компилировать и выполнять», что вполне соответствует идеологии, описанной Фаулером.
Каждая функция должна иметь хорошее название, если она делает не то, что описано в названии, ей должно быть подобрано новое имя. Комментарии, являющиеся переводом кода — излишни (Exception — Ошибка).
Всегда стремлюсь оставить код менее пахнущим, чем он был до этого. О запахах кода можно прочесть у многих, в частности у Фаулера.
Последствия
Почти после каждой более-менее существенной правки, мне задают вопросы, описанные выше. Говорят, что код стал менее понятным, становится трудно найти нужную строку и пр.
Причины
На самом деле проблема кроется как в коде, так и в разработчике, который привык к коду.
Предлагаю провести эксперимент.
Возьмите неизвестный участок кода, который написан хорошо. Он должен иметь методы со сложностью меньше 5 (имеется в виду упрощенная трактовка цикломатическая оценка). Если вам будет тяжело читать этот код, то обратите внимание, что вы пытаетесь транслировать код. Проверяете, как будет выполняться программа, поэтому неудобства доставляет постоянное перескакивание с метода на метод. Вы компилируете и выполняете код в голове.
Если код читать легко, то, скорее всего, вы больше внимания обращаете на сигнатуры методов, на их названия. Вы читаете код.
Для кода, содержащего несколько функций со сложностью более 30 верно обратное (к примеру, более 100 строк). Его читать невозможно, зато выполнение может принести свои плоды. Если вы не собьетесь в пятнадцатом вложении условия на двадцатой итерации цикла… Удачи!
Заключение
Можно сказать, что чем проще код, тем лучше. Только если вам кажется, что ваш код прост, то его можно упростить еще на несколько пунктов. Ничего страшного, что функция сейчас используется в одном месте, ничего, что ее название более 20 символов. Главное чтобы код читался, можно сказать, как художественная книга. Именно код, а не комментарии.
Хорошие примеры можно найти в трудах Гласса, Фаулера, Макконнелла, Мартина.
Еще хорошим контролем качества кода являются тесты. Не в том смысле, что в нем не ошибок — ошибки есть везде. Если, при написании теста, вы задумались на пару минут о том, как тестировать код, то он, на самом деле, сложноват, его можно упростить. Порой, приходят настоящие озарения.
Пишите и читайте свой код, а все остальное сделает компилятор!
Полезные ссылки:
1. Совершенный код. С. Макконнелл
2. Рефакторинг. Улучшение существующего кода. М. Фаулер
3. Чистый код. Р. Мартин
4. Greg Wilson — What We Actually Know About Software Development, and Why We Believe It's True
5. SOLID Principles with Uncle Bob — Robert C. Martin
6. Неплохой англоязычный ресурс sourcemaking.com
