如果重来，我会如何做在校项目

一直在反思当时在学校里面做过的项目，想着如果重来，我会怎么去做。有一些小的想法，按照我所理解的做项目的顺序总结、梳理一下。主要分为：明确目标；如何部署；如何开发；数据收集。由于之前在学校，和现在做得项目都是在线项目，所以所说的想法都是基于在线项目。

明确目标

在校项目往往是根据研究方向，先做点东西，然后找买家。这种模式的问题在于，当前做出来的产品，和用户最终期望的东西之间可能有一些距离。很多时候往往会为了满足用户希望，而修改产品。这样做也没有什么，但是一定要记住自己的底线。这个产品是为了解决什么样的问题，它的核心价值是什么。这方面我没有太多的经验，就只写这么多。

如何部署

如何部署包括了：新版本的部署，版本回退，数据恢复，应急响应等等方案。当时我们做得东西，由于一些连接语句是hard code的，导致部署需要大量的人工干预，成本很高。但是反观现在在单位，很大的产品，在azure和sql环境配置好的情况下，可以快速实现本地部署。而且现在每周可以实现小改动的发布，每月发布新的feature。这之间的差异是何等巨大。

如果周期性的迭代发布，当人员增多的时候，可能互相并不了解彼此之间的改动，可能形成冲突。另外，当测试覆盖率不够高或者其他因素导致新部署的版本有一些灾难性的问题，需要把在线版本回退到以前版本，该如何去做。为了避免一些开发当中导致的数据问题，我们也应该将开发数据库和真实数据库分离。

做在线服务，总会遇到这样或者那样的问题，如何快速响应？如何trouble shooting？怎么快速的发布hot fix。

如果我重新做在校项目，我会先集中精力把这些基本的问题解决掉。考虑到当时实验室的情况，我可能会用一台性能好的机器做产品的服务器。然后用另外一台机器，当成内部服务器。每周定时把所有新的改动发布到内部服务器，每两周或者每个月发布一次到正式版本。而每个人都是基于自己的机器上的local的系统和db进行开发。

如何开发

根据我的理解，敏捷开发和瀑布模型并没有本质上的不可调和。理想的开发模式是，在更短的周期里面完成设计、开发、测试、发布的流程。因为周期更短，所以每一次迭代的成本更低，犯错的代价更小。所以不用等到万事俱备再去开发，可以更大胆的尝试。因为开发周期变得更短，所以测试和开发可能更加需要并行，甚至基于产品测试(TIP, test in production)。

对于校园项目而言，可能人手紧缺，尤其是优秀的人手紧缺是永恒的痛。那么可以资源的分配就更加重要。可以让相对熟练的人承担更为重要的工作，而刚接触项目的人从事在产品上测试的工作。这并不是说测试的角色不重要或者要求更低。而是说低水平的人工测试的门槛相对较低，可以通过这个工作来更加熟练产品。同时，我认为开发人员保证逻辑部分的代码测试率是一件很必要的事情。UI部分的自动化测试，个人觉得对于校园项目来说，有点要求过高。

一些好的开发习惯也应该引入到项目开发中：code review和bug tracker。Code review可以帮助新人更快的提高，同时使得大家知道彼此在做什么。Bug tracker可以帮助记录问题解决的过程。这样遇到类似的问题可以借鉴。同时这个也对大家当前正在进行什么工作能有一个更好的了解。

数据收集

收集数据对于项目来说是一件非常重要的事情。对我而言，数据分为两种：1. 用户行为相关；2. 产品相关。前者包括用户点击了什么，动作序列是什么模式。从中我们可以知道用户到底怎么使用我们的产品。后者包括一些关于performance的信息、异常信息。这些信息可以帮助我们做trouble shooting，以及产品质量上的改进。所以，写Log对项目来说，非常重要！收集到了数据，好好分析也很重要！