读书笔记
文章平均质量分 93
该昵称已经被占用
这个作者很懒,什么都没留下…
展开
-
《构建之法》第十六章 IT行业的创新
创新的迷思最近几年,我们整个社会似乎对创新很感兴趣,媒体上充斥了创新型的人才、创新型的学校、创新型的公司、创新型的城市、创新型的社会,等等名词。有些城市还把“创新”当作城市的精神之一,还有城市要批量生产上千名顶级创新人才。IT行业也充斥了很多创新的新闻和掌故。这一章我们好好讲一讲IT行业的创新。对于创新,有一些似是而非的观点和传说(Myth,迷思)迷思之一:灵光一闪现,伟大的创新就紧跟原创 2015-10-01 23:00:51 · 2411 阅读 · 0 评论 -
《构建之法》第一章 概论
摘至 邹欣《构建之法》一书,以作学习之用1. 大马哈鱼洄游模型软件工程按照经典的瀑布模型 1. 需求分析 2. 设计阶段 3. 实现阶段 4. 稳定阶段 5. 发布阶段 6. 维护阶段事实上在现实世界中,软件工程师的职业发展与瀑布流程刚好相反毕业进入公司(或者实习生),开始学习并维护一些已有的软件(维护阶段),主要由自己的师傅(Mentor)带领能够在项目中改原创 2015-10-01 23:09:02 · 4870 阅读 · 0 评论 -
《构建之法》第二章 个人技术和流程
概述一个团队需要一定的流程来管理开发活动,每个工程师在软件生命周期所做的工作也应该有一个流程,这一章会介绍PSP(Personal Software Pro-cess,个人软件开发流程)单元测试单元测试的作用:让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的、量化的保证用VSTS写单元测试例子:许多应用程序中都会用到“用户”这原创 2015-10-01 23:07:11 · 2115 阅读 · 0 评论 -
《构建之法》第三章 软件工程师的成长
个人能力的衡量与发展软件团队和团队中的工程师也是这样。软件系统的绝大部分模块都是由个人开发或维护的。在软件工程的术语中,我们把这些单个的成员叫做Individ-ual Contributor(IC)。IC在团队中的流程是怎么样的呢?以开发人员为例,流程如下。通过交流、实验、快速原型等方法,理解问题、需求或任务提出多种解决办法并估计工作量其中包括寻找以前的解决方案,因为很多工作是重复性原创 2015-10-01 23:06:38 · 1472 阅读 · 0 评论 -
《构建之法》第四章 两人合作
1. 代码规范每个人对于什么是“好”的代码规范未必认同,这时我们很有必要给出一个基准线—什么是好的代码规范和设计规范计算机只关心编译生成的机器码,你的程序采用哪种缩进风格,变量名有无统一的规范等,与机器码的执行无关。但是,做一个有商业价值的项目,或者在团队里工作,代码规范相当重要。“代码规范”可以分成两个部分:1. 代码风格规范——主要是文字上的规定,看似表面文章,实际上非常重要2原创 2015-10-01 23:06:14 · 1496 阅读 · 0 评论 -
《构建之法》第五章 团队和流程
写了再改模式(Code-and-Fix)史蒂夫·迈克康奈尔(Steve McConnell)在这里提到了不少开发流程。第一个提到的开发流程——Code-and-Fix这个流程也有好处,不需要太多其他准备或相关知识,大家上来就写代码,也许就能写出来,写不出来就改,也许能改好。当面临下面的任务时,也许这个方法是有用的。只用一次”的程序看过了就扔”的原型一些不实用的演示程序但原创 2015-10-01 23:05:58 · 2461 阅读 · 0 评论 -
《构建之法》第六章 敏捷流程
摘至 邹欣《构建之法》一书,以作学习之用敏捷的流程在软件工程的语境里,“敏捷流程”是一系列价值观和方法论的集合 现有的做法 敏捷的做法 流程和工具 个人和交流 完备的文档 可用的软件 为合同谈判 与客户合作 执行原定计划 响应变化敏捷开发原则尽早并持续地交付有价值的软件以满足顾客需求敏捷流程欢迎需求的原创 2015-10-01 23:05:38 · 2299 阅读 · 0 评论 -
《构建之法》第七章 MSF
MSF 简史微软公司中关于软件开发的思想和宣言有一个方法论——微软解决方案框架(Microsoft Solution Framework,MSF),也就是微软推荐的软件开发方法大约在1993年,微软在总结了自己产品团队的开发经验和教训,以及微软咨询服务部门的业务经验后,推出了MSF。当时的MSF只是这些经验和教训的初步总结。在以后的几年中,MSF进一步吸收了微软各个部门和微软的合作伙伴在实原创 2015-10-01 23:05:19 · 2001 阅读 · 0 评论 -
《构建之法》第八章 需求分析
软件需求人们为了解决现实社会和生活中的各种问题,要求助于软件。人们的需求五花八门,那么软件团队如何才能准确而全面地找到这些需求呢?需求分析方法一1.获取和引导需求软件团队需要找到 软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求。不同的项目需要不同的手段,这一步骤也被叫做“需求捕捉”,形容真正的需求稍纵即逝,需要靠火眼金睛和敏捷的身手来发现并抓住它们原创 2015-10-01 23:04:59 · 4342 阅读 · 0 评论 -
《构建之法》第九章 项目经理
PM 是啥软件团队里除了能写代码、测试代码和画图做设计的成员,还有一类角色,不做上面这些事情但也很重要,我们叫他们项目经理——PMPM的M就是Manager,但是P有这几种:Prod-uct Manager、Project Manager、Program Man-ager,在不同的行业和公司,他们的作用各不相同。接下来介绍的是项目经理——ProgramManagerProduct M原创 2015-10-01 23:04:34 · 1005 阅读 · 0 评论 -
《构建之法》第十章 典型用户和场景
典型用户和典型场景开发一个软件时,我们都知道要为用户考虑,但是用户在哪里?由此可见,光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机!不能光根据用户的语言就匆忙做决定Visual Studio的典型用户微软在Visual Studio2005设计阶段使用的几个典型用户(Persona)典型用户的价值所谓“Persona”,就是典型原创 2015-10-01 23:04:08 · 2553 阅读 · 0 评论 -
《构建之法》第十一章 软件设计与实现
分析和设计方法我们写软件就是要解决用户的需求,我们需要表达和传递下面这些信息:在“需求分析”阶段,我们要搞清楚 在问题领域中的现实世界里,都有哪些实体,如何抽象出我们真正关心的属性,实体之间的关系是什么,在这个基础上,用户的需求是什么,软件如何解决用户的需求在“设计与实现阶段”,我们要搞清楚软件是怎么解决这些需求的?在“测试”和“发布”阶段,我们要搞清楚软件真的解决了这些需求了么原创 2015-10-01 23:03:23 · 1911 阅读 · 0 评论 -
《构建之法》第十二章 用户体验
概述其实,计算机软件的用户界面(User Interface,UI)和用户体验(User eX-perience,UX)是一个有着丰富内容的学术领域,软件工程师们在长期工作中也积累了很多相关的经验无论软件还是硬件,都有很多功能部件,各个部件还要有机地结合起来,才能满足用户的需求。在用户体验领域中,一个著名的用户体验的例子是茶壶茶壶有什么功能部件呢?茶壶盖,茶壶体,茶壶把,茶壶嘴下面的茶原创 2015-10-01 23:03:02 · 1637 阅读 · 0 评论 -
《构建之法》第十三章 软件测试
基本名词解释及分类团队统一思想要从基本名词解释开始。Bug:软件的缺陷Test Case:测试用例,测试用例描述了一个完整的测试过程,包括测试环境、输入、期望的结果等Test Suite:测试用例集,即一组相关的测试用例Bug可以分解为:症状(Symptom)、程序错误(Fault)、根本原因(Root Cause)。症状:即从用户的角度看,软件出了什么问题 例如,输入原创 2015-10-01 23:02:34 · 2508 阅读 · 0 评论 -
《构建之法》第十四章 质量保证
软件的质量从浪漫的角度看软件开发,人们不禁想象软件团队一开始就理解了用户的需求,完美的分析文档如高屋建瓴般流出,软件工程师在此基础上开发了各种完美的功能,按时交付给用户;用户一用就觉得特别符合自己的需求,皆大欢喜!然而所有的软件都没有这么浪漫。读者可以问一下周围的亲朋好友,大家使用的软件质量如何?相信回答绝不是“浪漫”。什么是软件的质量(Software Quality)?这个词应用非常广原创 2015-10-01 23:02:13 · 1415 阅读 · 0 评论 -
《构建之法》第十五章 稳定和发布阶段
从代码完成到发布一个团队经历了计划/设计/开发等阶段,达成代码完成(Code Complete)这一目标,似乎后面的事情就水到渠成了。其实不然,软件生命周期的最后阶段往往是最考验团队的,不但考验团队项目管理水平、应变能力,也考验团队的“血型”。原计划的软件发布时间快到了,但是软件还是有各种问题,怎么办?软件团队的血型优秀的软件团队会发布有已知缺陷的软件么?在我看来,与人类的血型类似原创 2015-10-01 23:01:33 · 1504 阅读 · 0 评论 -
读书笔记——总体架构目录
引用块内容IT 项目管理《构建之法》—— 邹欣 HadoopMahoutSparkScala原创 2015-10-12 10:20:47 · 628 阅读 · 0 评论