Comments 7
Все это прекрасно, но все эти призывы писать чистый код мне напоминают советы в духе - "не болей", "будь богатым, не будь бедным" и все прочее в таком духе.
На собесе тебе выносят мозг разными вопросами про паттерны, солид, чистый код, и прочими замечательными (без сарказма) вещами. Потом устраиваешься на работу, видишь исходный код.. а там все как обычно, солид там не валялся. Методы по несколько тысяч строк (сам видел в десяток тысяч), всякие странные навороты с запутанными и хрупкими иерархиями объектов, неоправданное применение паттернов, так что они вместо облегчения жизни разработчиков, только все ухудшают, превращают код в какой-то ребус, так что зачастую без отладчика просто невозможно понять какой код в какой ситуации отрабатывает.. И много подобного..
А всо от того что бизнесу до лампочки вся эта "чистота", ему главное больше фич в единицу времени. Ну и наш брат разработчик, конечно.. то-ли от скуки, то-ли из желания выпендриться зачастую такое пишет..
Самая большая проблема с КлинКодом в том, что некоторые отдельные люди не способны осознать разницу между рекомендациями и незыблемыми и нерушимыми истинами бытия.
Есть занятное видео https://youtu.be/tD5NrevFtbU?si=FBK2mnyYX3VZvcuv где автор показывает на практике, прямо на примере из книги про КлинКод как игнорирование этих принципов помогает улучшить производительность в 10,20,40(!) раз. В дальнейшем на почве этого ролика у автора были дебаты с самим Дядюшкой Бобом, в которых последний дико демеджконтролил, попытался свести все к ложному консенсусу, а потом совершил RageQuit и больше не обсуждает эту тему. Короткий разбор ситуации есть вот тут: https://youtu.be/oFiY7EEtAW4?si=3_IzWIihFqSlWpij
Выводы можно сделать примерно такие - клинкод необходим для того чтобы продукт было возможно поддерживать, однако есть места в которых можно отойти от парадигмы ради получения высокой производительности. Как всегда, радикальное следование любой идее скорее вредно, и нужно искать баланс и гармонию
На практике часто оказывается, что простой код, это не тот, который следует принципам дяди боба, а тот, в котором меньше явных и неявных ветвлений (полиморфизм или, не дай б-г, двойная диспетчеризация), используются подходящие (общепринятые и предсказуемые) структуры данных и т.п.
И оказывается, внезапно, что такой код и работает быстрее. И поддерживается отлично. И документации требует реже и меньше. И тестов писать приходится не миллиард на все пермутации.
В информатике есть только два сложных вопроса: инвалидация кэша, присвоение имен и ошибка на единицу.
В информатике есть только два сложных вопроса: инвалидация кэша и присвоение имен.
Добавлю третью проблему, которую практически никогда не решают правильно: удаление старых (неактивных) данных.
Чаще всего обходятся механизмом "soft delete", которая ведет к куче проблем с перепроверкой флагов и рекурсивной зависимостью других компонентов. Другой способ ("hard delete") тоже непростой, так как ты либо не можешь удалить элемент из-за FK, либо удаляешь элемент и все зависимые от него элементы с помощью каскадного удаления, которые не хотел бы удалять.
Философия чистого кода: эмпатия гораздо важнее мастерства