![Создаем свой проектный фреймворк автотестирования API [Часть 1-3] - 1](https://www.pvsm.ru/images/2026/01/03/sozdaem-svoi-proektnyi-freimvork-avtotestirovaniya-API-chast-1-3.png "Создаем свой проектный фреймворк автотестирования API [Часть 1-3] - 1")
Артем
Head of QA
Рубрика «принципы проектирования»
Создаем свой проектный фреймворк автотестирования API [Часть 1-3]
2026-01-03 в 17:16, admin, рубрики: python, автоматизация тестирования, архитектура системы, принципы проектирования, Программирование, проектирование систем, сбор требований, слоистая архитектура, фреймворки для тестирования
UI за 35 лет: как интерфейсы дошли от Comic Sans до нейросетей
2025-08-18 в 7:04, admin, рубрики: UI, uiux, uiux design, принципы проектирования, трендыUI никогда не стоит на месте — за последние тридцать лет веб-дизайн из хаоса с кислотными цветами и мигающими кнопками превратился в воздушные интерфейсы с акцентом на удобство и адаптивность. Но как именно мы к этому пришли? В этой статье мы исследуем, почему одни решения стали стандартами, а другие исчезли несмотря на эффектность.
Анализируя прошлые тренды, можно увидеть, как сочетание инноваций и проверенных принципов юзабилити создавало по-настоящему устойчивые интерфейсные решения. Возможно, именно этот баланс между новым и проверенным временем окажется ключом к созданию интерфейсов будущего.
Умные программисты пишут STUPID-код
2023-10-18 в 13:00, admin, рубрики: ruvds_перевод, solid, stupid, принципы проектирования, шаблоны проектированияУмные программисты пишут STUPID-код, ведь они понимают, что неожиданно возникшая сложность может привести к провалу проекта.
▍ Страдание
На момент написания этой статьи на моих часах 21:30.
Этим утром я проснулся в хорошем, оптимистичном настроении, рассчитывая на прекрасный день, но теперь вымотан.
Я вымотан не физически, а, скорее, разочарован тем, что, несмотря на все имеющиеся у нас замечательные технологии, позволяющие писать наилучшее ПО, мы, как люди, профессионально пишущие код, по множеству причин склонны ценить больше сложность, а не простоту.
Читать полностью »
Актуальность принципов SOLID
2021-06-05 в 19:00, admin, рубрики: solid, архитектура, архитектурные паттерны, принципы проектирования, Программирование, проектирование, Проектирование и рефакторинг, рефакторинг, Роберт Мартин, Совершенный кодВпервые принципы SOLID были представлены в 2000 году в статье Design Principles and Design Patterns Роберта Мартина, также известного как Дядюшка Боб.
С тех пор прошло два десятилетия. Возникает вопрос - релевантны ли эти принципы до сих пор?
Перед вами перевод статьи Дядюшки Боба, опубликованной в октябре 2020 года, в которой он рассуждает об актуальности принципов SOLID для современной разработки.
Недавно я получил письмо с примерно следующими соображениями:
Как не понимать принципы развития архитектуры SOLID
2019-03-23 в 7:59, admin, рубрики: solid, Анализ и проектирование систем, архитектура, личный опыт, принципы проектирования, Программирование, Проектирование и рефакторинг, Роберт МартинЕсть проблема с описанием и толкованием принципов развития архитектуры SOLID (авторства Роберта Мартина). Во многих источниках дается их определение и даже примеры их использования. Изучая их и пробуя использованием примерить на себя, стабильно ловил себя на мысли, что не хватает объяснения магии их применения. И пытаясь увидеть внутренние шестеренки, понять — и для меня значит запомнить — разложил их по своим "терминам-полочкам". Хорошо если это будет полезно еще кому-нибудь.
Размышления о Манифесте разработчика умных систем
2018-12-22 в 14:35, admin, рубрики: IoT, Железо, Интернет вещей, интерфейсы, принципы проектирования, разработка, Разработка для интернета вещей, умный домНесколько дней назад я прочитал отличную статью "Манифест разработчика умных систем: 15 принципов"
Решил поделиться мыслями про слой ниже, а именно базовые принципы архитектуры, которая бы в основном соответствовала предложенным принципам.
Ввиду природы поста, он будет еще более субъективным, чем Манифест.
Манифест разработчика умных систем: 15 принципов
2018-12-17 в 9:38, admin, рубрики: IoT, Блог компании Samsung, Железо, Интернет вещей, интерфейсы, принципы проектирования, разработка, Разработка для интернета вещей, умный домМы предлагаем вашему вниманию статью Владислава Зайцева(vvzvlad), приглашенного гостя нашего блога. Владислав давно занимается темой «умных домов», и обобщив свой опыт, он предлагает следующие основные принципы дизайна такого рода систем.
Сегодня я хочу поговорить с вами об «умных» домах в частности и IoT-устройствах в целом. Но это будет не обычная статья: тут не будет железок, ссылок на производителей, кусков кода и репозитариев на гитхабе. Сегодня мы будем обсуждать нечто более высокоуровневое — принципы, по которым организуются «умные» системы.
Продолжая читать статью, вы соглашаетесь с тем, что вас устраивает следующий disclaimer.
Собственно, сам disclaimer
1) Все эти пункты касаются только потребительских IoT-систем (читай «умных домов»). Тех, что человек может купить в магазине и установить без привлечения специализированных инсталляторов/интеграторов.
2) Часть этих принципов не применима к промышленным системам (там свои требования и принципы), а также, к системам, где есть отделённые от пользователя эксплуатанты (например, умный дом, который устанавливается и обслуживается специально обученными людьми).
Также часть принципов не применима к системам уровня «игрушка для гиков», к самодельным и open-source системам, у которых нет единого product owner.
3) И, конечно, всё написанное ниже — это исключительно моё мнение, основанное на моём многолетнем опыте. Вы имеете право не соглашаться с ним.
2) Часть этих принципов не применима к промышленным системам (там свои требования и принципы), а также, к системам, где есть отделённые от пользователя эксплуатанты (например, умный дом, который устанавливается и обслуживается специально обученными людьми).
Также часть принципов не применима к системам уровня «игрушка для гиков», к самодельным и open-source системам, у которых нет единого product owner.
3) И, конечно, всё написанное ниже — это исключительно моё мнение, основанное на моём многолетнем опыте. Вы имеете право не соглашаться с ним.
Умный дом — это система, которая берёт на себя часть повседневных забот человека. Отсюда следует первый и самый основной принцип:
Читать полностью »
Околоархитектурные рассуждения или результаты одного спора
2016-02-12 в 7:52, admin, рубрики: C#, архитектура приложений, Блог компании Zfort Group, принципы проектирования, Программирование, проектирование взаимодействия, проектирование интерфейсов, разработка В один прекрасный обыкновенный четверг в одной команде разработчиков появились разногласия по поводу некоторых архитектурных решений, реализация которых была утверждена приказом сверху, а не родилась в ходе аргументированного спора. По прошествии некоторого времени подобный спор возник опять, уже на новом проекте. Дискуссия становилась все жарче, и для прояснения ситуации и достижения просветления даже были привлечены сторонние высшие силы. Последнее достигнуто не было, и все же, тем же волевым решение, был принят один из вариантов развития бытия. Но мудрый Каа один из участников обсуждения решил не оставлять в команде неразрешенных споров — почвы для возникновения конфликтов в будущем, раскола команды и другого мордобития, и предложил все решить всеобщей пьянкой составлением данного документа, который поможет членам команды достичь просветления и снова стать мягкими и пушистыми.
В данном документе мне было предложено описать преимущества и недостатки двух подходов, достичь консенсуса и воцарить мир и справедливость во Вселенной.
Ниже я и попытаюсь в меру своих интеллектуальных возможностей это сделать (поэтому буду использовать очень простые слова и выражения) и вынести на суд кровавых мясников почтенной публики.
Читать полностью »
Создание архитектуры программы или как проектировать табуретку
2016-02-04 в 13:18, admin, рубрики: Анализ и проектирование систем, архитектура приложений, принципы проектирования, Проектирование и рефакторинг, разработкаВзявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.
К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».
Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.
Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.Читать полностью »
Управление API и SOA
2015-04-20 в 8:51, admin, рубрики: .net, api, ASP, C#, Conference, gosharp, Governance, JBORS, JBOWS, rest, sla, Блог компании GeekFamily, принципы проектирования, метки: API, Governance, JBORS, JBOWS, REST, SLA, SOA 
Достижение начального успеха для Сервис-ориентированной Архитектуры (Service Oriented Architecture, SOA) определяется:
- созданием слабосвязанных соединений «потребитель-поставщик»,
- соблюдение принципа разделения ответственностей между потребителем и поставщиком,
- публикация набора повторно используемых, общих сервисов
- и обеспечение того, чтобы потребители приняли и стали использовать сервис.
Множество команд разработчиков создают и используют сервисы, но до сих пор идет мучительный подбор архитектуры, при которой сервисы будут широко использованы, с потенциалом для повторного использования внутренними командами разработки. Вместо создания согласованной сервисной архитектуры и демонстрации множественного использования одних и тех же сервисов, разработчики вновь и вновь не нарочно создают «Просто Набор Веб Сервисов» (Just a Bunch of Web Services (JBOWS)) или «Просто Набор REST Сервисов» (Just a Bunch of REST Services (JBORS)).
Простое приложение чаще всего работает с неким сервисом и спагетти-сетью конечных точек, поставщиков данных этого сервиса, которые переплетены связями один-к-одному. Многие команды в этом случае сходятся во мнении что фокус на SOA и REST не то чтобы помогал в решении вопросов гибкости решений. Скорее просто происходит подмена набора IT инструментов, форматов сообщений и протоколов.
Управление SOA, API, и приложением может стать мостом между этими концепциями и улучшить архитектурную согласованность всего решения.
Сервисы, API и архитектура
Когда вы будете решать, что использовать как лучшие практики для сервис-ориентированной архитектуры, определять дизайн RESTful сервисов, когда будете формировать план по управлению ими, четко определите, как ваши сервисы и API вместе будут укладываться в общую архитектурную картину.
Читать полностью »