Phát triển dApp cho sản phẩm Web3: frontend, wallet và dữ liệu, một lần bàn giao

Phát triển dApp bao gồm những gì

Kiểm tra nhanh: Liệt kê 3 thao tác người dùng phải hoàn thành. Nếu bạn cần hơn 3 màn hình cho chúng, hãy đơn giản hóa luồng trước.

Phát triển dApp kết nối giao diện có thể sử dụng với chức năng blockchain và dữ liệu mà sản phẩm cần hiển thị. Công việc có thể bao gồm frontend web, kết nối wallet, tương tác hợp đồng và lớp lập chỉ mục; ranh giới chính xác phụ thuộc vào những gì đã được xây dựng và những gì người dùng cần có thể làm.

Bắt đầu với thao tác người dùng, không phải danh sách công nghệ. Ví dụ, xác định xem khách truy cập có nên kết nối wallet, kiểm tra vị thế on-chain, gửi giao dịch hay xem lại hoạt động hay không. Điều đó cung cấp cho đội ngũ cơ sở để xác định màn hình, trạng thái lỗi và yêu cầu dữ liệu trước khi triển khai.

Một ghi chú kế hoạch đầu tiên hữu ích trả lời:

• Nhóm người dùng nào sẽ sử dụng ứng dụng và mỗi nhóm nên có thể làm gì?
• Chuỗi hoặc các chuỗi nào đang được lên kế hoạch và hợp đồng đã có sẵn chưa?
• Thông tin nào phải xuất hiện trong giao diện và nó cần cập nhật đến mức nào?
• Những gì cần hoạt động trên trình duyệt di động cũng như máy tính để bàn?

Nếu sản phẩm cũng cần logic hợp đồng, hãy phối hợp kế hoạch ứng dụng với phát triển hợp đồng thông minh. Để có lộ trình kỹ thuật rộng hơn, hãy xem phát triển Web3. Chúng tôi biến câu trả lời của bạn thành ranh giới tính năng, phụ thuộc và kiểm tra chấp nhận thay vì coi "xây dựng dApp" là một đặc tả hoàn chỉnh.

Màn hình, wallet và dữ liệu kết nối với nhau như thế nào?

Frontend trình bày các thao tác sản phẩm, kết nối wallet cho phép người dùng tương tác với một chuỗi được hỗ trợ và lập chỉ mục giúp ứng dụng dễ dàng truy xuất và hiển thị dữ liệu blockchain đã chọn. Các phần này nên được thiết kế như một hành trình người dùng duy nhất, vì một màn hình rõ ràng không thể bù đắp cho trạng thái kết nối hoặc dữ liệu gây nhầm lẫn.

Đối với frontend, hãy xác định các màn hình chính và trạng thái mà mỗi màn hình có thể hiển thị: đã ngắt kết nối, đã kết nối, đang tải, đã hoàn thành hoặc cần chú ý. Đối với kết nối wallet, hãy ghi lại các chuỗi và thao tác đang được lên kế hoạch, sau đó quyết định giao diện nên giải thích điều gì trước khi yêu cầu người dùng phê duyệt một yêu cầu. Đối với lập chỉ mục, hãy liệt kê các bản ghi mà sản phẩm cần, chúng liên quan đến các tính năng của sản phẩm như thế nào và giao diện nên xử lý dữ liệu bị trễ hoặc không khả dụng ra sao.

Một danh sách kiểm tra yêu cầu thực tế là:

• Ánh xạ mỗi thao tác chính tới màn hình và trạng thái kết quả của nó.
• Xác định người dùng thấy gì khi họ thay đổi tài khoản hoặc mạng.
• Xác định các trường dữ liệu, lịch sử và bộ lọc mà sản phẩm cần.
• Thống nhất cách giải thích lỗi và thông tin không đầy đủ.

Chúng tôi cũng có thể lên kế hoạch phát triển wallet crypto độc lập nếu sản phẩm yêu cầu một wallet thay vì kết nối wallet hiện có. Dịch vụ phát triển website và landing Web3 phù hợp hơn khi nhu cầu là một trang marketing thay vì một ứng dụng tương tác.

Bàn giao dApp bao gồm những gì

Một bàn giao dApp hữu ích cung cấp cho đội ngũ của bạn một triển khai hoạt động và đủ ngữ cảnh để xem xét, vận hành và mở rộng nó. Trước khi công việc bắt đầu, chúng tôi thống nhất những gì bạn nhận được áp dụng cho kế hoạch của bạn và cách mỗi mục sẽ được kiểm tra; điều này tránh việc coi một kho lưu trữ hoặc một bản demo là toàn bộ định nghĩa của việc hoàn thành.

Tùy thuộc vào brief, việc bàn giao có thể bao gồm triển khai frontend, luồng kết nối wallet, công việc truy xuất dữ liệu và lập chỉ mục, phạm vi kiểm thử cho các hành trình đã thống nhất, ghi chú thiết lập và một buổi hướng dẫn. Nếu dự án của bạn đã có mã nguồn, quyền truy cập và một giải thích ngắn về kiến trúc hiện tại sẽ giúp chúng tôi phân biệt công việc mới với tích hợp hoặc sửa chữa.

Để có một danh sách kiểm tra chấp nhận rõ ràng, hãy thống nhất:

• Các hành trình người dùng phải hoạt động trong các môi trường đã thống nhất.
• Những chuỗi, kịch bản wallet và chế độ xem dữ liệu nào được bao gồm.
• Điều gì được coi là một bài kiểm tra hoàn thành và ai xem xét kết quả.
• Những tệp cấu hình, ghi chú vận hành và mã nguồn nào được bàn giao.

Chúng tôi giữ các tiêu chí chấp nhận gắn liền với hành vi có thể nhìn thấy: người xem xét có thể làm theo luồng đã thống nhất, thấy trạng thái giao diện mong đợi và kiểm tra cách ứng dụng phản hồi với lỗi. Nếu bản build bao gồm một ứng dụng di động riêng, hãy căn chỉnh kế hoạch của nó với phát triển ứng dụng di động cho sản phẩm Web3 trước khi coi hỗ trợ trình duyệt di động và ứng dụng gốc là cùng một mục bạn nhận được.

Danh sách kiểm tra brief dApp 6 điểm của bạn

Thu thập 6 mục này trước khi phát triển bắt đầu. Với chúng, người xây dựng có thể báo giá chính xác và đội ngũ của bạn có thể xem xét từng cột mốc theo một tiêu chuẩn rõ ràng. Giữ danh sách đã đánh dấu cùng với hồ sơ của bạn, vì đó là cách nhanh nhất để giải thích sau này những gì đã được thống nhất.

• Liệt kê địa chỉ hợp đồng và chia sẻ ABI.
• Mô tả 3 thao tác người dùng chính.
• Nêu tên các chuỗi và wallet cần hỗ trợ.
• Quyết định dữ liệu nào các màn hình cần hiển thị.
• Chia sẻ tài sản thương hiệu và ghi chú thiết kế.
• Thống nhất các mục bàn giao: mã nguồn, ghi chú và các bước kiểm thử.

Thuật ngữ trong một dòng

ABI (nói một cách đơn giản: mô tả các hàm của hợp đồng mà frontend cần để gọi nó).

Lập chỉ mục có nghĩa là thu thập dữ liệu on-chain thành một dạng mà ứng dụng có thể đọc nhanh.

Từ brief đến bàn giao

Nguyên tắc chung: Hiển thị trạng thái wallet và mạng trên mọi màn hình để người dùng không bao giờ phải đoán họ đang ở đâu.

Một dApp chuyển sang triển khai khi người dùng, hành trình cốt lõi, yêu cầu chuỗi và phụ thuộc của nó đủ rõ ràng để đưa ra quyết định. Tại MarketingExtra, một đánh giá có cấu trúc ban đầu kiểm tra brief dựa trên công việc frontend, wallet và lập chỉ mục mà bạn đang yêu cầu, sau đó chúng tôi xác nhận kế hoạch và các điểm xem xét với đội ngũ của bạn.

Trình tự làm việc là thực tế: làm rõ luồng sản phẩm; xác nhận hợp đồng có sẵn, chi tiết chuỗi và nguồn dữ liệu; xác định trạng thái giao diện và kiểm tra chấp nhận; triển khai các thành phần đã thống nhất; sau đó xem xét kết quả và bàn giao các tài liệu đã thống nhất. Nếu hợp đồng hoặc dịch vụ bên ngoài vẫn đang thay đổi, chúng tôi đánh dấu sự phụ thuộc đó sớm để đội ngũ có thể quyết định hoàn thiện nó trước hay giữ công việc ứng dụng liên quan riêng biệt.

Để khởi động hiệu quả, hãy chuẩn bị:

• Một mô tả sản phẩm ngắn gọn và các thao tác người dùng chính.
• Thiết kế hiện có, kho lưu trữ, chi tiết hợp đồng và quyền truy cập kiểm thử, nếu có.
• Yêu cầu về chuỗi và wallet, cùng với dữ liệu mà giao diện cần.
• Một đầu mối liên hệ có thể giải quyết các quyết định sản phẩm và xem xét luồng công việc.

Dòng thời gian tuân theo kế hoạch đã xác nhận, tích hợp và nhịp độ phản hồi, vì vậy chúng tôi lên kế hoạch sau khi các phụ thuộc này được xem xét thay vì đưa ra một khoảng thời gian chung chung. Bạn nhận được một kế hoạch đã thống nhất, các điểm kiểm tra để xem xét và một bàn giao phù hợp với các tiêu chí bàn giao.

Hành vi nào phụ thuộc vào wallet và mạng

Một số hành vi ứng dụng nằm ngoài tầm kiểm soát của đội phát triển, ngay cả khi giao diện được triển khai như đã thống nhất. Các nhà cung cấp wallet có thể thay đổi lời nhắc hoặc hành vi được hỗ trợ của họ, và xác nhận giao dịch của một chuỗi hoặc tính khả dụng dữ liệu của dịch vụ lập chỉ mục có thể ảnh hưởng đến những gì người dùng thấy; những điều kiện đó không thể được đảm bảo bởi một bản build frontend. Chúng tôi thiết kế các trạng thái rõ ràng và kiểm thử các luồng đã thống nhất, nhưng hành vi của bên thứ ba vẫn là một sự phụ thuộc.

Giảm các bất ngờ có thể tránh được bằng cách ghi lại wallet và mạng nào đang được lên kế hoạch, sắp xếp quyền truy cập vào môi trường kiểm thử và thống nhất cách ứng dụng nên phản hồi khi kết nối hoặc yêu cầu dữ liệu thất bại. Nếu sản phẩm của bạn dựa vào các bản ghi đã lập chỉ mục cụ thể, hãy xác nhận nguồn gốc của các bản ghi đó và cách đội ngũ có thể xác thực chúng trong quá trình xem xét.

Trong quá trình chấp nhận, hãy kiểm tra trải nghiệm người dùng thực tế thay vì chỉ kiểm tra xem giao diện có tải không:

• Người xem xét có thể hiểu thao tác wallet được yêu cầu trước khi tiến hành không?
• Sản phẩm có đưa ra phản hồi hữu ích khi người dùng từ chối hoặc ngắt kết nối không?
• Các trạng thái đang tải, thiếu dữ liệu và lỗi có khác biệt và dễ hiểu không?
• Đội ngũ có thể xác minh rằng thông tin hiển thị khớp với nguồn đã thống nhất không?

Những kiểm tra này làm cho các phụ thuộc trở nên rõ ràng và cung cấp cho đội ngũ của bạn một cơ sở cụ thể để quyết định những gì sẵn sàng để bàn giao. Chúng cũng giúp tách biệt vấn đề ứng dụng khỏi vấn đề wallet, mạng hoặc dịch vụ dữ liệu thượng nguồn mà không hứa hẹn hành vi mà không nhà phát triển nào kiểm soát được.

Gửi 3 thứ: địa chỉ hợp đồng và ABI của bạn, luồng người dùng của bạn, và wallet cùng chuỗi cần hỗ trợ.

Cách hoạt động

1. Chia sẻ brief sản phẩmGửi trường hợp sử dụng sản phẩm, các thao tác người dùng chính và bất kỳ thiết kế hoặc mã nguồn hiện có nào. Bao gồm các yêu cầu về chuỗi, wallet và dữ liệu mà bạn đã biết.
2. Xem xét kế hoạch và phụ thuộcChúng tôi kiểm tra nhu cầu frontend, wallet và lập chỉ mục, xác định các quyết định hoặc quyền truy cập vẫn cần thiết và xác nhận những gì thuộc về bàn giao.
3. Thống nhất kiểm tra chấp nhậnChúng tôi xác định các hành trình người dùng, môi trường và hành vi có thể nhìn thấy mà đội ngũ của bạn sẽ sử dụng để xem xét triển khai.
4. Xây dựng và xem xétĐội ngũ triển khai kế hoạch đã thống nhất và chia sẻ nó để xem xét dựa trên các kiểm tra chấp nhận, với các quyết định và phản hồi được ghi lại.
5. Bàn giaoChúng tôi cung cấp các tệp đã thống nhất, thông tin thiết lập và buổi hướng dẫn để đội ngũ của bạn có thể thực hiện bước tiếp theo của sản phẩm.