LINUX.ORG.RU

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

 


0

4

Вот есть такая проблема что логика программы очень сложная. Она сложная не потому, что написана плохо. Сложность кода естественным образом отражает сложность предметной области. Какие пути существуют в упрощении такого кода? Присматриваюсь к следующим вариантам: агентам (agent-oriented programming); явной state-machine; попытке разбить всё на компоненты, взамодействующие через передачу сообщений (SOA). На уровне кода всё становится чище (и проще в unit-тестировании), но на уровне семантики всё так же запутывающе сложно. Да и сами подходы имеют свои плюсы и минусы, оверхед. Одна задача решается, но создаются две новые.
Просто интересны истории успеха/неуспеха. Может кто-то писал ПО для авиации какой-нибудь, которое является системой зависящей от сотен параметров _одновременно_? Такие системы еще эволюционируют со временем (когда бизнес требования меняются). Кстати, в Linux kernel логика непростая, особенно в планировщике задач и i/o, но там вроде как революционные изменения происходят не часто.

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

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

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

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

ziemin ★★ ()
Ответ на: комментарий от ziemin

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

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

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

/fixed

tailgunner ★★★★★ ()
Ответ на: комментарий от nerdogeek

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

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

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

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

ziemin ★★ ()

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

d ★★★ ()

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

dizza ★★★★★ ()

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

anonymous ()

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

Dron ★★★★★ ()
Ответ на: комментарий от Dron

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

nerdogeek ()
Ответ на: комментарий от Dron

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

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

d_Artagnan ★★ ()
Ответ на: комментарий от nerdogeek

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

ziemin ★★ ()
Последнее исправление: ziemin (всего исправлений: 1)
Ответ на: комментарий от nerdogeek

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

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

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

d_Artagnan ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.