Но тогда в любом объекте должны содержаться либо только одна единственная структура данных, либо только один единственный метод....
Такое разделение скорее всего не будет улучшением кодовой базы и следует его проверить на соответствие другим принципам, или на соответствие принятой архитектуре.
.. Иначе возможна ситуация, когда потребуется несколько причин, чтобы поменять объект - когда надо поменять и структуру данных и метод, или же несколько методов, или несколько структур данных.
В каждый отдельный момент причина одна - требования заказчика. Если по одному требованию заказчика, мы в одном классе меняем данные и методы и не затрагиваем другие классы - то это хорошо. Если мы по разным требованиям заказчика, опять всё меняем только в одном классе - то это плохо - скорее всего наш класс реализует слишком много (склонность к божественному классу) и его функциональность надо перегруппировать.
Скорее должно быть «не больше жестов», а должны быть жесты органично встраиваемые в программы. Например, для CAD системы «ухватить деталь», «перетащить деталь», «выполнить сечение». И тут уже распознаванием пальца-направления не обойтись — потребуется распознавание положения и движения всей кисти. Возможно нужен будет новый класс для таких жестовых устройств, чтобы система и софт могли работать с различными устройствами такого класса, и не приходилось адаптировать программы под каждое такое устройство.
Дело в том, что в этом примере не используется ничего из объекта «Человек». То есть этот метод мог бы быть статическим в терминах С++. А в терминах «рефакторинга» — скорее всего класс «Человек» в данном случае «жадный» и метод может быть удалён (так как перемещать его в класс «Кошка» смысла нет — он уже там в виде «есть_из» ).
Ещё вариант — использовать job dsl плагин, чтобы генерировать задачу с подставленными нужными значениями параметров. Как побочный эффект — можно одновременно иметь различные конфигурации параметров в разных сгенерированных задачах.
При таком подходе получается, что все задачи видят все параметры. И скорее всего потребовалось прописать много разрешений для выполнения кода groovy для доступа к объектам hudson. А Вы рассматривали как вариант запустить downstream задачу с помощью build step из upstream задачи и передать массив параметров?
Для арабских цифр придумали хак для быстрой оценки порядка — экспоненциальную форму записи числа. И тут вроде умножается хорошо и порядок виден, но чтобы сложить — числа нужно нормализовать.
Получается есть сохраняющаяся сложность — это полезная информация. А сложность, «которую невозможно оправдать», — это помеха. И методики чистки кода пытаются снизить уровень «помехи». Неудачное применение методик может привести не к снижению уровня помехи, а просто к преобразованию, в лучшем случае, «помехи» из одного вида в другой.
п4. как раз о том чтобы не попадать в ступор и чётко видеть, где находишься при решении конкретной задачи. Естественно, не возможно детализировать задачу полностью до последней строчки кода. Но какие-то вешки надо сделать — определить какие классы будут затронуты в процессе решения, что там требуется изменить и в каком порядке. Возможно в процессе реализации что-то уточнится, а что-то из первоначального плана откинется. Но зато будет понятно двигаешься ли к поставленной цели или пытаешься по кругу вносить какие-то изменения наобум.
Окончательную полировку-рефакторинг, конечно, никто не отменял. В процессе реализации может накопиться много лишнего — всё-таки примерный план — это не UML с описанием всего возможного.
3 не противоречит 1.
3-ий говорит о том, что не надо писать то, что действительно не требуется прямо сейчас (заказчиком или требованиями), то есть не надо реализовывать что-то на будущее. Потому что в будущем могут появиться, вообще, прямо противоположные требования.
1-ый же говорит: «Вот делаешь изменения — почисти старый код, чтобы он, возможно, не конфликтовал с новыми реалиями, а, возможно, просто не очень аккуратный старый код или совсем не аккуратный старый код.»
Согласен, что закладывать совместно и решение задачи, и что-то слабо относящееся к задаче в одном коммите это вносит неразбериху. (Хотя если следовали Single Responsibility — код в одном классе будет всё-таки связан с задачей или багом. А если не следовали, то фикс для бага — хороший повод провести улучшение кода — всё равно придётся анализировать код в процессе фикса.)
И тут, конечно, могут быть свои стайл гайды — вплоть до отдельной таски или отдельной ветки. Но всё это не нарушает совет — главное оставить код лучше, чем он был — хоть немного.
Читайте совет полностью. Он предлагает улучшить код, например, в том же классе, в который вы вносите правки. А не переделывать всё подряд под себя, потому что не нравится.
А если совсем не заниматься «улучшайзингом», то система в скором времени скатится в «Big ball of mud» — для чего есть очевидные предпосылки — первоначальный дизайн никогда не удовлетворит все будущие требования.
Зачем сравнивать строки и передавать вектора?!
Мы же не хотим измерять, как работает strcmp и менеджер памяти.
Так как вектора используются просто для выборки — переделал на for по коллекции с нужным условием.
С фиксом для количества эпох время обучения сократилось со 102 до 1 секунды.
Для сравнения — kotlin на этой же машине выдаёт 7 секунд.
Неплохой тест получился.
Приятно, когда берёшь исходник и он компилируется и работает.
К тому же вышло неплохое сравнение именно реализации на разных языках программирования.
Конечно качество кода хромает и сложно говорить о сравнении производительности между языками — всё-таки для одних языков используются ссылочные типы, а для с++ доступ по индексу.
Такое разделение скорее всего не будет улучшением кодовой базы и следует его проверить на соответствие другим принципам, или на соответствие принятой архитектуре.
В каждый отдельный момент причина одна - требования заказчика. Если по одному требованию заказчика, мы в одном классе меняем данные и методы и не затрагиваем другие классы - то это хорошо. Если мы по разным требованиям заказчика, опять всё меняем только в одном классе - то это плохо - скорее всего наш класс реализует слишком много (склонность к божественному классу) и его функциональность надо перегруппировать.
" remember that the reasons for change are people. It is people who request changes." последний параграф в https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Код на рис.3 с "проваливающимися" условиями в результате на рис.4,б последний PL блок вычисляет результат за 3 такта вместо ожидаемых 5
Получается есть сохраняющаяся сложность — это полезная информация. А сложность, «которую невозможно оправдать», — это помеха. И методики чистки кода пытаются снизить уровень «помехи». Неудачное применение методик может привести не к снижению уровня помехи, а просто к преобразованию, в лучшем случае, «помехи» из одного вида в другой.
Окончательную полировку-рефакторинг, конечно, никто не отменял. В процессе реализации может накопиться много лишнего — всё-таки примерный план — это не UML с описанием всего возможного.
3-ий говорит о том, что не надо писать то, что действительно не требуется прямо сейчас (заказчиком или требованиями), то есть не надо реализовывать что-то на будущее. Потому что в будущем могут появиться, вообще, прямо противоположные требования.
1-ый же говорит: «Вот делаешь изменения — почисти старый код, чтобы он, возможно, не конфликтовал с новыми реалиями, а, возможно, просто не очень аккуратный старый код или совсем не аккуратный старый код.»
И тут, конечно, могут быть свои стайл гайды — вплоть до отдельной таски или отдельной ветки. Но всё это не нарушает совет — главное оставить код лучше, чем он был — хоть немного.
А если совсем не заниматься «улучшайзингом», то система в скором времени скатится в «Big ball of mud» — для чего есть очевидные предпосылки — первоначальный дизайн никогда не удовлетворит все будущие требования.
Мы же не хотим измерять, как работает strcmp и менеджер памяти.
Так как вектора используются просто для выборки — переделал на for по коллекции с нужным условием.
С фиксом для количества эпох время обучения сократилось со 102 до 1 секунды.
Для сравнения — kotlin на этой же машине выдаёт 7 секунд.
Приятно, когда берёшь исходник и он компилируется и работает.
К тому же вышло неплохое сравнение именно реализации на разных языках программирования.
Конечно качество кода хромает и сложно говорить о сравнении производительности между языками — всё-таки для одних языков используются ссылочные типы, а для с++ доступ по индексу.