花了四天时间， 读完邹欣老师的《构建之法》这本书，个人觉得非常值得一读， 这本书主要介绍了软件测试、软件工程师的成长、编写代码的规范、团队合作开发软件的重要性、还有开发软件项目的总体流程、IT的发展创新等等，书中的内容丰富多彩，跟其他的软件工程书不一样，其他书往往写得千篇一律，太生硬呆板，而这本书的内容给读者一种欢快的阅读体会，能让人更加的快速去接受里面的内容，并吸收为自己所用；并且里面的内容都举例生活中的例子，使人看上去更加的了解其实软件工程就在我们的身边。
通过构建之法这本书使我对软件的构建很清晰的了解，让我对软件设计更加有了清晰的认识，增加了我对软件的认识的兴趣,这本书第一张讲概论：软件等于程序加文档，软件工程是什么，第二章讲 个人技术和流程 单元测试，效能分析工具，个人开发流程，第三章讲软件工程师的成长 个人能力的衡量与发展，软件工程师的职业发展，技能的反面 第四章讲 俩人合作（其中感触最深就是结对编程，很有意思） 代码的规范，代码的风格规范，代码设计规范，代码复审，结对编程，俩人合作的不同阶段和技巧 第五章讲团队和流程 非团队和团队，软件团队的模式，开发流程 第六章讲敏捷开发 敏捷的流程简介，敏捷流程问题和解法，敏捷的团队，敏捷的总结，敏捷的问答 第七章讲MSF MSF简史，MSF基本原则，MSF团队模型，MSf过程模型，MSF对敏捷和CMMI的支持 第八章讲 需求分析 软件需求，软件产品利益相关者，获取用户需求——用户调研，竞争需求分析的框架，功能的定位和优先级别，计划和估计，分而治之 第九章讲项目经理 PM是啥，微软PM的来历,PM做开发和测试之外的所有事情，PM和风险管理，PM的能力要求的任务，第十章 典型用户和场景 典型用户和典型场景，用例，规格说明书，功能驱动的设计，第十一章 软件设计与实现 分析和设计方法，图形建模和分析方法，其他设计，从sPec到实现，开发阶段的日常管理，第十二章 用户体验 ，用户体验的要素，用户体验设计的步奏和目标，评价标准 第十三章 软件测试 基本名词解释及分类，各种测试方法，实战中的测试，运用测试工具，第十四章 质量保障，软件的质量，软件的质量保障工作，第四五章 稳定发布阶段 ，从代码完成到发布，不同频率和不同覆盖范围的渐进发布，发布之后——事后诸葛亮会议 第十六章讲 IT行业的创新 创新的迷思，创新的时机，创新的招数，魔方的创新，创新和作坊，第十七章 人，绩效和职业道德 猪，鸡和鹦鹉的故事，其实还是人的问题，绩效管理，萝卜与白菜，团队合作的几个阶段，软件工程师的职业道德。
读完这本书，心中还是有不少疑惑的，下面就是最想知道的五个问题：
问题一：第一个问题是我看完本书第2章所产生的。按照书上对于一个软件工程师的评价标准来说我们这个团队里大部分都不是合格的软件工程师，因为我们个人技术都没有很好的储备，那么有什么比较有效的方法来提升我们的能力？
问题二：第六章提到了敏捷流程，看了很多的方法有点蒙，粗略的以为又一些明确的任务目标分块的用敏捷开发比较适合，而一些只有大致方向的用传统的瀑布式的比较好，但我我想知道当一个项目的开发从开始用传统的瀑布式的开发后有了明确的目标分块，这时还可以转换为敏捷开发吗？
问题三: 在团队开发软件时如何能保障单元测试能够较为全面的进行下去？如何测试才算为全面周密的单元测试？
问题四：书中提到“在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的一位”。我的问题是：是否要在结对成员选择上，刻意区分出"一强”和“一弱”进行结对呢？
问题五：第五个问题是看完第16章产生的。我们现在真比较困难去想出一些创新，因为科技太发达，很多软件都已经被他人开发出，所以有什么方法能够帮助我们去创新吗？
标签：流程,构建,MSF,敏捷,软件,团队,PM 来源： https://www.cnblogs.com/Zbj-Public/p/16201567.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。