區塊鏈的特徵之一是不變性。也就是說事務和狀態是不可變的。這意味著，一旦部署到鏈上，智慧合約就無法更改。由於多種原因而導致的需求延遲更改可能會產生一系列後果，這與硬體設計類似。當然，也有一些緩解措施，比如重新部署，但也有一些問題(比如合約地址的變更會耗費時間、燃料甚至名譽，因此會產生錯誤的解決方案)。目前對智慧合約的普遍關注是透過審計預防安全性和 bug, 但未來在實現改進之後關注點可能會被人們忽略。有時很難預測未來的業務需求和變化。此外，構建通用的或可升級的智慧合約可能很棘手，但這並不意味著計劃應該以草率的方式完成。儘管如此，智慧合約的開發通常適合進行團隊開發，在這種開發中，使用者故事應該被分解成任務並以適當的方式進行規劃。綜上所述，很明顯，計劃過程和智慧合約審計一樣重要。規劃過程的輸出應該是某種書面上的規範，同時這可以作為開發的輸入，也可以作為未來使用和整合的指導。不管團隊的總體開發過程是什麼，每個智慧契約開發過程都應該有幾個步驟，大致如下:1.需求收集和計劃——包括從多個來源收集輸入事實，同時注意需求的可追溯性2.規範編寫——這是一種非標準化的技術指定收集的需求3.編碼——編寫符合指定需求的程式程式碼4.測試——手動測試自動單元的功能，通常智慧合約的程式碼覆蓋率為90%。5.稽覈——首先在內部稽覈程式碼，然後在所有前提條件下提交外部安全稽覈6.部署流程——“推進生產”的手動或自動流程當智慧合約以適當的方式完成時，它可以適合敏捷的迭代或增量。或者可以以增量的方式進行，看起來就像水流落下一樣通暢。它的缺點是，測試應該在整個過程中就全部完成，因為智慧合約是安全關鍵。所以，V和W的模型很合適。無論如何，它通常取決於團隊的偏好或專案管理決策。以一種不僅對開發有幫助，而且對以後的任務也有幫助的方式編寫規範是至關重要的。有幾個方面需要考慮。首先，安全性是一個高階需求，它可以歸結為對已知攻擊的測試和維護安全的編碼原則。這包括對不同使用者的訪問限制可以從最初的需求中識別的角色。UML用例圖可以用於此目的，其中角色很容易被識別。如果存在多個RBAC模型，則可以用訪問控制矩陣表示RBAC模型。稍後，在開發過程中，可以歸結為編寫函式訪問修飾符。有時需要部署多個依賴的合約來完成指定的需求。如果複雜性更高，其他的選項是UML通訊圖和N2圖表。但是，智慧合約不是一個孤立的島。它與正在構建的產品的其他部分有連線和互動。其中一些只是讀取狀態，另一些可以執行事務。然而，DApp通常使用ABI作為合約的介面。對於通訊序列，UML序列圖是最好的解決方案。如果合約中涉及的各方更多，資料流程圖也是一種選擇。此外，部署前和部署後的維護操作應該在規範中進行預見和編寫。編碼風格通常是開發人員抉擇的，但是實現乾淨的程式碼應該始終是一種高階追求。Antoine DE Saint-Exupery 曾經說過:“完美的實現不是沒有什麼可新增的，而是沒有什麼可帶走的。”在編寫程式碼時，應該始終強調這一原則。它意味著對模式的需求和使用有清晰的理解。此外，有必要考慮智慧合約的通話效能，這可以歸結為天然氣成本最小化。綜上所述，智慧合約與標準編碼有一定的區別。它們應該是簡單和直接的，所以在實際開發它們之前，適當的計劃至關重要。作為第一步，應該進行適當需求收集和分析，以便以令人滿意的方式編寫規範。然後, 充分的編碼原則會產生高質量的程式碼, 作為測試和稽覈階段的輸入。最後，部署過程是最後一步，走到這一步就沒有回頭的選擇了。因此，確保以最佳方式進行規劃和審計至關重要。
更多數字貨幣資訊：www.qukuaiwang.com.cn/news
