Comments 10
Первое, из таких необоснованных утверждений предполагает, что тесты должен писать тот кто пишет основной код. Это противоречит всему опыту технологического развития, и здравому смыслу. Что если качество строительства будут утверждать сами строители. Что если свежесть блюд будут утверждать сами сотрудники точек питания.
А вот тут манипуляция. Уровней тестирования много, и никто не говорит, что всеми ими должны заниматься разработчики. Речь же о юнитах. Строитель же проверяет, что раствор действительно держит кирпич, а лестница действительно выдерживает вес человека. Повар же проверяет соленость блюда. Ну а если хочется кровопролития чтобы один человек писал код, а другой юниты, то удачи. О результатах эксперимента не забудьте написать.
Чистый код решает проблемы производительности
Я б сказал, что не решает, а расчищает путь к решению. Когда все по полочкам, то легче найти хотспоты и оптимизировать их прицельно и изолировано.
У меня ощущение, что набор статей - это или чей то диплом (что-то такого типа) или попытка оправдать какие то решения на конкретном проекте.
Комментариев от автора ноль, хватает громких заявлений (Чистый код отменяет рефакторинг ) и при этом много странных и сомнительных моментов, которые по сотне раз обсуждали в разных местах в разные годы.
Что если качество строительства будут утверждать сами строители.
Не знаю как у автора и как у вас, у нас - качество решают строители, т.е. разработчики. А вот если произошел customer impact, то прилетит тем, кто накосячил - в смысле им придется косяки исправлять. Чистый код помогает делать исправления эффективнее, т.е. быстрее и, я бы сказал, окончательнее.
Но, разумеется, сказав это нельзя не сказать, что есть и лучшие практики, свод правил, есть и контроль за тем что несет PR, там должно быть достаточное покрытие и эти нормы и их наличие устанавливаются свыше. Сейчас. А пару лет назад это было опционально.
Чистый код, и соответствие принципу KISS (по моему, это одно и тоже)
Да?
Допустим, это KISS, ибо проще некуда:
class some_thread_safe_type {
std::mutex m_lock;
some_data m_data;
...
public:
void modify() {
m_lock.lock();
m_data.modify();
m_lock.unlock();
}
...
};
А вот это чистый код:
class some_thread_safe_type {
...
public:
void modify() {
std::lock_guard lock{m_lock};
m_data.modify();
}
...
};
Одно и тоже же ж.
ЗЫ. Не могу удержаться:
class IPasswordHash
{
public:
virtual std::string get(std::string pass) = 0;
};
Чем обосновывается передача pass в get по значению? Или это тоже магическая часть "чистого" кода?
вы маленько перескочили, мне кажется. Надо было начать с вопроса: А где здесь код?
Вот вы действительно продемонстрировали код, даже две реализации кода. Эти реализации можно сравнивать, делать какие то выводы.
Разве голую декларацию без реализации, без вариантов использования можно в серьез анализировать? Декларация это только обещание. Как говорится обещать жениться, не значит жениться.
Я воспринял автора так, что у него до этой статьи была серия, где он приводил примеры кода, а сейчас это некий метаанализ, который содержит общие выводы из содержимого головы автора статьи, поэтому примеров кода здесь нет. Что можно понять.
Но это не повод не показать, что некоторые "выводы", скажем так, совсем не интуитивны и больше походят на заблуждения.
Первое, из таких необоснованных утверждений предполагает, что тесты должен писать тот кто пишет основной код.
Допустим это так. Но как практически то это будет работать? Я написал фичу, пнул кого то, типа давай программировай тесты? Это так работает?
Частый код - это правильно организованный код, код без ничего лишнего, код который легок для понимания и модификаций.
Понимание концепции чистого кода приходит с опытом.
Чистый код, по большей части, это способ Фаулера и ему подобных продавать свой консалтинг. Это маркетинговый метриал, в первую очередь, и что-либо другое во вторую. Он никогда не ставил себе цели сделать какую-либо строгую теорию,и это стоит воспринимать как набор частично актуаьлных, частично полезных мыслей, но ни в коем случае не как руководство к действию и, упаси боже, религиозный догмат.
Чистый код без предварительно проектирования бесполезен.
Невозмножно полностью пре-проектировать live-service систему, ибо, изменения постоянно поступают, иногда неожиданные и в разные стороны. Таких систем едва ли не большинство, и если следовать статье, чистый код бесплезен?
Весь функционал проекта необходимо правильно, подчеркну, правильно разделить на составляющие.
Делайте хорошо, не делайте плохо. Насколько ценен этот совет? Конструктив по поводу того как это делать и доказательства того что делать так - это оптимально, хотя бы, для частного случая сильно убедительнее.
Чистый код использует паттерны проектирования естественным образом.
Паттерны - не религиозный догмат и не универсальное решение, и не все из них полезны во всех ситуациях. Они даже не записаны в виде аксиоматизироавнной теории.
Чистый код не требует усилий на тестирование.
Трудозатраты на тестирование определяются требуемым уровнем надёжности в первую очередь, то как написан код это уже дело 10.
Я не вижу смысла лезть в подробности, ибо они очень и очень спорные.Ну, и, накопилось множество вопросов к личным качествам автора.
Что если качество строительства будут утверждать сами строители.
Так качество строительства строители и утверждают 🙄 Прочитал статью - это либо крайне кривой перевод либо поток несвязных мыслей. QA существуют давно, более 30 лет, если для автора это недавно - наверное от 1000 летний вампир. По чистому коду тоже много вопросов, например почему его должно быть легче тестировать? Проще читать? Да. Он быстрее? Иногда. Но если функционально он не отличается, то и нагрузка при тестировании не должна отличаться.
В идеальном мире, команда проектирования не только может сделать график прямой линией, но и выгнуть его, то есть завершать проект без напряжения сил.
Зачем эти примеры из идеального мира? Должен быть график в котором будет заложено время на тестирование, фикс багов и возможную регрессию. Намного легче заранее заложить чуть больше времени, чем потом гнать всю команду и оправдываться перед клиентом.
Чистый код: Начало