Все думают, что программист большую часть своего рабочего времени пишет код. Кроме самих программистов. Они знают, что большую часть времени они этот код читают. Читают, силясь понять, как же он работает, зачем он здесь написан и что с ним теперь делать.
Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.
В классической книге “Рефакторинг” М. Фаулера приводятся всего три типа “подозрительного кода”, относящиеся к объёму: “Длинный метод”, “Большой класс”, “Длинный список параметров”. В современных реалиях этот список можно было бы пополнить, но даже эти три давно известных принципа нарушаются сплошь и рядом, а большие куски кода продолжают доставлять массу проблем.
Первая (и главная) проблема — это потраченное время. “Много кода” — это, прежде всего, просто много текста, который нужно читать. И никакие техники быстрого чтения здесь не помогут, потому что в коде важен каждый нюанс. Прочесть его “по диагонали”, значит впустую потратить своё время и сделать ложные выводы о том, как он работает.
Неправильно представляя, как работает кусок системы, программист обречён ошибиться при написании нового кода.
Большие куски кода трудно тестировать. Большие методы, использующие кучу данных, практически нереально покрыть Unit тестами, а интеграционные тесты оказываются огромными и очень сложными. Наcтолько, что впору писать тесты на тесты. Впрочем, можно сделать вид, что на проекте вообще нет автоматических тестов, и всё хорошо. Тогда вам очень пригодится книга Э. Йордона “Путь Камикадзе”.
Большие куски кода сложно ревьюить. Коллега был очень продуктивен и написал подсистему за выходные? Прекрасно, но теперь нужно потратить уйму человеко-часов на чтение этого опуса перед отправкой его в master! Дочитывая изменения в третьем десятке файлов, будет непросто удержать в голове изменения из самого начала, не говоря уж о своей собственной текущей задаче.
Большой кусок кода практически невозможно переиспользовать. Он делает слишком много вещей одновременно, а переиспользовать обычно нужно лишь некоторые из них. Улучшить ситуацию, применяя “Выделение метода” и другие приёмы, тоже не всегда возможно, так как этот огромный кусок вряд ли хорошо покрыт тестами.
Попробуйте вообще избежать написания кода.
- Проверьте, не решал ли кто-то до вас в этом проекте такую же (или сильно похожую) задачу. Переиспользуйте код, выделяйте абстракции, не стесняйтесь.
- Знайте и любите утилиты и API собственного проекта. Особенно, если ему больше полугода. Там могут найтись жемчужины, которые сэкономят вам десятки строк кода.
- Ещё знайте и любите популярные библиотеки для вашего языка или платформы. Если говорить о java, то не поленитесь ознакомиться как минимум с Google Guava и семейством Apache Commons. Не изобретайте велосипеды.
Когда всё-таки пишите свой код.
- Выделяйте новые функции и методы (и структуры, классы, компоненты, файлы). Код заслуживает быть вынесенным в отдельную функцию не только тогда, когда его планируется переиспользовать, но и в целях улучшения читаемости. Не экономьте стек вызовов. В вашем блоке
if { … } else { … }стало больше 20 строк кода? Вынесите его ветки в отдельные функции с хорошими именами, отражающими суть действия. Ваш метод занимает больше половины экрана (в альбомной ориентации)? Разбейте его на семантически значимые части. - Не увлекайтесь лямбда-выражениями и анонимными классами. Если какой-нибудь обработчик
onSuccess()занимает 200 строк из 400 строк метода, то выделите его код в отдельную функцию, объект или класс. Он не должен мешать понимать, что же ещё (кроме установкиonSuccess()) делает исходный метод. - Следите за уровнем абстракции. Не сваливайте в одну кучу бизнес-логику (например, принятие решения об отправке сообщения) и прикладной уровень (работа с сокетами для отправки).
Используйте простую мнемонику — правила драматургии. Единство места, времени и действия. Код одного метода должен выполняться здесь (выделяйте код callback-ов), сейчас (выделяйте код, выполнение которого откладываете в очередь, таймер и т. д.) и делать одно дело (держите один уровень абстракции).
Уменьшая количество кода, вы
- Сэкономите кучу времени себе (на написание) и другим (на чтение).
- Уменьшите количество ошибок в системе.
- Упростите поддержку и развитие системы.
- Получите эстетическое удовольствие от результата.
В следующий раз, перед тем, как погрузиться в поток, вспомните об этой статье. И напишите равно столько кода, сколько необходимо. Но ни строчкой больше.
Автор: Никита Скворцов
