Cadence入门|系列三：我如何组织Cadence项目

本篇文章将从以下几个方面为大家介绍:

• 组织和标准的价值

• 结构

• 应用程序代码

众所周知，保持代码清晰,项目结构合理非常重要，尤其是对于智能合约代码⽽言。这包括命名字段和函数的⽅式，如何在合同或交易中组织定义和结构以及如何写文档。所有这些都是非常重要的，将来我会写⼀篇博客来分享我的想法和建议，关于我认为最有效的组织Cadence代码的方法。今天，我将讨论更⾼层次的内容：如何在Github存储库中为项⽬目组织文件。

如果你正在构建⼀个其他⼈会想使用或者会⼀起使用的项目，那么让你的项目尽可能易于使⽤是⾮常重要的。其中一部分是如何组织你的项⽬结构。

建⽴在 Ethereum 的项⽬有 Truffle 框架，这是⼀个开发工具，帮助开发者获轻松设置，测试和部署。我们还处于Flow 的早期阶段，⽬前还没有⼀个很棒的自动化解决方案，但我们希望很快就能有!我们有⼀个很棒的团队在 Flow CLI 上⼯作，解决了这些问题中的一些，还有⼀些社区在努力简化Flow 上的开发者体验。

对于开发人员社区来说，在开发工作流的标准上保持⼀致是很重要的，这样实践就可以标准化、可复⽤和改进，从而使每个人都受益。

同时，我们必须自⼰进⾏管理，我想我已经找到了⼀种⾮常可靠的方法，希望其他人可以开始实施！如果您已经看过了了nba topshot，fungible token，nft，kitty items 或 core contracts ，那么您已经了解了这⼀点。

我花了一些时间思考这个问题，并对其进⾏了迭代，这是基于Cadence 智能合约交互的复杂性,我相信合约和交易应该是项目的⾸要和中心，应⽤程序代码和特定于语言的包在项⽬层次结构中要么同等重要，要么不那么重要。合约和交易是项目运作的核心，与每个人选择使⽤何种语⾔编写应⽤程序无关，对于开发者来说，理解和知道在第一次遇到项目时在哪里找到它是相当关键的。这个推理告诉了我如何构建Flow智能合约的回购。

重要的⽬录是:

contracts/transactions/lib/

contracts/: 这应该容纳项⽬的主要合约。从顶层轻松访问。

transactions/: 它应该包含所有与合约交互的交易和脚本，并充当事实上的的唯一来源。这个⽬录的内容可以按照开发人员想要的任何⽅式组织，但是可能每个都有一个目录，包含不同类型的合约⽤户的⼦目录，以及脚本，就像我对质押合约所做的那样:

idTableStaking/admin/delegation/node/scripts/

我对transactions 这个名字不感兴趣，所以如果有更好的名字，我洗⽿恭听。您还可以将脚本分割到⼀个单独的顶级⽬录中，这取决于您想如何组织项⽬。

lib/: 这就是我认为特定于语言的包和库应该存在的地方。可以想象，来⾃许多不同背景的开发人员都希望学习如何与合约进行交互，⽽公开对合约的访问并不像导入ABI那样简单。每种语言都需要一组包来生成公共交易和合约脚本。

在⼀个完善的合约仓库中，我想应该是这样的：

lib /js /python /cplusplus /go /rust /java /......

然后每种语⾔都可以有⼀个契约、模板和测试包，或者任何对特定语⾔或项⽬有意义的组织。这些包将采⽤contract / 和transactions/ (source of truth top level directories)中的模板，并根据其特定的语⾔对它们进⾏打包。

现在，太多的项目只是将交易复制粘贴到他们的应⽤程序代码中，这在短期内可以很好地⼯作，但如果在Cadence或合同或事务代码中出现了巨⼤的变化，更新复制和粘贴的代码将是⼀个巨大的麻烦。

像任何其他软件项⽬一样，合约应该用他们想要⽀持的语⾔发布他们的交易和合约包，然后依赖于它们的项目可以简单地更新他们的版本。

这就是我组织合同存储库的⽅式，但是到⽬前为⽌，我只有Go软件包。在lib/go/⽬录中，我有以下软件包：

• contracts ：包含一个包，⽤于获取repo中每个合约的代码，使用调用者指定的地址替换导⼊地址，具体取决于要部署到的⽹络

• templates ：包含⼀个软件包，用于获取存储库中每个交易和脚本模板的代码，使用调⽤者指定的地址替换导入地址，具体取决于要部署到的⽹络

• test ：包含智能合约和交易的模拟器自动化测试。这使得测试可以使用合约和模板目录中的包，以及特定于语言的实⽤⼯具方法来简化单元测试。

不幸的是，在构建除Go之外的语言包⽅面，我没有得到⾜够的帮助，所以如果有人有兴趣帮助，我将⾮常感激!

我们正计划创建⼀个测试框架，该框架可以直接在Cadence中进⾏单元测试，但这仍处于早期阶段。准备好之后，我可以想象另⼀个顶级目录可能包含⼀个用Cadence编写的⽬录tests/ 。

最后，应⽤程序代码需要⼀个位置。这是我在应⽤程序开发最佳实践⽅面经验最少的地方，但是我认为⼀个项⽬可以在两个选项之间进行选择。

我倾向于选择1，但我可能有点偏颇，因为我主要是⼀名智能合约开发者。我承认，我可能漏掉了我所谈到的各种不同选择的⼀些利弊，所以我绝对愿意听取反馈。即使我的结构被认为是⾸选的，它仍然需要⼤量的精简才能成为最好的。

我很⾼兴听到每个人的想法！我想尽快开始达成共识，以便社区能够对此进⾏标准化。随时在这里发表评论，或者在Flow论坛上发表⼀篇⽂章，如果需要，您可以留下更多反馈。

Flow Discord: https://discord.gg/flow

Flow Forum: https://forum.onflow.org

Flow Github: https://github.com/onflow/flow

下周见！