Пришлось тут окунуться в функцию расчта кредита в системе.
Если смотреть сверху то получатся тако дерево.
уровней вложенности порядка 4-5, и получается на каждом уровне идут ветвления и находясь на 3 уровне в одной ветке сложно понять откуда сюда попал и где находишься в рамках общего процесса.
Это нормально вообще на одну функцию иметь такой код и как с ним работать чтобы суть уловить?

ET>как с ним работать чтобы суть уловить?

Сверить код с ТЗ, которое будет представлять собой то же самое дерево с кучей вложенных условий.

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

ET>Пришлось тут окунуться в функцию расчта кредита в системе.
ET>Если смотреть сверху то получатся тако дерево.
ET>уровней вложенности порядка 4-5, и получается на каждом уровне идут ветвления и находясь на 3 уровне в одной ветке сложно понять откуда сюда попал и где находишься в рамках общего процесса.
ET>Это нормально вообще на одну функцию иметь такой код и как с ним работать чтобы суть уловить?

1. Вынести это дерево и весь связанный с ним бизнес-код в отдельную сущность, если ещё не сделано. Класс, файл и тд. Там не должно быть постороннего кода, всяких там работ с БД, жсонами и прочего. На вход некий объект-описание, на выходе ответ в виде скаляра или объекта.

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

3. Оставить все ветвления в одном месте. В идеале должен получиться псевдоанглийское (ну или псевдорунглийское, на вкус) описание бизнес-процесса.

В целом на этом можно закончить. Это описание можно дать специальным людям на предмет проверки его корректности с логической точки зрения.

Условно говоря

if (borrowerIsPerson) {
  if (borrowerIsDisabledPerson) {
    return false;
  }
  if (salaryEstimateIsNotEnough()) {
    return false;
  }
  ...
}

Если получается очень развесистое дерево, можно пытаться его рефакторить и выносить в под-деревья. Но тут опять же надо скорей от бизнес-описания идти, там скорей всего тоже будет какое-то разбиение процесса по кускам.

И, конечно, ко всему этому должен быть документ на человеческом языке, постановка или что-то в этом роде.

В общем цель — чтобы программный код семантически максимально соответствовал постановке на человеческом языке. Не нужно тут вспоминать про всякие DRY и тд, единственный критерий это насколько просто понять, что происходит и сверить с человеческой постановкой.

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

ET>Это нормально вообще на одну функцию иметь такой код и как с ним работать чтобы суть уловить?

Считается, что цикломатическая сложность не должна превышать 10-и. Обычно цикломатическая сложность ограничивается в правилах кодирования внутреннего документа компании.