Чистый код — дар или проклятие? Акт I. Конфронтация

• "Чистый" код, ужасная производительность
• Дискуссия
  • Обозначение позиций
  • Почему ты нас не предупредил?
  • GitHub не даёт вводить текст
  • Читаемость и тесты
  • Классы против if/switch
• Итоги

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

"Открытое разногласие — часто — признак движения вперёд".

Махатма Ганди

Чистый код — явление, превратившееся из правил написания качественного кода в целую философию. Причём с этой философией знаком, мне кажется, каждый разработчик на планете. Однако есть некоторые доводы о том, что чистый код на самом деле является всего лишь красивой обёрткой, которая вредит индустрии.

Мы в PVS-Studio придерживаемся концепции написания качественного кода, поэтому нам и интересно глубже погрузиться в эту тему и разобраться, кто же прав.

В первой части я посчитал важным разобрать дискуссию Роберта Мартина и Кейси Муратори о чистом коде и производительности, поскольку это обсуждение является самым обширным на эту тему. Да и участники событий не заставляют сомневаться в своей компетентности:

Роберт Мартин (дядя Боб) — инженер, программист, консультант и автор книг в сфере разработки программного обеспечения ("Чистый код", "Идеальный программист", "Идеальная архитектура" и др.), один из авторов манифеста Agile, создатель принципов SOLID.

Кейси Муратори — программист, специализирующийся на исследовании и разработке игровых движков. Работал над проектами, которые в том числе широко применялись в разных игровых франшизах (Destiny, Age of Empires, Gears of War и др.).

"Чистый" код, ужасная производительность

Спусковым крючком для всех дальнейших событий стал ролик Кейси Муратори ("Чистый" код, ужасная производительность).

В этом ролике Кейси ставит под сомнение необходимость чистого кода, обращая внимание на то, какой вред производительности он несёт:

Далее для эксперимента берётся пример кода. В нём содержится базовый класс фигуры, а также классы, его наследующие: круг, треугольник, прямоугольник и квадрат. Код этого примера соответствует правилам чистого кода, в том числе описанным выше.

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

В итоге таких изменений финальная версия программы работает в 15 раз быстрее первоначального варианта, который соблюдает правила чистого кода. Сам Кейси использует довольно интересные сравнения для описания этой ситуации:

Принцип Don't repeat yourself (DRY) Кейси, кстати, всё же признал вполне пригодным:

В конце статьи автор констатирует невозможность получения достаточной производительности при использовании правил чистого кода:

Такой материал не мог остаться незамеченным. После выхода ролика казалось, что о нём говорят везде. Как я и отмечал ранее, вопросы к производительности чистого кода возникали и ранее, но ролик Кейси Муратори будто стал манифестом этих обсуждений.

Дискуссия

Собственно, я ни капли не драматизирую и не придаю лишней важности ролику Кейси Муратори, ведь на приведённые в нём доводы ответил сам амбассадор чистого кода (в каждой шутке есть доля шутки) — Роберт Мартин.

Дискуссия Мартина и Муратори проходила в GitHub репозитории и привлекла внимание немалого количества разработчиков. Далее я постараюсь выбрать всё наиболее интересное из этого диалога, приправив это горсткой своих комментариев.

Обозначение позиций

Дискуссия началась, что называется, "с места в карьер". Кейси начал с конкретных вопросов:

Ответ Роберта был предсказуем и понятен:

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

Однако Кейси это не остановило и обсуждение продолжилось:

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

Собственно, в разных контекстах разный и эффект от выжимания производительности. Мы бесконечно можем ускорять код, разбивать задачу на потоки, процессы и так далее, однако где-то мы в любом случае будем зависеть, например, от ввода/вывода информации, получения данных из сети и тому подобное. А где-то лишние наносекунды не произведут вообще никакого эффекта на конечного пользователя продукта.

К этой же теме Мартин добавляет и общую классификацию программного обеспечения по необходимости производительности. Мол, зачем маленькому приложению-календарю, написанному на Python, выжимать максимальную производительность?

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

Почему ты нас не предупредил?

Кейси Муратори вернулся к самому первому вопросу, немного конкретизировав его:

Вопрос уточнён настолько, что Кейси привёл даже конкретный цикл лекций Мартина, в которых о вопросах производительности чистого кода не говорится ни слова.

Дядя Боб, собственно, принял критику:

И этот вопрос действительно интересен, потому что в моей голове понимание того, что чистый код не для производительности, будто было по умолчанию. С этой же проблемой столкнулся и дядя Боб. Об этом нужно говорить, поэтому мы сейчас здесь. Мартин пришёл к этому же выводу:

Кейси принял такой ответ и оставил за Робертом право выбора, продолжать ли дискуссию далее:

GitHub не даёт вводить текст

Забавно, что проблемы с производительностью показали себя прямо во время диалога. Причём проблемы такие, что их получилось потрогать руками!

Кейси упомянул, что, когда он вводит текст через веб-редактор GitHub, задержка между нажатием клавиши и появлением символа на экране довольно велика. И на приведённом им видео видно, что это действительно создаёт неудобства. Причём такие проблемы происходят несмотря на довольно быстрый чип Zen2.

И здесь началось расследование!

Роберт предположил, что проблема в длине абзаца:

Его предложение для решения проблемы — ставить отступы в конце строки:

Но Кейси чётко диагностировал проблему, проверив вкладку Производительность в Chrome:

Эта функция сканирует введённый текст справа налево на наличие эмодзи. И, если абзац длинный, работа функции становится несовместимой с удобным использованием редактора. А также Кейси находит временное решение этой проблемы:

Дядя Боб проверяет:

Don't:you:just:love:being:a:programmer:and:diagnosing:interesting:problems:
from:the:symptoms?
To:do:that:well:you:have:to:think:like:a:programmer.::
....

Пусть данный фрагмент и не несёт непосредственной ценности для основной темы, для меня он показался важным с точки зрения некоторого раскрытия мотивации участников дискуссии. Роберт и Кейси здесь — отчаянные исследователи, которые пришли друг к другу не для того, чтобы поставить чью-либо компетентность под сомнение, а для того, чтобы разобраться в вопросе и понять, что делать дальше.

Читаемость и тесты

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

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

Однако Кейси добавил, что в некоторых ситуациях переменные, названные по типу a, b, c и т. д., вполне могут быть приемлемыми. Чуть далее Мартин сформулировал это более конкретно:

То есть, в рамках маленького цикла переменная с названием i – вполне нормальное решение, но при большей области видимости стоит обозначить название более явно. А с функциями всё наоборот, (в основном из-за удобства). Если они используются во многих местах, то вызов функций с коротким названием будет быстрее и удобнее.

Вторым пунктом, который затронул Кейси в своих размышлениях, стали тесты. И здесь участники тоже согласны, что они полезны и нужны, но Кейси указывает на конкретное расхождение в понимании тестов:

И это расхождение действительно легко обнаружить. Дядя Боб в своих книгах довольно часто упоминает методологию экстремального программирования и разработку через тестирование (TDD), преподнося этот подход как один из лучших вариантов работы с тестами.

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

У Мартина же своё понимание необходимости тестов:

Но дядя Боб всё-таки говорит, что понимает проблему, связанную с невозможностью протестировать весь код, и сам признаётся, что оставляет его части без тестов именно по этой причине.

Основной причиной для использования правила "сначала тест" Мартин называет свою уверенность в том, что при внесении изменений в код тесты сразу покажут, что сломалось. Поэтому покрытый ими код можно быстро рефакторить, улучшать его производительность и так далее:

В вопросе тестов участники дискуссии пришли к согласию, а Мартин сформулировал их небольшие в этом расхождения следующим образом:

Классы против if/switch

После обсуждения довольно богатого списка тем Кейси предложил перейти к самому главному:

Он говорит о том, что чистый код скорее относится к operand-primal и соответствует основным идеям объектно-ориентированного программирования. То есть методология благоприятствует добавлению новых типов для существующих операций, нежели добавлению новых операций для существующих типов. И Кейси, хоть и работал с таким кодом и видит его распространённость в индустрии, всё же не понимает преимуществ этого подхода.

Дядя Боб уточнил категоризацию и привёл к виду, в котором те же вопросы разбирались в книге "Чистый код". В главе "Объекты и структуры данных" он в одном из пунктов рассказывает про удобство использования полиморфизма. Там же он разделяет код на процедурный и объектно-ориентированный. Эти определения будут использованы им в ходе дискуссии.

Далее Мартин последовательно разобрал, какими преимуществами и недостатками обладает ОО в таком контексте:

То есть, исходя из последнего пункта, ОО помогает программистам соблюдать принцип открытости/закрытости (OCP), пусть это происходит и не во всех случаях.

Однако здесь Мартин подмечает ещё одну деталь: случаи использования switch создают исходящую цепь зависимостей к модулям более низкого уровня. В итоге любое изменение одного из модулей более низкого уровня приведёт к перекомпиляции и повторному развёртыванию оператора switch и всех модулей более высокого уровня, которые от него зависят.

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

Однако Кейси Муратори не согласился с этим аргументом. Он допускает, что при переходе от n к n + 1 типу при использовании полиморфизма нужно будет перекомпилировать только один файл. А в случае использования switch, где имеется m функций по n случаев, для перехода к n + 1 типу нужно будет пройти по всем этим функциям и добавить туда новый случай, что потребует перекомпиляции m файлов. Проблема в том, что при добавлении новой операции получится обратная ситуация. В случае использования switch нужно будет просто добавить m + 1-ю функцию, тогда как при использовании полиморфизма потребуется пройти по всем классам и добавить туда операцию, то есть перекомпилировать m файлов против одного при использовании switch.

Кейси говорит, что в этом случае Роберт повернул ситуацию в свою сторону, оставляя другие подробности нераскрытыми:

Далее Роберт Мартин предложил ввести в дискуссию гипотетический компилятор, который преобразует процедурный и объектно-ориентированный код в один и тот же двоичный, чтобы увести тему от производительности непосредственно к архитектуре. Но Кейси посчитал это лишним:

Также дядя Боб отметил, что обсуждаемые стили мало что меняют в процессе управления исходными файлами, а выбор здесь является скорее делом вкусов, но инверсия зависимостей создаёт важное различие. Кейси сократил эти рассуждения для ясности:

Кейси хотел понять, в чём, с точки зрения Роберта, состоит польза инверсии зависимостей. Дядя Боб ответил, что отделение деталей низкого уровня от деталей высокого уровня важно исключительно для людей, а машинам на это всё равно, а также привёл причины, по которым это разделение важно:

Для разъяснения, возможна ли описанная ранее изоляция в обоих видах архитектуры, Роберт Мартин приводит такой фрагмент Java-кода:

public class Payroll {
  public void doPayroll(Date payDate) {
    for (Employee e : DB.getAllEmployees()) {
      if (isPayDay(e, payDate)) {
        Paycheck check = calculatePaycheck(e, payDate);
        pay(e, check);
      }
    }
  }
}

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

Вопрос Мартина состоит в том, возможно ли сделать такое же в процедурной архитектуре. Кейси ранее упоминал union, но даже он, по мнению Роберта, не поможет сокрыть детали реализации.

Кейси ответил, что при использовании union нет никакой разницы по сравнению с иерархиями с точки зрения раскрытия деталей:

Более того, свои слова он подкрепил примером типичного h-файла:

struct file;
file *Open(...);
void Read(file *File, ...);
void Close(file *File);

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

Мартин поправил своего собеседника относительно термина "иерархия", поскольку он скорее говорит о подходе "интерфейс/реализация", чем о глубоких иерархиях наследования. Также дядя Боб согласился, что разделение .c/.h хорошо скрывает реализацию, поскольку непосредственно в C оно является инверсией зависимостей.

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

К этому моменту я и сам, честно сказать, подумал, что дискуссия движется в странном направлении. Из-за того, что участники так сильно увлечены тем, о чём они говорят, вектор обсуждения менялся довольно сильно.

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

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

#include <stdio.h>

main(tp,pp,ap)
int tp;
char **pp;
char **ap;
{int t=tp;int _=pp;char *a=ap;return!0<t?t<3?main(-79,-13,a+main(-87,1-_,
main(-86, 0, a+1 )+a)):1,t<_?main(t+1, _, a ):3,main ( -94, -27+t, a
)&&t == 2 ?_<13 ?main ( 2, _+1, "%s %d %d\n" ):9:16:t<0?t<-72?main(_,
t,"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+\
,/+#n+,/#;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l q#'+d'K#!/\
+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# ){n\
l]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#\
n'wk nw' iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \
;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;\
#'rdq#w! nr'/ ') }+}{rl#'{n' ')# }'+}##(!!/")
:t<-50?_==*a ?putchar(a[31]):main(-65,_,a+1):main((*a == '/')+t,_,a\
+1 ):0<t?main ( 2, 2 , "%s"):*a=='/'||main(0,main(-61,*a, "!ek;dc \
i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);}

Мне кажется важным, что чистый код это не только динамический полиморфизм. Об этом сказал и Мартин, а ещё упомянул вопросы именования, управления зависимостями, организации кода и прочие.

Кейси продолжил свой вопрос, предложив конкретные варианты для замены классов:

Кейси предложил Роберту теоретически представить интерфейс операционной системы для ввода/вывода, разработанный в соответствии с принципами чистого кода.

Дядя Боб ответил на это ровно тем же способом, который был использован им когда-то: создание абстракции File с операциями open, close, read, write и seek. Устройства ввода-вывода были классифицированы как типы, и при дальнейшем использовании было неважно, какое именно устройство используется. Благодаря такой организации возможно реализовать следующую программу для копирования одного устройства на другое, не зная, что это за устройство:

void copy() {
  int c;
  while((c=getchar()) != EOF)
  putchar(c)
}

Дядя Боб предложил посмотреть на тот же самый интерфейс, только реализованный с помощью switch:

#include "devids.h"
#include "console.h"
#include "paper_tape.h"
#include "...."
#include "...."
#include "...."
#include "...."
#include "...."

void read(file* f, char* buf, int n) {
  switch(f->id) {
    case CONSOLE: read_console(f, buf, n); break;
    case PAPER_TAPE_READER: read_paper_tape(f, buf n); break;
    case....
    case....
    case....
    case....
    case....
  }
}

Понятно, что чем больше будет устройств, тем больше будет условий; количество исходящих зависимостей также растёт, так ещё и в контексте задачи таких файлов пять. То есть каждый из файлов должен быть обновлён при добавлении нового устройства. А ещё возникает необходимость перекомпиляции файлов, включающих devids.h.

Однако Мартин сказал, что бывает время и место как для switch, так и для динамического полиморфизма.

Кейси попросил у Роберта подробнее расписать этот пример и рассказать, где именно подход с принципами SOLID и чистым кодом экономит время программистов. И Мартин это сделал!

Для начала он реализовал базовый класс:

#include "file.h"
class raw_device {
public: 
  virtual file* open(char* name) = 0; 
  virtual void close(file* f) = 0;
  virtual void read(file* f, size_t n, char* buf) = 0;
  virtual void write(file* f, size_t n, char* buf) = 0;
  virtual void seek(file* f, int n) = 0;
  virtual char* get_name() = 0; 
}

Далее добавил драйвер ввода-вывода:

#include "raw_device.h"
class new_device : public raw_device {
public: 
  virtual file* open(char* name);
  virtual void close(file* f);
  virtual void read(file* f, size_t n, char* buf);
  virtual void write(file* f, size_t n, char* buf);
  virtual void seek(file* f, int n);
  virtual void get_name();
}

И, наконец, дошло до конкретной реализации:

#include "new_device.h"

file* new_device::open(char* name) {...}
void new_device::close(file* f) {...}
void new_device::read(file* f, size_t n, char* buf) {...}
void new_device::write(file* f, size_t n, char* buf) {...}
void new_device::seek(file* f int n) {...}
void new_device::get_name() {return "new_device";}

Осталось добавить модуль для создания экземпляров драйверов ввода-вывода и загрузки их в карту устройств:

io_driver_loader.cc
#include "new_device.h"
#include "new_device2.h"
#include "new_device3.h"
...
  
void load_devices(device_map& map) {
  map.add(new new_device());
  map.add(new new_device2());
  map.add(new new_device3());
  ...
}

Теперь осталось только посчитать, сколько действий нужно сделать для добавления нового устройства:

• создать new_device_4.h;
• создать new_device_4.cc;
• изменить io_driver_loader.cc;
• перекомпилировать и заново связать три файла.

А вот в случае использования switch действий становится побольше:

• создать new_device_4.h — предварительное объявление пяти функций;
• создать new_device_4.cc — реализация пяти функций;
• изменить пять операторов switch (по одному для каждой функции), возможно, в пяти разных файлах;
• изменить devids.h, чтобы добавить новый #define макрос для устройства;
• перекомпилировать и заново связать файлы 4 и 8, а также все файлы, зависящие от devids.h.

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

class raw_device {
public: 
  virtual void read(size_t offset, size_t n, char* buf) = 0;
  virtual void write(size_t offset, size_t n, char* buf) = 0;
  virtual char* get_name() = 0; // return the name of this device.
}

Соответственно, поменялась и реализация этого драйвера:

#include "raw_device.h" // from the DDK
class new_device : public raw_device {
public: 
  virtual void read(size_t offset, size_t n, char* buf);
  virtual void write(size_t offset, size_t n, char* buf);
  virtual void get_name();
}

Во-вторых, Кейси предложил добавить функцию для поиска используемого устройства через карту устройств:

raw_device *find_raw_device(char *name) {
  raw_device *device = global_device_map[name];
  return device;
}

Мартин согласился на такие изменения, обратив внимание, что количество операций сильно сократилось.

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

Дядя Боб предложил реализацию этого API как подключаемой функции, которая будет предоставлять доступ к функциям делегирования:

read(char* name, size_t offset, size_t n, char* buf);
write(char* name, size_t offset, size_t n, char* buf);

Собственно, предложенная Кейси функция find_raw_device будет использоваться этими функциями, чтобы делегировать ответственность за исполнение запроса на конкретный экземпляр raw_device.

Роберт предложил вернуться от гипотетического примера к теме, которой он посвящён, констатируя, что от правил чистого кода он никуда не уйдёт, и ещё раз повторил свою мысль по поводу switch:

Кейси предложил ещё один вариант для интерфейса ввода/вывода, реализованный с помощью enum:

enum raw_device_operation : u32
{
  RIO_none,
  RIO_read,
  RIO_write,
  RIO_get_name,
  RIO_private = 0x80000000, 
};

struct raw_device_id
{
  u32 ID;
};

struct raw_device_request
{
  size_t Offset;
  size_t Size;
  void *Buffer;
  raw_device_operation OP;
  raw_device_id Device;

  u64 Reserved64[4];
};

strcut raw_device_result
{
  u32 error_code;
  u32 Reserved32;
  u64 Reserved64[7];
};

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

Также Кейси привёл доводы к большей эффективности использования enum в этом примере:

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

Дядя Боб с некоторыми оговорками согласился с приведёнными доводами и сказал, что при всём желании что-либо доказать, они говорят об одном и том же:

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

На этом дискуссия Кейси Муратори и Роберта Мартина закончилась, оставив аудитории пищу для размышлений о том, кто же был прав.

Итоги

После окончания этой дискуссии я видел мнения о том, что чистый код был компрометирован в её процессе и больше не заслуживает внимания. Мне кажется, что это абсолютно неверно, как и неверно подобное утверждение в обратную сторону. Оба участника остались при своём, объяснив при этом свою позицию.

Отмечу, что в некоторых моментах чувствовалось недопонимание между участниками беседы. Например, когда Кейси утверждал о недостатках иерархий наследования, а Роберт Мартин о них и не говорил. Возможно, это связано с форматом проведения диалога. Я лишь констатирую свои ощущения как сторонний наблюдатель.

Если говорить про выводы, которые можно сделать по итогам этой дискуссии, то концепция чистого кода всё ещё остаётся для меня важной при написании своего кода. Важно писать его таким, чтобы в дальнейшем была возможность использовать и сопровождать его. Однако важно при этом думать и о производительности. Меня в этом случае можно отнести скорее к сторонникам избирательной производительности, о которой говорил дядя Боб. Не все задачи требуют выжимки максимального перфоманса из каждой написанной строки (немного утрирую, но, думаю, вы меня понимаете), и, как мне кажется, даже пример из статьи Кейси про фигуры не требовал сил, потраченных на увеличение его производительности аж в 15 раз.

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