-
First step*
前言：
在他人或者老师的引导下，本小白终于有了自己的博客，怀着好奇和新鲜的情怀在这里开始了自己接触大舞台的机会？接触csdn的确很有意义，至少眼前一亮是有的，并且似乎燃起了很久没有萌动的学习欲望，于是我决定认真的按要求的去听听话。
感受：
- 可能是他人的高度评价，让我在翻开《构建之法》时有一些agitation，仔细看过第一版的读者反馈，感触就是评价真高，能有一本好书来学习观看是一件很开心的事。不漏一字的看过所有前序，随后迫不及待的读完1，5，17三个章节，不得不说邹欣老师给读者展现的画面非常生动有趣，虽然依旧有懵懂的感觉，但是相比于课本，我一定更倾向于这本书。
文字幽默，内容专业，诠释细致，一些不懂的地方大概就是个人水平还不太够吧~
关于团队模式和软件流程：
概论里讲到软件=程序+软件工程，软件开发有四个阶段，玩具，业余，探索和成熟，循序渐进，就像一个人的成长历程，同理，一个团队也要经历类似的过程，从最初的组建，大家还不是很了解的时候，就类似与玩具，工作时的模式就像窝蜂模式，随着团队间 的熟悉，对于学生团体来说，更容易演变成主治医师模式，整个团队有一个住负责的人物，其他的人配合他，当然随后就非常有可能发展成明星模式，而且很多时候，都是这个模式，一个人就掩盖了其他人的光芒，逐渐其他人开始放弃出力，因为那一个人会把所有人的都做得很好，其余人做的他会觉得档次不够，效率慢等。
很明显，如果一个团队的工作变成了一个人做，那么这个团队就没有任何意义，并且有可能会激发一些没必要的矛盾，我认为，针对于学生团队，大家的综合实力水平不能差距过大，同时，各自的侧重点应该有所不同，这样，在一个项目中，可以各司其职，不会有冲突，在不断磨合之后，整个团队的效率就会得到显著的提高，因为每个人都在做事，每个人都会认为自己是有价值的，而如果团队中的个体侧重一样，比如说两个人同时写相同功能的代码，肯定会有一个人的效率高，另一个稍差，这样的好处是有的，因为人多大家可以相互弥补各自的bug，但是另一方面，这也加大了资源浪费，既然有一个人写的可以胜任？那另一个人干嘛还要浪费在这方面呢？他可以去分担其他的任务，可是其它的任务他不太会，那么这个人在团队中的作用就大大降低，我认为团队中不需要这样的存在。
一个好的团队，应该有一个好的核心，这个核心不一定是综合实力最好，他应该更像一个领导或者公司的项目经理？他能兼顾督促项目的进度和成员之间的关系，并且对整个团体的进步起主要作用，好的领头人可以让团体的进取心提升，不断加强各种实力，培养学习兴趣，提高成员之间的默契度，这个核心也需要是成员认可的。
一个团队规范化后，开始了软件开发，开发流程模式挺多，学校里专业的大作业就是写了再改模式，非常形象，至于瀑布模型同学大多没想过，软件工程课上完之后也只是粗滤的了解下，并没有任何深入的理解，认识的一个大牛说‘这些东西很有用的，看不懂学不会只是实力不到位’，因为老师的要求低，学生的自我要求更低，所以做的东西都比较简单，接触不到深层次的东西也是情理之中？但是一个优秀的软件一定是要有严格的模式方法的，因为他需要让用户满意，同时包含后续的优化和修改增减功能等，瀑布模型之后的各种模型都比较重视计划，事先设计以及文档表达，RUP就把软件开发的各个阶段统一到一个框架，从最初的建模，需求分析和设计到测试部署等，个人感觉这适合大公司的软件开发，依旧是针对于学生来说的话，我认为MVP是很好的选择，最小可行产品把最核心的功能实现，这样就可以看到它实现之后是否满足需求，比较省时省力，至于MBP，完美作品肯定不是初学者可以一蹴而就的，需要很多的经验和资历，当然，也需要很大的自信。
ps：
用了段时间写完这些内容还是比较有成就感的，不过以后的自己看到肯定会嘲笑现在自己水平的拙劣，不过那又如何呢~这个markdown编辑器也是第一次接触，排版好看点还不太会,”(font size face )”