制作可发布的扩展
在本章中，你学到了如何创建各种类型的Yii扩展。现在我们来讨论如何分享你的结果，以及为什么这是重要的。
准备
首先为一个好的扩展准备一个清单。一个好的编程产品应该遵守如下点：
- 好的代码风格
- 人们应该找到它
- 一致性，易读，易使用的API
- 好的文档
- 扩展应该应用到大部分常用的使用例子上
- 应该被维护
- 充分被测试，理想情况下使用单元测试
- 你需要为它提供支持
当然，所有这些需要很多工作，但是他们是创建一个好产品所必需的的。
如何做…
- 每一个现代PHP产品应该遵守自动加载的PSR4标准，以及编码风格的PSR1和PSR2标准，这些标准参考指南http://www.php-fig.org/psr/。
- 详细回顾我们的清单，从API开始，API应该有一致性，易读易使用。一致性意味着所有的风格不会改变，变量名不变，没有不一致的名称，例如
isFlag1()和isNotFlag2()等等。每一件事应该遵守你为你代码定义的规则。它会让你很少查看文档，把精力集中在编码上。 - 没有文档的代码几乎是没有用的。一个例外是相对简单的代码，但是尽管只是很少几行，如果没有一些单词说明如何安装和如何使用，感觉并不会很好。什么构成了好文档？代码的目的和他的赞成者尽可能可见，并被明显和清晰的写出来。
- 如果开发者不知道在哪里放置它，以及如何在应用配置中使用它，那么这个代码是没有用的。不要期望人们知道如何做框架相关的事情。安装指南应该是啰嗦的。大部分开发者都喜欢手把手的形式。如果代码需要SQL schema才能工作，就提供他们。
- 尽管你的API方法和属性正确的被命名了，你仍然需要使用PHPDoc注释为他们加文档，指出参数的类型和返回类型，为每一个方法提供一个简洁的描述。不要忘记受保护的和私有方法以及属性，因为这对于阅读代码和理解代码是如何工作的细节是非常有帮助的。此外，考虑在文档中列出公共方法和属性，这样它可以作为一个引用被使用。
- 提供被充分注释的示例案例。尝试覆盖这个扩展大部分使用方法。
- 在一个例子中，不要尝试一次去解决多个问题，因为这可能会让人困惑。
- 让你的代码更灵活非常重要，这样它就会应用到需要使用情况中。但是，因为不能为每一种使用情况创建代码，尝试覆盖大部分的情况。
- 让人感觉舒服很重要。提供一个良好的文档是第一步。第二步是提供一个证明，说明你的代码能按预期工作，如果未来更新来可以。最好的方式是提供一组单元测试。
- 扩展应该被维护，至少它是稳定的，没有更多的特性请求和bug报告。所以期望问题和报告，并保留一些时间为代码的未来工作。如果你没有更多的时间来维护扩展，但它又是非常创新的，没有在此之前做过它，它仍然是值得分享的。如果社区喜欢它，就会有人提供帮助。
- 最后，你需要让扩展可用。为你的扩展创建Composer包，将它放在Github或者其它分享平台上，并将它发布在https://packagist.org网站上。
- 每一个扩展应该有一个版本号，以及一个修改日志。它能让社区检查他们是否用的最新版本，以及在升级前检查修改了什么。我们建议使用http://semver.org网站上提供的语义化版本规则。
- 尽管你的扩展相对简单，并且文档也很好，但仍然会有人在第一次使用时提问题，而能回答的人只能是你。典型情况下，问题会在官方论坛上提出，所以最好创建一个主题，这样人们可以讨论你的代码并在这个扩展页面上提供这个链接。
工作原理…
如果你想分享一个扩展到社区，并确定它是有用的和流行的，你需要做的不只是写代码。制作可发布的扩展有非常多的工作要做。甚至多于制作扩展本身。所以，why is it good to share extensions with the community in the first place?
将你自己项目中的使用的代码开源有它的赞成者。你能让人们，很多人测试你的闭源项目。使用你扩展的人在测试它，给出有价值的反馈，以及报告bug。如果你的代码是流行的，将会有热情的开发者尝试提高你的代码，让它更可扩展、更稳定以及可复用。而且，你将会感觉很爽，因为你做了一件好事。
我们覆盖了大部分重要的事情。此外，有更多的事情需要检查。在写自己的扩展前尝试用已有的扩展。如果一个扩展已经非常合适了，尝试联系这个扩展的作者，并贡献你自己的想法。检查已有的代码能帮助你找到有用的技巧、需要做什么以及不应该做什么。此外，不时地检查wiki文档，和官方论坛；这里有非常多有用的信息，关于创建扩展和使用Yii进行开发。
参考
- 欲了解更多关于PHP编码规则的信息，参考http://www.php-fig.org/psr/
- 欲了解更多关于语义化版本的信息，参考http://semver.org