Главная » Хабрахабр » Не пишите лишнего

Не пишите лишнего

Кроме самих программистов. Все думают, что программист большую часть своего рабочего времени пишет код. Читают, силясь понять, как же он работает, зачем он здесь написан и что с ним теперь делать. Они знают, что большую часть времени они этот код читают.

Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException. Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк.

Фаулера приводятся всего три типа “подозрительного кода”, относящиеся к объёму: “Длинный метод”, “Большой класс”, “Длинный список параметров”. В классической книге “Рефакторинг” М. В современных реалиях этот список можно было бы пополнить, но даже эти три давно известных принципа нарушаются сплошь и рядом, а большие куски кода продолжают доставлять массу проблем.

“Много кода” — это, прежде всего, просто много текста, который нужно читать. Первая (и главная) проблема — это потраченное время. Прочесть его “по диагонали”, значит впустую потратить своё время и сделать ложные выводы о том, как он работает.
Неправильно представляя, как работает кусок системы, программист обречён ошибиться при написании нового кода. И никакие техники быстрого чтения здесь не помогут, потому что в коде важен каждый нюанс.

Большие методы, использующие кучу данных, практически нереально покрыть Unit тестами, а интеграционные тесты оказываются огромными и очень сложными. Большие куски кода трудно тестировать. Впрочем, можно сделать вид, что на проекте вообще нет автоматических тестов, и всё хорошо. Наcтолько, что впору писать тесты на тесты. Йордона “Путь Камикадзе”. Тогда вам очень пригодится книга Э.

Коллега был очень продуктивен и написал подсистему за выходные? Большие куски кода сложно ревьюить. Дочитывая изменения в третьем десятке файлов, будет непросто удержать в голове изменения из самого начала, не говоря уж о своей собственной текущей задаче. Прекрасно, но теперь нужно потратить уйму человеко-часов на чтение этого опуса перед отправкой его в master!

Он делает слишком много вещей одновременно, а переиспользовать обычно нужно лишь некоторые из них. Большой кусок кода практически невозможно переиспользовать. Улучшить ситуацию, применяя “Выделение метода” и другие приёмы, тоже не всегда возможно, так как этот огромный кусок вряд ли хорошо покрыт тестами.

Попробуйте вообще избежать написания кода.

  • Проверьте, не решал ли кто-то до вас в этом проекте такую же (или сильно похожую) задачу. Переиспользуйте код, выделяйте абстракции, не стесняйтесь.
  • Знайте и любите утилиты и API собственного проекта. Особенно, если ему больше полугода. Там могут найтись жемчужины, которые сэкономят вам десятки строк кода.
  • Ещё знайте и любите популярные библиотеки для вашего языка или платформы. Если говорить о java, то не поленитесь ознакомиться как минимум с Google Guava и семейством Apache Commons. Не изобретайте велосипеды.

Когда всё-таки пишите свой код.

  • Выделяйте новые функции и методы (и структуры, классы, компоненты, файлы). Код заслуживает быть вынесенным в отдельную функцию не только тогда, когда его планируется переиспользовать, но и в целях улучшения читаемости. Не экономьте стек вызовов. В вашем блоке if else { … } стало больше 20 строк кода? Вынесите его ветки в отдельные функции с хорошими именами, отражающими суть действия. Ваш метод занимает больше половины экрана (в альбомной ориентации)? Разбейте его на семантически значимые части.
  • Не увлекайтесь лямбда-выражениями и анонимными классами. Если какой-нибудь обработчик onSuccess() занимает 200 строк из 400 строк метода, то выделите его код в отдельную функцию, объект или класс. Он не должен мешать понимать, что же ещё (кроме установки onSuccess()) делает исходный метод.
  • Следите за уровнем абстракции. Не сваливайте в одну кучу бизнес-логику (например, принятие решения об отправке сообщения) и прикладной уровень (работа с сокетами для отправки).

Единство места, времени и действия. Используйте простую мнемонику — правила драматургии. д.) и делать одно дело (держите один уровень абстракции). Код одного метода должен выполняться здесь (выделяйте код callback-ов), сейчас (выделяйте код, выполнение которого откладываете в очередь, таймер и т.

Уменьшая количество кода, вы

  • Сэкономите кучу времени себе (на написание) и другим (на чтение).
  • Уменьшите количество ошибок в системе.
  • Упростите поддержку и развитие системы.
  • Получите эстетическое удовольствие от результата.

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Переезд в австрийский социализм

Пора восполнить пробел. На Хабре часто пишут про эммиграцию в разные страны, а про Австрию ещё не было. Хальштатт Старался кратко, заранее извиняюсь, что не получилось 🙂 Я попробую описать мой опыт переезда в Австрию (в Вену), а также немного ...

App Store не позвонит. Или как я сделала своё приложение, но оно не попадёт к пользователям

Чуть позже я узнала, что неплохо дополнять код дизайном. Когда-то я думала, что для того, чтобы запустить своё приложение достаточно написать код. Но всё это может быть лишним, если не следовать гайдлайнам. Ещё позже я поняла, что необходимо искать аудиторию ...