开发成长之路（20）-- 面试时没项目经验？大学生如何写个人/团队项目
项目经验
应届生、暑期实习生在找实习的时候，项目经验重不重要？不用我说了嘛。
那就需要写一些项目。
昨天聊完一场这方面的话题之后就有不少的小伙伴来问我这个问题，这让我怎么回答嘛，还是统一回复吧。
首先，可以去网上找一些成熟的项目框架学习，然后找一份项目，自己从头开始做需求分析，做时间规划，做人员安排（不过不出意外所有方面都是一个人在做，团队不好找），然后每天写日报，项目写出来之后再联调、优化、联调、优化，写心得。
大致流程是这样的，不过比较忌讳几点：
1、某个环节偷懒了，去找现成的，特别出现在需求分析、代码编写部分，找现成的，多看几遍，真以为面试官看不出来吗？
2、写好之后就万事大吉了，没有优化，甚至连联调都没有。大兄弟，当简历投递页面建议你最好提交作品的时候你却不敢提交，你就知道个中苦闷了。
3、不写日报，不写心得，或者写了也是划水。不要以为是自己写的项目就记得很牢，你且过几个月再看，没有这些“一手资料”，你还想不想的起来自己当时写的是什么玩意儿。
敏捷
完整团队
计划游戏
客户测试
简单设计
结对编程
测试驱动开发
改进设计
可持续的速度
重构
重构？是什么：
对项目内部结构的一种调整，目的是在不改变成品可观察行为的前提下，使项目更加亲切，通俗易懂，高效。
重构提高编程速度！！
有的人可能不同意这一点啊，感觉像是在开玩笑，毕竟重构一次需要不少时间，这也不是开玩笑的。我一般，第一波重构要花个一两天，当然，我是个对自己有要求的人，所以我现在控制在一天。第二波重构也就花个半天，然后还能歇个半天，最后那波优化就比较久了。
但是，曾经一个亲身经历让我明白，重构所花费的时间都不算什么。那是我刚开始做项目时候的事情了，刚开始还好，代码之间的联系不多，写了几天之后，各个功能需要串在一起了，这时候麻烦来了。首先是函数接口不明朗，有的功能函数，单独的测试demo都好好的，但是一接起来就各种不适应出来，好不容易串起来了，又出现那种牵一发而动全身的状况，陷入泥潭之后，又发现有些细节的东西就忘了，不知道某些地方为什么要那样写，那样写的优势和意义在哪里？之前明明记得很清楚，这才几天咋就忘了。。。然后，然后···心照不宣，一把辛酸泪。
一般重构也不用重构很多次，三次差不多，做到中间的时候、做完的时候、优化的时候。
少了不好，多了确实浪费时间。
大改的时候重构：
比方说要添加一些重要功能的时候，特别是那种后期会牵一发全身抖一抖的那种，这时候需要对项目又足够的把控的时候。
重构的几个大方向：
1、重复代码
2、过长函数
3、过大的类
4、过长的参数列
5、发散式变化，霰弹式修改
6、脚踏n条船的函数
7、内存管理
8、多余的注释
每个类都配备测试代码：
每个类都配备测试代码，烦不烦啊你？
烦。但是项目run的时候爆了烦不烦？那会儿可就不是一个人烦了，那是一个团队一起烦。
这种问题其实完全可以避免，甚至可以不发生，只要给每个类配备一个测试代码。
写一个测试代码能花多少时间，十分钟，测试一下能花多少时间，十分钟。害怕测出问题？那有问题就是有问题啊，专项解决不是效率更高吗！！！
怎么写那是个人自己的事情。但是，我想说的是，测试代码，最好写在功能类之前，这样可以预先界定功能类的具体功能，也可以把思路清晰一下。
至于测试代码要测试哪些东西？
你害怕哪里出问题就重点测试哪里，我们不能确保在测试代码中把所有问题全暴露出来，但是我们要花最少的时间，将利益最大化！！！
一般测试的地方：
1、寻找内存边界条件，防止越界（段错误）
2、寻找特殊的，可能导致错误的条件。
3、测试最高容量、效率，如线程池、epoll等。
4、测试数据库调度。
5、测试任务调度情况。
6、害怕哪里重点测试哪里。
7、继承下的测试：这个要自己想办法去做组合测试。
测试无法抓出所有bug，但是它可以·抓出绝大部分bug。
花合理时间去抓出大部分bug，要好过穷尽一生去抓出所有bug。