阅读笔记
我在阅读书籍的时候，大部分都是浏览，也许是跟我看的书籍的内容有关系吧，但是，在浏览过《构建之法》这本书后，我精读了它，以下是我在阅读完1，2，16章后有的想法和问题，希望和大家一起分享和讨论。质疑和不断探索会帮助大家进步。
第一章 概论
引用
软件团队要从需求分析（Requirement Analysis）开始，把合适的需求梳理出来，然后逐步开展后续工作，如设计（软件架构）、实现（写数据结构和算法）、测试，到最后发布软件
——P3
问题一：需求易变，可否将需求分割成为细密的任务点？
好的软件，一定会有很好的用户体验，不同的用户对软件的功能和界面有不同的需求，而在开发过程中，有时会出现需求变化的情况，有些变化甚至可以将整个项目推倒重来。这样，我们在对需求的实现过程中，任务点分配或许可以帮助软件提高其本身的可维护性，对于软件的后续发展也有些许进益。
引用
什么是Bug呢？简单的说，软件的行为和用户的期望值不一样，就叫Bug，是否是Bug，取决于用户、开发者的不同角度。
——P16
问题二：当用户的期望值和软件的优化方向起冲突时，应当如何抉择？
业务方面与用户方面之间产生了冲突，如果我们将业务层面的需求简单考虑之后，我们再进行对用户方面的思考，这个时候，我们所面对的一些用户需求，有时候很容易和业务目标之间有会冲突，当我们围绕用户期望为中心去设计时，业务目标往往不能很好的达成，而实际上，正确的思维方式应该是，以业务目标为基准去推导用户的行为，当这个行为和用户目标相违背时，我们应该想办法把用户不喜欢做的事转化为和用户使用动机相关的事情，引导他完成。
根据我所查阅的资料显示：
从开发者的角度，解决方案围绕四个点进行：
1、 寻找业务和目标的关联
2、 确定相对平衡的方向
3、 提供多个设计方案
4、 最终方案呈现
第二章 个人技术和流程
引用
单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了
——P25
问题一：单元测试一定要作者自己写吗？
查阅了部分资料后，发现了开发人员和测试人员都可以写单元测试；对于一些测试人员供给不足的小公司，要求开发人员写单元测试，而对于一些大公司，常常设置有测试部门进行。开发人员对代码最熟悉，而且开发技能也强，开发自己写单元测试效率上和覆盖率上都比较高。而且单元测试有时候需要开发对代码进行部分重构才方便进行，开发自己做这些重构也比较顺手。但是开发人员可能会因为业务代码的繁重而顾不及单元测试的书写，如果只是写单测对软件的进益帮助不大。测试人员写测试有比较好的测试思想，可以更好地保证用例的覆盖。而且通过写单测测试能更好地了解具体代码结构、流程，对于后续的业务测试也有利。但是测试人员对代码没有开发人员熟悉。
具体怎么选择就是个问题。
第十六章 IT行业的创新
引用
迷思之一：灵光一闪现，伟大的创新就紧随其后
迷思之二：大家都喜欢创新
迷思之三：好的想法会赢
迷思之四：创新者都是一马当先
迷思之五：要成为领域的专家，才能创新
迷思之六：技术的创新是关键
迷思之七：成功的团队更能创新
迷思之八：创新者都是冒险家
——P340-P354
问题一：IT业创新究竟需要什么？
对于软件开发人员来说，创新是非常重要的。在这个需要创新的时代，无论什么行业都需要创新。但是在如今的时代，进行前无古人的创造难度很大，在某些情况下我们需要在前人的基础上进行一定的创新。
有时候，创新并不是能被所有人接受的，每个新事物的出现都需要一定的时间才能被人们接受。如果我们有好的想法，就要搞清楚我们能从这个想法中得到什么，现在自己具备的条件，以及与这个时代是否兼容。否则好的想法也不能付之实践。
创新者通常都会很成功，但是这些人一般不会是先行者。在IT行业中，系统项目或者其他软件是经过不断的创新开发才得以完善。大部分人会觉得自己不是这一领域的专家人才，而不愿意去尝试，但是蒂姆-伯纳斯李就实现了，他是物理学家，实现了HTTP协议通信。
创新并不是必须要一个非常优秀的团队才能完成的事情，如果一个软件开发团队有技术，有耐心，有团结心，有尝试的勇气，未来有无数种可能性，创新也有无限种来源，他们也可以成功。
