팀이 검토할 수 있는 규칙을 위한 스마트 컨트랙트 개발

스마트 컨트랙트 개발은 어디서부터 시작해야 하나요?

사용자가 수행해야 할 작업과 각 작업을 제어하는 규칙부터 시작하세요. 저희는 이러한 세부 정보를 바탕으로 코드를 작성하기 전에 컨트랙트 동작을 설명합니다.

1. 사용자 작업을 명명하세요. 할당 청구나 자산 예치 등 누군가가 수행해야 할 작업을 설명합니다.
2. 조건을 설정하세요. 작업이 허용되는 시기와 허용되지 않을 때 발생해야 하는 상황을 기록합니다.
3. 역할을 나열하세요. 각 기능을 사용할 수 있는 사람과 설정을 관리할 수 있는 사람(있는 경우)을 식별합니다.
4. 종속성을 표시하세요. 관련 컨트랙트, 자산, 서비스 또는 인터페이스 작업을 기록합니다.
5. 동작을 검토하세요. 정상 사용과 제한된 작업을 반영하는 테스트 케이스에 합의합니다.

이를 통해 팀은 구현 전에 검토할 수 있는 공유 설명을 얻을 수 있습니다. 또한 변경이 여전히 논의하기 쉬운 시기에 미결정된 제품 규칙을 조기에 발견하는 데 도움이 됩니다. 연결된 토큰 작업은 토큰 생성 및 배포를 참조하세요.

사용자가 온체인 인터페이스를 필요로 하는 경우, dApp 개발이 동일한 플랜의 일부가 될 수 있습니다. 저희와 상담하기 전에 모든 기술적 선택을 확정할 필요는 없습니다. 결정한 사항을 가져오고 미결 사항을 표시하면, 저희가 제품 질문과 구현 세부 사항을 분리하는 데 도움을 드립니다.

컨트랙트를 커뮤니티 운영 방식에 가깝게 유지하세요

컨트랙트의 규칙이 사람들이 실제로 수행해야 하는 작업과 일치할 때 계획이 더 쉬워집니다. 사용자에 대한 약간의 맥락은 표준 토큰이나 보상 모델을 가정하지 않고 그 연결을 만드는 데 도움이 됩니다.

파트타임 관리자가 있는 디스코드 서버를 상상해 보세요. 관리자는 어떤 채널부터 시작할지 결정하고 있습니다. 팀은 또한 기여자들이 시간이 지남에 따라 토큰 할당을 받는 방법을 논의 중입니다. 저희는 먼저 할당 규칙, 누가 청구할 수 있는지, 관리자가 무엇을 담당하는지 설명하는 데 도움을 드립니다. 그런 다음 이러한 컨트랙트 규칙을 커뮤니티가 업데이트를 공유하는 방식에 대한 결정과 분리합니다.

예를 들어, 제품에 토큰과 함께 스테이킹이 필요하다고 가정해 보겠습니다. 저희는 예치와 인출이 어떻게 작동해야 하는지, 보상이 어떻게 표현되는지, 계획이 의존하는 자산이나 다른 서비스가 무엇인지 물어볼 것입니다. 답변을 가정된 경제 설계가 아닌 검토할 동작으로 기록합니다.

이러한 경계는 인접 작업이 관련될 때 중요합니다. 저희는 컨트랙트 요구사항을 Web3 웹사이트 및 랜딩 페이지와 조정하거나 암호화폐 지갑 개발로의 인계를 매핑할 수 있습니다. 팀에 이미 개발자가 있는 경우, 작업 시작 전에 각 연결된 부분의 담당자를 합의할 수 있습니다.

팀이 따라갈 수 있는 인수인계

합의된 컨트랙트 동작을 이해하는 데 필요한 코드와 작업 노트를 받게 됩니다. 개발 전에 내용을 확인하여 인수인계가 일반 체크리스트를 따르기보다 제품에 맞춰지도록 합니다. 더 광범위한 제품 요구사항은 Web3 개발을 참조하세요.

베스팅 컨트랙트는 할당 및 청구 조건에 대한 명확한 설명이 필요할 수 있습니다. 스테이킹 빌드는 예치, 인출 및 보상 동작을 기록해야 할 수 있습니다. 저희는 승인한 기능에 맞춰 문서화된 자료를 구성하여 검토자가 명시된 규칙을 테스트 및 코드와 비교할 수 있도록 합니다. 이는 또한 팀이 dApp 개발로 인터페이스 작업을 계획하는 데 도움이 될 수 있습니다.

컨트랙트가 더 큰 제품의 일부인 경우, 책임이 끝나는 지점도 기록합니다. 이렇게 하면 연결된 작업을 계획하기가 더 쉬워집니다.

첫 번째 검토와 릴리스 사이에는 어떤 일이 발생하나요?

제품 결정에서 검토된 명세로 이동한 후 빌드, 테스트 및 합의된 인수인계를 준비합니다. 팀은 릴리스가 고려되기 전에 동작을 확할 수 있는 명확한 지점을 가집니다.

저희는 제품 목표, 체인, 사용자 및 연결된 시스템을 검토하는 것으로 시작합니다. 킥오프 체크리스트는 컨트랙트 규칙을 수집하고, 미결 선택을 식별하며, 승인할 사람을 확인하는 데 도움이 됩니다. 문서화된 동작을 승인하면 합의된 기능을 구현하고 기술 담당자와 진행 상황을 공유합니다.

테스트는 설계 중 합의된 케이스를 따릅니다. 감사 조정이 포함된 경우 검토 자료를 준비하고, 기술 질문을 전달하며, 결과에 대한 응답을 정리합니다. 변경이 합의되면 관련 코드를 업데이트하고 관련 테스트를 다시 실행합니다. 결정 사항을 문서화된 진행 노트에 표시하여 팀이 준비된 것과 여전히 검토가 필요한 것을 확인할 수 있도록 합니다.

체인과 컨트랙트 설계에 따라 사용 가능한 릴리스 제어가 결정됩니다. 테스트는 설명된 케이스만 다룹니다. 독립 감사는 합의된 검토로 제한됩니다. 배포 후 코를 변경할 수 있는지는 설계와 체인에 따라 다릅니다.

컨트랙트 경계를 중심으로 연결된 Web3 작업 계획하기

컨트랙트가 토큰, 인터페이스 또는 지갑 흐름에 의존하는 경우 관련 구성 요소를 함께 구축하세요. 각 부분의 담당자를 합의하면 팀이 온체인 동작과 주변 제품 간의 격차를 피하는 데 도움이 됩니다.

유용한 첫 번째 확인은 이미 계획된 부를 나열하고 각각의 담당자를 지명하는 것입니다. 컨트랙트는 토큰 런칭, 사용자 인터페이스, 지갑 흐름 또는 다른 서비스에 연결될 수 있습니다. 저희는 개발자와 함께 이러한 연결을 매핑한 후, 다른 팀이 구축할 것과 컨트랙트 작업을 구분하여 유지합니다.

프로젝트에 한 명의 기술 담당자와 문서화된 진행 노트를 제공합니다. 그 사람은 미결 질문을 추적하고, 검토를 위해 작업을 공유하며, 다음 결정을 명확히 합니다. 다음 3가지 시작점을 가져오세요:

• 제품 개요와 컨트랙트가 지원해야 할 사용자 동작.
• 선택한 경우 대상 체인, 기존 코드 또는 기술 노트.
• 현재 베스팅, 스테이킹 또는 토큰 규칙, 답변되지 않은 질문 포함.

해당 자료를 Brand Community로 보내주세요. 저희가 함께 검토하고, 해결해야 할 결정을 식별하며, 컨트랙트 빌드를 위한 명확한 계획을 준비합니다.

이용 방법

1. 컨트랙트 경계 매핑제품 목표, 사용자, 대상 체인 및 연결된 부분을 검토합니다. 제품 담당자의 답변이 필요한 결정을 식별합니다.
2. 문서화된 동작 합의기능, 역할, 조건 및 테스트 케이스를 기록합니다. 팀이 구현 시작 전에 설명을 검토합니다.
3. 기능 구축 및 테스트합의된 동작을 구현하고 예상 및 제한된 작업에 대한 테스트를 준비합니다. 기술 담당자와 진행 상황 및 미결 질문을 공유합니다.
4. 독립 검토 조정감사 조정이 포함된 경우 검토 자료를 준비하고 결과에 대한 응답을 정리합니다. 합의된 변경을 적용하고 관련 테스트를 다시 실행합니다.
5. 릴리스 및 인수인계 준비합의된 코드, 테스트 노트 및 배포 자료를 제공합니다. 팀이 릴리스 소유권을 확인하고 배포 세부 사항을 검토합니다.