因为时间有限，开发时间是早上6:00-9:00，晚上9:00-12:00，周末，所以项目周期可能比普通的。我的计划是这样的：七月到八月，完成了zendengine部分核心数据库的封装。这个阶段主要是对zendengine一些常用的数据接口进行面向对象的封装，比如用的最多的HashTable。zendAPI会为其提供一个STL风格的数据访问迭代器，HashTable的通用访问语义接口，在开发者的日常调用中避免使用类型不安全的宏调用。8-9月，初步完成了功能和面向对象语义的接口封装。这部分主要是让开发者方便的将自己定义的函数、变量、类等挂载到zendengine，获取一些日常的参数和返回值。进行标准化，让写自定义函数的时候只关心自己的业务逻辑，让这部分代码远离zendengine的底层细节。面向对象的思想类似于函数。它主要允许开发者创建自己的命名空间。自定义类更加简洁，不需要太在意底层的一些繁琐细节。ZendAPI届时将提供与PHP版本号的兼容性，所以对于以后的升级，可以最大程度的避免修改你的扩展。9-10月完成全球资源统一访问接口的封装。PHP一开始就引入了一些非常糟糕的全局变量和资源。其实这样不太好，会大大降低程序的可维护性。但历史已经无法改变。我们只能以相对安全的方式使用它，逐步淘汰它。在zendAPI中，我们会为它提供一些统一的访问接口。10月到11月，zendengine启动过程的封装和扩展离不开zendengine。我们必须将我们开发的扩展挂载到zend引擎内核。Zendengine有自己的启动流程，自己定义了生命周期的概念，提供了很多钩子函数和很多宏来帮助我们完成这个工作，但是比较繁琐和复杂，有时候我们不一定需要深究这样的细节是在浪费我们宝贵的开发时间，所以我们将这个过程封装在zendAPI中，并尽量以面向对象的方式简化整个启动过程。从11月到12月，我一直认为文档对于一个好的开源项目来说是非常重要的，有时候甚至比项目本身还重要，因为现在大家的节奏都比较快，没有时间纠错.研究代码。如果一个项目有很好的文档支持，会大大降低入门门槛，让更多人使用这个项目，才会物有所值。如果zendenginekernel这方面做的好，估计我们这个项目也不存在了。zendAPI的文档主要在官网提供。分为三个方面：用户手册、API接口文档、开发博客，从12月到2018年1月，软件打包和发布流程将得到改进。因为是我一个人临时开发的，包括网站维护和文档编写，所以很多方面都欠缺。到这个阶段，第一个版本的开发就基本结束了。这个阶段基本完成了打包脚本的优化和一些小工具的开发，比如生成项目结构的小程序。规范版本号和版本发布流程，针对主流平台进行测试，提供相应的二进制包（rpm，deb）等。总的来说，这对我来说是一个非常大的挑战。很多事情对我来说都是第一次。希望zendAPI能顺利和大家见面，谢谢。
