Здравствуйте, gandjustas, Вы писали:

G>Этот рефакторинг выполняется автоматически и занимает минимум времени. Гораздо больше займет собственно понимание что делает код.

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

G>Так что для "восприятия" нужно "обучение".

Возможно термин восприятие не очень удачен, но в моём определении важно как раз то, что он отделён от обучения и относится к форме кода, а не его содержанию. Если у тебя есть более точное определение предлагай.

IT>>Сложность обучения придётся преодолевать каждому новому бойцу в команде, для которого порог вхождения в код выше его текущего предела.
G>Это еще более редкое явление.

G>Преодоление этих сложностей требует гораздо меньших затрат по сравнению с преодолением сложности изменений при постоянном развитии проекта.

Опять же это всё зависит от конкретного рассматриваемого случая. В моей команде используется всё, что сегодня доступно на рынке мэйнстрима: последние версии компиляторов и их новые возможности, последние технологии и т.д. Это позволяет нам перераспределить сложность наших проектов в сложность обучения и контролировать наш код малым числом людей. Я не возьму на работу человека далёкого от всего этого, например, такого, который застыл на уровен .NET 1.1. Не возьму по простой причине — затраты на его обучение не будут, как ты утверждаешь, меньше по сравнению с преодолением других видов сложности. Они будут значительно больше, и если это будет контрактник на 10 месяцев, то за это время он не успеет сделать ничего полезного.

G>>>3)Пониятие алгоритмической сложности слишком обобщено. Напрмиер разработка парсера языка и трехзвенной бухгалтерской системы обладают высокой сложностью, но причины сложности совершенно разные.
IT>>Какие?
G>В случае парсера — нетривиальные алгоритмы — неочевидное преобразование входных данных в выходные, которое вряд ли получится декомпозировать на более протые части. В случае бухгалтерской системы все можно до элементарных вещей декопозировать, но возникает пролема распределения обязанностей между программными модулями и обеспечение их взаимодействия.

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