Python-сообщество

Мотив:
хочу понять основы построения любой системы,для того чтобы продвигать и пользоваться знаниями о построении любых систем

Ожидаемый результат:
Любая информация,полученая от участников сообщества по этой теме.
Интересен ваш опыт создания систем,по каким канонам строили?
Какими системами восхищаетесь?Чем эта система интересна.Примеры плохих систем?
Системы,основанные на взаимодействии людей.И любые другие системы.

Мое понятие термина “система”- совокупность компонентов,содействующих достижению
Основного результата работы системы.Примеры систем: механические часы, компьютерная программа,футбольная команда,живой организм, и тд

На входе: ваши мысли,ссылки на интересные статьи по теме,живое рассуждение,дискуссия.

По Вашему мнению с чего начинается любая система?

xam1816
По Вашему мнению с чего начинается любая система?

После некоторого изучения этого вопроса,у меня сформировалось мнение:

“Любая система начинается с осознания какой-то проблемы,нужды,какого-то мотива,вопроса ”зачем?“(одним словом не могу выразить)”

….Поэтому я начал эту тему в таком ключе.Зачем знать о создании систем?Да потому-что люди постоянно строят системы.Систему можно увидеть во всем,мы делаем их осознанно или неосознанно.Моя же цель разобраться в построении эффективных систем.Это мотив.
….Только зная о проблеме,можно сформировать какой-то конечный результат,который будет решать эту проблему, или удовлетворять некий мотив.Если выразиться по-другому:“не зная конечного результата,неизвестно к чему стремиться.Это как участвовать в беге на неопределенную дистанцию. ”
….Теперь когда знаешь конечный результат,можно сложить систему из компонентов,которые работают на достижение основного результата.Каждый компонент дает свой результат.Компонент по сути является такой же системой(он решает какую-то проблему,задачу,у него свой мотив,свой конечный результат,и тоже состоит из систем более меньших)
….Система строится из существующих систем,это скажем так входные данные,которые могут складываться,вычитаться,иметь между собой отношение.

МОТИВ->РЕЗУЛЬТАТ->КОМПОНЕНТЫ->ВХОДНЫЕ ДАННЫЕ.

….Смотря на вопросы,которые задают новички,которые хотят научится программированию,а по другому это создать систему из алгоритмов,по моему мнению,должны сначала понять мотив,проблему.Замечали,как часто бывает на непонятный вопрос,мы говорим “А в чем проблема то?”,а тот сам не знает в чем,вот и непонятно какой-нужен результат.
….
Как вы считаете,на сколько актуальна эта тема?

xam1816
хочу понять основы построения любой системы,для того чтобы продвигать и пользоваться знаниями о построении любых систем

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

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

Хорошая система обладает пятью качествами (из книжки Буча по объектно-ориентированному анализу и объектно-ориентированному проектированию):
1) Иерархическая структура
2) Распределение базовых элементов по разным уровням
3) Разделение обязанностей по отдельным частям
4) Переиспользование структур и механизмов
5) Эволюция в виде цепочки стабильных состояний

Дальше примеры
1) Иерархическая структура
Что даёт иерархическая структура. Она даёт синергию и эмерджентность - появление у системы свойств, не присущих её элементам в отдельности; несводимость свойств системы к сумме свойств её компонентов.

Пример:
У нас есть полк солдат. Если перестрелять всех офицеров, этот полк превратится просто в стадо ничего не знающих и ничего не понимающих рядовых. Вроде по составу ничего сильно не изменилось, количество офицеров мало по сравнению с общей численностью, но при разрушении иерархической структуры структура стала плоской и перестала действовать как мощная единица. В то же время при грамотном командовании - при построении иерархии - это стадо образует какую-то мощь, появляющуюся из ниоткуда. Вот это “ниоткуда” и есть эмерджентность.

Соответственно, когда ты пишешь программу, не надо писать её плоской, её надо писать иерархической. Тогда она будет работать мощно.

2) Распределение базовых элементов по разным уровням
Это значит, что если система образует целое, то она должна состоять из каких-то отдельных повторяющихся элементов. Каждый из этих отдельных элементов сам по себе образует целое, поэтому он тоже должен состоять из отдельных повторяющихся элементов. Каждый из этих отдельных элементов сам по себе образует целое, поэтому он тоже должен состоять из отдельных повторяющихся элементов. И так оно идёт до самого низа, пока не дойдёт до неразложимых элементов (хотя таких нет, оно идёт бесконечно). Таким образом, самая верхняя система в качестве целого состоит как из базовых элементов уровня под ней, так и из базовых элементов подуровня уровня под ней, так и из базовых элементов подподуровня уровня под ней. И всё это происходит одновременно. То есть система состоит одновременно из разных базовых элементов, которые отделены друг от друга по уровням общности.

Пример:
У нас есть полк солдат. Полк состоит из батальонов. Батальоны состоят из рот. Роты состоят из взводов. Взводы состоят из отделений. Отделения состоят из солдат. Таким образом, полк состоит из батальонов, из рот, из взводов, из отделений и из солдат. И всё это происходит одновременно. Таким образом, полк может из одного своего батальона перекинуть какую-нибудь роту в другой свой батальон, и одновременно с этим полк может из одной своей роты перекинуть какой-нибудь взвод в другую свою роту, и одновременно с этим полк может из одного своего взвода перекинуть какое-нибудь отделение в другой свой взвод, и одновременно с этим полк может из одного своего отделения перекинуть какого-нибудь солдата в другое своё отделение. Вот это перекидывание элементов возможно благодаря тому, что они одинаковые. И при перекидывании этих элементов на разных уровнях у полка в целом ничего не меняется.

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

3) Разделение обязанностей по отдельным частям
Это значит, что сами части системы должны быть как можно самостоятельнее и независимее от других частей. Для самостоятельности часть должна быть собранной и действовать в одном направлении, её не должно разрывать в разные стороны. Для независимости часть не должна пользоваться чужими силами, а должна действовать только своими силами.

Пример:
У нас есть танк. В нём сидит экипаж. И этот экипаж что делает, он хочет поразить другой танк. Один член экипажа управляет танком, чтобы подъехать к месту выстрела и правильно встать. Другой член экипажа следит за другим танком и сообщает расстояние и место, куда надо подъехать, наводит пушку. Третий член экипажа заряжает снаряд и ждёт указания, когда нужно выстрелить и зарядить новый снаряд. Они действуют в одном направлении. Наводчик не вылазит из танка и не идёт чинить гусеницу в это время, механик тоже никуда не уходит, и заряжающий тоже сидит на своём месте. Это самостоятельность танка при поражении другого танка - внутри танка всё действует так, что танк как целое сможет выполнить эту задачу сам. Второе. В танке всё есть для поражения другого танка. Ему не нужно ждать, когда ему привезут снаряды на машине, снаряды есть внутри. Ему не нужно ждать, когда приедет наводчик и подскажет, куда подъехать для выстрела, наводчик есть внутри. Ему не нужно ждать водителя, который придёт из кустов и поведёт танк к месту выстрела, водитель есть внутри. Это независимость от других машин, танков и солдат.

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

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

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

Соответственно, когда ты пишешь программу, ты должен обращаться к уже написанным программам и искать там идеи. Там есть уже какие-то готовые идеи по структурам, какие-то придуманные механизмы. Если у тебя есть какие-то проекты, они должны быть написаны так, чтобы из них что-нибудь можно было выдернуть и вставить в абсолютно другой проект. Поэтому когда ты изготавливаешь функцию, она должна быть максимально общей, хотя, на первый взгляд, это не является необходимым для данного конкретного проекта и ты будешь думать “а зачем мне напрягаться и делать её общей? мне же тут нужно только что-то сделать”. Потом, когда ты будешь делать другой проект, ты вспомнишь, что у тебя есть такая-то функция, в таком-то проекте, написанном столько-то лет назад, и она у тебя, к счастью, сделана в общем виде и подойдёт в текущий проект без какой-либо переделки - прямо через копипаст. Так ты сэкономишь время и за минуту сделаешь работы на день. Бывает и неделю экономишь, потому что копировать можно не только маленькие функции, но и целые компоненты, состоящие из множества модулей и библиотек функций. И всё это нужно делать в одном проекте, чтобы у тебя проект был компактным, но чтобы мог делать разные вещи через одни и те же средства. Тогда и изучение проекта будет занимать меньше времени.

5) Эволюция в виде цепочки стабильных состояний
Это означает, что систему нельзя делать сразу в конечном виде. Это не получится сделать, как бы там тебе не казалось обратное. Любая продвинутая система появлялась постепенно. Она проходила ряд хорошо отделённых друг от друга стабильных состояний, в которых она подолгу находилась. Она приходила в какое-то состояние, находилась в нём долго, потом постепенно начинала из него выходить, выходила всё больше и больше, в какой-то момент она начинала скатываться к новому состоянию и потом она приходила в новое состояние окончательно, в котором она опять надолго останавливалась. И так потом повторялось снова. Это неизбежный процесс формирования системы в каком-то виде. Его нельзя проскочить.

Пример:
В армию приходит новобранец. И кто-нибудь говорит “а давайте сделаем из него не генерала армии, а хотя бы командира роты”. Ну, не хватает им там людей. И его начинают учить, тетрадку там дают какую-то, чтобы он записывал. Потом его одевают в офицерскую форму, дают пистолет с кабурой и фуражку, ставят перед ротой и говорят всей роте “это теперь ваш командир”. Допустим, он хороший человек, он хотя бы не будет их там мучать, как-то будет поправляться, если будет видеть, что делает что-то неправильно, признавать свои ошибки. Но вот нужно будет покормить роту, а для этого надо будет почистить картошку. А он не знает, как это происходит, потому что он в тетрадке только это записывал, из него же командира роты делали. И он не накормит солдат. То есть это даже не боевая задача, а он уже не вывозит её. Он должен был сначала сам всё это проходить. Месяцами выполнять эти задачи, переходить из рядового в ефрейтора, потом ефрейтором выполнять задачи посложнее. И так он вырастает, постепенно переходя из одного состояния в другое и находясь в каждом отдельном состоянии подолгу, а не по одному дню и так далее. И только после этого он вырастет и станет командиром роты, который был во всех этих состояниях. Невозможно сделать его командиром роты, не проведя его через все необходимые промежуточне состояния в тех временных промежутках, которые для этого необходимы.

Соответственно, когда ты пишешь программу, ты не должен делать из неё сразу многофункциональный комбайн. У тебя это не получится, хотя тебе будет казаться, что “вот оно, да я щас напишу, да оно сразу взлетит”. Не взлетит оно. Прохождение промежуточных состояний у программы неизбежно. Когда она будет проходить свои состояния, это будет видно очень отчётливо, ты не спутаешь две соседние версии. В каждом состоянии она просуществует долгое время, ты не сможешь сказать “а всё, неделя прошла, можно её дальше писать”. И с каждой версией настоящей, а не той, которую ты пытаешься налепить искусственно, ты будешь видеть большой отрыв в мощности программы.
Поэтому ты пишешь сначала просто набросок. Потом он работает у тебя. Потом ты этот набросок дорабатываешь немного. Потом он работает у тебя. Потом ты этот набросок доработанный дорабатываешь ещё немного. Потом он работает. Потом ты всё это повторяешь. И потом уже ты увидишь, что программа сделала шаг. Вот там она точно была гусеницей, а вот там она точно была коконом, а вот там она точно стала бабочкой. Их не перепутаешь.


tags: system grady booch

Отредактировано py.user.next (Фев. 6, 2021 02:04:33)

py.user.next
Так все хотят так делать. То есть ты далеко не первый, кто об этом задумался, и даже далеко не сотый.

Хорошо когда все придерживаются общего мотива,из этого складывается система.

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

Хочу донести всем читающим,это тема не про самолюбие,и показушничество,что мол “смотрите какой я умный и говорю умные слова”, а про то что эти знания о системах нужно продвигать,поднимать из памяти,искать среди пыльных книг,и ПЕРЕИЗЛАГАТЬ знания своими словами,примерами,сказаниями.Что толку если,это все затеряется в книгах,умах отдельных личностей,каких-то постах на форумах.

py.user.next
вот те, кто об этом думал раньше, они вот это всё придумали уже и изложили эти мысли в своих книгах

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

Пост выше py.user.nextа,яркий пример того как передаются знания,ведь он мог просто закончить пост на том,что все ответы уже есть,что я в свое время потратил ресурсы чтобы их раздобыть,а ты теперь хочешь чтобы я еще тратил ресурсы чтобы тебе их изложить своими словами,и вообще плати деньги,как сейчас любят делать.Он так не сказал,и теперь его мысли перешли на другие сознания,наградой для него будет то,что,кто-то приняв эту информацию к сведению,будет создавать системы,которые не будут его бесить своей нелогичностью, неэффективностью,противоречием.Много он сделал или мало,но он сделал,и теперь эти знания не сгниют вместе с туловищем.Спасибо ему за это!

Читаем,думаем,задаем вопросы,рассуждаем.

Прочитай про Буфер-Верёвка-Барабан, думаю что тебе это пригодится.

Отредактировано Rodegast (Фев. 6, 2021 19:42:41)

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

У меня идёт процесс самообучения. Соответственно, я использую инструменты, чтобы производить это самообучение эффективно.

Есть такое свойство у психики. Человек знает что-то и одновременно с этим человек думает, что знает это же. То есть человек верит, на самом деле, что знает там какое-то знание или что умеет какое-то действие выполнять. И очень часто эта связь оказывается ложной. Ложной, но при этом довольно устойчивой, может даже годами сохраняться. Человек думает, что умеет что-то делать, а когда пытается это сделать, оказывается, и для него самого в том числе это становится открытием, что у него не получается сделать это. Оказывается, что он это делать не умеет, хотя до этого он думал наоборот и был уверен на сто процентов. То есть психика верит в то, чего нет на самом деле. Это встречается довольно часто как у людей, так и у животных. Примеров можно найти миллион.

В программировании такое встречается сплошь и рядом, поэтому придумали такой приём “объясни уточке”. Ставят уточку на стол и ей объясняют, как работает программа, как написать такую-то функцию и так далее. И когда человек начинает объяснять то, что, по его мнению, он хорошо понимает, оказывается, что это его мнение ложно, потому что он не может объяснить. Так он узнаёт про свои пробелы в знаниях, которых ранее для него не существовало. Когда он про них узнаёт, он начинает эти запробеленные знания чинить - заполнять пробелы. И таким образом он приводит свои знания в соответствие своему мнению об этих знаниях. Меняет ложность связи на истинность.

Вот говорят “теория без практики мертва” - это из той же серии.

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

Rodegast
Прочитай про Буфер-Верёвка-Барабан, думаю что тебе это пригодится.

Это один из элементов довольно обширной модели. Есть книжка, где в одной из глав это дело описано, но это реально не всё, что там написано, а лишь малая часть. Брать этот элемент в отрыве от всей модели и применять его в каждом контексте я бы не стал. Нужно всю модель брать и смотреть, где он работает, а где нет.

Много хайповых тем есть. И не всегда они работают, хотя толпы ведутся на них.
Хайповые темы:
“Надо сохранять второй питон по максимуму”
“Сайты делать нужно на Django”
“Барабан-Буфер-Верёвка - отличный метод”
“Канбан везде должен быть”
“Всё должно быть на GitHub'е”

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


tags: psy

Отредактировано py.user.next (Фев. 7, 2021 00:14:10)

Rodegast
Прочитай про Буфер-Верёвка-Барабан, думаю что тебе это пригодится.

Здесь применили этот методТеория ограничений

Отредактировано xam1816 (Фев. 7, 2021 10:48:02)

py.user.next
Человек думает, что умеет что-то делать, а когда пытается это сделать, оказывается, и для него самого в том числе это становится открытием, что у него не получается сделать это. Оказывается, что он это делать не умеет, хотя до этого он думал наоборот и был уверен на сто процентов. То есть психика верит в то, чего нет на самом деле. Это встречается довольно часто как у людей, так и у животных. Примеров можно найти миллион.

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

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

Когда хочется понять,как достигается эффективность,то здесь тоже должны быть какие-то паттерны эффективности,которые опять же где-то описаны в каких-то “тайных скрижалях”.Посыл темы в этом и есть: поднять все эти знания наверх.Чтобы каждый,кто соберется строить систему понимал хоть какой-то базис.

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

По моему мнению,мы все компоненты одной системы,результатом которой является понимание мотива основной системы.

А пока

py.user.next
Вот говорят “теория без практики мертва”

,строим системы и смотрим на сколько они эффективны,логичны,удовлетворяют ли мотив


Читающим: Если у вас есть какие-то знания,или размышления на эту тему,как строить эффективные системы,пишите,делитесь ссылками,задавайте вопросы.

py.user.next
Всё должно быть на GitHub'е

я ртутью пользуюсь это плохо?

AD0DE412

py.user.next
Всё должно быть на GitHub'е

я ртутью пользуюсь это плохо?

До появления Git'а были другие системы контроля версий. Все сидели на них и считали их лучшими. И даже покупали их и радовались, что цены не очень высокие. Потом появился Git и убил их всех, теперь о тех системах никто и не вспоминает. Они даже бесплатно никому не нужны больше. Теперь те же люди сидят на GitHub'е, возникшем только благодаря существованию Git'а, и превозносят его, он у них в центре внимания. Они не понимают, что участь его ждёт точно такая же. Ну, и когда его купила Microsoft, весь мир перевернулся в их головах, они жутко расстроились и стали переходить на GitLab, хотя это просто полный аналог GitHub'а, а не нечто новое. То есть они, следуя за хайпом, в результате подарили свой свободный и неприкосновенный софт Microsoft'у, передав его ей в собственность. Теперь Microsoft решает, как ты будешь свой неприкосновенный софт хранить. Вот как это бывает. GitHub казался нерушимым, а оказался туфтой, продавшейся за три копейки. После Git'а в мире будет следующий шаг, который полностью уничтожит Git и все его особенности, просто заменит его. Вместе с ним отомрут все эти GitHub'ы/GitLab'ы и они станут никому не нужны. Однажды знания всех суперспециалистов обесценятся в ноль. А почему это произойдёт? Потому что они шли за хайпом, они изучали всё хайповое. Они потратили на эту кучу времени, всё про это знают и так и останутся в этом периоде. Когда он закончится, они будут устаревшими - великими спецами, но только там, в далёком прошлом.

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

Отредактировано py.user.next (Фев. 9, 2021 22:05:25)