GK
Суть - нужно повысить степень самообслуживания при производстве информационных продуктов. Как это будет реализовано в каждом конкретном случае, это уже другой вопрос.
Size: a a a
2021 February 01
VN
Суть - нужно повысить степень самообслуживания при производстве информационных продуктов. Как это будет реализовано в каждом конкретном случае, это уже другой вопрос.
Самообслуживание повышает порог входа :(
GK
V N
Самообслуживание повышает порог входа :(
Тот самый trade-off
VN
Согласен. Но все равно это плота за скорость :(
VN
Даже в мышеловке сыр одному стоит денег, а другому жизни :(
М
GK
А кто-то до сих пор на бересте пишет)
СЛ
Это е-береста. Инновационная.
СЛ
64-битная.
AL
AZ
DB
Запускаем книжный клуб по совместному чтению литературы по проектированию и архитектуре в ИТ
Встречаемся в онлайне каждую среду в 18 часов
Первая книга для чтения — Чистая архитектура, Роберт Мартин
https://www.ozon.ru/product/chistaya-arhitektura-iskusstvo-razrabotki-programmnogo-obespecheniya-147833453/
https://t.me/joinchat/IczKhYpiRejBO1xZ
Встречаемся в онлайне каждую среду в 18 часов
Первая книга для чтения — Чистая архитектура, Роберт Мартин
https://www.ozon.ru/product/chistaya-arhitektura-iskusstvo-razrabotki-programmnogo-obespecheniya-147833453/
https://t.me/joinchat/IczKhYpiRejBO1xZ
OS
Мне не надо, я просто выше спросил:
какие законы в архитектуре ПО существуют и которые следовало бы знать уважающему себя спецу (например я мог бы это включить в общий курс лекций)
В качестве примеров таких законов назвал
закон Конвея - который как я понимаю неумолимый как предел скорости света:)
закон Деметера -(закон Деметры), по разному встречается в литературы и являющийся частным случаем Low coupling
CAP теорема
в ходе дискуссии были упомянуты принципы SOLID И GRASP - являются ли они законами в полном смысле или нет. наверное да как эмпирические
добавили закон Седова - никогда ранее не слышал, было интересно.
Разные дискуссанты разветвляли дискуссию на разные ветви, все в конце концов перемешалось и от начала ушло далеко:)
какие законы в архитектуре ПО существуют и которые следовало бы знать уважающему себя спецу (например я мог бы это включить в общий курс лекций)
В качестве примеров таких законов назвал
закон Конвея - который как я понимаю неумолимый как предел скорости света:)
закон Деметера -(закон Деметры), по разному встречается в литературы и являющийся частным случаем Low coupling
CAP теорема
в ходе дискуссии были упомянуты принципы SOLID И GRASP - являются ли они законами в полном смысле или нет. наверное да как эмпирические
добавили закон Седова - никогда ранее не слышал, было интересно.
Разные дискуссанты разветвляли дискуссию на разные ветви, все в конце концов перемешалось и от начала ушло далеко:)
"GitHub - dwmkerr/hacker-laws: 💻📖 Laws, Theories, Principles and Patterns that developers will find useful. #hackerlaws" https://github.com/dwmkerr/hacker-laws
VA
"GitHub - dwmkerr/hacker-laws: 💻📖 Laws, Theories, Principles and Patterns that developers will find useful. #hackerlaws" https://github.com/dwmkerr/hacker-laws
Крутая репка, схоронил
ST
#реклама
Канал для серьезных тестировщиков и QA. Свежие новости в сфере тестирования ПО, обучающие видеоматериалы, интересные статьи. Присоединяйся @serious_tester 👍
Канал для серьезных тестировщиков и QA. Свежие новости в сфере тестирования ПО, обучающие видеоматериалы, интересные статьи. Присоединяйся @serious_tester 👍
EG
"GitHub - dwmkerr/hacker-laws: 💻📖 Laws, Theories, Principles and Patterns that developers will find useful. #hackerlaws" https://github.com/dwmkerr/hacker-laws
Спасибо
EG
"GitHub - dwmkerr/hacker-laws: 💻📖 Laws, Theories, Principles and Patterns that developers will find useful. #hackerlaws" https://github.com/dwmkerr/hacker-laws
Посмотрел, вааще супер :) Спасибо
ТЛ
"GitHub - dwmkerr/hacker-laws: 💻📖 Laws, Theories, Principles and Patterns that developers will find useful. #hackerlaws" https://github.com/dwmkerr/hacker-laws
👍 благодарим
IB
А не наоборот? Пусть меня не сильно пинают, но дизайн про реализацию функциональных требований, а архитектура про реализацию нефункциональных. Ну очень грубо.
Предложу вам другое понимание (и вроде согласованное с классиками). "Любая архитектура - это дизайн. Не любой дизайн - это архитектура." Это, кажется, Philipp Kruchten. Ну так вот. Дизайн - все проектные решения. Архитектура - только фундаментальные. Граница, конечно же, нечеткая, а не проходит по виду решений (ФТ/НФТ или что-то такое). Архитектура, high-level design и low-level design соотносятся примерно как вершина горы, склон, и подножие. Характерные области в общем поле зависящих друг от друга дизайн-решений. Пытаться убрать все решения по ФТ и их реализации - сильно не рекомендуется. Обычно ФТ (основные фичи, взятые в крупном) очень сильно шейпят архитектуру.