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

scf>время, убитое на попытки сделать единообразно и хорошо, очень существенно превышает время, потраченное на делание велью.

Ладно б только время, убитое на сами попытки сделать. Много времени уходит на мучительные раздумья и попытки хотя бы понять, как лучше делать.

scf>код, который я реально переиспользовал на практике — это код, который не зависит от остального приложения и библиотек с нестабильным API.

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

scf>чтобы собрать приложение из изолированных модульных кусочков, нужно писать очень много glue code — для интеграции этих кусочков между собой.

Именно. Вот я сейчас наплодил полтора десятка классов, наследующихся один от другого, чтобы точнее отразить иерархию сущностей — объем glue code уже сильно превысил объем кода, потребного для реализации того же самого на пяти-шести классах, с отработкой всех частных случаев.

scf>И я пока (примерно за 15 лет) не понял, какой путь правильный.

Я вот и за сорок не понял.

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

ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа? Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Сначала делаю максимально просто, даже если вижу что тут нужно бы сделать более общий вид, потом при добавлении функциональности, начинаю изменять этот простой код под новый сценарий, теперь он покрывает то что было +1 фича, берем следующую фичу и смотрим, не ложится опять переписываем, ложится хорошо, оставляем как есть. Вариант прочитал ТЗ, спроектировал, реализовал сразу под все сценарии не подходит, так как почти в каждом сценарии есть не учтенные нюансы, поэтому делаю максимально просто чтобы потом можно было просто изменить. Из проектирования есть только высокоуровневое разделение ответственности, этот класс/подсистема отвечает за такой то аспект программы, всё, реализуем только там, если получается много, разбиваем на несколько классов чтобы проще было поддерживать, но наружу торчит всё равно один фасад, да оберточного кода без логики, который тупо перекладывает данные или информирует что данные изменились приходится в таком случае писать достаточно много, но потом добавлять что то новое относительно просто.

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

ЕМ>Когда читаешь умные книги о разработке ПО, создается впечатление, что люди нашли способы достаточно быстрой и надежной разработки. Когда пытаешься применять это на практике, получается, что многие решения хороши лишь в идеальной среде, а в реальной они не намного лучше наколенных, зато менее очевидны и более сложны.
Нашли конечно, только они в других книгах описаны.


ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа?
Я иногда делаю pet projects, не связанные с зарабатыванием денег. Много раз уже спотыкался на одном и том же, назову это "проектирование снизу вверх".
Обычно желание делать pet project возникает не из-за реальной потребности, которую надо закрыть, а из того, что ты хочешь попробовать новый подход\язык\технологию. Поэтому начинаешь непосредственно разработку с основной фишки — новой технологии, языка или подхода. Аккуратно воспроизводишь то, что ты видел в статьях, учебных видео или книжках. А потом оказывается что все это не помогает закончить программу. Получив новый опыт ты уходишь на второй круг, но начинаешь с того же места. Далее третий, и так до бесконечности.

Все pet-проекты, которые я довел до конца, были созданы начиная с "интерфейса пользователя", не всегда это был именно GUI, иногда это было просто число возвращаемое функцией в плагине, но я заранее знал какое это должно быть число.
Я даже больше скажу: вообще нет смысла заниматься кодированием пока вы не определите как будет "выглядеть" ваше приложение для "пользователя". Ибо вы не дойдете до конца.


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

После того как "интерфейс пользователя" готов, то возникают за ним котроллеры\хэндлеры\баттонклики в которых пишется логика. Если логика разрастается сильно, то проводится рефакторинг, выделяются шаблоны итд.



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


ЕМ>Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Как-то так https://youtu.be/2RhvJ4VY6Cg

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

I>Сначала делаю максимально просто, даже если вижу что тут нужно бы сделать более общий вид, потом при добавлении функциональности, начинаю изменять этот простой код под новый сценарий, теперь он покрывает то что было +1 фича, берем следующую фичу и смотрим

Такой метод годится только для независимых фич, вроде уже упомянутых операций по инициативе пользователя. К софту, который встраивается в ОС или ее подсистему сразу множеством концов, такое почти не применимо. Это примерно как ставить современный двигатель в автомобиль: нельзя его просто наживить на болты, подключить только трубку с топливом, и сразу запускать. Нужно подключить все трубки, датчики, клапаны и прочее, залить масло, антифриз (или хотя бы воду), и только после этого имеет смысл запускать.

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

G>Нашли конечно, только они в других книгах описаны.

В которых?

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

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

G>вообще нет смысла заниматься кодированием пока вы не определите как будет "выглядеть" ваше приложение для "пользователя". Ибо вы не дойдете до конца.

Во многих случаях у мой софт не взаимодействует с пользователем непосредственно — только через ОС и ее подсистемы. Он вообще не умеет "выглядеть" — умеет только отвечать на запросы и генерить свои.

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

Забыть можно, когда параллелизм вводится в виде бонуса, для ускорения/сглаживания работы. У меня он чаще всего является необходимым условием функционирования софта. Если где-то синхронизация/взаимоблокировка сделана неправильно, то очень быстро виснет или падает с малопонятными ошибками.

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

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

G>>Нашли конечно, только они в других книгах описаны.
ЕМ>В которых?
About Face Купера
Жемчужины программирования Бентли
Pragmatic Programmer Ханта и Томаса


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

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

ЕМ>Мне чаще приходится делать софт, получающий множество независимых сигналов/сообщений/запросов с разных сторон, обрабатывающих их все в совокупности, и генерирующий сигналы/сообщения/запросы в адрес других подсистем. Там большое значение имеют синхронизация, взаимные блокировки, режимы, состояния и т.п. По сути, это конечные автоматы с изрядным количеством входов, выходов и промежуточных состояний — например, реализация протоколов взаимодействия.
Я вижу проблему в том, что вы не на результате фокусируетесь, а на внутренней структуре программы. Это прекрасный способ никогда программу не сделать.

G>>вообще нет смысла заниматься кодированием пока вы не определите как будет "выглядеть" ваше приложение для "пользователя". Ибо вы не дойдете до конца.
ЕМ>Во многих случаях у мой софт не взаимодействует с пользователем непосредственно — только через ОС и ее подсистемы. Он вообще не умеет "выглядеть" — умеет только отвечать на запросы и генерить свои.
Это мантра, которая вам мешает.

G>>про параллельные потоки лучше сразу забыть пока у вас не заработает все в одном потоке.
ЕМ>Забыть можно, когда параллелизм вводится в виде бонуса, для ускорения/сглаживания работы. У меня он чаще всего является необходимым условием функционирования софта. Если где-то синхронизация/взаимоблокировка сделана неправильно, то очень быстро виснет или падает с малопонятными ошибками.
Это тоже мантра, которая вам мешает.
Не существует ни одно задачи где параллелизм является необходимым для работы.

Из всего сказанного могу сделать вывод, что вы программу делаете не для результата, а для того чтобы повозиться с многопоточностью, синхронизацией и блокировками. Вас очевидно привлекает этот процесс. Тут нечего исправлять.

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

G>About Face Купера
G>Жемчужины программирования Бентли
G>Pragmatic Programmer Ханта и Томаса

Спасибо, полистал навскидку. Первое — в основном об пользовательском интерфейсе, этого вопроса я даже не поднимал в данной ветке. Второе и третье — самые общие приемы, которые многократно описаны в различной литературе, статьях, гайдлайнах. Мало-мальски опытному программисту многое из этого понятно интуитивно. Так что не нашел там ничего особенного по обсуждаемым здесь вопросам. Если считаете, что я неправ — укажите, пожалуйста, конкретные главы/пункты.

G>Любую программу можно описать в терминах функций, принимающих что-то на вход и дающих что-то на выходе.

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

G>Я вижу проблему в том, что вы не на результате фокусируетесь, а на внутренней структуре программы.

Проблемы с видением результата у меня возникают в основном в плане GUI — какой внешний вид придать окнам программы, в каком виде удобнее отображать данные и элементы управления, как организовать структуру меню и т.п. Здесь я этих вопросов не поднимал — речь исключительно о внутренней структуре, которую нужно сделать максимально непротиворечивой, без лишних зависимостей (как статических, так и динамических).

ЕМ>>Во многих случаях у мой софт не взаимодействует с пользователем непосредственно — только через ОС и ее подсистемы. Он вообще не умеет "выглядеть" — умеет только отвечать на запросы и генерить свои.
G>Это мантра, которая вам мешает.

Вы представляете, как устроен и работает, например, драйвер устройства? Как, с Вашей точки зрения, "выглядят" драйверы дисков, видео- и звуковых адаптеров?

G>Не существует ни одно задачи где параллелизм является необходимым для работы.

Сильно подозреваю, что Ваш опыт в разработке софта весьма фрагментарен.

G>Из всего сказанного могу сделать вывод, что вы программу делаете не для результата, а для того чтобы повозиться с многопоточностью, синхронизацией и блокировками. Вас очевидно привлекает этот процесс.

Этот вывод следует исключительно из Вашей неосведомленности о вещах, которыми я преимущественно занимаюсь.

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

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

G>>About Face Купера
G>>Жемчужины программирования Бентли
G>>Pragmatic Programmer Ханта и Томаса

ЕМ>Спасибо, полистал навскидку. Первое — в основном об пользовательском интерфейсе, этого вопроса я даже не поднимал в данной ветке. Второе и третье — самые общие приемы, которые многократно описаны в различной литературе, статьях, гайдлайнах. Мало-мальски опытному программисту многое из этого понятно интуитивно. Так что не нашел там ничего особенного по обсуждаемым здесь вопросам. Если считаете, что я неправ — укажите, пожалуйста, конкретные главы/пункты.
Выглядит как "не читал, но осуждаю". Ну ваше правод.


G>>Любую программу можно описать в терминах функций, принимающих что-то на вход и дающих что-то на выходе.
ЕМ>Если свести все к абсурду, то любую программу можно представить, как функцию, на входе которой объект "задача", а на выходе — объект "решение". Но философия мне малоинтересна, интересны конкретные, практические приемы.
Это не абсурд, а самая что ни на есть правда. Вы представляете программу как функцию входных данных и разибваете её на шаги-функции, вызывающие друг друга, которые дают в итоге необходимые выходные данные.
Если у вас на старте нет представления о том, какая функция вам нужна, то программу вы не напишите.


G>>Я вижу проблему в том, что вы не на результате фокусируетесь, а на внутренней структуре программы.
ЕМ>Проблемы с видением результата у меня возникают в основном в плане GUI — какой внешний вид придать окнам программы, в каком виде удобнее отображать данные и элементы управления, как организовать структуру меню и т.п. Здесь я этих вопросов не поднимал — речь исключительно о внутренней структуре, которую нужно сделать максимально непротиворечивой, без лишних зависимостей (как статических, так и динамических).
Внутренняя структура зависит от интерфейса программы. Об этому упоминается в about face, которую вы не захотели читать.


ЕМ>>>Во многих случаях у мой софт не взаимодействует с пользователем непосредственно — только через ОС и ее подсистемы. Он вообще не умеет "выглядеть" — умеет только отвечать на запросы и генерить свои.
G>>Это мантра, которая вам мешает.
ЕМ>Вы представляете, как устроен и работает, например, драйвер устройства?
Да, даже создавал такой драйвер.

ЕМ>Как, с Вашей точки зрения, "выглядят" драйверы дисков, видео- и звуковых адаптеров?
Какое это имеет отношение к осбуждаемой теме?



G>>Не существует ни одно задачи где параллелизм является необходимым для работы.
ЕМ>Сильно подозреваю, что Ваш опыт в разработке софта весьма фрагментарен.
Подозреваю что вы тоже не знаете ни одной такой задачи.

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

G>Это не абсурд, а самая что ни на есть правда. Вы представляете программу как функцию входных данных и разибваете её на шаги-функции, вызывающие друг друга, которые дают в итоге необходимые выходные данные.
G>Если у вас на старте нет представления о том, какая функция вам нужна, то программу вы не напишите.

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

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

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

G>>Это не абсурд, а самая что ни на есть правда. Вы представляете программу как функцию входных данных и разибваете её на шаги-функции, вызывающие друг друга, которые дают в итоге необходимые выходные данные.
G>>Если у вас на старте нет представления о том, какая функция вам нужна, то программу вы не напишите.

scf>Ну серьезно, это выглядит как ответ программиста из анекдота. Всё правильно, как будто списано с академического пейпера (или статьи по хаскелю), но бесполезно для любой более-менее сложной программы. В качестве упражнения можно описать сайт рсдн как функцию входных данных
Берешь UI и каждую функцию в UI описываешь как функцию входных-выходных данных. Это очень помогает не только начать, но и закончить разработку.
Почему вы видите в этом проблему?

scf>Получится либо чушь, либо (если у вас нечеловеческий уровень интеллекта) спецификация валидная, но бесполезная без такого же уровня интеллекта.
А вы хоть раз пробовали так делать? подозреваю что нет.


Это мне напомнило давний спор про оценку размера программы и сроков разработки. Один мой знакомый, хорошо знающий модель COCOMO2, оценил размер будущей программы в строках и во времени разработки. Тимлид с ним спорил, что сейчас языки другие и вообще можно сделать быстрее. В итоге модель разошлась с реальностью не более чем на 10%.
Вообще любая зарекомендовавшая себя практика в ИТ выглядит как нерабочая и бесполезная пока ты ей не занимаешься.

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

vsb>>При таком подходе главное стараться писать код максимально изолированно

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

На мой взгляд этот вопрос стоило бы проработать подробней. Я не знаю API DirectX, но уверен, что всё можно оформить изолированно, с юнит-тестами и потом всё "сцепить" воедино, если поставить такую задачу. Добавить промежуточные интерфейсы где-то, например. Многопоточность — сложная тема, но и там есть свои паттерны, позволяющие бороться со сложностью и изолировать куски кода. Например когда архитектура построена в виде акторов, с одной стороны каждого актора можно тестировать, как обычный однопоточный объект, с другой стороны фреймворк, который обеспечивает запуск и взаимодействие акторов уже считается достаточно протестированным и обеспечивает многопоточность без багов (ну почти без багов, дедлок скорей всего всё ещё возможен, но всё же многие баги устраняются). Проблемы начинаются, когда потоками рулят вручную, с общим состоянием, ручной синхронизацией на мютексах или подобных примитивах. Такой код действительно не протестировать адекватно, поэтому его нужно по возможности избегать, если взглядом окинуть всё не получается.

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

бейсик это уровень написание скриптов на bash
нашли чем гордиться
о том что вы программирование изучали в 80x годах по вашим знаниям и видно

Евгений, прекращайте превращаться обросшего жиром тролля,
какое отношение дедлоки, гонки итд(ваши фантазии) имеют отношение к правильной декомпозиции задач для того что бы не было до черта связей которые вы не можете связать ?

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

ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа? Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Не, я начинаю колбасить код, который потом многократно переписывается.
Такого счастья, чтобы прямо сходу была готовая модель абстракции — практически не бывает.
Ну, вот недавно делал учебный проект — надо было напилить персистентные (иммутабельные) коллекции с приемлемым быстродействием.
И вот я раза три пытался нарулить такую штуку на системе типов дотнета — и в итоге сдался.

По логике вещей, иммутабл коллекция — она всегда ковариантна. То есть ImmutableList<Derived> можно приводить к ImmutableList<Base>.
В частности, при добавлении элемента Base в ImmutableList<Derived> должен получаться ImmutableList<Base>.
Это в предположении, ессно, что Derived унаследован от Base.
Увы, на C# такое ограничение не компилируется:

public class ImmutableList<T>
{
  public ImmutableList<B> Add(B item) where T: B => default;
}

Ну, ок. Можно написать метод-расширение:

public static class ImmutableHelper<T>
{
  public static ImmutableList<T> Add<D>(this ImmutableList<D> list, T item) where D: T => default;
}

А дальше — засада. Потому, что для производительности этой immutable коллекции надо сделать так, чтобы операция Add повторно использовала те же данные, которые уже лежат в существующем списке.
И если всё делать через интерфейсы (а вариантность в дотнете работает только через них), то производительность падает на дно. Банальная операция list[x] начинает тормозить, как не в себя (а должна быть не хуже o(log(N)), и с нормальным коэффициентом).

Вот я там код переписывал трижды, в попытках таки написать то, что я хочу.
В итоге вернулся к стандартному интерфейсу иммутабельных коллекций дотнета — там нет никакой вариантности, и в список Derived вы никакой Base не добавите. Только наоборот.

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

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

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

G>Выглядит как "не читал, но осуждаю".

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

G>Вы представляете программу как функцию входных данных и разибваете её на шаги-функции, вызывающие друг друга, которые дают в итоге необходимые выходные данные.

Это все прекрасно работает с программами, не имеющими промежуточных внутренних состояний. А у меня они почти все их имеют — более того, они строятся главным образом вокруг состояний, а не данных.

G>Если у вас на старте нет представления о том, какая функция вам нужна, то программу вы не напишите.

Представление о том, что нужно, у меня есть всегда. Вопрос о том, как это сделать, применив наименьшее количество кривых костылей.

G>Внутренняя структура зависит от интерфейса программы.

Еще раз напоминаю: программы, о которых здесь идет речь, вообще не имеют UI, как такового.

ЕМ>>Вы представляете, как устроен и работает, например, драйвер устройства?
G>Да, даже создавал такой драйвер.

Каким устройством он управлял? Как Вы организовали хотя бы обработку прерываний без синхронизации с основным кодом?

ЕМ>>Как, с Вашей точки зрения, "выглядят" драйверы дисков, видео- и звуковых адаптеров?
G>Какое это имеет отношение к осбуждаемой теме?

Самое непосредственное. По-Вашему, пока разработчик драйвера не представит себе, как тот "выглядит", он не сможет его изготовить.

G>>>Не существует ни одно задачи где параллелизм является необходимым для работы.
ЕМ>>Сильно подозреваю, что Ваш опыт в разработке софта весьма фрагментарен.
G>Подозреваю что вы тоже не знаете ни одной такой задачи.

Какой "такой"?

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

R>бейсик это уровень написание скриптов на bash
R>нашли чем гордиться

Где Вы углядели, чтоб я "гордился" бейсиком? Я его и не знал-то никогда толком.

R>какое отношение дедлоки, гонки итд(ваши фантазии) имеют отношение к правильной декомпозиции задач для того что бы не было до черта связей которые вы не можете связать ?

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

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

S>я начинаю колбасить код, который потом многократно переписывается.

Вот и у меня к успеху приводила только такая тактика. Все попытки сперва создать изящную структуру, а затем наполнить ее работающими кодом, не поломав даже в малости, провалились.

S>А дальше — засада. Потому, что для производительности этой immutable коллекции надо сделать так, чтобы операция Add повторно использовала те же данные, которые уже лежат в существующем списке. И если всё делать через интерфейсы (а вариантность в дотнете работает только через них), то производительность падает на дно. Банальная операция list[x] начинает тормозить, как не в себя (а должна быть не хуже o(log(N)), и с нормальным коэффициентом).

А у меня много мест, где нехватка производительности будет не просто раздражать юзера, а приведет к полной неработоспособности конфигурации, в которой участвует софт и, как следствие, к полному отказу от него. Причем самые большие проблемы возникают даже не со скоростью выполнения "алгоритмического" кода, а с количеством взаимоблокировок потоков и местами их размещения в коде. Предсказать заранее, где именно будет тормозить, а где прокатит, почти никогда не получается — только эмпирически. А чтобы вся эта хрень хотя бы просто зашевелилась, нужно написать бОльшую часть кода, затычки мало где катят. Поэтому и приходится сперва сшивать все на живую нитку, затем приводить в устойчивое состояние, и только после этого пытаться придать стройность той мешанине, что получилась.

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

vsb>Я не знаю API DirectX, но уверен, что всё можно оформить изолированно, с юнит-тестами и потом всё "сцепить" воедино

API — это для пользовательских приложений, там действительно все довольно просто и ортогонально. А я про фильтры DirectShow, которые "на той стороне" от пользовательских приложений. Каждый фильтр обязан экспортировать кучу интерфейсов, за которые его регулярно и в разной последовательности дергают и клиентские приложения, и сама подсистема управления графом. Пока их все не реализуешь, в динамике (на живых потоках) почти ничего не работает.

Есть стандартный фреймворк Base Classes, где сделана более-менее приличная структура классов, для которых нужно реализовать свои методы. Синхронные фильтры, которые всю обработку делают в момент вызова метода, на них делать достаточно удобно, а с асинхронными, которые работают с устройствами, может быть геморрой, поскольку у фреймворка полно своих объектов синхронизации, у фильтра — своих, управление ходит туда-сюда далеко не очевидными путями, и нарваться на дедлок проще простого.

vsb>Добавить промежуточные интерфейсы где-то, например.

Пробовал. Когда их становится слишком много — начинаешь путаться еще больше.

vsb>Например когда архитектура построена в виде акторов, с одной стороны каждого актора можно тестировать, как обычный однопоточный объект, с другой стороны фреймворк, который обеспечивает запуск и взаимодействие акторов уже считается достаточно протестированным и обеспечивает многопоточность без багов (ну почти без багов, дедлок скорей всего всё ещё возможен, но всё же многие баги устраняются).

В такой структуре часто страдает производительность, поскольку для развязки потоков используются последовательные списки, сводятся к минимуму точки контакта, уменьшается количество объектов синхронизации с одновременным расширением их действия, и т.п.

vsb>Впрочем у тебя своя специфика с реалтаймом. То, о чём я пишу, достигается с некоторым оверхедом

Именно. Для большинства применений можно было бы допустить и оверхед, но есть немало случаев, где даже прилично оптимизированный код работает впритирку. Не хотелось бы потерять эти ниши.

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

ЕМ>Позже несколько раз пытался, как взрослые, начинать с проектирования. Помогало очень слабо. Общая структура программы, иерархия модулей/классов, их взаимодействие в целом неплохо видны и умозрительно.

Потому что нормальное проектирование это не про это все. Нормальный диздок начинается с параграфа, описывающего что мы собственно делаем, какую проблему решаем. Потом расписываем сценарии. Исходя из сценариев описываем UI или публичное API. А уж затем можно начинать углубляться в реализацию.
А ты все выворачиваешь вверх ногами, начиная проектирование с деталей реализации, а потом удивляешься фиговому результату.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А ты все выворачиваешь вверх ногами, начиная проектирование с деталей реализации

Где Вы у меня такое усмотрели? Наоборот, я пытался начинать с общей структуры. Но, пока не углубишься в детали реализации, далеко не всегда ясно, как будут передаваться управление и сообщения между моим кодом и кодом подсистемы, в которую он встраивается. А когда до этих деталей дошло, нередко оказывается, что данные и методы, изначально внутри, приходится доставать наружу, создавать лишние зависимости между классами, расширять сферу действия блокировок, чтобы уменьшить вероятность дедлока в цепочке, и вся изящно построенная структура становится все уродливее. В итоге каждый раз возникает вопрос, на кой нужны методы безопасного программирования, требующие лишней писанины, если их все равно приходится регулярно нарушать — снова с дополнительной писаниной в виде assert'ов, вспомогательных переменных/методов, комментариев "а этот костыль нам необходим потому, что ..." и т.п.

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

НС>>А ты все выворачиваешь вверх ногами, начиная проектирование с деталей реализации
ЕМ>Где Вы у меня такое усмотрели?

Важнее чтоя у тебя не усмотрел — требования, юзкейсы и т.п.

ЕМ> Наоборот, я пытался начинать с общей структуры.

Общая структура это и есть детали реализации, которые, в норме, должны вытекать из сценариев.

ЕМ> Но, пока не углубишься в детали реализации, далеко не всегда ясно, как будут передаваться управление и сообщения между моим кодом и кодом подсистемы, в которую он встраивается.

Ну вот в этом и есть твоя ошибка.