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

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

5 декабря в 19:30 в комнате прямой трансляции видеоаккаунта Tencent Cloud Developer «Программисты Goose Factory лицом к лицу» мы пригласили автора проанализировать для вас тему «Проектирование и обдумывание контрактной платформы». посмотрите и получите возможность приобрести периферийные устройства Goose Factory. Какой подарок!

01. Дилемма развития

У меня есть два друга: Сяо Мин и Сяо Хун. Однажды они вместе работали над проектом и столкнулись с некоторыми проблемами...

1.1 Поддельные документы?

1.2 Изменено, почему я не знал?

После периода повторных проверок код Сяо Хуна и Сяо Мина наконец оказался в сети, но вскоре после того, как он появился в сети, что-то пошло не так...

1.3 Что означает код ошибки?

В 2:35 ночи на второй день после того, как служба была подключена к сети, Сяо Мин был разбужен вызовом полиции во сне. Он взглянул на сообщение об ошибке и обнаружил, что возврат вниз по течению не удался, и получил следующее сообщение:

{    
"code": 71756425,"message":"системазанятый"
}

Сяо Мин подумал про себя: «Что это?» Итак, я нашел нижестоящего одноклассника А. Нижестоящий одноклассник А посмотрел на это и понял, что это не моя ошибка, а код ошибки нижестоящего, который я передал прозрачно, поэтому я начал искать кого-то посреди ночи.. .

1.4 Попробуйте решить

Вышеупомянутая сцена,верно Вразвивать Для одноклассников：я все понимаю,они такиеобщий,Но такТрудно сделать,Давайте проанализируем это еще раз

• Сценарий поддельного документа: здесь многое раскрыто,Например, при общении с протоколом,Не существует стандартной позы,Json, один пб, простой iwiki или даже предложение.,Все может даа протокол,процесс разработки,протоколесли изменился,«Тайно» изменилось,Одноклассники выше по течению вообще не знают,Это, несомненно, значительно увеличивает онлайн-риски.
• Смена сцены: В смене сцены,Может быть много вышестоящих сервисов,Изменения в нижестоящих услугах,да Соответствует ли он онлайн-ожиданиям？Каков эффект?？понятия не имею！НапримерпротоколсерединаПоле было удаленоИли добавил одинОбязательные параметры,Это неизбежно повлечет за собой изменения в вышестоящей системе.,Но ужасное да,Иногда есть кто-то выше по течению,Ты даже не знаешь. изменение,Вот и вышел глюк.
• Сценарий кода ошибки: сообщение об ошибке службы,Я понятия не имею, что означает да.,Некоторым людям нравится оформлять коды ошибок последующих версий в своем собственном стиле.,Некоторые люди напрямую прозрачно передают код ошибки в нисходящий поток.,Единой спецификации не существует,Каждая команда работает самостоятельно,Когда пора выходить в интернет,Чтобы узнать, откуда берутся эти коды ошибок и что они означают,Этот процесс подобен детективу, раскрывающему преступление.

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

Как это звучит?,имеет смысл,Но подумай об этом хорошенько,Нисколько,Потому что между строк написано два словаПолагайтесь на людей,Но, к сожалению, да,Люди делают ошибки , Развитие – это человек, а не бог! Иногда дело не в том, что вы не знаете решения, а в том, что вам приходится бороться со слабостями своей человеческой природы и делать вещи, которые вы знаете, но которые трудно сделать. Точно так же, как я знаю, что перекусывать поздно вечером — это недопустимо. хорошо, но иногда я все равно их ем!

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

02. Думайте как продукт

Как и многие отличные продукты,люди проходятНаблюдайте и думайтечтобы запечатлеть жизньсерединаиз Феномен,отсередина Обнаружитьвопрос,Затем пройдите через создание «продукта», чтобы решить вопрос.,тем самым создавая ценность,Ниже мы также остановимся на этих двух моментах.

2.1 Информация

В первом разделе (дилемма развивать),Мы перечислили впроцесс разработкиобщийболевые точки,Но это, наверное, толькодаверхушка айсберга,Мы не можем не задаться вопросом,Что еще находится под айсбергом? В чем суть вопроса и да? так,Прежде чем решить вопрос,Нам нужно сначала четкоОпределение вопроса,Я далСправочный ответда：существоватьЛучший способ эффективной передачи информации в командной работе и общении!Почемудаобщатьсявопрос？Давайте представим себе эти сценарии сотрудничества：

• Внутри команды в небольшой команде,Вы и ваши коллеги, проработавшие вместе пять лет, вместе завершаете работу.,Они очень хорошо знают друг друга,молчаливое понимание,Общение становится простым и эффективным. При согласовании технических деталей,Возможно, тебе просто нужно слово: «Эй,,brother,Просто добавьте два поля в этот интерфейс. Вскоре после этого,Новые функции были завершены и успешно запущены.
• кросс-команда существоватькросс-командапроектсередина,Сложность общения значительно возрастает. Информация легко искажается при передаче через несколько слоев.,Координация нескольких ресурсов также становится сложной. Различные инструменты и процессы усложняют интеграцию.,Добавление сложности. Эти вопросы могут привести к ошибкам доставки информации.,Вызвать онлайн-сбой.
• В организациях В организациях При сотрудничестве,возникший вопрос может быть более сложным,Разные организации имеют разные культуры, процессы и технологические стеки.,Многие технические стандарты и спецификации, вероятно, будут противоречивыми. Как лучше интегрировать стандарты и эффективно передавать информацию, стало чрезвычайно важным,если Неправильное обращение,приведет к искажению данных,В конечном итоге это приведет к онлайн-сбоям.

Закон Конвея говорит нам：«Организация, разрабатывающая систему, неизбежно создаст дизайн, соответствующий ее коммуникационной структуре».,Это означает, что организационная структура напрямую влияет на формирование технической архитектуры. реагировать на реальность,Этот эффект также в конечном итоге будет проявляться при вызовах интерфейса.,приводящие к искажению информации,В конечном итоге это приводит к онлайн-сбоям.

На следующем рисунке показана коммуникационная структура организации и модель отображения технической архитектуры.,Мы можем ясно понять одну вещь：Передача информации и интерфейсный вызов по сути одно и то же,То есть в процессе передачи информации,как разместить информацию（знание предметной области）Структурный, стандартизированный, полный и понятный Осадки и возможность отображения информации без потерь на протяжении всего процесса исследований и разработок — это основная проблема!

2.2 Создание

Ответ часто скрыт в вопросе, когдавопрос Чем точнее определение,Процесс решения вопроса стал проще,Столкновение со сложностью вопроса,разделяй и властвуй,Сразудаодно слово：демонтировать,демонтировать на маленькие решаемые вопросы,После решения их один за другим,а затем интегрировать их вместе,Так как делить демонтировать,Здесь я даюдемонтироватьразделенныйСправочный ответ：

2.2.1 Об информации

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

message GetUserBalanceReq {
string user_id = 1;
string user_type = 2;
}
message GetUserBalanceRsp {
int32 code = 1; 
string message = 2;
int32 balance=3；
}
service testsvr {
rpc GetUserBalance(GetUserBalanceReq) returns (GetUserBalanceRsp) {};
}

Вы используете свой уровень владения английским языком на уровне 6, чтобы понять значение каждого поля... О, user_id, вероятно, идентификатор пользователя, user_type, кажется, тип, а баланс означает баланс... Я не знаю, сталкивались ли вы с это перед экраном. Я был на такой сцене, но действительно сталкивался с ней (особенно когда проект очень плотный), но подумайте о protobuf. Существует только самое базовое определение интерфейса, но настоящее соглашение (контракт) выходит далеко за рамки определения интерфейса, а также включает сценарии использования, ограничения использования, коды ошибок, примеры, безопасность, среду вызова и т. д.

Поэтому нужно задать вопрос и попытаться ответить: Какой договор считается качественным? Прежде чем ответить на этот вопрос, давайте сначала взглянем на два наиболее часто используемых в отрасли метода передачи протоколов: Protobuf и OpenApi.

ProtoBuf VS OpenApi

ProtoBuf да Google Формат данных, опубликованный в 2008 году.,Предназначен для решения проблемы связи между машинами.сначала,Google инженеры обнаружили, что использование XML и JSON Скорость передачи данных низкая, а объем данных велик. Поэтому они хотели изобрести универсальный «язык», который позволил бы компьютерам «разговаривать» быстрее. Protobuf родился, очевидно, ProtoBuf дизайн Не в началедапозволятьразвивать Пойдемверновместеинтерфейспротокол,Но с быстрым развитием да,Потому что это просто и понятно,Во многих случаях он служит документом.

OpenAPI (Swagger)выпущен в 2010 году.,Предназначен для решения вопроса коммуникации между людьми и протоколом документов (договоров).сначала,развивать ВОЗсуществоватьписать API Иногда документацию приходится писать вручную, что утомительно и чревато ошибками. Кстати, кому-то пришла в голову новаторская идея: можно ли добиться автоматического создания документов? Это похоже на умного помощника, который автоматически сочиняет за вас. API руководство по эксплуатации. Этот творческий инструмент был быстро внедрен и позже постепенно стал отраслевым стандартом, помогая многочисленным разработчикам легче управлять. API。

Когда мы понимаем предысторию, естественно осознавать: ProtoBuf Не то чтобы это решило проблему согласования вопросов протокола, но да, по мере быстрого развития, постепенно стало способом связи по умолчанию между разработками. В сравнении Openapi Тогда да – носитель информации сцены чтения, ориентированный на пользователя.,Но до «идеала» еще далеко.,Как показано ниже,Внимательные студенты обнаружили, что самая большая разница между ними заключается в том, что полная информация должна нести в себе знания предметной области!

Что такое яблоко?

Когда мы идем в Чжунгуаньцунь в Пекине и говорим продавцу магазина: «Босс, помогите мне купить последнюю версию Apple», продавец магазина сразу же знакомит вас с новейшим мобильным телефоном Apple 16. И когда мы идем на мокрый рынок, он. также поможет мне получить последний iPhone. Когда я попрошу яблоки, босс скажет: «Какие вы хотите?»

То же слово «яблоко»,по разным сценариям,совершенно другой смысл。Наше программное обеспечениепроцесс разработки,Мы все еще можем использовать"сцена"точно описать значение слова（существовать Управление доменомсередина“верхний и нижний пределы”、“единый язык” такжеда Хотите сделать что-то подобное）нода Одного этого описания недостаточно,Например, для мобильного телефона Apple.,Также есть iPhone 16, Apple 16pro и старшее поколение 15.,Цены у них тоже разные,Яблоко, съеденное В.,Также разделены на размеры и разновидности.,Следовательно, естественно, в основе языковой концепции должно лежать правило, описывающее его физические свойства.

если перенести этот шаблон в интерфейспротокол,Тогда каждое поле должно быть таким же, как «Apple».,Существуют соответствующие «сцены» и «физические правила».,Например, мы хотим описать концепцию поля времени, когда пользователь платит за интерфейс.,Семантику можно выразить так: концепция времени в сценарии оплаты пользователя.,Его физические правила могут быть временной меткой или строкой года и дня... Передаем информацию через «Концепция» + «Правило».,Цель не потерять информацию при передаче достигнута.,и«Концепция» + «Правило»на самом деле Сразудазнание предметной области。

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

Объединив знания предметной области, вот вопрос, поднятый в начале этой главы: что должно включать в себя высококачественное соглашение о взаимодействии (контракте)?

2.2.2 Общение в отношениях

вопрос в общении в развитии,Часто представлен на интерфейсе,В конечном итоге приводит к провалу,В этом разделе обсуждается Основной вопрос：Почему общение так сложно?

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

Давайте перенесем эту модель,если Мы заменим источник отправки и источник получения людьми,нас Сразуможно объяснить：Почему общение затруднено?,Поскольку семейное происхождение, личность и опыт роста у всех разные, система кодирования и система декодирования у всех разные.,Это приводит к искажению информации.

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

2.2.3 Выкл. ограничения

Вот часть с относительно большими переменными,Различные бизнес-сценарии будут иметь разные ограничения.,Возьмите WeChat Pay в качестве примера.,В финансовой сфере существует множество требований соответствия.,Должен удовлетворить,Нет места для производительности,Какой-то дизайн должен быть таким,не так уж и много, почему,Просто сделай это.

03. Договорное проектирование

4 июня 1996 г.,Ракета Ariane 5, запущенная Европейским космическим агентством, сошла с рельсов и самоуничтожилась всего через 37 секунд после старта.,Причинил убытки примерно в 500 миллионов долларов США. Позже обзор показал, что,трагедияизисточниксуществовать Впрограммное обеспечениесерединаключизизинтерфейсиметь дело с：Произошло переполнение при преобразовании 64-битного числа с плавающей запятой в 16-битное целое число.этот“крошечный”Ошибки в конечном итоге привели к этой катастрофе,Подобных аварий бесчисленное множество,Все Мы не можем не задаться вопросом,Существует ли режим проектирования, позволяющий эффективно избежать подобных происшествий? Ответ определенно да,Давайте представим это дальше: Контрактный дизайн.

3.1 Основная концепция: разделение ответственности и обязательств

Договорной дизайн（Design by contract）да Бертран·Мейер（Bertrand Meyer）существовать1980Год , в разработке Eiffel Концепции, возникающие при изучении языков программирования.,глазиз СразудастроитьВысокая надежностьпрограммное обеспечениесистема,Слово «контракт» на самом деле происходит от юридического понятия.,Относится к юридически обязательному протоколу.,цельсуществоватьпрозрачныйпротокол Обе стороны должны нестиответственностьиобязательство,еслиПучокэтот概念迁移到программное обеспечениедизайнсередина,Цель - уточнить ответственность иобязательство во взаимодействии. (Рекомендуется к прочтению: https://en.wikipedia.org/wiki/Design_by_contract)

Суть контрактного дизайна состоит в том, чтобы четко выразить знания предметной области посредством структурированного описания.,Добейтесь осадков в поле,Помогите системе лучше общаться,

Еще одним преимуществом контрактного дизайна является: благодаря структурированному выражению,Это может развивать способность учащихся обращать внимание на детали.,силаразвивать Одноклассники идутДумайте ясно, говорите ясно, пишите ясно!Этот видсосредоточиться наможет помочь нам эффективно поддерживать сложныесистемасерединаиззаказ,Тем самым уменьшая энтропию системы! Как это сделать? Контрактный дизайн предлагает три основные концепции,То есть предусловия, постусловия и инварианты.,Когда люди, разрабатывающие протокол, определяют протокол, им сначала нужно задать себе три вопроса:,Таким образом получены эти три структурных определения.

• Предпосылки (ожидания):Предварительные условиядакомпонентыверноснаружиизожидать,также Сразуда Выполнено успешно Должен удовлетворитьусловия,Обратите внимание на перспективу здесь,Для передаваемой стороны (компонента) внешние ожидания равны да, а для вызывающей стороны да становится обязательство,То есть, какие условия необходимо выполнить для успешного вызова самогенерации.
• Постусловия (гарантии):постусловиенодакогда Предварительные условия После того, как были удовлетворены,Что должны обеспечивать компоненты,То есть возвращать данные правильно и своевременно.
• Инварианты (обслуживание):инвариантнодакомпонентысуществовать Данные должны быть гарантированы во время работы.изкакое-то ограничение、Например, сохранение состояния объекта、и достоверность данных.

3.2 Дать каштан

Давайте возьмем простой пример, чтобы проиллюстрировать концепцию: реализуем функцию, которая открывает корневой знак.,Как использовать договорное определение иразвивать,Код описывается следующим образом:

/**
 * @brief Вычислить квадратный корень из неотрицательного числа
 *
 * @param number Неотрицательное число для вычисления квадратного корня из
 * @return double Введите квадратный корень числа
 *
 * @Precondition Входное число должно быть неотрицательным (число >= 0）
 * @Postcondition Возвращаемое значение должно быть неотрицательным, а его квадрат должен быть равен входному числу.
 * @Invariant Количество входов остается неизменным во время выполнения функции.
 *
 * @throws std::invalid_argument есливведенное число отрицательное
 * @throws std::logic_error если результаты расчета не соответствуют ожиданиям
 *
 * @Example
 * Например, вычислитеSquareRoot(4.0) вернется 2.0 потому что 2 Площадь 4。
 */
double calculateSquareRoot(double number) {
// Предпосылки: Входное число должно быть неотрицательным.
if (number < 0) {
throw std::invalid_argument("Входное число должно быть неотрицательным.");
    }

// Инвариант: Введенные числа остаются неизменными во время расчета.
    double result = std::sqrt(number);

// Постусловия: Результат должен быть неотрицательным, а его квадрат должен быть равен введенному числу.
if (result < 0 || std::abs(result * result - number) > 1e-9) {
throw std::logic_error("Результат расчета не соответствует ожиданиям");
    }

return result;
}

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

3.3 Защитное программирование и решения в эпоху ИИ

если Подведите итог в одном предложении Договорной дизайн Сразуда：использоватьструктурированныйизметодВход и выход управления,Предусловия – это вариант управления входом,Для системы вызова,Необходимо выполнить его предпосылки,для завершения ожидаемой функции,Для названной системы,отвечатькогдаиспользоватьпринцип взаимного недоверия,в соответствии с Предварительные условия Практикуйте защитное программирование。и防御性编程на самом деле Сразудаитоговое мышлениепроявление,Заставляет нас задуматься об аномалиях программного обеспечения,Что в нас самое невыносимое? Чтобы лучше построить программное обеспечение Высоконадежнойсистемы.,Следующий договорной проект представляет модель взаимодействия между системой,следующее:

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

Раньше нам часто приходилось писать какой-нибудь простой, утомительный, но важный код, но сейчас, в эпоху больших моделей, такую ​​работу можно поручить разработчикам. AI справиться, как Copilot и Cursor Такие вспомогательные инструменты хорошо справляются с этими задачами.。эти инструменты Сразукартинадатвой помощник,помочь тебеиметь дело сэти фазыверно Простойноважныйизиметь значение。Ваша роль меняется с человека, который пишет код, наПросмотрите кодлюди,Эта смена ролей кажется потрясающей. Должен сказать,AI В определенной степени это помогает нам преодолеть слабости человеческой натуры.

Не просто простой код,Большую роль может сыграть отличный контракт + большая модель. Контракт как данные,Большая модель может автоматически генерировать для вас тестовый и бизнес-код.,и интерфейсный контракт,Много повторяющейся работы будет заменено,Для улучшения персонала необходимо лишь внести небольшое количество дополнений в бизнес-код.

3.4 Часть и целое: договор в широком смысле

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

Это очевидно,«Контракт на взаимодействие» — это лишь часть всего процесса НИОКР.,ивесьдизайндолжен быть уточнен в：Три этапа бизнес-моделирования, анализа и проектирования,эти три этапаверноотвечать着三个Основной вопрос：Какую ценность организация должна предоставлять пользователям?？Чтобы реализовать эти ценности,Какие функции должна иметь система? И какие технологии следует использовать для реализации этих функций? Эти вопросы развиваются шаг за шагом.,и Как ответитьдизайнэтотвопросизструктурированное выражение,Все контракты!

04. Напишите в конце

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

Договорной дизайн,В общих чертах,Оно дает нам методологию, которая позволяет нам упорядоченно думать о реальных вещах? и осуществить упорядоченное решение этой проблемы,Пусть все аспекты процесса НИОКР,Есть законы, которым нужно следовать, и следы, которым нужно следовать!

-End-

Оригинальный автор | Лу Хаомата

Как вы решаете проблемы общения в повседневной работе? Добро пожаловать, чтобы оставлять комментарии и сообщения.