프로토콜 구성성: 하나의 애플리케이션이 다른 애플리케이션에 연결되는 방법

버튼부터 시작해보자

온체인 애플리케이션을 열 때 사용자가 일반적으로 보는 것은 지갑을 연결하고 금액을 입력하고 작업을 확인하는 것입니다. 인터페이스는 매우 간단하지만 그 뒤에 있는 작업은 여러 프로그램으로 완료될 수 있습니다. 하나의 모듈은 계정을 읽고, 다른 모듈은 교환 결과를 계산하며, 다른 모듈은 자산 수신, 잔액 업데이트 및 상태 기록을 담당합니다. 우리는 이러한 협업을 프로토콜 구성성으로 이해할 수 있습니다. 기존 기능은 인터페이스를 통해 연결되고 다른 애플리케이션의 일부가 됩니다.

이 개념을 이해하기 위해 먼저 모든 코드를 읽을 필요는 없습니다. 먼저 구체적인 질문을 할 수 있습니다. 이 버튼을 누르면 어떤 개체가 관련됩니까? 인터페이스에서 작업을 분리하고 누가 요청하고, 누가 규칙을 실행하고, 누가 결과를 기록하는지 구분함으로써 점차적으로 애플리케이션 간의 관계를 확인할 수 있습니다. 본 글은 읽기 방식을 설명하기 위해 가상의 시나리오를 사용했으며 특정 제품의 실제 작동 과정과 일치하지 않습니다.

읽는 과정에서 제품 홍보의 거창한 이야기를 일시적으로 무시하고 관찰 가능한 가장 작은 행동부터 시작할 수도 있습니다. 먼저 쿼리를 설명한 다음 상태 변경을 설명하고 마지막으로 여러 모듈이 어떻게 협력하는지 논의합니다. 이 순서는 익숙하지 않은 용어가 동시에 나타나는 부담을 줄이고 각각의 새로운 개념이 이전에 이해된 예를 기반으로 할 수 있도록 합니다.

한 애플리케이션이 다른 애플리케이션을 사용할 수 있는 능력

자산 관리를 위한 애플리케이션을 고려해보세요. 사용자가 자산 A를 자산 B로 교환하기를 원했지만 팀은 교환 메커니즘을 재개발하지 않았습니다. 대신 기존 계약에서 제공하는 인터페이스를 통해 교환 기능을 호출했다. 사용자는 한 페이지에서 작업을 시작하지만 실제 교환은 다른 계약의 계약일 수 있습니다. 이러한 작업 분할을 통해 애플리케이션은 자체 경험에 집중하고 성숙한 기본 기능을 재사용할 수 있습니다.

여기서는 두 가지 관계를 구별해야 합니다. 사용자를 다른 웹사이트로 데려가는 것은 단지 포털 간의 연결일 뿐입니다. 프로그램은 실행 수준 조합을 포함하는 다른 프로그램을 직접 호출합니다. 이 둘은 인터페이스가 유사해 보이지만 서로 다른 책임을 갖고 있습니다. 제품 소개를 읽을 때 "통합"을 점프, 데이터 읽기 및 트랜잭션 호출과 같은 특정 작업으로 분류할 수도 있습니다.

인터페이스는 공통 언어이며 규칙은 여전히 개별적으로 존재합니다.

모듈을 먼저 연결할 수 있는지 여부는 양측이 서로의 입력과 출력을 이해하는지 여부에 따라 달라집니다. 인터페이스는 호출할 수 있는 함수, 제공해야 하는 매개변수, 반환될 결과를 규정합니다. 예를 들어 잔액을 읽는 것과 이체를 요청하는 것은 다른 작업이며 동일한 자산을 중심으로 진행되더라도 혼동될 수 없습니다. 통합 인터페이스는 통신 비용을 절감하지만 모든 제품 규칙을 자동으로 통합하지는 않습니다.

특정 토큰 표준을 사용하는 자산에도 여전히 다른 발행 방식 및 제한 사항이 있을 수 있습니다. 접근하는 당사자는 실제 동작이 가정과 일치하는지 확인해야 하며, 익숙한 이름을 본 후에 확인을 종료할 수는 없습니다. 따라서 인터페이스는 연구의 출발점으로 사용될 수 있으며 특정 구현, 권한 설정 및 예외 처리에 따라 연결이 현재 시나리오에 적합한지 여부가 결정됩니다.

자산 경로를 따라 프로세스 압축 풀기

계속해서 자산 관리 예시를 살펴보겠습니다. 사용자 계정, 교환 모듈, 수신 계정의 세 가지 노드를 종이에 기록한 다음 각 단계에서 자산 유형, 수량 및 통제 당사자를 차례로 기록할 수 있습니다. 자산이 중간 계약에 먼저 들어가나요? 상환 후 수령 주소는 누구입니까? 페이지에 예상된 결과가 표시됩니까, 아니면 이미 실행된 결과가 표시됩니까? 이러한 질문은 단순히 제품 이름을 기억하는 것보다 더 도움이 됩니다.

프로세스에 다른 프로토콜에 대한 입금도 포함되는 경우 모든 작업을 "완전한 투자"로 결합하는 대신 다른 노드를 추가하십시오. 입금 후 얻는 것은 잔액 기록이나 다른 종류의 바우처일 수 있습니다. 구체적인 의미는 별도로 확인이 필요합니다. 디스어셈블리의 목적은 각 상태 변경에 대한 해당 설명을 제공하고 여러 다른 작업을 다루기 위해 하나의 인터페이스 단어를 사용하지 않는 것입니다.

실행 종속성과 데이터 종속성을 분리하세요.

애플리케이션 간의 연결이 반드시 자산 이동을 동반하지는 않습니다. 일부 연결은 잔액, 가격 또는 특정 상태와 같은 데이터 읽기만 담당합니다. 자산 이전 또는 위치 업데이트와 같은 다른 연결의 상태가 변경됩니다. 읽을 때 두 가지 유형의 종속성을 분리하면 외부 모듈의 변경이 표시, 판단 조건 또는 실제 실행에 영향을 미치는지 더 빠르게 판단할 수 있습니다.

페이지는 동시에 여러 데이터 소스를 사용할 수 있습니다. 표시된 가격의 출처가 계약 체결 시 사용된 가격과 반드시 ​​일치하는 것은 아닙니다. 페이지 업데이트 속도는 체인의 상태 변경 속도와 같지 않습니다. 데이터가 어디서 생성되었는지, 누가 업데이트했는지, 어떤 링크에서 사용되었는지를 연구 기록에 명시하는 것이 가장 좋습니다. 설명되지 않는 부분이 나타나면 직접 완성하기보다는 검증 항목으로 남겨두는 것이 좋습니다.

한번의 확인은 단지 하나의 행동을 의미하지 않습니다

사용자가 거래를 확인하면 내부적으로 여러 계약 호출이 발생할 수 있습니다. 특정 실행 환경에서는 동일한 트랜잭션 내에서 여러 단계를 예약할 수 있지만, 이 경우 특정 구현을 살펴봐야 합니다. 페이지에 버튼이 하나만 있다고 해서 모든 링크의 완료 조건이 동일하다고 가정할 수도 없고, 네트워크 간, 서비스 간 프로세스를 동기 실행으로 이해할 수도 없습니다.

독자는 "요청 제출"과 "목표 상태 형성"을 구별하는 것이 더 실용적입니다. 인터페이스 프롬프트, 거래 기록 및 최종 잔액은 각각 다른 질문에 답합니다. 또한 프로그램이 내부 단계의 실패를 포착한 다음 다른 논리를 계속할 수 있는 상황도 고려해야 합니다. 따라서 트랜잭션이 성공한 것을 확인한 후에도 예상 결과와 비교하여 실제로 어떤 일이 발생했는지 확인해야 합니다.

권한은 복합 관계의 일부입니다.

기능이 연결될 수 있다고 해서 모든 계정이 어떤 방식으로든 해당 기능을 호출할 수 있다는 의미는 아닙니다. 특정 항목에는 인증이 필요할 수 있으며 특정 관리 작업은 특정 역할에 의해서만 수행될 수 있습니다. 결합된 애플리케이션을 연구할 때 일반적인 프로세스를 살펴보는 것 외에도 어떤 주체가 매개변수를 조정하고, 기능을 일시 중지하고, 종속 주소를 변경하거나 구현을 업그레이드할 수 있는지 기록하는 것도 필요합니다. 이러한 능력은 후속 행동에 영향을 미칩니다.

사용자 측의 승인도 별도로 이해해야 합니다. 지갑 연결, 메시지 서명, 자산 승인은 서로 다른 동작입니다. 승인이 필요한 업무의 경우 승인 대상, 금액, 목적 등을 확인하고, 추후 철회 방법을 숙지하시기 바랍니다. 여기서 요점은 모든 인증을 예외로 처리하는 것이 아니라 실제 요구 사항에 권한을 일치시키고 사용자가 동의하는 내용을 설명할 수 있도록 하는 것입니다.

조합은 편의성을 제공하고 종속성 체인을 증가시킵니다.

기존 기능을 재사용하면 처음부터 구축하는 작업이 줄어들어 팀이 새로운 사용 시나리오에 집중할 수 있습니다. 사용자의 경우 원래 여러 페이지에 걸쳐 완료해야 하는 작업을 보다 연속적인 프로세스로 구성할 수도 있습니다. 그러나 진입 횟수가 적다고 해서 기본 관계가 적다는 의미는 아닙니다. 복잡성은 종종 인터페이스에 의해 간단히 포함됩니다.

따라서 결합제품을 평가할 때 단지 몇 개의 프로토콜이 연결되어 있는지만 보고 판단하는 것은 바람직하지 않습니다. 더 주의할 점은 연결이 필요한지, 종속성이 명확한지, 예외를 설명할 수 있는지, 종료가 여전히 가능한지 여부입니다. 외부 링크를 일시적으로 사용할 수 없는 경우 다른 기능은 얼마나 영향을 받나요? 이러한 질문에 답할 수 있다는 것은 긴 협업 로고 목록을 표시하는 것보다 실제 작업에 훨씬 더 가까운 근사치입니다.

버전과 네트워크에 따라 연구 중인 개체가 결정됩니다.

동일한 제품 이름으로 다른 네트워크에 배포되거나 여러 버전이 동시에 유지 관리될 수 있습니다. 조사할 때 단순히 브랜드 이름을 기록하는 것만으로는 충분하지 않습니다. 네트워크, 버전, 계약 주소, 문서 링크, 검토 날짜 등을 함께 넣어두면 나중에 사람들이 결론이 어떤 객체를 참조하는지 알 수 있고 변경 후 다시 확인할 수 있도록 하는 것이 가장 좋습니다.

문서가 인터페이스 설명과 일치하지 않는 경우 둘 중 하나를 성급하게 믿지 마십시오. 먼저 두 버전이 동일한 버전을 가리키는지 확인한 다음 릴리스 기록과 온체인 기록을 찾아보세요. 확인할 수 없는 관계에 대해서는 의문점과 누락된 증거를 명확하게 기재합니다. 이 기록 방법을 사용하면 연구를 계속하기가 더 쉬워지고 이전 버전의 경험을 새로운 구현으로 직접 이전하는 것을 피할 수 있습니다.

완전한 기록으로 귀하의 이해를 확인하십시오.

연구 질문과 관련된 공개 기록에서 사례를 선택하는 것이 광고문을 반복해서 읽는 것보다 더 효과적인 경우가 많습니다. 먼저 원래 주소, 대상 계약 및 시간을 기록한 다음 자산 변경 및 관련 이벤트를 관찰하십시오. 이전에 작성한 프로세스와 기록을 항목별로 비교하여 확인되지 않은 중간 링크가 있는지, 실제 결과가 자신의 해석과 일치하는지 확인하십시오.

그러나 하나의 예시는 당시의 상황만을 설명할 뿐 모든 입력이 동일한 결과를 낳는다는 것을 증명할 수는 없습니다. 제약 조건 및 예외 경로에 대해서도 읽어보세요. 예를 들어 수량, 유동성 또는 권한이 변경된 후 프로세스가 다른 분기로 분기될 수 있습니다. 연구노트에는 관찰된 사실, 문서에 근거한 설명, 개인적 추론을 명확하게 기술해야 합니다.

일반적인 결론을 내리는 것보다 구체적인 질문을 적어 두는 것이 더 중요합니다.

연구 노트의 일반적인 표현은 "이 프로토콜은 다른 프로토콜에 의존합니다."입니다. 이 문장은 올바른 방향이지만 독자가 그 영향을 이해하는 데 도움이 되지 않습니다. 어떤 함수가 서로 의존하는지, 어떤 정보를 읽는지, 어떤 단계를 호출하는지, 반환 값이 어떤 판단에 사용되는지 등 좀 더 구체적으로 다시 작성할 수 있습니다. 상대방이 응답을 멈추면 현재 작업이 종료될까요, 기다릴까요, 아니면 다른 경로로 들어갈까요? 질문이 구체적일수록 후속 조사가 더욱 집중적으로 진행됩니다.

마찬가지로 "자산 지원"도 풀어야 합니다. 잔액 표시 지원, 이체 지원, 교환 지원 및 일종의 바우처 지원은 다양한 수준의 기능입니다. 애플리케이션은 이 중 일부만 수행할 수 있습니다. 읽을 때 먼저 우려되는 기능을 정의한 다음 해당 증거를 확인하세요. 이렇게 하면 인터페이스에 나타나는 이름이 주변의 모든 작업을 지원하는 것으로 해석되는 것을 피할 수 있습니다.

다른 독자에게 메모를 보고 전체 과정을 다시 말해 보도록 권유할 수도 있습니다. 상대방이 여전히 자산이 어디로 가는지 알지 못하거나, 페이지와 계약의 책임을 구분하지 못한다면 기록에 공백이 있다는 의미입니다. 이 과정에서는 전문적인 어휘량을 추구하는 것이 아니라 그 표현이 다른 사람들도 동일한 명확한 이해를 확립하는 데 도움이 될 수 있는지 테스트합니다.

이탈 경로는 자체 페이지에 적합합니다.

많은 프리젠테이션에서는 프로세스를 시작하는 방법을 자세히 설명하지만 프로세스를 종료하는 방법은 자세히 설명하지 않습니다. 자산 상태 변경과 관련된 신청의 경우 상품권 검색, 상환, 승인 취소 또는 상환 경로를 별도로 구성할 수 있습니다. 각 단계가 어떤 조건에 달려 있는지, 추가 거래가 필요한지, 다른 당사자가 참여하는지 등은 모두 제품을 이해하는 데 없어서는 안 될 부분입니다.

여기에서 간단한 역읽기를 수행할 수 있습니다. 원하는 최종 상태에서 시작하여 점차적으로 이전 단계에서 수행해야 할 작업이 무엇인지 물어보세요. 특정 링크가 수동 처리에만 의존할 수 있거나 외부 상태 업데이트를 기다려야 하는 경우 진실되게 기록되어야 합니다. 일반 진입과 일반 종료를 함께 사용하면 시작 버튼에 대한 이해뿐만 아니라 프로세스에 대한 완전한 이해를 얻을 수 있습니다.

지속적으로 업데이트할 수 있는 연구노트를 작성하세요

마지막으로, 애플리케이션이 어떤 문제를 해결하는지, 어떤 기능이 자체에서 나오는지, 어떤 기능이 외부에서 나오는지 메모 페이지로 연구를 마무리할 수 있습니다. 자산과 데이터 흐름 방식 조정 권한이 있는 사람 결과는 어디에서 확인됩니까? 그리고 출국을 위해서는 어떤 조건이 필요한지. 각 결론에 대해 검토할 수 있는 기록을 포함시키고, 다음 업데이트에서 명확한 출발점이 있을 수 있도록 해결되지 않은 문제를 표시하십시오.

프로토콜 구성성에 대해 이해해야 할 가장 가치 있는 점은 기능 간에 새로운 협력 관계가 형성될 수 있다는 것입니다. 이 관계를 이해하려면 인터페이스의 편의성과 각 모듈이 유지하는 경계를 모두 확인해야 합니다. 애플리케이션을 설명 가능하고 검증 가능한 링크로 나누고 연결할 수 있을 때 우리는 인터페이스를 관찰하는 것에서 인터페이스 뒤의 작동을 이해하는 것으로 이동했습니다.