第3次作业：阅读《构建之法》1-5章
这个作业的要求来自于：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178
不知不觉已经开学一个月了，趁着国庆长假，抽时间阅读了一下《构建之法》的1-5章
第一章 概论
第一章主要讲述了计算机科学的领域，软件工程和计算机科学的关系，软件的特性，软件工程的定义与组成部分。
选择了软件工程这个专业，同时以为自己对软件工程的概念是可以解释清楚的，知道看了打一章才知道原来以前的想法有点异想天开了
在第一章止中我印象最深的就是1.1中的疑问“2我成了一名职业程序员，但是我发现所有的算法别人都已经实现了，我只要调用就可以。似乎我们公司的软件与数据结构、算法的关系都不大。那我当初辛辛苦苦学习的数据结构和算法有用么？如何区分一个好的程序员和不好的程序员呢？”这个也是我上大学之后的一个比较在意的疑问，从书中能够了解到“软件=程序+软件工程”而“程序=数据结构+算法”从中可以体会到，开发一个软件，我们所要做的并不仅仅是把软件的功能实现，一些内在的比如算法优化之类的都是我们所要最求和完善的。算法是计算机科学领域最重要的基石之一，而现成的算法确实很多。但“没有一身好内功，招式再多都是空。”新的语言、技术可以比作“外功”，将算法比作“内功”，只懂得招式，没有功力，是不可能成为高手的。
其实我有听过一些工作的前辈说过一个这样的问题，公司一个就员工走后，新来的员工其实很难完全接手前人留下的程序。虽然可以规范一下，但个人觉得其实是很难实现的，看完书也没找到比较好的解决方法
第二章 个人技术和流程
这一章主要介绍单元测试，回归测试，效能分析，个人软件开发流程
在2.1.1中小飞和阿超的对话充分地说明了单元测试的重要性，并且了解到单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位：函数。但我对怎样写单元测试还是不够清楚
关于不知道怎样写单元测试这个问题我找到了一些大佬给你看法“这个问题在于，还没有接触过单元测试，同时，也没有体会过企业级的代码开发。不知道同时也不了解单元测试能带给你什么。单元测试是根，是基本，基本最无敌。单元测试存在于测试金字塔的底端，撑起了整个金字塔，编写它是开发人员的职责。设想一下，当你开发完一个功能模块的时候，你如何确定你的模块没有 bug 呢？如果涉及到具体的业务，你会执行 debug 模式，然后一点一点的深入到代码中去查看吗？如果你一直都是这样，那么你早就已经 OUT 了。赶快去了解一下单元测试的工具吧，你会收获很大的”
有个疑惑的地方就是单元测试很重要，但是单元测试也是真的很费时间，那么实际项目的开发中，为了减少Bug，如果每个小函数，小程序都进行单元测试向合格真的有必要吗？还是说视情况而定？
第三章 软件工程师的成长
这一章主要讲评论软件工程师水平的主要方式，技能的反面，TSP对个人的要求，软件工程师的思维误区
在3.3中的魔方事件我可以说是感同身受了，在特别迷恋魔方的时期能够根据公式熟练地还原，后来慢慢的就忘了很多。这个感觉跟编程有点像，但又有区别，编程所遗忘的时间更短，遗忘的内容也能更多，除了不停地联系，我找不到更好的方法去巩固和提高编程能力了，在3.4.5中也有说到成长和代码量的关系，在csdn上有个博主是这样说的"当代码是在2,000行以下，你可以写任何混乱肮脏的代码并依靠你的记忆拯救你。深思熟虑的类和包分解会让你的代规模达到20,000行。突破这个瓶颈的关键是什么？对我而言，就是让事情保持简单。除非现在就非常需要，否则完全拒绝添加任何新特性或者新代码。真正的诀窍是知道什么需求增加了线性的复杂度（只和自身相关）和指数级复杂度（和别的需求有关联）。”所以我们不能之最求数量，代码的质量更加重要。
现阶段有各种各样的开发平台，各种各样的编辑器，而我们现阶段也是什么都有涉猎，其实是不是应该有所主攻，有所舍弃呢。
第四章 两人合作
这一章主要讲述了代码规范，极限编程，结对编程，两人合作的不同阶段，影响他人的技巧
从小我们就被教育要学会与同伴合作，当然，考试时除外。结对编程，一堆程序员肩并肩，平等地，互补地进行开发工作，虽说这样这样能够更快的完成项目要求，但绝对编程真的这么容易实现吗？David Green,TIM Group的软件工程师,说结对并不适合所有人。他在最近的博客 上分享了他的观点:
任何一个团队最终都是由不同性格的人混合在一起的。外向型的人更喜欢结对,然而内向型的人会更倾向性地认为这很难做到,并且他们尽量避免这种做法。这并不一定是教育或者说服的问题,相对来说也看不清其中的收益,甚至更多内向型开发人员可能会发现整个过程并不比独自工作更快乐。
Joe Barnes,ASCII字符的制作者,提到了剽窃是团队停止做结对的原因。
我相信我已经意识到了,扼杀我们团队合作的最大因素是结对。老是担心被剽窃就会间接这样的结果。
结对编程时如何更好地分配两个人的工作？如果项目已经要上交了，有一方因为能力或者时间问题没办法完成自己的那部分，这时候该如何解决？
第五章 团队和流程
这一章主要讲述了典型的软件团队模式和开发流程都有哪些，以及一些团队优缺点。
软件团队模式分为很多种，如主治医师模式、社区模式、爵士乐模式，官僚模式等等，它们各有优缺，应用于不同环境，不同类型的团队成员，比如主治医师模型适用于首席程序员极其优秀的情况等等。个人觉得在学生阶段比较好的还是交响乐团模式以及功能团队模式，因为这样大家都能一定的锻炼，并且比较适合实际情况。软件开发流程必不可少也极其众多，但是它们各有其适用的范围，比如“瀑布模型”适用于产品定义非常稳定，技术非常成熟等条件下，而RUP适用于大型软件团队开发大型项目。虽然有些流程存在很多问题，但是只要清楚定位，在不同环境下使用不同的开发流程，就可以降低成本，节省时间，节约人力物力，以最小的成本达到各户的期望。
在老菜鸟的笔记中看到技术团队的管理， 真正质变的大概是从超过25-30人起， 一个人可以直接充分管理的人大概就是4-5个为佳。但是这个管理人该怎样决定？如果大家都想去竞争管理人，在实际的项目开发中作为管理人的要求是责任心比较重要还是变成能力比较重要？
