一直在反思当时在学校里面作过的项目,想着若是重来,我会怎么去作。有一些小的想法,按照我所理解的作项目的顺序总结、梳理一下。主要分为:明确目标;如何部署;如何开发;数据收集。因为以前在学校,和如今作得项目都是在线项目,因此所说的想法都是基于在线项目。sql
在校项目每每是根据研究方向,先作点东西,而后找买家。这种模式的问题在于,当前作出来的产品,和用户最终指望的东西之间可能有一些距离。不少时候每每会为了知足用户但愿,而修改产品。这样作也没有什么,可是必定要记住本身的底线。这个产品是为了解决什么样的问题,它的核心价值是什么。这方面我没有太多的经验,就只写这么多。数据库
如何部署包括了:新版本的部署,版本回退,数据恢复,应急响应等等方案。当时咱们作得东西,因为一些链接语句是hard code的,致使部署须要大量的人工干预,成本很高。可是反观如今在单位,很大的产品,在azure和sql环境配置好的状况下,能够快速实现本地部署。并且如今每周能够实现小改动的发布,每个月发布新的feature。这之间的差别是何等巨大。服务器
若是周期性的迭代发布,当人员增多的时候,可能互相并不了解彼此之间的改动,可能造成冲突。另外,当测试覆盖率不够高或者其余因素致使新部署的版本有一些灾难性的问题,须要把在线版本回退到之前版本,该如何去作。为了不一些开发当中致使的数据问题,咱们也应该将开发数据库和真实数据库分离。性能
作在线服务,总会遇到这样或者那样的问题,如何快速响应?如何trouble shooting?怎么快速的发布hot fix。测试
若是我从新作在校项目,我会先集中精力把这些基本的问题解决掉。考虑到当时实验室的状况,我可能会用一台性能好的机器作产品的服务器。而后用另一台机器,当成内部服务器。每周定时把全部新的改动发布到内部服务器,每两周或者每月发布一次到正式版本。而每一个人都是基于本身的机器上的local的系统和db进行开发。设计
根据个人理解,敏捷开发和瀑布模型并无本质上的不可调和。理想的开发模式是,在更短的周期里面完成设计、开发、测试、发布的流程。由于周期更短,因此每一次迭代的成本更低,犯错的代价更小。因此不用等到万事俱备再去开发,能够更大胆的尝试。由于开发周期变得更短,因此测试和开发可能更加须要并行,甚至基于产品测试(TIP, test in production)。code
对于校园项目而言,可能人手紧缺,尤为是优秀的人手紧缺是永恒的痛。那么能够资源的分配就更加剧要。可让相对熟练的人承担更为重要的工做,而刚接触项目的人从事在产品上测试的工做。这并非说测试的角色不重要或者要求更低。而是说低水平的人工测试的门槛相对较低,能够经过这个工做来更加熟练产品。同时,我认为开发人员保证逻辑部分的代码测试率是一件很必要的事情。UI部分的自动化测试,我的以为对于校园项目来讲,有点要求太高。orm
一些好的开发习惯也应该引入到项目开发中:code review和bug tracker。Code review能够帮助新人更快的提升,同时使得你们知道彼此在作什么。Bug tracker能够帮助记录问题解决的过程。这样遇到相似的问题能够借鉴。同时这个也对你们当前正在进行什么工做能有一个更好的了解。资源
收集数据对于项目来讲是一件很是重要的事情。对我而言,数据分为两种:1. 用户行为相关;2. 产品相关。前者包括用户点击了什么,动做序列是什么模式。从中咱们能够知道用户到底怎么使用咱们的产品。后者包括一些关于performance的信息、异常信息。这些信息能够帮助咱们作trouble shooting,以及产品质量上的改进。因此,写Log对项目来讲,很是重要!收集到了数据,好好分析也很重要!开发