《构建之法》13,14,15,16,17章读后感

13章:效能测试 不一样的机器运行软件效率是不一样的,怎么能做到效能测试的权威性 14章:软件质量保障 这是一个很重要的问题,国外公司很注重维护,中国公司也注重更新维护吗? 15章:稳定和发布阶段 软件发布后,逐步冻结为什么要从人机界面开始冻结 16章 IT行业的创新 创新者都是一马当先,为什么美国易贝网站最先在互联网世界提出用户对用户交易平台,然而在中国却基本听不懂易贝交易平台 17章 读一个程序猿的生命周期 这让我懂得人生不管干什么方向很重要,更重要的是要手上有实力

1 题目描述 输入一个矩阵,按照从外向里以顺时针的顺序依次打印出每一个数字,例如,如果输入如下4 X 4矩阵: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 则依次打印出数字1,2,3,4,8,12,16,15,14,13,9,5,6,7,11,10. 2 思路和方法 直接定义一个矩形,在矩形的四条边取值,程序大大简化. 3 核心代码 1 class Solution { 2 public: 3 vector<int> printMatrix(vector<

读<构建之法>第4,17章有感 第四章:两人合作 原文:另外,注释(包括所有的源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 我的问题和看法:对于英语水平没有那么高的人来说,不允许中文注释真的太难了.刚开始学习代码的时候,老师就教导我们编程的时候一定要写注释,但是并没有非常严格的要求我们必须要用ASCII字符.我上网查找了一些资料,发现大部分公司对于注释并没有明确的要求.注释是为了方便让别人理解你的代码的,所以简洁易懂应该才是最重要的,在水平达到的情

    诗云:半亩方塘一鉴开,天光云影共徘徊.问渠哪得清如许?为有源头活水来. 这是宋代理学大家朱熹对阅读一本好书的感受.这几天我看了邹欣老师写的<构建之法>第4.17章之后,产生了一点点类似的感受.下面我来点评一下. 关于"第4章 两人合作"的点评: 问题一: 原文(见第68页):另外,注释(包括所有源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 个人见解:可移植性是指代码在不同平台能否执行.注释会被执行吗?不会.那么,注释就与

<构建之法>第六第七章读后感 阅读<构建之法>第6~7章,并参考以下链接,发布读后感.提出问题.并简要说明你对Scrum的理解. 学习附录: Scrum中文网--什么是Scrum?  http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1 Scrum认证体系 http://www.scrumcn.com/agile/scrumtraining/scrum-certification-progr

阅读教材<构建之法>第1.2.3章之后,满满的对话,生动形象.其中第一章写到软件=程序+软件工程,程序=数据结构+算法,这也反馈出我们要学好数据结构以及算法.软件工程这方面的内容.我们要做出"足够好”的软件,并且不要忽视软件的每一个小部分,因为软件的每一部分都有可能成为关键的致命部分,犹如飞机或小车的安全带.我们做出的软件要符合客户的要求,软件分析需求分析至关重要,要花费很长的时间和精力.而且,软件维护是一个漫长的历程.在个人软件开发过程中,单元测试.回归测试以及效能分析虽然花费大量

 概论: 敏捷开发以用户的需求进化为核心,采用迭代.循序渐进的方法进行软件开发.在敏捷开发中, 软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视.可集成和 可运行使用的特征.换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目, 并分别完成,在此过程中软件一直处于可使用状态. 遵循原则: 我们最优先要做的是通过尽早的.持续的交付有价值的软件来使客户满意. 即使到了开发的后期,也欢迎改变需求.敏捷过程利用变化来为客户创造竞争优势. 经常性地交付可以工作的软件,

第一章读后感: 看了大概了解软件从一个想法到最终成品的一个过程.软件先是由一个想法引出的,有那个想法,你需要一个工具去做什么,然后根据自己想要的功能大概做一个能实现基本功能的软件,再对客户提出的要求进行完善,实现了功能后对软件进行维护.还有做的软件要符合客户的要求,而不是只根据自己的想法去做,要满足大部分的需要,满足客户的需求,在使用过程中发现有bug对其进行修复. 软件工程在社会发展处于什么地位,发展潜力在未来究竟有多大? 第二章读后感: 看完第二章后知道软件是需要单元测试的,之前对这个没什么

1.成功的变革不是完全自上而下或者自下而上,而是通过结合两者的变革相关要素. 2.如果我们不能预见到Scrum转型的结束状态,便无法确定当前状况和结束状态之间所有的差距. 3.变革与过去培训的内容往往产生冲突,软件开发人员很难在短时间适应这种变化,导致转型的失败. 4.人进行改变的能力是有限的,因此企业进行改变的能力也是有限的-———要求人们在同一时间内做太多改变,他们是无法承受的,毁坏性的压力和未来的冲击产生的迷惑会随之而来.加之,当代技术革新的速度之快,人们无法快速跟上,导致人们工作和交互方