在校的时间基本上是越来越少，这个时间基本没有项目在做了（应该只剩一个毕设——已被安排貌似还不错就是比较简单）。反观之前做的很多项目，理想跟现实总是大相径庭——这也是客观事实，不过从项目里还是得到了很多东西，再加上实习期间自己的学习感触，如果很多校内项目重新来过，我们有很多方面可以改进，不仅仅是跳过那些不必要的过程或者更高效的完成项目中的某些阶段，更重要的是清晰的知道自己要怎么做和如何做得更好。
目标与计划齐飞
一句废话。然而事实是说到做不到的人太多了，废话也要不停说。
不管是“自发性”的还是“委托性”的项目，都需要一个相对规范的Plan，成员的空余时间决定了团队的进度安排和整体走向，很多项目就是在漫无目的的敲敲打打中晃过去了大部分的时间，过了很久才发现只做了一点点东西或者距离目标相去甚远。
学过《软件项目管理》的同学应该了解其中的奥妙，没看过也没关系，只要懂目标，分步规划就好了，这样总是没错的。从计划的角度看，很多人在项目中学到的不单单是如何编程和解决问题，更重要的是知道了如何对项目的状况进行管理。
管理，这个词就这样轻松的进入了你的世界，不知不觉。
如果重新做这些项目，把目标和工作计划制定的井井有条，效率的提升可能是难以想象的，不仅仅是今天的总结和明天的Issue，更重要的是每个成员都对项目有一个整体的把我和对自我功能性的明确，这是校内项目跟商业项目最为不同的一点。
不靠谱的用户才是好用户
以前犯过这样的错误：想要一个非常确定的需求。后来渐渐发现这是不现实的。有Idea的人不见得就想的清楚Detail。
很多同学的状况是：“好啦，你给我一个需求文档吧，详详细细，我只要知道实现什么功能嘛”，“你给的不全要我怎么办，这样我没办法做啊”，“这个怎么是BUG呢，我是按照需求来做的啊”，“那个BUG我改了，如果还不行，就没办法了”……
很难说孰是孰非，如果站在一个码农的角度，你可能合格了（当然不排除这里面的消极情绪，很可能这是一个“冗余”的开发过程或者干脆就是一个“被动受制”的项目）；如果把自己提升到开发者或者更高的层次，这样的做法显然有问题。
“唯一不变的就是需求不停的改变。”绝大多数用户是不知道自己真正想要什么的，他们心里只有模糊的概念，这时候的需求分析就是从用户的角度和实际的角度来综合分析出需要实现的目标（这样说也许简单了，如果是商业项目的话需要考虑的方面会更多），然后去同用户进行确认，然后迭代基本就不会出现大的问题了。细节因项目而异，自己感知吧。
部署什么的Bullshit
做一个成品的项目，最终需要生成很多的东西：源码包，文档（Manual，Demand，Design），可运行包（或者是线上），DB，其他Data……一开始我们的项目，一到最后需要Test的阶段基本上可以用惨不忍睹来形容——每一步都需要不停的重复一些繁琐的配置或者运行脚本机制等等，究其缘由，其实是部署的问题。
部署包括了：新版本的部署，版本回退，数据恢复，应急响应等等方案。当时我们做得东西，由于一些连接语句是hard code的，导致部署需要大量的人工干预，成本很高。但是反观实习单位和目前行业的状况，很大的产品，在azure和sql环境配置好的情况下，可以快速实现本地部署。而且现在每周可以实现小改动的发布，每月发布新的feature。这之间的差异是何等巨大。
如果周期性的迭代发布，当人员增多的时候，可能互相并不了解彼此之间的改动，可能形成冲突。另外，当测试覆盖率不够高或者其他因素导致新部署的版本有一些灾难性的问题，需要把在线版本回退到以前版本，该如何去做。为了避免一些开发当中导致的数据问题，我们也应该将开发数据库和真实数据库分离。
做在线服务，总会遇到这样或者那样的问题，如何快速响应，如何trouble shooting，怎么快速的发布hot fix；做离线服务，如何做到流程精化；做分布式服务，如何做到CAP，又需要根据情况舍弃哪一种特性，等等。
如果我重新做在校项目，我会先集中精力把这些基本的问题解决掉。考虑到实验室的情况，我可能会用一台性能好的机器做产品的服务器。然后用另外一台机器，当成内部服务器。每周定时把所有新的改动发布到内部服务器，每两周或者每个月发布一次到正式版本。而每个人都是基于自己的机器上的local的系统和DB进行开发。
开发？你挑水来我浇园
在我看来，敏捷开发和瀑布模型并没有本质上的不可调和。理想的开发模式是，在更短的周期里面完成设计、开发、测试、发布的流程。因为周期更短，所以每一次迭代的成本更低，犯错的代价更小。所以不用等到万事俱备再去开发（这是我以前常犯的一个错误，总是希望自己能把一切准备都做好，殊不知这样不仅不现实而且无形中浪费着自己已有的资源），可以更大胆的尝试。因为开发周期变得更短，所以测试和开发可能更加需要并行，甚至基于产品测试(TIP, test in production)。