与传统程序代码相比，solidity智能合约代码量往往很少，不同点是，每行代码都很重要，需要小心谨慎，可谓字字珠玑：-），正是这样的原因，一个没有太多经验或者思维不严谨的软件工程师转向solidity智能合约工程师后会感到亚历山大，遇到问题无从着手。不过，随着行业的发展，我们仍然可以总结出一些应对问题的思路，我们需要做的只是如何借鉴别人的经验：
一，遵循最佳实践
这个行业里，“code is law”是一个神圣的准则，因此开源已经成了基本规则，当你的源代码摊在阳光下的时候，安全就成为了首要的考虑因素，特别是涉及金钱交易的时候。不幸的是，由于安全意识的淡薄和大多数工程师的能力原因，智能合约的安全现状仍然很严峻。不过业界仍然总结出了一些最佳实践，如“Checks-Effects-Interactions”模式，“fail-safe”模式，合约最小化，合约模块化，”禁止tx.origin 用于认证“等，更多详细内容也可以参考我以前的文章。这些都是前人在一次次失败后总结出的珍贵教训，我们应该认真学习这些最佳实践，并运用到实践中，以避免重蹈覆辙。
二，尽可能复用成功的代码
尽管短小，从零写出一套智能合约同时有比较完美实属不易，短小的代码背后需要考虑太多的因素。好在前人们已经帮我们做了很多，业界已经有了一些基本的合约代码库供我们复用，如果你用truffle作为开发工具，你会发现它已经包含了很多有用的库，你只需要继承并实现你自己的逻辑即可。值得提醒的是，哪怕你很自信你可以写出更好更安全的代码，我们仍然建议你复用这些代码而不是重新造轮子，因为这些代码是一个团队而不是一个人的作品，而且这些代码都是久经生产环境考验的代码。当然，这么做也节省了我们的时间与精力。
三，合理考虑升级
众所周知的是，智能合约代码一旦部署就无法改变。合约的升级一直是一个令业界头疼的话题。事实上，用传统软件思维方式套在智能合约的脑袋上这种新瓶装旧酒的想法本来就有待商榷。毕竟，区块链的一个特性就是不可更改，从而“code is law”的神圣准则才得以彰显。而合约的升级本质就是更改，这显然与区块链的规则是相悖的。但另一方面，我们凡夫之人总是纠结于如何改变，面对这一普遍性意识，作为工程师，你无能为力。因此，你仍然需要在设计合约时就要考虑如何升级，虽然业界目前并没有太好的办法，模块化是一种普遍的思路。
四，独立的流程管理
由于所有智能合约工程师都是从传统软件工程师进化而来，很多人仍然在用传统软件的思维指挥着自己的四肢。但至少有一点需要引起人们的警觉，即链上的任何操作都是不可回退的。笔者就遇到一个案例，由于一个工程师对业务目的理解的小小偏差，导致一个错误的操作上链，造成业务极大的影响。因此，对待链上操作应该比对待传统生产环境更加严格，而达成目的的方法就是制定适合区块链业务的独特流程。
以上这些只是从大的方面介绍了智能合约开发的思路，希望能帮到有需要的小伙伴，至于细节，还需要结合自己情况，量体裁衣。
