内容简介 · · · · · ·
软件工程牵涉的范围很广, 同时也是一般院校的同学反映比较空洞乏味的课程。 但是,软件工程 的技术对于投身 IT 产业的学生来说是非常重要的。作者有在世界一流软件企业 20 年的一线软件开 发经验,他在数所高校进行了多年的软件工程教学实践,总结出了在 16 周的时间内让同学们通过 “做 中学 (Learning By Doing)” 掌握实用的软件工程技术的教学计划,并得到高校师生的积极反馈。在此 基础上,作者对软件工程的各个知识点和实战技能要求进行了系统性整理,形成教材。目前,本书已经在至少 25 所高校作为软件工程课程的教材。
本书共分 17 章, 对照美国 ACM/IEEE 2013 年出版的计算机科学教学指导中软件工程相关部分, 本书覆盖了其中大多数的核心内容。本书同时覆盖了最新的业界实战方法,软件团队中各个角色的成 长和关系,以及 IT 行业...
软件工程牵涉的范围很广, 同时也是一般院校的同学反映比较空洞乏味的课程。 但是,软件工程 的技术对于投身 IT 产业的学生来说是非常重要的。作者有在世界一流软件企业 20 年的一线软件开 发经验,他在数所高校进行了多年的软件工程教学实践,总结出了在 16 周的时间内让同学们通过 “做 中学 (Learning By Doing)” 掌握实用的软件工程技术的教学计划,并得到高校师生的积极反馈。在此 基础上,作者对软件工程的各个知识点和实战技能要求进行了系统性整理,形成教材。目前,本书已经在至少 25 所高校作为软件工程课程的教材。
本书共分 17 章, 对照美国 ACM/IEEE 2013 年出版的计算机科学教学指导中软件工程相关部分, 本书覆盖了其中大多数的核心内容。本书同时覆盖了最新的业界实战方法,软件团队中各个角色的成 长和关系,以及 IT 行业的创新奥秘。作者可以向感兴趣的读者提供全部章节的教学课件。
作者简介 · · · · · ·
邹欣现任微软Windows中国工程团队首席研发总监。1996—2003年,邹欣在微软Outlook团队从事开发工作,2003—2005年,他在微软内部质量工具团队和Visual Studio团队负责软件项目管理工具的开发。2005—2012年,他担任微软亚洲研究院技术创 新组研发主管,负责研究成果的产品化和创新项目。2012—2014年,他担任微软亚洲互联网工程院首席研发总监,负责必应搜索客户端、必应输入法、必应词典等产品。加入微软前,邹欣从事过商用Unix系统、GPS/GIS软件开发及测试工作。他在2007年出版了《移山之道》,于2008年出版了《编程之美》 (合作)。他于1991年获北京大学计算机软件专业学士学位。1996年获美国美国韦恩州立大学(Wayne State University)计算机软件专业硕士学位。
微博 http://weib...
邹欣现任微软Windows中国工程团队首席研发总监。1996—2003年,邹欣在微软Outlook团队从事开发工作,2003—2005年,他在微软内部质量工具团队和Visual Studio团队负责软件项目管理工具的开发。2005—2012年,他担任微软亚洲研究院技术创 新组研发主管,负责研究成果的产品化和创新项目。2012—2014年,他担任微软亚洲互联网工程院首席研发总监,负责必应搜索客户端、必应输入法、必应词典等产品。加入微软前,邹欣从事过商用Unix系统、GPS/GIS软件开发及测试工作。他在2007年出版了《移山之道》,于2008年出版了《编程之美》 (合作)。他于1991年获北京大学计算机软件专业学士学位。1996年获美国美国韦恩州立大学(Wayne State University)计算机软件专业硕士学位。
微博 http://weibo.com/sdxinz
博客 http://www.cnblogs.com/xinz
专栏 http://zhuanlan.zhihu.com/goujianzhifa
目录 · · · · · ·
1.1 软件 = 程序 + 软件工程
1.2 软件工程是什么
1.3 练习与讨论
第2章 个人技术和流程 /21
2.1 单元测试
2.2 效能分析工具
2.3 个人开发流程
2.4 实践
2.5 练习与讨论
第3章 软件工程师的成长 /46
3.1 个人能力的衡量与发展
3.2 软件工程师的思维误区
3.3 软件工程师的职业发展
3.4 技能的反面
3.5 练习与讨论
第4章 两人合作 /68
4.1 代码规范
4.2 代码风格规范
4.3 代码设计规范
4.4 代码复审
4.5 结对编程
4.6 两人合作的不同阶段和技巧
4.7 练习与讨论
第5章 团队和流程 /96
5.1 非团队和团队
5.2 软件团队的模式
5.3 开发流程9
5.4 练习与讨论
第6章 敏捷流程 /114
6.1 敏捷的流程简介
6.2 敏捷流程的问题和解法
6.3 敏捷的团队
6.4 敏捷总结
6.5 敏捷的问答
6.6 练习与讨论
第7章 实战中的软件工程 /133
7.1 MSF简史
7.2 MSF基本原则
7.3 MSF团队模型
7.4 MSF过程模型
7.5 实战中的软件工程
7.6 练习与讨论
第8章 需求分析 /157
8.1 软件需求
8.2 软件产品的利益相关者
8.3 获取用户需求—用户调研
8.4 竞争性需求分析的框架
8.5 功能的定位和优先级
8.6 计划和估计
8.7 分而治之(Work Breakdown Structure)
8.8 练习与讨论
第9章 项目经理 /191
9.1 PM是啥
9.2 微软PM的来历
9.3 PM做开发和测试之外的所有事情
9.4 领导力—高效的团队讨论
9.5 PM 和风险管理
9.6 练习与讨论
第10章 典型用户和场景 /211
10.1 典型用户和典型场景
10.2 用例(Use Case)
10.3 规格说明书
10.4 功能驱动的设计
10.5 练习与讨论
第11章 软件设计与实现 /232
11.1 分析和设计方法
11.2 图形建模和分析方法
11.3 其他设计方法
11.4 从Spec到实现
11.5 开发阶段的日常管理
11.6 实战中的源代码管理
11.7 代码完成(Code Complete)
11.8 练习与讨论
第12章 用户体验 /258
12.1 用户体验的要素
12.2 用户体验设计的步骤和目标
12.3 评价标准
12.4 贯穿多种设备的用户体验
12.5 练习与讨论
第13章 软件测试 /279
13.1 基本名词解释及分类
13.2 各种测试方法
13.3 实战中的测试
13.4 运用测试工具
13.5 练习与讨论
第14章 质量保障 /310
14.1 软件的质量
14.2 软件的质量保障工作
14.3 练习与讨论
第15章 稳定和发布阶段 /329
15.1 从代码完成到发布
15.2 不同频率和不同覆盖范围的渐进发布
15.3 发布之后—事后诸葛亮会议
15.4 练习与讨论
第16章 IT行业的创新 /346
16.1 创新的迷思
16.2 创新的时机
16.3 创新的招数
16.4 魔方的创新
16.5 创新和作坊
16.6 练习与讨论
第17章 人,绩效和职业道德 /384
17.1 领导力
17.2 领导力—知人善任
17.3 领导力—带领团队成长
17.4 猪、鸡和鹦鹉的故事
17.5 其实还是人的问题
17.6 绩效管理
17.7 萝卜与白菜
17.8 软件工程师的职业道德
17.9 练习与讨论
给任课老师和助教的建议 /420
课程安排
师生关系
给授课老师和助教的建议
索引 /436
· · · · · · (收起)
"构建之法(第三版)"试读 · · · · · ·
第一版前言:https://book.douban.com/reading/32686193/
原文摘录 · · · · · · ( 全部 )
-
把所有的错误记在一个“我常犯的错误”表中,作为以后自我复审的第一步。 (查看原文) —— 引自章节:在代码复审后要做什么 -
什么是好的软件?一些同学认为,所谓好软件,就是软件没有缺陷(Bug),所谓软件工程,就是把软件中的Bug都消灭掉的过程。这的确是抓住了软件工程的一个要素。和软件打交道的专业人士都知道软件有“Bug”(缺陷),软件团队的很多人都整天和Bug打交道,Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。 ——P15 很多人认为有Bug就是质量不合格,没有Bug就是质量完美,其实这也未必。我们在大街上看到很多小汽车,这些汽车出厂时都通过了各自的质量检测,符合行业的质量标准。但是你问路人哪些车的“质量好”,很多人会告诉你有些车的质量大大好于另外一些车,那为什么还有人买那些质量“不够好”的汽车呢?对于某些顾客来说,某一类的汽车满足了他们的需求,他们就会买。如果销售人员不经市场调研胡乱推销自己公司的汽车,最后销量未必理想。 市面上有这么多不完美的产品,软件团队为什么还要把这些不完美的软件发布出来呢?为什么不能等到它们完美之后再发布?**软件工程的一个重要任务,就是要决定一个软件在什么时候能“足够好”,可以发布。** ——P16 (查看原文) —— 引自第1页
> 全部原文摘录
喜欢读"构建之法(第三版)"的人也喜欢的电子书 · · · · · ·
喜欢读"构建之法(第三版)"的人也喜欢 · · · · · ·
构建之法(第三版)的书评 · · · · · · ( 全部 104 条 )

水面下的冰山——读《构建之法》

构建之法,运用之妙,存乎一心

可否把邹欣老师这个人也给“出版”了?

以独特的视角来看软件工程--读《构建之法:现代软件工程》有感

说实话,难得的一本好书

100倍速度前的慢动作

不论在校或者已经工作,都值得一读
-
问题一: 在第一章概论中提到,软件工程的目标— 创造“足够好”的软件,并对其做了定义: 什么是好的软件?一些同学认为,所谓好软件,就是软件没有缺陷(Bug),所谓软件工程,就是把软件中的Bug都消灭掉的过程。这的确是抓住了软件工程的一个要素。和软件打交道的专业人士都知道软件有“Bug”(缺陷),软件团队的很多人都整天和Bug打交道,Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。 —... (2回应)
2018-09-09 20:35:23 3人喜欢
问题一:
在第一章概论中提到,软件工程的目标— 创造“足够好”的软件,并对其做了定义:
什么是好的软件?一些同学认为,所谓好软件,就是软件没有缺陷(Bug),所谓软件工程,就是把软件中的Bug都消灭掉的过程。这的确是抓住了软件工程的一个要素。和软件打交道的专业人士都知道软件有“Bug”(缺陷),软件团队的很多人都整天和Bug打交道,Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。 ——P15 很多人认为有Bug就是质量不合格,没有Bug就是质量完美,其实这也未必。我们在大街上看到很多小汽车,这些汽车出厂时都通过了各自的质量检测,符合行业的质量标准。但是你问路人哪些车的“质量好”,很多人会告诉你有些车的质量大大好于另外一些车,那为什么还有人买那些质量“不够好”的汽车呢?对于某些顾客来说,某一类的汽车满足了他们的需求,他们就会买。如果销售人员不经市场调研胡乱推销自己公司的汽车,最后销量未必理想。 市面上有这么多不完美的产品,软件团队为什么还要把这些不完美的软件发布出来呢?为什么不能等到它们完美之后再发布?**软件工程的一个重要任务,就是要决定一个软件在什么时候能“足够好”,可以发布。** ——P16 引自 1 从书本中大概能了解到一个好软件,就是Bug尽可能的少。而书中定义的Bug即软件的行为和用户的期望值不一样。那么如果一个功能对于一部分用户来讲是十分好用的,而有一部分的用户认为这是不合乎自己的期望值的功能,那么此时这算不算是Bug,工程师需不需要解决优化这个Bug。在一个被认定为“足够好”的软件发布后,得到的用户反馈中,哪些是有用的?什么时候才能将这个软件优化到相对稳定的版本?
不同的人对不同的事物有不同的看法,那么倘若这个软件已经被80%的用户认为已经很完美了,那剩下20%所提的建议还是否需要采纳,按照反馈来修复这20%所认为的Bug呢?我个人认为,Bug是相对的,只有软件的行为和大多数用户的期望值不一样才叫做Bug。
倘若一个软件能让80%的用户喜爱上那便是成功的好软件。但是如果那20%的用户提出的一些更加细致化功能化的模块时,程序员是否应该当做Bug来完善,这样会不会导致整个程序为了小部分的精致要求变得越来越复杂,到最后由小认知阻力的软件成长为一个大认知阻力的软件呢?
问题二:
在第四章两人合作中结对编程一小节中提到极限编程这一思想:
既然代码复审能发现这么多问题,有这么好的效果,如果我们每时每刻都在代码复审的状态,那不是很好么?事实上,极限编程(Extreme Programming)正是这一思想的体现——为什么不把一些卓有成效的开发方法用到极致(Extreme),让我们无时无刻地使用它们? ——p84页 极限编程对工程师提出了更高的要求。这种要求不关乎技术水平,也不关乎学历水平或工作经验。这种要求是对一个人的心智、道德修养的更高要求。结队编程中,编码不再是私人的工作,而是一种公开的“表演”。程序员的代码、工作方式、技术水平都变得公开和透明,这也许是一些人不喜欢这一方式的原因。 ——P87 引自 1 那么,极限编程和结对编程,这两者的关系到底是怎样的?书中也只是提到这个名词,并没有详细的对这两者进行解释,根据百度我查到:
- 极限编程包括了十几种实践(就是一些具体做法),结对编程是极限编程的一种实践。
- 极限编程是一种轻量级的、灵巧的、简单的软件工程方法。与传统的开发过程不同,极限编程的核心活动体现在需求→测试→编码→设计过程中。因此适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的代价来满足用户未来的需求。
- 结对编程,也就是两个人写一个程序,其中,一个人叫Driver,另一个人叫Observer,Driver在编程代码,而Observer在旁边实时查看Driver的代码,并帮助Driver编程。并且,Driver和Observer在一起时可以相互讨论,有效地避免了闭门造车,并可以减少后期的code review时间,以及代码的学习成本。
随着现代软件产业的发展,一个软件的开发不再是一个人就可以完成的任务了,都是在相互合作中完成的。合作的最小单位便是两个人,那么两个人的合作如何才能真正的实现“1+1>2”的效果?传统编程上是双方提前做好约定,分别完成不同模板再进行后期拼接,共同完成同一个项目。而结对编程则是两人一同一致的一起完成项目的每一个步骤,其基本合约是双方平等合作,不存在领导与被领导的关系。这两种方式各自有各自的好处,但是在什么情况下选择何种方式,这并没有在书中详细告知。
我们知道,一个大型项目的完成肯定需要分工合作,需要将任务分解成不同模块,让队员分开编写代码,同步进行项目的制作。所以合作时,工作效率是一个必须考虑的问题。我们在期末的课程设计时,大多数组都会出现一个致命的问题,代码拼接时所浪费测试的时间不如同一个人完成来的效率更高。而两个人采用结对编程的方法一同完成时确实会比较高效快速完成,同时两个人也会对于代码的认知度达到一个相对持平的水平。
我个人对于结对编程的方式是十分推崇的,前提条件是双方要尽可能的水平一致。但是好像学校的课程设计组队中又很难真正的运用到结对编程这一思想观点,就像书中所说结对编程产生的代码是“公共”代码,不属于任何一个人,故而在课程设计组队中很难评判结对编程两人的贡献值,这对老师的评分评判有很大的难度,但是倘若仅仅为了严格区分每个人的代码分配而采用传统的编程方式导致项目在拼接时消耗大量时间的话,这就成了仅仅为考试而做的工作,违背了课程设计的初衷。我想请问倘若在结对编程更加受益于整个团队时,老师是否可以接受部分队员之间存在部分的“公共”代码?倘若需要对这部分“公共”代码进行划分,要如何划分这部分代码的归属。
参考文献:https://blog.csdn.net/lanjianhun/article/details/8963374
参考文献:https://blog.csdn.net/haoel/article/details/3868090
问题三:
这本书对计算机科学这一学术领域划分了两个不同方面,其一是偏理论领域,其二是偏实践领域,人工智能划分在实践领域,同时本书对于“智能”的阐述也让我对人工智能的发展有了不同的认知。
计算机人工智能研究的一个重大挑战,就是计算机程序是否在国际象棋这个游戏中打败人类。从20世纪60年代开始,就有很多研究人员从理论和“智能”的角度去着手,取得了一定进栈,但是里最终胜利还是遥遥无期。1985年,还是一个研究生的徐峰雄这样想: “我们从一个不同的方向去逼近这个问题。我们,至少是我自己,把这个问题看成是一个纯粹的工程问题。” 历史证明,这个从工程的角度出发,用“蛮力”提高计算机速度的工程方法远远甩开了同时代的各种“智能”方案。1997年,徐峰雄带队设计的“深蓝”战胜了国际象棋大师加里·卡斯帕洛夫。 ——P13 引自 1 提到人工智能的发展,大家往往都持有不同的观点。有的人认为人工智能可以将人类从低级繁琐劳动中解放出来,而有的人担心高智能之后脱离人类的控制导致不可预估的后果。霍金曾在接受英国广播公司(BBC)采访时明确表示:
“制造能够思考的机器无疑是对人类自身存在的巨大威胁。”、
“它(人工智能)能够自行发展,并且以从未有过的速度重塑自我,而人类受限于缓慢地生物进化,无法与之抗衡而终将被替代。”
这些对于人工智能观点如果从工程角度来判断的话,仿佛并不可信。1997年,徐峰雄所带领小组研发的深蓝战胜国家象棋世界冠军卡斯帕罗夫。这是人类进化史上的一个里程碑,人类制造工具来打败自己。而人工智能在弈棋机实现上主要由三个主要部分组成:
- [1] 走法生成器;
- [2] 评价函数;
- [3] 搜索控制。
这与人类的记忆选择是非常相似的。我之前在一场讲座中听到周昌乐教授讲人工智能的时候,他讲述智能在棋盘的体现便是,程序员设计程序将所有的可能性指出,并给出每一种可能的对应策略,对于每一种可以选择的方案进行评估,最后选出最合适最受益的棋路。同时他还提到了人工智能的发展的瓶颈不是算法的局限性,是计算机计算速度的局限性。如果这么理解的话,那么人工智能的实现便是人类赋予的各种可能性的综合,倘若计算的速度允许,那么人工智能将迎来再次的快速发展,这和书中指出用“蛮力”提高计算机速度的工程方法远远甩开了同时代的各种“智能”方案是吻合的。那么我想问的是,如果人工智能的发展现阶段仍旧是工程问题,局限性还是计算速度的问题的话,那人工智能的发展对于人类文化的破坏,以及人类受限于缓慢地生物进化,无法与之抗衡而终将被替代的观点是否在此基础上无法成立?
参考文献:http://www.360doc.com/content/17/1010/21/41653239_693879542.shtml
参考文献:https://book.douban.com/annotation/17174085/
问题四:
在第十二章的用户体验中,作者用了大量的文笔来介绍用户体验的要素,如:用户的第一印象、用户的角度考虑问题、软件服务始终都要记住用户的选择、短期刺激和长期影响、不让用户反简单错误、用户体验和质量、情感设计。 这几点给出的故事都是在讲述如何从细节部分让用户喜欢上甚至爱上设计的程序。在了解了影响用户体验的要素后,设计就显得至关重要,如何设计、怎样设计才能满足大部分的用户团体?这是每个工程师都需要考虑的部分。书中讲到:
用户体验设计的一个重要目的就是要降低用户的认知阻力(Cog-nitive Friction),即用户对于软件界面的认知(想象某事应该怎么做,想象某操作应该产生什么结果)和实际结果的差异。我们来看一个具体的例子,如果用户(一个生活在中国二线城市,有高中文化水平,有基本计算机基础的成年人)要在一个文稿中写居中的一句话,在下表所列的各种工具中,用户是怎么才能做到的。 倘若认知阻力大,学习曲线就会比较陡;但是经过学习和练习,如果用户适应了新的认知模式,工作效率便会有较大的提高。 ——P271 引自 1 在用户体验设计这里有一个文字编辑软件的对比表格。由表可见,在Word 2007版本之前需要手动选择选择“居中”功能而Word 2007版之后的软件有添加一个新方法:在文档任意地方双击鼠标,光标将会停在双击的地方。无论是在07版本之前还是之后,这些设计的各种方式也没有办法做到不学就上手,顶多算是学起来图形化界面比较完整,相比起LaTex等论文编辑器更容易上手罢了。而且对于表中提到新添加的双击居中方法在下载后也没有很好的简易教程交给用户,我相信很多人都不知道这个功能,那么如果大多数用户都不了解,不会用到的小功能是否还有必要去开发?
我个人认为,针对这类的软件,应该配备简易的图文流程。就像腾讯每次QQ的更新都会通过五六步的图文引导来简明快捷的介绍最新版本增加的新功能,起到一个推广的作用。
本书中有写到,用户体验设计的一个重要目的就是要降低用户的认知阻力(Cog-nitive Friction),而对于LaTex编辑器来讲,它的认知阻力就相对较大,但是对应的功能就更加强大,对于计算机专业或需要专业论文撰写的用户来说是非常有帮助的。那这类工具所面向的用户团体不就是有专业需求的人士吗?那么这类认知阻力极大的软件岂不是降低了用户体验感吗?针对这种专业性较强的软件来讲,降低认知阻力还是用户体验设计的一个重要目的吗?还是说在一些情况下,总有一些软件是开发给那些需要功能强大,忽略认知阻力的受用团体的。
问题五:
在第十七章 人、绩效和职业道德中:
很多心理学家通过各种试验和分析告诉我们,纯粹强调外界的驱动因素(金钱的报酬或惩罚)仅仅对体力劳动或有明确规则的活动有效(奖金越多,结果越好),但对于需要创造性思维的活动,即使是简单的认知能力的活动,更多奖金反而起到相反的效果。 ——P409 引自 1 这里讲到对于创造性思维的活动来说,创造力的激发和金钱成反比?奖金为何会没有作用?就算不起作用也不会起到相反的作用吧?但是换个角度来看,倘若一个工程师的一个创造性idea达到一个天价的地步,那么除非他真的看淡名利应该也是会有心理压力和动力的。但是压力和动力不就是激发创造的源泉吗?在有压力和动力的情况下产生创造性突破的概率应该比没有压力和动力的情况下概率更高不是吗?
于是我查了百度,了解到发现创造力的激发和金钱确实成反比!参考的文献中通过一个实验说明了虽然基础良好的待遇的工作环境,是基本的保障,人们在良好的基础保障上在发挥创造力,就是现实的可操作的。但是人脑其实非常孱弱,因此要好好发挥其灵光闪耀,则必须提供和营造良好的分享氛围,强调和激励工作人员去关注创造力本身,而不去纠结奖金激励。
但是个人认为,在员工角度来看,一个员工完成一次创新之后,如果只得到了鼓励没有金钱方面的报酬,会不会影响下一次创造性idea的出现?
参考文献:https://wenku.baidu.com/view/560c086648d7c1c708a1456d
2回应 2018-09-09 20:35:23 -
Question 1:软件工程师的能力衡量? Question 2:绞刑架和职业发展? Question 3:为什么要充分授权和信任? Question 4:成功的团队更能创新? Question 5:不太做广告,主要靠口口相传,容易被技术进步淘汰.? 个人博客园地址:[http://www.cnblogs.com/qichang/] 欢迎大家评论指教!不胜感激 (1回应)
2018-03-18 11:56:44 1人喜欢
Question 1:软件工程师的能力衡量?
Question 2:绞刑架和职业发展?
Question 3:为什么要充分授权和信任?
Question 4:成功的团队更能创新?
Question 5:不太做广告,主要靠口口相传,容易被技术进步淘汰.?
个人博客园地址:http://www.cnblogs.com/qichang/
欢迎大家评论指教!不胜感激
1回应 2018-03-18 11:56:44
-
GreyZeng (程序员)
我成为了一名职业程序员,但是我发现所有的算法别人都已经实现了,我只要调用就可以。似乎我们公司的软件与数据结构、算法的关系都不大。那我当初辛辛苦苦学习的数据结构和算法有用么?如何区分一个好的程序员和不好的程序员呢? 体会:书中举的四则运算的例子做深了以后可能还涉及一些相对比较复杂的算法,可是在现实中接触到的系统很多是业务驱动的系统,用户量可能不会超过2000,CRUD,业务复杂流程交给成熟的工作流系统去做... (1回应)2017-07-11 20:25:26
我成为了一名职业程序员,但是我发现所有的算法别人都已经实现了,我只要调用就可以。似乎我们公司的软件与数据结构、算法的关系都不大。那我当初辛辛苦苦学习的数据结构和算法有用么?如何区分一个好的程序员和不好的程序员呢? 引自 概论 体会:书中举的四则运算的例子做深了以后可能还涉及一些相对比较复杂的算法,可是在现实中接触到的系统很多是业务驱动的系统,用户量可能不会超过2000,CRUD,业务复杂流程交给成熟的工作流系统去做了,CRUD是很简单的数据库表操作,数据库操作有现成的框架,前端有现成的框架,后端有现成的框架,程序员要做的事情就是熟悉现有的框架,完成相应的业务模块的开发。典型的开发过程是:拿到一个业务需求,建模->转换成实体类->对这个实体类的CRUD->拖出一个工作流流程图->把流程涉及的表单用前端框架做好->调用封装好的工作流的方法实现业务流程操作。在整个过程中,似乎用不到任何复杂一些的算法和数据结构(最多可能会考虑一下实体类之间一对多之间的关系),但是仍旧有些程序员做的很好,bug非常少,功能也很稳定,有些bug很多,这样可以区分去好的程序员和不好的程序员么?
1回应 2017-07-11 20:25:26 -
什么人群适合看《构建之法》这本书? 为什么会有这样的疑问呢?在于我粗略看下这本书后发现,我不适合看这本书。确实,本书作为计算机专业的教材很有意思,当作者提出一个具有争议或让人困惑的观点时,会通过文中虚构的人物来提出读者可能的疑问,并通过对话的形式,给出作者自己的见解。 但是如果学生没有足够的代码量和工程经验(比如我),对里面所讲的很多问题并不会有太多的切身体会,可能很难深刻理解。 我认为《构建之法... (1回应)
2018-03-17 00:22:42
什么人群适合看《构建之法》这本书?
为什么会有这样的疑问呢?在于我粗略看下这本书后发现,我不适合看这本书。确实,本书作为计算机专业的教材很有意思,当作者提出一个具有争议或让人困惑的观点时,会通过文中虚构的人物来提出读者可能的疑问,并通过对话的形式,给出作者自己的见解。 但是如果学生没有足够的代码量和工程经验(比如我),对里面所讲的很多问题并不会有太多的切身体会,可能很难深刻理解。
我认为《构建之法》最适合有一定代码量积累和经验的人阅读,尤其是在做项目过程中,时常感到困惑的一线工程师,或者是面对一个庞大的软件项目开发任务而感觉力不从心,无力掌控的负责人。此时,这本书就能帮助读者“理论结合实际”,发挥它最大的功效。
不知道作者在写书时,学院考试在选教材时是否有考虑过这个问题呢??。
1回应 2018-03-17 00:22:42 -
我看到推荐序的这一段: 《现代软件工程》采用的“做中学”的教学方法和面向实战、超大量的项目实践给学生带来了明显的帮助…… 根据我的实践,我觉得:“做中学”模式确实对我们学习编程、学习数学类、物理类知识很有帮助(应该说对理工科很有帮助,我只举例自己学过的),学编程就是要会使用一门语言并能够让它来做我们想要它做的事情,它就是我们的双手,手要多加练习才能灵活使用,我在过去两年半的学习中也深刻体会到了实... (1回应)
2018-03-18 13:55:02
我看到推荐序的这一段: 《现代软件工程》采用的“做中学”的教学方法和面向实战、超大量的项目实践给学生带来了明显的帮助…… 根据我的实践,我觉得:“做中学”模式确实对我们学习编程、学习数学类、物理类知识很有帮助(应该说对理工科很有帮助,我只举例自己学过的),学编程就是要会使用一门语言并能够让它来做我们想要它做的事情,它就是我们的双手,手要多加练习才能灵活使用,我在过去两年半的学习中也深刻体会到了实验课的重要性,因此我对这句话的前半部分非常赞同。 但是我对“超大量”不太认同,我认为学习编程应该在代码中“玩”,就是在学习中体验编程的快乐,当我完成一项实验后会有比较大的成就感,但“超大量”这个词听起来是高中式的刷题战略,练多了当然能熟练使用,但我觉得刷题不是最好的学习方法。我觉得这个词用的不太好,不知道老师怎么看?
目录对小节没有标识页码,感觉比较简约,跟其他书不太一样哦~但是这样一来查阅也比较不方便了,我觉得老师应该是有考虑到这样翻目录不容易找到对应页码,不知道老师是怎么想的呢?为什么这样设计? 我发现书本中对知识点都有强调地标出来,序号加粗、上下空半行,这对阅读很有帮助,其他课本上经常是知识点混杂在一段话里面,要仔细阅读挑出来,我觉得老师出这本书是真心热爱教育、为同学考虑,是个逻辑思维很强的人;书中加入了很多有趣的背景故事,像第6页的从爱好到产业举的几个例子和第56页《念奴娇》等等等,几乎每件事情老师都能拿简单的事例引入,让我身临其境地理解书包内容。我很好奇的是:老师是如何培养自己的幽默感和趣味性的呢? 我一直觉得逻辑性强的人幽默感会比较差,可能是因为我母亲是一个很有条理很有逻辑的人,做事喜欢提前列好序号,哪些先做、哪些后做……她要求我做一件事就要一心一意做好,不能分心,虽然她只要求我一件事:好好读书。所以我的初中、高中生活比较单调,特别羡慕那些兴趣爱好广泛的同学,也希望培养自己的娱乐精神和幽默感,很好奇老师平时的爱好是什么呢?
1回应 2018-03-18 13:55:02 -
1. 在这周的网络工程课上,张敏老师提出这样一个问题。如果一个软件中的功能,用户使用它的概率是百万分之一,你还要做这个功能么?书中指出了飞机的安全功能,诚然,人的生命是第一位,所以安全功能不可小觑,虽然不安全的状况发生的概率极低。然而,对于一些用户不太需要的功能或者很少用的功能,又不涉及到人身财产安全。是否有开发的必要? 2. 第12章有说到,微软必应搜索有一个“实时显示英语解释”的功能,但是这个功能把... (1回应)
2018-03-18 16:17:38
1. 在这周的网络工程课上,张敏老师提出这样一个问题。如果一个软件中的功能,用户使用它的概率是百万分之一,你还要做这个功能么?书中指出了飞机的安全功能,诚然,人的生命是第一位,所以安全功能不可小觑,虽然不安全的状况发生的概率极低。然而,对于一些用户不太需要的功能或者很少用的功能,又不涉及到人身财产安全。是否有开发的必要?
2. 第12章有说到,微软必应搜索有一个“实时显示英语解释”的功能,但是这个功能把鼠标所在的所有英语单词都解释一下。显得用户很笨的样子!但是微信也推出了同样的翻译功能,支持多种语言,确使得另绝大多人欢迎。 一个软件的功能越多,是否越受用户欢迎,或者说越好用,为什么有的软件用起来会觉得很白痴,有的则觉得很人性化?
3. 对于敏捷流程中的测试驱动开发,英文全称Test-Driven Development,简称TDD,是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码,并加速开发过程。其方法的重大差距也是代码。且这代码必须得写,得维护,它还会含有bug。所以如果整个项目中开发员花x%的时间写新的(测试)代码而不重视写产品代码,那它其中的意义何在?
4. 如今强盗软件,捆绑下载无处不在 那么什么是IT人的职业道德规范,今后会不会有法律来约束?
5. 如果我不擅长开发,更倾向于人际交往,营销方面,想做一个PM,从现在开始应该做什么,学习些什么?
1回应 2018-03-18 16:17:38
-
这一章中,对软件工程师的思维误区这个部分,感受很深。 书中列举了4种误区: 分析麻痹:因为想等到所有分析都完毕之后再动手,结果心理上恐惧,没法起步; 不分主次,想解决所有依赖问题:想解决所有依赖,结果精力被分散,比较好的解决方法应当是找一个当前“足够好”的方案,先解决主要问题; 过早优化:花大量时间优化局部,没有考虑全局 过早扩大化、泛化:过早地将一个工具或算法对其进行扩展 这些问题种,我都或多或少有... (2回应)
2019-01-31 23:24:36
这一章中,对软件工程师的思维误区这个部分,感受很深。
书中列举了4种误区:
分析麻痹:因为想等到所有分析都完毕之后再动手,结果心理上恐惧,没法起步;
不分主次,想解决所有依赖问题:想解决所有依赖,结果精力被分散,比较好的解决方法应当是找一个当前“足够好”的方案,先解决主要问题;
过早优化:花大量时间优化局部,没有考虑全局
过早扩大化、泛化:过早地将一个工具或算法对其进行扩展
这些问题种,我都或多或少有涉及,其中不分主次最为麻烦。现在工作之后,走了很多弯路之后,才知道问题分优先级、分主次的重要。聚焦核心问题,避免过程中精力分散,问题才好解决。把当时遇到的困难绕过,主要问题解决后,再来解决次要问题。如果一开始在次要问题上折腾,主要问题就没时间解决了,得不偿失。
2回应 2019-01-31 23:24:36 -
解决问题的一般流程: 1.抽象、剥出核心问题 2.寻找可以解决核心问题的模型 3.根据模型解决问题 开发阶段的经验 1.聚焦高优先级的事情,延缓处理低优先级的事情 2.排列事情的优先级,轻重缓急 3.要重视核心竞争力能力构建,不能忽视基本功的积累(要能做基础的事情,又不能只做基础的事情) 在代码提交的制度上, 如果只是对个人有影响,采取宽松的代码管理方式; 如果是对团队有影响,采取严格的代码管理方式。 这样做,既有效... (3回应)
2019-01-27 23:09:28
解决问题的一般流程:
1.抽象、剥出核心问题
2.寻找可以解决核心问题的模型
3.根据模型解决问题
开发阶段的经验
1.聚焦高优先级的事情,延缓处理低优先级的事情
2.排列事情的优先级,轻重缓急
3.要重视核心竞争力能力构建,不能忽视基本功的积累(要能做基础的事情,又不能只做基础的事情)
在代码提交的制度上,
如果只是对个人有影响,采取宽松的代码管理方式;
如果是对团队有影响,采取严格的代码管理方式。
这样做,既有效率又有质量
小强地狱:
如果一个人要解决的问题的数量或者严重程度超过阈值,要全职投入问题解决,功能开发放一边。
要做充分的软件测试。这个我很认同,之前读过《clean code》,这本书里面也同样重点提到了这一点。同时提到的软件设计原则包括:
1.软件要有充分的测试
2.软件要尽可能消除重复
3.通过给函数、变量命令明确作者意图
4.使用尽量少的元素
3回应 2019-01-27 23:09:28
论坛 · · · · · ·
书单 | 微软首席研发经理邹欣的书架:从程序到创新 | 来自larcsmile | 2020-08-09 16:22:23 | |
微软(亚洲)首席研发经理邹欣:计算思维+兴趣+学... | 来自larcsmile | 2020-08-09 16:22:00 | |
【专访邹欣】投身软件工程教育的程序员 | 来自larcsmile | 2020-08-09 16:21:45 | |
第一届“构建之法”软件工程实践教学论坛在福州召开 | 来自larcsmile | 2020-08-09 16:21:20 | |
构建之法的扩展:“教练”角色的转变——作者:张... | 来自larcsmile | 2020-08-09 16:20:55 |
> 浏览更多话题
当前版本有售 · · · · · ·
-
每满100-30
这本书的其他版本 · · · · · · ( 全部3 )
-
人民邮电出版社 (2014)8.6分 539人读过
-
人民邮电出版社 (2015)8.0分 144人读过
以下书单推荐 · · · · · · ( 全部 )
- 现代软件工程的教材和参考书 (xinz)
- 购物车 (cruyff)
- 大厂方法论 (豆友4104547)
- 工作后购书目录 (张小国)
- 蟒营®101.camp (Zoom.Quiet)
谁读这本书?
二手市场
订阅关于构建之法(第三版)的评论:
feed: rss 2.0
1 有用 Zoom.Quiet 2020-02-29 17:45:11
是也乎,( ̄▽ ̄) 这是和 蟒营™101.camp 开源网络课程框架 https://101.camp/ 设计思想最接近的课程... 邹老师多年以来挤出时间回学校任教, 因为没有职称的期待,所以, 能将真实软件工程的经验融入大学课程来... 真正训练学生们形成切实的软件开发实力, 而不仅仅是移动书架... 可惜这种课程太少了.... 唯一意见, 构建之法, 这名称太不直觉了, 构建之路, 更... 是也乎,( ̄▽ ̄) 这是和 蟒营™101.camp 开源网络课程框架 https://101.camp/ 设计思想最接近的课程... 邹老师多年以来挤出时间回学校任教, 因为没有职称的期待,所以, 能将真实软件工程的经验融入大学课程来... 真正训练学生们形成切实的软件开发实力, 而不仅仅是移动书架... 可惜这种课程太少了.... 唯一意见, 构建之法, 这名称太不直觉了, 构建之路, 更加吻合内容吧. (展开)
1 有用 韩小四 2020-11-22 12:50:03
讲的挺好的。说说缺点吧,引用资料用了很多链接,但对于纸质书来说,链接体验很差劲,还得打开电脑在url上一个字一个字的敲出链接,甚至有的链接都已经失效了。知道好多文章是从博客整理过来的,但咱都出纸质书了,能不能检验一下,希望下一版优化一下,出个二维码不好吗?
2 有用 很自然的宿命 2019-07-23 15:46:23
好书啊,软件从业相关人员必看啊
1 有用 X.min 2018-05-11 15:26:19
全面和紧跟时代,获益良多,如果要说遗憾,那就是关于设计部分,只有一个章节,也有很多关于设计的点但散布于书本其他章节需要分析提炼,界限上并不是很清晰。本书是目前看过的最好的软件工程书。
1 有用 masterplan 2018-01-01 23:02:02
对初出茅庐的人有用, 学习开发中的方法论和心得. 文字也幽默流畅. 希望能出电子版
0 有用 一升 2022-06-26 16:35:26
复习一下现代软件工程的构建之法,知识点系统又全面,案例丰富又接底气,据说本书是一些学校软件工程的教科书,很不错 👍
0 有用 雁过留痕 2022-05-29 11:47:42
前半部分比较有用,第16章比较啰嗦
0 有用 moverzp 2022-05-16 00:40:46
研二的时候就买了,但是限于非科班的自身水平,读了2次都没有读下去。后来成功转码,工作5年之后再看本书,发现里面的内容就是我日常工作采用的各种方法和流程,可惜没有早点看到本书,能从书本和高人身上学到的东西,就尽量不要从「坑」里面学习。。作为互联网企业的开发,用到的方法都是那种能及格之后能快则快的方法,还是挺羡慕本书那种稳扎稳打的IT开发方式的。最后,能看出来作者是个非常严格的人,发表这个评论的时候发... 研二的时候就买了,但是限于非科班的自身水平,读了2次都没有读下去。后来成功转码,工作5年之后再看本书,发现里面的内容就是我日常工作采用的各种方法和流程,可惜没有早点看到本书,能从书本和高人身上学到的东西,就尽量不要从「坑」里面学习。。作为互联网企业的开发,用到的方法都是那种能及格之后能快则快的方法,还是挺羡慕本书那种稳扎稳打的IT开发方式的。最后,能看出来作者是个非常严格的人,发表这个评论的时候发现作者已经在CSDN工作了,希望能把这个「垃圾堆」梳理干净吧,中国人能有一个自己的程序员网站应该是一件好事。 (展开)
0 有用 rambling 2022-05-05 17:13:20
比较浅显,适合初级人员使用
0 有用 Wilson Edwards 2022-04-28 13:15:32
邹老师,你是我的神.jpg