现代软件工程 练习与讨论 第二章 个人技术

第二章:是懒人造就了方法 引用典故李冰烧山的故事,同是战国时期,愚公就要“碎石击壤”,而李冰就已经懂得“积薪烧之”了,为什么说懒人造就了方法呢,假如李冰也像愚公一样没日没夜的督促他的团队凿石开山,那么他肯定没有时间来学习.寻找或者观察,当然也不会发现“烧”这种方法可以加快工程进度,使得一大座山短时间就被哗啦哗啦地给“碎”掉了. 李冰的团队成百上千,若只为吃喝拉撒,那必然会寝食难安,因为工程太过巨大.相反,他应是个闲人,可以闲到去观察火能否把石头烧爆.在如此大的工程中,如果会闲到去看石头,那他一定

如果说第一章我还有点概念,那么第二章我可以说一窍不通,什么是VSTS,什么是单元测试,什么是回归测试,还是什么是效能分析--好多的新名称,第一次看见,是那么的没有头绪.要不是百度了,仅仅看书,我完全不知VSTS--Visual Studio Team System,是由微软开发的一套具有高生产力.高集成性.可扩展的生命周期开发工具. 2.1.1节图文并茂的告诉我,单元测试重要作用,可能是自己的能力不足,相关知识了解的太少了,一边看还一边想,单元测试怎么写?写在哪里?什么时候写?就算是按照书本上的

在第二章的学习之中,了解到第二章主要讲:单元测试,回归测试,效能分析,个人软件开发流程(PSP) 1.单元测试 软件是由多人合作完成的,不同的工作有相互依赖的关系.单元测试应该准确,快速地保证程序基本模块的正确性. 单元测试好坏的标准如下: 1.单元测试应该在最低功能/参数上验证程序的正确性.        2.单元测试必须由最熟悉代码的人(程序的作者)来写        3.单元测试后,机器状态保持不变        4.单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟)       

1. #include<cstdio> #include<cstdlib> #include<cstring> #include<ctime> using namespace std; int main() { int a,b,c; a = rand() % 1000; b = rand() % 1000; c = rand() % 4; if (c==0) { printf("%d+%d=?\n",a,b); } else if (c=

9.5.1故事: 从PM的无意中观察所得到打印预览功能的实现,证明了一个好的PM不止要自己去开发出来一些功能,更重要的是看到一个功能的潜在的价值,从而来把它进行推广.功能本天成,妙手偶得之,邹欣老师引用的这句话正是恰到好处,生动的解释了这个例子. 从乔布斯说服聪明的同事的故事中可以得出一个道理,一个出色的PM不一定在技术上比同事更优秀,但一定要让同事信服,手段就可以是通过生活中经验故事,来有效诚恳的达到目的. 9.5.2  我是做PM 的料吗? 在校学生如何为成为PM做准备 个人认为,不想当PM

世界由形形色色的人构成,勤奋的,懒惰的…… 我们也大可不必带任何有色眼镜看待这好像站在对立阵营的两类人.事实上对这个世界,谁都有谁的贡献. 当然我这里说的懒惰并不是无所事事,碌碌无为. 愚公马不停蹄叩石垦壤,当然兢兢业业勤奋非常. 很多时候,我们把人生的大部分时间都用在重复一个动作上,却不敢花费一点时间停下来思考. 但有时候,这种勤奋反而是一种荒芜,因为除了那个重复的动作,我们很可能一无所获. 就愚公移山事件而言,故事的开头自然很好,善心非常,恒心非常.愚公的决心我们似乎不用再考究了,他一定是要

本章作WebRTC的技术介绍,主要讲以下的概念: .  如何建立P2P的通信 .  有效的信令选项 .  关键API的关系 2.1 设置通信 尽管WebRTC通信的基础是P2P的, 但设置这个通信的初始步骤是要求一些协作的. 这些动作通常由Web服务器和/或信令服务器提供. 这个协作可以允许两个或多个WebRTC设备或端找到彼此,交换通信的细节, 协商定义了他们如何通信的会话, 最后建立它们之间的直播P2P媒体流. 2.2 一般流程 应用场景其实是很多的,从简单的页面DEMO到多方会议. 这里只

这一章重点介绍的是以前了解过但未曾注重过的单元测试&回归测试:个人技术素养是团队协作的基础. 1.VSTS单元测试 源代码 public Class User() { public User(string userEmail) { memail = userEmail; } private string memail;//private变量拒绝外部类访问(除非用get/set方法) } 测试代码1 public void ConstructorTest() { string userEmail

2.1 单元测试 大部分软件是由多人合作完成,不同工作人员相互有依赖关系.例如,一个人负责的模块功能被别人调用.软件的很多错误都来源于程序员对模块功能的误解.疏忽或不了解模块的变化.怎样能让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的.量化的保证?单元测试是一个很有效的解决方法. 好的单元测试标准:a.单元测试应该在最基本的功能/参数上验证程序的正确性. b.单元测试必须由最熟悉代码的人(程序的作者)来写.  c.单元测试过后,机器状态保持不变.