Рефакторинг сложных алгоритмов

Присматриваюсь к следующим вариантам

ИМХО это не варианты, а то, что тебе надо сделать:

• Сначала разбиваешь на компоненты, компоненты, содержащие копоненты и т.д. (я юзаю mindmap для наглядности);
• Потом последовательно настраиваешь связи между ними;
• В зависимости от поведения реализуешь для каждого компонента ту или иную парадигму

В итоге у тебя должен получится код на 90% состоящий из типовых взаимовызовов компонентов и кучи этих самых компонентов, с закреплённым поведением.

Теоретически, да. Но по каждому пункту:

• Разбить можно и нужно, но такое разбиение не бесплатно. Как минимум определение интерфейса и «контракта» для компоненты.
• Проблема в том, что связи могут быть «все ко всем». Т.е. тут даже многослойную архитектуру не запилишь (как сетевой стек, например). Можно все отношения запихнуть в медиатор, но... :D
• Вот это интересно. Функциональное программирование с его чистотой и иммутабельностью значительно упрощают понимание системы. Меньше «нежданчиков», так сказать.

я хочу знать, как пишутся сложные программы

/fixed

Кто после троллей идёт на лоре? Лисперы потом идут :)

Как минимум определение интерфейса и «контракта» для компоненты.

Я же не предлагаю прям сто тыщь компонент - по одной на сигнал. Можно же их сгруппировать?

Проблема в том, что связи могут быть «все ко всем».

Опять же можно добавить уровень и пусть компоненты обмениваются сущностями «связь» (или «соединение» и т.д.)

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

Я работал в инвестбанке, алгоритмы там были порой сложные. ИМХО весь секрет успеха во-первых в грамотном разбиении на компоненты (сервисы) во-вторых банально в умении хорошо кодировать: выбирать хорошие названия переменных и методов, бить код на маленькие понятные методы и так далее. Короче никакой магии, опыт, опыт, опыт.

Завтра ищешь в интернете книжку Dive into python. Похуй если ничего не поймешь. Затем идешь на python.org и изучаешь стандартную библиотеку от корки до корки. Потом зубришь, именно, сука, вызубриваешь конвенцию по написанию питоньего кода - PEP8, чтобы от зубов отскакивало. Когда напишешь свою первую имиджборду, по пути изучив верстку на html+css, скачиваешь и изучаешь любой питоний асинхронный вебсервер, рекомендую Tornado или Gevent. Как переделаешь имиджборду, чтобы выдавала по крайней мере 5 тысяч запросов в секунду, можешь идти дальше - тебя ждет увлекательный мир хайлоада. Apache Hadoop, сверхбыстрые асинхронные key-value хранилища, MapReduce. Отсос хиккующих выблядков / просто неудачников типа рейфага или сисярп/джава-хуесосов, которые сосут хуй по жизни не заставит себя ждать и уже через пол года ты будешь получать такие суммы, что любая баба будет течь при одном упоминании твоей зарплаты.

Язык какой? Просто проще будет понять глубину проблемы.

Любой императивный со статической типизацией. А вообще не важно.

проще будет понять глубину проблемы.

Ха! Она как-то зависит от языка? :)

Я на сишкошарпике сейчас перепроектирую. Пока 105 сущностей, которые можно описать фразой «данные от датчика поступают в базу данных и т.д.». В рабочем сервере 46 классов. Может усложнение всё-таки нужно?

Судя по словам «компонента», «медиатор», «контракт» и «Вот это интересно, Функциональное программирование» система у тебя попроще будет нашей клиники, и там не так уж много работы оптребует, т.к. эти сущности слишком близко «к железу» :)

Но тем не менее.

Ты девелопер или архитектор? Если девелопер - наступил исторический момент в вашей конторке нанять (избрать) архитектора ( и аналитика(-ов!). Если архитектор, то начинай (очевидно же!) с рисования собсно предметной области. У нас похожая ситуация, разуплотнение сложной и запутанной системы начинали с анализа предметки и того, как системы легли на нее. Когда будет в наличии внятная композиция подсистем (это не оговорка относительно «систем» упомянутых ранее) в виде диаграмм, начнется самая мякотка - методичное преобразование одной (нескольких - в зависимости от размера команды) за другой подсистем к более вменяемому виду. и вот когда подсистема «развалится» на набор компонент, вот где-то тут можно тихонько-легонько для каждой компоненты включать слова: «контракт» и «Функциональное программирование». Как-то так. Для рефакторинга необходимо полное понимание и контроль ситуации. В одном человеке совмещать разработвчика и аналитика будет тяжко или неэффективно.