Когда у вас монолит (как человеческий мозг), то доступ к данным и принятие решений происходят очень просто - ваш мозг просто берет и обрабатывает всю информацию что есть в памяти. Вы не управляете этим специально, у мозга просто есть прямой доступ ко всем знаниям, поэтому решения принимаются быстро - либо моментально, либо за несколько минут подумав
Вы очень ошибаетесь и преукрашаете возможности человеческого мозга. Быстрый доступ к данным возможен только по накатанной нейронной колее - например, с чем-то часто работаешь, поэтому быстро можешь на что-то ответить или сделать.
Попробуйте-ка воспользоваться знаниям, которые давно не использовались? вытащить их.
Да, иногда можно биться над решением часами или днями, но это обычно когда не хватает какой-то информации. А вот если вся информация есть - монолитный мозг думает быстро.
Быстрые данные - полученные интуитивно - очень часто ошибочны. Много исследований на эту тему. Например, можно прочитать труды Канемана. Интуиция и распознание шаблонов - это вообще мимо интеллекта.
Про долгосрочную память можно ознакомиться в трудах Эббингауза.
Сравнение с мозгом некорректно в данном ключе. Либо надо более удачную метафору придумать.
Я работаю в организации, где 6к микросервисов и огромные монолиты под десятки ТБ реляционных данных. Нужно определиться "что такое монолит". У нас монолит - это журнючая БД (или набор БД) работающая под управлением одного экземпляра СУБД, с 10К+ хранимых процедур. Т.е. это ни что иное, как глобальные данные и куча процедурной обработки вокруг, с миллионами связей. Чувствуете пахнет 60мы годами 20ого века? Это стрельба дробью. Порушил связь - беда. И я вам скажу, что в такой монолит очень сложно вносить изменения. Любое мелкое изменение - необходимость менять логику, единомоментно, согласованно в куче мест только внутри БД. Обычно монолит характеризуется еще и внешними зависимостями (поискать связи по репе не такая и проблема, а вот за пределами - сущий ад). И поэтому внесение изменений в монолит это очень большой геморой, с вовлечением большого количества отделов и понятно дело согласований, техкомов, кроссдоменных проектов.
Микросервисная архитектура, при правильном использовании, как раз таки должна решить проблему глобальных данных. Если ты грамотно разделяешь ответственность, если ты умело скрываешь внутрянку, то будет тебе счастье. Но увы. Разработчики очень редко учатся разрабатывать/проектировать. Обычно они больше внимания уделяют инструментам - языкам программирования, базам данных, кафкам и т.д. А проектирование, по большей части, сводится к подражанию. "Мы так всегда делали". "Соседний отдел так делает".
Монолиты к сожалению не масштабируемые - ни по железу, ни по кодовой базе. Со временем, как раз из-за глобальных данных и числа связей, становятся неповоротливым "аппаратным" обеспечением. Но и неправильное применение микросервисных паттернов тоже приводит к такому же.
p.s.: опять же, подчеркну, нужно дать определение монолиту.
Миллион связей внутри, миллион связей наружи.. хрен редьки не слаще..
Проектироварие это грязная проблема, проектирование это эвристика, а не алгоритм. Вот здесь то собака и зарыта. Проще говоря - заставь дурака молиться, он и лоб расшибет (нашлепает бездумно микросервисы, монолиты, композиты и все что хочешь)
Ну вот можно поисследовать - деградировал ли человек с развитием ide. Раньше приходилось все вручную делать, апи знать, скрипты для сборки писать, если еще дальше капнуть - машинный (или мнемо) код. И т.д. Правда нужно будет еще определиться - а что такое деградация. Ибо абстрагирование и обобщение - это прогресс (в целом), это не ухудшение качеств.
Если настоящий ИИ, с бесконечной памятью, когда либо появится, то и люди не нужны будут. А так в любом случае нужны будут те кто разбирается и те кто побыстрому чтото начитает "ИИ". Пока выглядит так, что поменяется процесс, ускорится, но программирование никуда не денется.
Не нужно миллион. У вас в коде не бывает более 3х уровней вложенности? Откуда такое сопротивление на менее широкий TAB? В статье есть пример как выглядит файл кода с ТАВ в 4 пробела и в 2, ровно один и тот же файл.
Ну вот смотрю я на 2 и 4 - для меня одинаково, для когото лучше 4, для кого-то 2. Вы же пытаетесь доказать что только вы правы.
Есть куча книг на тему стайлов, написанных умными людьми. Просто их прочитайте и не придумывайте велосипеды
Есть исследование, что от 2 до 4 - эквивалентно для восприятия.
Я считаю, что в разных языках по разному воспринимаются табы. Гдето 2 достаточно, гдето лучше 4. Это зависит от уровня вложенности типичных блоков. Где можно писать маленькие фунции, там 2 за глаза. Где в основном большие портянки (какие нибудь хп на tsql), то лучшее добавить.
Некорректно сравнивать ВУЗ с курсами. ВУЗ это целый набор дисциплин, иногда очень узкоспециализированных, а курсы - какая-то конкретная тема, достаточно простая, рассчитанная на массы, в основном с посредственной теоретической базой. На курсах вы получаете очень ограниченные навыки. Для того чтобы изучить язык программирования конечно не нужно идти в ВУЗ, даже на курсы можно не ходить (есть куча книг, видео, статей). Для того чтобы админить ось - тоже не обязательно (хотя и здесь можно найти исключения). Но есть круг задач, которые требуют серьезной теоретической базы, в обширном кол-ве областей. Конечно можно пройти N специализированных курсов, но чем тогда это отличается от ВУЗа?
Сможете ли вы, пройдя какой-то курс, сделать что-то из последних достижений науки? Давайте попробуем найти ученых без вышки, нобелевских лауреатов? (по литературе найдете)
т.е., бинарный формат предполагает особый формат - типы/метки, особый вид кодирования. Обратная совместимость, вот это вот всё.
А ПО это что такое? Программное обеспечение. Т.е., предполагает, что будет меняться, улучшаться.
Вот надо изменить дерево (например, сделать дерево не деревом), как-то по другому перекодировать, ускорить. Чо делать со старыми IDE? еще и с таким разнообразием разных производителей. Чо делать с новыми - тащить поддержку старых форматов с самых первых версий?
А обратно как в текст? Разработка это не про машины, а про людей. 10 строчек читаем, 1 пишем.
IDE и так оптимизируют и хранят промежуточные состояния, которые изменяют инкрементально и только при изменении исходного текста. Всё уже давно придумано за нас и до нас.
Случилась проблема - помолился и нормально. Зачем разбираться в причинах, чтобы исправить и не повторять!? В тоску только себя вгонять и напрягаться лишний раз.
Вы очень ошибаетесь и преукрашаете возможности человеческого мозга. Быстрый доступ к данным возможен только по накатанной нейронной колее - например, с чем-то часто работаешь, поэтому быстро можешь на что-то ответить или сделать.
Попробуйте-ка воспользоваться знаниям, которые давно не использовались? вытащить их.
Быстрые данные - полученные интуитивно - очень часто ошибочны. Много исследований на эту тему. Например, можно прочитать труды Канемана. Интуиция и распознание шаблонов - это вообще мимо интеллекта.
Про долгосрочную память можно ознакомиться в трудах Эббингауза.
Сравнение с мозгом некорректно в данном ключе. Либо надо более удачную метафору придумать.
Я работаю в организации, где 6к микросервисов и огромные монолиты под десятки ТБ реляционных данных. Нужно определиться "что такое монолит". У нас монолит - это журнючая БД (или набор БД) работающая под управлением одного экземпляра СУБД, с 10К+ хранимых процедур. Т.е. это ни что иное, как глобальные данные и куча процедурной обработки вокруг, с миллионами связей. Чувствуете пахнет 60мы годами 20ого века? Это стрельба дробью. Порушил связь - беда. И я вам скажу, что в такой монолит очень сложно вносить изменения. Любое мелкое изменение - необходимость менять логику, единомоментно, согласованно в куче мест только внутри БД. Обычно монолит характеризуется еще и внешними зависимостями (поискать связи по репе не такая и проблема, а вот за пределами - сущий ад). И поэтому внесение изменений в монолит это очень большой геморой, с вовлечением большого количества отделов и понятно дело согласований, техкомов, кроссдоменных проектов.
Микросервисная архитектура, при правильном использовании, как раз таки должна решить проблему глобальных данных. Если ты грамотно разделяешь ответственность, если ты умело скрываешь внутрянку, то будет тебе счастье. Но увы. Разработчики очень редко учатся разрабатывать/проектировать. Обычно они больше внимания уделяют инструментам - языкам программирования, базам данных, кафкам и т.д. А проектирование, по большей части, сводится к подражанию. "Мы так всегда делали". "Соседний отдел так делает".
Монолиты к сожалению не масштабируемые - ни по железу, ни по кодовой базе. Со временем, как раз из-за глобальных данных и числа связей, становятся неповоротливым "аппаратным" обеспечением. Но и неправильное применение микросервисных паттернов тоже приводит к такому же.
p.s.: опять же, подчеркну, нужно дать определение монолиту.
Кто сказал, что я могу легко получить доступ к знаниям? Что такое легко?
При чем здесь мой комент и статья?
Миллион связей внутри, миллион связей наружи.. хрен редьки не слаще..
Проектироварие это грязная проблема, проектирование это эвристика, а не алгоритм. Вот здесь то собака и зарыта. Проще говоря - заставь дурака молиться, он и лоб расшибет (нашлепает бездумно микросервисы, монолиты, композиты и все что хочешь)
Хабр-конспекты..
Разобрать в кавычках
Не от всех, а от мин.ин.синк
Ну вот можно поисследовать - деградировал ли человек с развитием ide. Раньше приходилось все вручную делать, апи знать, скрипты для сборки писать, если еще дальше капнуть - машинный (или мнемо) код. И т.д. Правда нужно будет еще определиться - а что такое деградация. Ибо абстрагирование и обобщение - это прогресс (в целом), это не ухудшение качеств.
Если настоящий ИИ, с бесконечной памятью, когда либо появится, то и люди не нужны будут. А так в любом случае нужны будут те кто разбирается и те кто побыстрому чтото начитает "ИИ". Пока выглядит так, что поменяется процесс, ускорится, но программирование никуда не денется.
Пусть радуется
Мазерофгод. Автор вообще не понимает что такое cqrs и абстракция. Mediatr приплел зачем-то. Какое он отношение имеет к cqrs?
Заставь дурака молиться, он и лоб расшибет
я вот пожалел времени, чтобы сиё творение коментить )
это просто какой-то поток сознания
Обычная soa.
А сложность чего и по сравнению с чем?
Ну вот смотрю я на 2 и 4 - для меня одинаково, для когото лучше 4, для кого-то 2. Вы же пытаетесь доказать что только вы правы.
Есть куча книг на тему стайлов, написанных умными людьми. Просто их прочитайте и не придумывайте велосипеды
Есть исследование, что от 2 до 4 - эквивалентно для восприятия.
Я считаю, что в разных языках по разному воспринимаются табы. Гдето 2 достаточно, гдето лучше 4. Это зависит от уровня вложенности типичных блоков. Где можно писать маленькие фунции, там 2 за глаза. Где в основном большие портянки (какие нибудь хп на tsql), то лучшее добавить.
Однозначно да.
Некорректно сравнивать ВУЗ с курсами. ВУЗ это целый набор дисциплин, иногда очень узкоспециализированных, а курсы - какая-то конкретная тема, достаточно простая, рассчитанная на массы, в основном с посредственной теоретической базой. На курсах вы получаете очень ограниченные навыки.
Для того чтобы изучить язык программирования конечно не нужно идти в ВУЗ, даже на курсы можно не ходить (есть куча книг, видео, статей). Для того чтобы админить ось - тоже не обязательно (хотя и здесь можно найти исключения).
Но есть круг задач, которые требуют серьезной теоретической базы, в обширном кол-ве областей.
Конечно можно пройти N специализированных курсов, но чем тогда это отличается от ВУЗа?
Сможете ли вы, пройдя какой-то курс, сделать что-то из последних достижений науки?
Давайте попробуем найти ученых без вышки, нобелевских лауреатов? (по литературе найдете)
Сколько же внимания такому
высеруопусут.е., бинарный формат предполагает особый формат - типы/метки, особый вид кодирования. Обратная совместимость, вот это вот всё.
А ПО это что такое? Программное обеспечение. Т.е., предполагает, что будет меняться, улучшаться.
Вот надо изменить дерево (например, сделать дерево не деревом), как-то по другому перекодировать, ускорить. Чо делать со старыми IDE? еще и с таким разнообразием разных производителей. Чо делать с новыми - тащить поддержку старых форматов с самых первых версий?
А обратно как в текст? Разработка это не про машины, а про людей. 10 строчек читаем, 1 пишем.
IDE и так оптимизируют и хранят промежуточные состояния, которые изменяют инкрементально и только при изменении исходного текста. Всё уже давно придумано за нас и до нас.
1) нужно уметь писать 2) нужно уметь читать
Не абстракции ли дают упрощение? Гдето слышал, что они скрывают детали, которые можно игнорировать.
Хороший язык - богатый инструмент. Хочешь - пиши лапшу, а не хочешь - не пиши.
>> 20 лет.. для новичка... по c# ...практика.. запахи.. динамическое программирование...
Хоть и не читал, но вангую...
Случилась проблема - помолился и нормально. Зачем разбираться в причинах, чтобы исправить и не повторять!? В тоску только себя вгонять и напрягаться лишний раз.
Могут ли последовательные процессы быть конкуррентными?
А параллельные?
Кгам
Любая конкуррентность параллельна, но не наоборот правда.