Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Это понятно. Я б с удовольствием наделал мелких функций, но в описанных выше условиях отслеживать все возможные пути вызовов очень геморройно, хоть у меня все и утыкано assert'ами.

Хотел бы пояснить тут немного.
Имеется в виду, что поток выполнения один, то есть выбор стоит между:

function X {
   if (yyy) {
      aaa
      bbb
      ccc
   }
}

и

function X
{
   if (yyy) {
     Z
  }
}

function Z {
  aaa
  bbb
  ccc
}

Мне кажется, исполнение этого куска не должно зависеть от приоритетов или блокировок, то есть, технически,
это то же самое (но потенциально есть лишний вызов функции во втором случае)?
Второе решение потенциально улучшает читаемость кода за счет ухудшения его производительности.
Впрочем, практики проектирования вроде вообще все такие — улучшают что-то одно за счет ухудшения чего-то другого.

Вроде как довольно тривиальная вещь, для понимания ценности или использования которой не нужно быть семи пядей во лбу
Так почему бы не использовать подобные приемы в своем коде. То есть, не очень понятно в чем тут упомянутая разница "стратегией" и "тактикой".
Речь же просто о наборе практик, которые позволяют создавать что-то что можно будет поддерживать с меньшими усилиями. Или?

bnk>>Также чтобы их можно было протестировать независимо друг от друга например.

ЕМ>У меня не так много функций, зависимых только от параметров. Большая часть работает с членами классов, и они могут вызываться не только из кода, который полностью контролирую я, но и из запросов, приходящих от системы, а запросы эти могут приходить на разных приоритетах, с разной доступностью ресурсов.

Можно и не тестировать (не писать юнит-тесты), это нормально (с) Малышева.jpg
Зависит от ситуации. Иногда просто хочется писать так, чтобы быть уверенным что на определенных параметрах вызова точно получится определенный результат, а вручную проверить сложно.
К системным вызовам скорее всего неприменимо. Но кроме системных вызовов бывает есть же куча служебных функций (начиная от преобразования строк например) которые являются самодостаточными.
Чем большую часть системы можно так проверить, тем выше уверенность что ничего не сломается при внесении изменений.

bnk>>Чем-то похоже на чтение книг типа "Искусство войны".

ЕМ>Подобные книги в основном описывают стратегию, а у меня весь затык на тактике

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Это понятно. Я б с удовольствием наделал мелких функций, но в описанных выше условиях отслеживать все возможные пути вызовов очень геморройно, хоть у меня все и утыкано assert'ами.

Хотел бы пояснить тут немного.
Имеется в виду, что поток выполнения один, то есть выбор стоит между:

function X {
   if (yyy) {
      aaa
      bbb
      ccc
   }
}

и

function X
{
   if (yyy) {
     Z
  }
}

function Z {
  aaa
  bbb
  ccc
}

Мне кажется, исполнение этого куска не должно зависеть от приоритетов или блокировок, то есть, технически,
это то же самое (но потенциально есть лишний вызов функции во втором случае)?
Второе решение потенциально улучшает читаемость кода за счет ухудшения его производительности.
Впрочем, практики проектирования вроде вообще все такие — улучшают что-то одно за счет ухудшения чего-то другого.

Вроде как довольно тривиальная вещь, для понимания ценности или использования которой не нужно быть семи пядей во лбу
Так почему бы не использовать подобные приемы в своем коде. То есть, не очень понятно в чем тут упомянутая разница "стратегией" и "тактикой". В данном примере — "разделяй и властвуй"
Речь же просто о наборе практик для создания продукта, который можно будет поддерживать и развивать с меньшими усилиями. Или?

bnk>>Также чтобы их можно было протестировать независимо друг от друга например.

ЕМ>У меня не так много функций, зависимых только от параметров. Большая часть работает с членами классов, и они могут вызываться не только из кода, который полностью контролирую я, но и из запросов, приходящих от системы, а запросы эти могут приходить на разных приоритетах, с разной доступностью ресурсов.

Можно и не тестировать (не писать юнит-тесты), это нормально (с) Малышева.jpg
Зависит от ситуации. Иногда просто хочется писать так, чтобы быть уверенным что на определенных параметрах вызова точно получится определенный результат, а вручную проверить сложно.
К системным вызовам скорее всего неприменимо. Но кроме системных вызовов бывает есть же куча служебных функций (начиная от преобразования строк например) которые являются самодостаточными.
Чем большую часть системы можно так проверить, тем выше уверенность что ничего не сломается при внесении изменений.

bnk>>Чем-то похоже на чтение книг типа "Искусство войны".

ЕМ>Подобные книги в основном описывают стратегию, а у меня весь затык на тактике

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