Понимание концепции чистого кода приходит с опытом.
Чистый код, по большей части, это способ Фаулера и ему подобных продавать свой консалтинг. Это маркетинговый метриал, в первую очередь, и что-либо другое во вторую. Он никогда не ставил себе цели сделать какую-либо строгую теорию,и это стоит воспринимать как набор частично актуаьлных, частично полезных мыслей, но ни в коем случае не как руководство к действию и, упаси боже, религиозный догмат.
Чистый код без предварительно проектирования бесполезен.
Невозмножно полностью пре-проектировать live-service систему, ибо, изменения постоянно поступают, иногда неожиданные и в разные стороны. Таких систем едва ли не большинство, и если следовать статье, чистый код бесплезен?
Весь функционал проекта необходимо правильно, подчеркну, правильно разделить на составляющие.
Делайте хорошо, не делайте плохо. Насколько ценен этот совет? Конструктив по поводу того как это делать и доказательства того что делать так - это оптимально, хотя бы, для частного случая сильно убедительнее.
Чистый код использует паттерны проектирования естественным образом.
Паттерны - не религиозный догмат и не универсальное решение, и не все из них полезны во всех ситуациях. Они даже не записаны в виде аксиоматизироавнной теории.
Чистый код не требует усилий на тестирование.
Трудозатраты на тестирование определяются требуемым уровнем надёжности в первую очередь, то как написан код это уже дело 10.
Я не вижу смысла лезть в подробности, ибо они очень и очень спорные.Ну, и, накопилось множество вопросов к личным качествам автора.
Тем что билдер обычно пытаются использовать там где поехало SRP и в один класс пытаются впихнуть то что надо бы делать разными. Но людям обычно лень размечать агрегаты так чтобы не было миллионов параметров. Конечно, ведь "проще" воткнуть ещё одну переменную и несколько условных операторов чтобы оно "просто работало" нежели делать отдельный класс под это, вот только это подходит только для тех случаев где future- proof не нужен.
Да и иммутабельные классы без методов для данных сильно проще и чище чем по заветам дяди боба.
Чистый код, по большей части, это способ Фаулера и ему подобных продавать свой консалтинг. Это маркетинговый метриал, в первую очередь, и что-либо другое во вторую. Он никогда не ставил себе цели сделать какую-либо строгую теорию,и это стоит воспринимать как набор частично актуаьлных, частично полезных мыслей, но ни в коем случае не как руководство к действию и, упаси боже, религиозный догмат.
Невозмножно полностью пре-проектировать live-service систему, ибо, изменения постоянно поступают, иногда неожиданные и в разные стороны. Таких систем едва ли не большинство, и если следовать статье, чистый код бесплезен?
Делайте хорошо, не делайте плохо. Насколько ценен этот совет? Конструктив по поводу того как это делать и доказательства того что делать так - это оптимально, хотя бы, для частного случая сильно убедительнее.
Паттерны - не религиозный догмат и не универсальное решение, и не все из них полезны во всех ситуациях. Они даже не записаны в виде аксиоматизироавнной теории.
Трудозатраты на тестирование определяются требуемым уровнем надёжности в первую очередь, то как написан код это уже дело 10.
Я не вижу смысла лезть в подробности, ибо они очень и очень спорные.Ну, и, накопилось множество вопросов к личным качествам автора.
Тем что билдер обычно пытаются использовать там где поехало SRP и в один класс пытаются впихнуть то что надо бы делать разными. Но людям обычно лень размечать агрегаты так чтобы не было миллионов параметров. Конечно, ведь "проще" воткнуть ещё одну переменную и несколько условных операторов чтобы оно "просто работало" нежели делать отдельный класс под это, вот только это подходит только для тех случаев где future- proof не нужен.
Да и иммутабельные классы без методов для данных сильно проще и чище чем по заветам дяди боба.