关键词：
阅读了《构建之法》第一章中软件工程的概论，我学习到了“软件=程序+软件工程”这个黄金公式，并且对软件工程充满了兴趣和信心。但是，一个好的软件工程开发团队需要首先确保团队里的每个成员是合格的工程师，为此我们得先普及一些基本概念和技术，即单元测试、回归测试和效能分析工具。书的第二章讲述了个人技术和流程，给我们着重介绍了PSP（个人软件开发流程）。
绝大部分软件都是由多人合作完成的，大家的工作相互有依赖关系。怎么才算一个好的单元测试？单元测试应该准确、快速地保证基本模块的正确性：1.单元测试应该在最基本的功能/参数上验证程序的正确性；2.单元测试必须由最熟悉代码的人来写；3.单元测试之后，机器状态保持不变；4.单元测试要快；5.单元测试应该产生可重复、一致的结果；6.独立性；7.单元测试应该覆盖所有代码路径；8.单元测试应该集成到自动测试的框架中；9.单元测试必须和产品代码一起来保存和维护。针对一个Bug Fix，我们也要做Regression Tset，目的是：1.验证新的代码的确改正了缺陷；2.同时要验证新的代码有没有破坏模块的现有功能，有没有Regression。所以对于“回归测试”中的”回归”，我们可以理解为“回归到以前不正常的状态”。我们需要经过充分分析之后才能进行优化，否则也许可能就会事倍功半。卡内基梅隆大学的能力成熟度模型，是用来衡量一个团队能力的一套模型，CMU的专家们针对软件工程师也有一套模型，叫Personal Software Process（PSP）。
软件工程需要我们自己去创新实践，多加练习来锻炼自己的编程基本功，实践一些最简单的项目例如wc。正如谚语所说：不能一口吃成个胖子。罗马不是一天建成的。同样，一个功能完整的程序也不是一蹴而就的，我们要把大人物划分为可操作的小任务，排序任务的次序。在设计程序的时候，我们要保证程序的质量，那如何保证呢？是回归测试。
编程可以是一门理论，也可以是一门工程，还可以是一门手艺，我们要学好编程。 读了《构建执法》这本书使我受益匪浅，收获颇深，对现代软件工程有了更深一步的了解。
构建之法现代软件工程（第二次）
... 构建之法现代软件工程（第二次）单元测试是什么？ 单元测试是为了让各个模块的质量能得到稳定的，量化的保证的一种有效解决方案。（VSTS） 好的单元测试的... 查看详情
《构建之法》第二次
第二章讲的是个人技术和流程。绝大多数软件是由多人合作完成的。单元测试能够让自己负责的模块功能定义更加明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证。 创建一... 查看详情
《构建之法》小组第二次
这周我们小组阅读了《构建之法》的第二章和第三章，讨论了关于软件工程师的个人能力问题。我们一致认为，团队的团结很重要，但每个人的个人能力也是需要的，好的团队是由好的个人组成，明确的分工以及卓越的个人能力... 查看详情
构建之法第二次作业
a:测试需要确定计算器的每个按钮功能正确，没bug； 多次计算结果正确；尤其要关注特殊情况，除以“0”......；分析代码覆盖率。 b:1 2遇到的最大的问题是小数点的运算。解决方案：不会不会。 ... 查看详情
《构建之法》第二次读书笔记
1551428黄维单元测试：创建单元测试的主要步骤是：1.设置数据2：使用被测试类型的功能3：比较实际结果和预期的结果验证单元测试好坏的标准：1.单元测试应该在最基本的功能/参数上验证程序的正确性2、单元测试必须由最熟悉... 查看详情
《构建之法》第一次随笔
...间的学习，逐步对软件工程有了新的理解与认识。读了《构建之法-现代软件工程》（邹欣 著 第二版）这本书，感觉学习到了很多有用的知识和以前不理解的方面。书中一开始给出了一个定式“软件=程序+软件工程”，几... 查看详情
《构建之法》第四次随笔
《构建之法》第四次随笔这半个月我阅读了《构建之法》第六章，第七章，第八章。 第六章主要讲的是敏捷流程。敏捷流程是一系列价值观和方法论的集合。敏捷对团队的要求很简单：自主管理，自我组织，多功能型。但是... 查看详情
随笔之读《构建之法》（作业一）
自从拜读了邹欣老师的力作《构建之法》后，感触颇深。从书中不难看出邹老师是一个才华横溢、卓尔不群的人。《构建之法》言辞精辟，引人入胜。虽然只是浅读了《构建之法》的部分章节，但是对其中的一些内容我也有... 查看详情
《构建之法》随笔一
...巧和方法还是比较陌生。所以，在这个周末，我学习了《构建之法》的第一章。一开始我以为是很枯燥的教科书类的题材，只有系统的代码教学之类的内容，但是翻了几页后，竟然出乎我的意料，编者的语言相当幽默有趣，引人... 查看详情
《构建之法》第七次随笔
典型的软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色也很重要，我们叫他们项目经理——PM。 PM的M就是Manger，但是P就有这几种：ProductManager、ProjectManager/ProgramManager,在不同的行业和公司，... 查看详情
《构建之法》第四次随笔
从《构建之法》前两章的阅读学习中，我了解到了软件工程的概论，知道了“软件=程序+软件工程”，明白了个人技术和流程。阅读了第四章之后，我了解到了软件工程中的“两人合作”。 现代软件产业经过几十年... 查看详情
《构建之法》第七次随笔
这周，我学习了《构建之法》第十四十五章。第十四章主要讲的是软件的质量。软件质量等于程序质量加软件工程质量。程序的质量体现在软件外在功能的质量。衡量软件的功能，基本的判断可以用是、否来判定。软件的开发过... 查看详情
《构建之法》第三次随笔
从《构建之法》前两章的阅读学习中，我了解到了软件工程的概论，知道了“软件=程序+软件工程”，明白了个人技术和流程。阅读了第三章之后，我体会到了软件工程师的成长。 软件工程包括了开发、运营、维护软件... 查看详情
构建之法阅读随笔一
《构建之法》一书已完成了第一遍的阅读，接下来，我将随机抽取其中的一段进行精读。移山公司的项目进行了一段时间，TFS上也积累了不少数据。大栓做了“数据挖掘”，整理出来一些统计信息，向各位领导汇报。大牛：哇！... 查看详情
构建之法随笔
软件需求分析在软件开发过程中十分重要，过去人们一直认为需求分析是整个软件工程中的一个简单的步骤，“软件危机”爆发之后，人们才逐渐认识到需求分析是软件开发过程中最关键的一个工程。由此可见需求分析的重... 查看详情
构建之法第六次随笔
我这个礼拜阅读了构建之法第12,13章。其中，第十二章讲的是用户体验，我们要考虑用户体验的不同角度，用户的第一印象就很重要，用户第一次使用软件，就很大程度上决定了用户对软件的评价。软件服务始终都要记住用户的... 查看详情
《构建之法》第五次随笔
MSF，即微软解决方案框架，也就是微软推荐的软件开发方法，大约在1993年，微软在总结了自己产品团队的开发经验和教训，以及微软咨询服务部门的业务经验后推出的。MSF基本的原则：1.推动信息共享与沟通；2.为共同的远... 查看详情
构建之法阅读随笔二
谁不喜欢创新呢？然而细细想来，创新就是做和以前不一样的事，并不是所有的人都喜欢“不一样”。当你提出一个创新的想法时，你会得到什么回答呢？为什么我辛辛苦苦想出来的点子得不到领导或同事的赞赏？这里面有好几... 查看详情