與傳統(tǒng)程序代碼相比，solidity智能合約代碼量往往很少，不同點(diǎn)是，每行代碼都很重要，需要小心謹(jǐn)慎，可謂字字珠璣：-），正是這樣的原因，一個(gè)沒(méi)有太多經(jīng)驗(yàn)或者思維不嚴(yán)謹(jǐn)?shù)能浖こ處熮D(zhuǎn)向solidity智能合約工程師后會(huì)感到亞歷山大，遇到問(wèn)題無(wú)從著手。不過(guò)，隨著行業(yè)的發(fā)展，我們?nèi)匀豢梢钥偨Y(jié)出一些應(yīng)對(duì)問(wèn)題的思路，我們需要做的只是如何借鑒別人的經(jīng)驗(yàn)：

一，遵循最佳實(shí)踐

這個(gè)行業(yè)里，“code is law”是一個(gè)神圣的準(zhǔn)則，因此開(kāi)源已經(jīng)成了基本規(guī)則，當(dāng)你的源代碼攤在陽(yáng)光下的時(shí)候，安全就成為了首要的考慮因素，特別是涉及金錢(qián)交易的時(shí)候。不幸的是，由于安全意識(shí)的淡薄和大多數(shù)工程師的能力原因，智能合約的安全現(xiàn)狀仍然很?chē)?yán)峻。不過(guò)業(yè)界仍然總結(jié)出了一些最佳實(shí)踐，如“Checks-Effects-Interactions”模式，“fail-safe”模式，合約最小化，合約模塊化，”禁止tx.origin 用于認(rèn)證“等，更多詳細(xì)內(nèi)容也可以參考我以前的文章。這些都是前人在一次次失敗后總結(jié)出的珍貴教訓(xùn)，我們應(yīng)該認(rèn)真學(xué)習(xí)這些最佳實(shí)踐，并運(yùn)用到實(shí)踐中，以避免重蹈覆轍。

二，盡可能復(fù)用成功的代碼

盡管短小，從零寫(xiě)出一套智能合約同時(shí)有比較完美實(shí)屬不易，短小的代碼背后需要考慮太多的因素。好在前人們已經(jīng)幫我們做了很多，業(yè)界已經(jīng)有了一些基本的合約代碼庫(kù)供我們復(fù)用，如果你用truffle作為開(kāi)發(fā)工具，你會(huì)發(fā)現(xiàn)它已經(jīng)包含了很多有用的庫(kù)，你只需要繼承并實(shí)現(xiàn)你自己的邏輯即可。值得提醒的是，哪怕你很自信你可以寫(xiě)出更好更安全的代碼，我們?nèi)匀唤ㄗh你復(fù)用這些代碼而不是重新造輪子，因?yàn)檫@些代碼是一個(gè)團(tuán)隊(duì)而不是一個(gè)人的作品，而且這些代碼都是久經(jīng)生產(chǎn)環(huán)境考驗(yàn)的代碼。當(dāng)然，這么做也節(jié)省了我們的時(shí)間與精力。

三，合理考慮升級(jí)

眾所周知的是，智能合約代碼一旦部署就無(wú)法改變。合約的升級(jí)一直是一個(gè)令業(yè)界頭疼的話題。事實(shí)上，用傳統(tǒng)軟件思維方式套在智能合約的腦袋上這種新瓶裝舊酒的想法本來(lái)就有待商榷。畢竟，區(qū)塊鏈的一個(gè)特性就是不可更改，從而“code is law”的神圣準(zhǔn)則才得以彰顯。而合約的升級(jí)本質(zhì)就是更改，這顯然與區(qū)塊鏈的規(guī)則是相悖的。但另一方面，我們凡夫之人總是糾結(jié)于如何改變，面對(duì)這一普遍性意識(shí)，作為工程師，你無(wú)能為力。因此，你仍然需要在設(shè)計(jì)合約時(shí)就要考慮如何升級(jí)，雖然業(yè)界目前并沒(méi)有太好的辦法，模塊化是一種普遍的思路。

四，獨(dú)立的流程管理

由于所有智能合約工程師都是從傳統(tǒng)軟件工程師進(jìn)化而來(lái)，很多人仍然在用傳統(tǒng)軟件的思維指揮著自己的四肢。但至少有一點(diǎn)需要引起人們的警覺(jué)，即鏈上的任何操作都是不可回退的。筆者就遇到一個(gè)案例，由于一個(gè)工程師對(duì)業(yè)務(wù)目的理解的小小偏差，導(dǎo)致一個(gè)錯(cuò)誤的操作上鏈，造成業(yè)務(wù)極大的影響。因此，對(duì)待鏈上操作應(yīng)該比對(duì)待傳統(tǒng)生產(chǎn)環(huán)境更加嚴(yán)格，而達(dá)成目的的方法就是制定適合區(qū)塊鏈業(yè)務(wù)的獨(dú)特流程。

以上這些只是從大的方面介紹了智能合約開(kāi)發(fā)的思路，希望能幫到有需要的小伙伴，至于細(xì)節(jié)，還需要結(jié)合自己情況，量體裁衣。