вводишь новые контракты.

это одна плоскость

а интерфейсы тебе тоже масштаба не дают, согласись

интерфейсы тут в общем смысле, я повторюсь, я не про кейворд

это одна плоскость

не, вопрос как ты позволяешь расширять контракты. почитай всяких там Мэйеров, Робертов Мартинов.... да даже старичка Гради буча, который это говно с uml придумал)

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

ну и да - подавляющее большинство очень херовы в этих вещах...

вот-вот

принцип открытости-закрытости конечно збс

не потому что это сложно а потому что многие узнают об этом через 10 лет практики) и часто приходят к этому зафэйлив пяток проектов)

но только ничего не решает пока система статична

+

но только ничего не решает пока система статична

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

это как рассуждать о принципе единой ответственности без учета стрима изменений требований)

тьфу, сорян, я вообще непрвильно написал

сплю на ходу - "это ничего не решает когда твоя система динамична"

сплю на ходу - "это ничего не решает когда твоя система динамична"

что значит "система динамична"?)

меняет себя?...

я знаю только одну систему которая меняет себя - вирусы

(если мы про программы))

ну как пример

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

но прикол в том что все эти изменения, как ты заметил, эвалюционные, а значит в целом изменения в один момент времени будут довольно незначительны. Да, соблюсти open/close на 100% нельзя, но можно очень нехило за счет более высокого уровня декомпозиции и контроля над связанностью уменьшить эффект от этих изменений. И да, говно разманное по стенам в ходе строительства системы будет всегда. Увы.

короч это к вопросу о том почему формализовать процесс разработки так сложно - потому что сложно формализовать требования)) можешь про семантический разрыв в контексте формальных языков почитать0

читал, там все плохо

не знай, мне кажется все эти подходы збс заходят когда у тебя требованимя фризятся каждый спринт как минимум

а лучше вообще ватерфолл

но под кардинальные изменения эти принципы не заточены

иначе не придумывались бы бесконечно новые техники на тему КАК в очередной раз сделать DDD и TDD и BDD и вообще все что можно

в условиях "мы придумали это тогда-то" + "N лет" = "сегодня"

я неправ?

а лучше вообще ватерфолл

ты читал к слову публикацию в которой ватерфол упоминался впервые?))))) это отдельная ржака. 7-ми страничный документ, на первой странице описание классического ватерфола, на второй страничке легендарная картинка его описывающая, и 5 страниц почему это говно и почему нужно оптимизировать обратную связь между всеми стадиями (то что лет через 30 назвали agile))

не, оригинал не видел) надо глянуть

http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf

вот если интересно...

но под кардинальные изменения эти принципы не заточены

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

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

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

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

мы не на том уровне прогресса

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

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

ну потому что на данный момент дешевле и проще просто сделать новую систему

вопрос всегда упирается в стоимость

У Кента Бэка на эту тему есть любопытные лекции - типа X3

Explore, Expand and Extract

мы не на том уровне прогресса

ну это понятно) хотя на самом деле вопрос в том что люди могут сделать мощности но просто не знают что с ними делать

Бека на эту тему не читал, спс, интересно

ну это понятно) хотя на самом деле вопрос в том что люди могут сделать мощности но просто не знают что с ними делать

нет, то что ты описываешь подразумевает что система себя осознает. мы пока в такое не умеем и даже не доконца понимаем.

исключительно второе

вопрос "умеем" тут только в мощностях

а случайные мутации системы - это и так происходит))))

вопрос "умеем" тут только в мощностях

не думаю, мы принципы не понимаем. Кто знает, возможно мощности у нас уже есть, вопрос в архитектуре и подходах

вон только недавно оказалось что память в мозгу это не чисто электрический процесс) всего года 2-3 назад вроде.

так я тебе об этом и сказал - "умеем" это когда знаем как, а мы не знаем

электрохимический к сожалению... или к счастью

как и все процессы в мозге

лень гуглить, там были нюансы)

забей на нюансы, суть одна - не знаем что, а не как

короч... на сегодняшний день.... в основном все работают с технологиями 50-ти летней давности, развивается синтаксис, разваивается инструментарий (рефакторинг браузер, фак е, почти не глючит с 16-ю гигами оперативы и 4-ех ядерным процом))), мы работаем с несовершенными требованиями, зачастую вообще не разбираясь в них, и раз в 10 лет полностью переизобретаем все существующие подходы (потому что нет времени разбираться что уже есть)))

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

короч... на сегодняшний день.... в основном все работают с технологиями 50-ти летней давности, развивается синтаксис, разваивается инструментарий (рефакторинг браузер, фак е, почти не глючит с 16-ю гигами оперативы и 4-ех ядерным процом))), мы работаем с несовершенными требованиями, зачастую вообще не разбираясь в них, и раз в 10 лет полностью переизобретаем все существующие подходы (потому что нет времени разбираться что уже есть)))

+

даже Кент Бэк и Фаулер признают что XP и прочие штуки в целом были переизобретены. Вот в этой доке 1970-ого года было описано примерно это

а если ты посмотришь один видосик на ютубе - Mother of all demos - вообще хочется плакать

которую ты скинул? я прост не успел бы прочитать при всем желании

которую ты скинул? я прост не успел бы прочитать при всем желании

ну почитаешь))

я про доку 1970

короч оставлю видяшку 68-ого года и пойду плакать

https://www.youtube.com/watch?v=yJDv-zdhzMY

тебе не кажется что мне после этого программировать перестанет хотеться?)))

хз.... 68-ой год.... 60 лет прошло... а webrtc до сих пор глючит

оу оу, палегче, нахер это все, ты вспомни протоколы B2B у авиации

они позже появились но такие же хреновые)

история людей ничему не учит

не думаю, мы принципы не понимаем. Кто знает, возможно мощности у нас уже есть, вопрос в архитектуре и подходах

А ведь был прицидент, что отключили AI, который выработал свой собственный язык для переводов из любого языка в любой - испугались! Принципы уже реализованы, только боимся дать им свободу...

А ведь был прицидент, что отключили AI, который выработал свой собственный язык для переводов из любого языка в любой - испугались! Принципы уже реализованы, только боимся дать им свободу...

без пруфа это пустая болтовня)

ребят, а кто пробовал у себя что-то из service mesh?

linkerd, istio и т.д.

мне правая девушка всегда нравилась больше :) и да. вопрос. GraphQL - это же про выборку данных. т.е. read операции. write там как обычный RPC? или вообще в стандарт не входят?

Rest api:)

мне правая девушка всегда нравилась больше :) и да. вопрос. GraphQL - это же про выборку данных. т.е. read операции. write там как обычный RPC? или вообще в стандарт не входят?

Не, там есть мутации

Не, там есть мутации

Если не листать к оригинальному комменту, ощущение что ты про правую девушку

Там тоже есть

асимметрия это нормально

кстати я говорил про девушку! а не про REST апи :)

я как раз сейчас слайды делаю где показываю что rest - отстой :)

мне правая девушка всегда нравилась больше :) и да. вопрос. GraphQL - это же про выборку данных. т.е. read операции. write там как обычный RPC? или вообще в стандарт не входят?

а я вообще с опытом пришел к тому что RPC мне милее всего

а я вообще с опытом пришел к тому что RPC мне милее всего

+1

назвал метод понятными словами, фронтендер дернул его и получил то что надо ему

я как раз сейчас слайды делаю где показываю что rest - отстой :)

Рест норм

Просто это не про апишки, которые жсоны кидают

+ с Event Driven идеально сочетается

rest я на данный момент вижу как штуку для быстрого создания простого круда

Просто это не про апишки, которые жсоны кидают

там глаголов нормальных нет. приходится извращаться. придумывать псевдосущности

и вообще, когда про преимущества rest говорят чаще всего сами того не замечая описывают стандарт HTTP

там глаголов нормальных нет. приходится извращаться. придумывать псевдосущности

Где?

типо вот как здорово можно названием метода передать действие а не в uri

POST PUT DELETE...

POST PUT DELETE...

Это http verb