《构建之法》读后感

《构建之法》是由亚洲研究院首席研发经理邹欣基于在微软20余年的开发经验和高校教育实践的6年经验，针对传统软件工程课程理论脱离实践的问题所著的兼具学科科普和专业解答意义的一本书。
本书在解释了软件工程的内核及特质后，首先对软件工程师的个人行为与发展做出了深刻分析。对于。如我一样尚未接触软件开发真实过程的同学，这部分内容可谓拨云见日，让我们对软件开发有了最初的认识。用于验证代码正确及稳定性的单元测试，验证代码是否因修改而出现误差的回归测试，寻找代码优化之处的效能分析工具，陌生的名词，通过作者的分析，变得易于理解。接着作者又向我们介绍起个人工程师的思维方式，如何衡量自己的的水平，如何衡量软件开发的工作量与质量，在这里都被作者揭晓。还有软件工程师容易产生的思维误区，过于追求细节而产生的分析麻痹，极端的积极导致无法分清主次，因为钻牛角尖造成的过早优化，因为贪心所造成的过早扩大化，在这里由作者向我们提前提出警示，指出根源所在。接着作者又向我们介绍了软件工程师的职业发展，由临时工作到追求理想的多层次工作生态，从全国考试到私企认证的水平分级，无不告诉我们软件工程是需要投入相当精力的专业。最后作者借用魔方的例子告诉我们一定要结合自身的实力进行学习，避免进入恐慌区和舒适区而错失学习的机会。
然后本书开始强调在前面部分就一直在强调的多人协作的重要性。从两人到多人，虽未明说说，但可以看出，真正的软件开发并非零星几个人就可以随意完成的。主治医师，明星，社区，多样的团结运行模式，昭示着多少前人在软件领域的辛勤探索，无论如何他们的共同点就是人各司其职，尽其所能，就像程序里的函数一样，只做一件事，并且要做好。然后读作者又向我们介绍了团队开发软件的具体流程，先是环环相扣的瀑布模型，再试线性展现的RUP，或许这些只是实际开发过程中的冰山一角，来说无疑是打开了新世界的大门。可以感受到，如果说没有团结合作的一窝蜂模式是搓橡皮泥，那么有团队合作的代码开发过程就是搭积木，每个人都有独立的一块儿，但又可以放在一起合作，甚至开发过程本身就是更大架构中的一块儿积木。相互独立又相互联系，我想这大概就是团队开发最重要的核心。
然后作者又带着我们开始了对软件工程市场环境，工作流程更深入的发掘。比如从21世纪初开始倡导的“敏捷”团队风格，其自管理性、自组织性、多功能性至今受到追捧。MSF，微软解决方案框架，这方面的介绍让我们更加接近了解软件工程在商业领域的行事风格，MSF的基本原则大概可以概括为信任、互通、责任、广视、远视、真诚，这些基本原则是微软项目开发的基底，也伴随着一个项目的整个生命周期。对于需求的分析，让我们的视角跳出团队转向用户，思考怎样从用户那里找到开发的思路，也就是如何安排杀手功能和外围功能，或者必要需求和辅助需求，不仅考验团队的用户审查能力，也考验着领队的假设估计能力。PM，典型用户与场景，用户体验，IT行业的创新，领导人，这部分更深入地向我们展现了软件企业是如何在市场中竞争，又如何生存下来的，软件团队始终是在以适合自己的风格开发，但是成果始终是要面向大众的，也就是为什么说“软件服务始终都要记得用户的选择”。软件设计与实现、软件测试、质量保障、稳定和发布阶段，这些章节。最后更深切的向我剖析了软件开发的过程，如此重复，只紧扣几个核心：设计，开发，检测，实验，修正，交付。闭门造车，宽严皆误，打破bug地狱，各种测试，大扫荡，项目会诊，设计变更，Zbb，砍掉已完成功能，最后回归测试…从繁琐复杂流程中我看到的是对任务的严谨态度，面对客户的真诚态度，面对大众的责任态度。我没有参加过甚至没有见过软件开发的过程，但我仍能从这串文字中感受到团队万众一心时的那股拼劲儿，并且期待着我能真正体验一回。
《构建之法》不仅向我们展现了软件开发工程的环境、流程，还向我们展现了作为一个人，我们将在软件开发过程中，需要做什么，思考什么，面对什么，呈现什么，作为团队一员的我们需要分担什么，理解什么，做什么。