新書推薦:
《
何以中国·何谓唐代:东欧亚帝国的兴亡与转型
》
售價:HK$
87.4
《
一间只属于自己的房间 女性主义先锋伍尔夫代表作 女性精神独立与经济独立的象征,做自己,比任何事都更重要
》
售價:HK$
44.6
《
泉舆日志 幻想世界宝石生物图鉴
》
售價:HK$
134.2
《
养育女孩 : 官方升级版
》
售價:HK$
50.4
《
跨界:蒂利希思想研究
》
售價:HK$
109.8
《
千万别喝南瓜汤(遵守规则绘本)
》
售價:HK$
44.7
《
大模型启示录
》
售價:HK$
112.0
《
东法西渐:19世纪前西方对中国法的记述与评价
》
售價:HK$
201.6
|
編輯推薦: |
本版本为【简装便携版】小册,轻巧好带!!地铁、公交、图书馆、教室、办公室,一本适合多场景阅读。
百度学院精品课“代码的艺术”核心内容首次成书,百度技术培训中心官方指定用书。
清华大学、IT名企开设“代码的艺术”课程及讲座,课程获广泛赞誉。
成为优秀软件工程师三条路径:(1)学习-思考-实践;(2)知识-方法-精神;(3)基础乃治学之根本。
具备正确的意识比掌握具体的知识更重要。
读者对象:软件工程师和管理者;计算机和软件方向的在校学生。
随书附赠配套视频,作者在线一对一答疑等增值服务。
|
內容簡介: |
● 本书是作者围绕软件工程能力所做的系列培训的内容汇编。这些内容来源于作者20 多年以来对软件工程的学习体会和项目实践,以及对中国工业界软件工程师的观察和教育实践。
● 全书共8章,第1 章说明了什么是软件工程能力,阐述了软件工程能力中的素质要求。第2~8章分别从代码、文档、项目管理这三个方面讲解了提升软件工程能力素质的实践方法。 对于代码,第2章\代码的艺术”对其进行了总体说明,第3 章重点说明了代码评审,第4章以Mini-spider 为例说明了方法如何运用。 对于文档,第5章说明了如何写好项目文档,第6章说明了做研究的基本方法。对于项目管理,第7章简要说明了如何做好项目管理,第8章重点说明了如何做好项目沟通。
|
關於作者: |
章淼,博士,百度智能云资深研发工程师,BFE开源项目发起人。
1997年至2006年在清华大学从事互联网协议和网络体系结构的研究。
2012年加入百度,一直从事网络基础架构的研发工作。同时积极推动百度的代码质量和工程能力的提升,百度技术培训中心“金牌讲师”,曾任百度代码规范委员会主席。
|
目錄:
|
第1 章
软件工程能力
1.1 为什么要重视工程能力 / 3
1.2 什么是工程能力 / 5
1.2.1 工程能力的误区 / 5
1.2.2 工程能力的定义 / 6
1.3 怎样提升工程能力 / 11
第2 章
代码的艺术
2.1 背景和初衷 / 17
2.2 代码和艺术 / 18
2.2.1 代码也能成为艺术作品 / 18
2.2.2 软件工程师和“码农” / 22
2.2.3 来自艺术的启发 / 24
2.2.4 写代码并非易事 / 26
2.3 好代码和坏代码 / 28
2.3.1 好代码的特性 / 28
2.3.2 坏代码的例子 / 33
2.4 好代码从哪里来 / 35
2.4.1 好代码不止于编码 / 35
2.4.2 需求分析和系统设计 / 36
2.5 如何做好需求分析 / 41
2.5.1 如何描述需求 / 41
2.5.2 对需求分析的误解 / 43
2.5.3 需求分析的重要性 / 47
2.6 如何做好系统设计 / 47
2.6.1 什么是系统设计 / 48
2.6.2 设计文档的分类 / 49
2.6.3 什么是系统架构 / 50
2.6.4 系统设计的原则和方法 / 52
2.6.5 重视对外接口 / 56
2.7 如何写出好代码 / 59
2.7.1 代码的沟通价值 / 59
2.7.2 模块的设计方法 / 64
2.7.3 划分模块的方法 / 71
2.7.4 函数的设计方法 / 75
2.7.5 代码块的编写注意事项 / 85
2.7.6 软件开发中的命名 / 89
2.8 如何支持系统运营 / 90
2.8.1 可监测性的重要性 / 91
2.8.2 以BFE 开源项目为例 / 92
2.9 成为优秀软件工程师的三条路径 / 93
2.9.1 路径一:学习—思考—实践 / 93
2.9.2 路径二:知识—方法—精神 / 96
2.9.3 路径三:基础乃治学之根本 / 98
第3 章
代码评审
3.1 代码评审的常见误区 / 103
3.2 为什么要做好代码评审 / 104
3.2.1 代码评审的重要意义 / 104
3.2.2 没有做好代码评审的后果 / 106
3.2.3 为什么要提升代码质量 / 106
3.2.4 为什么要提升编码能力 / 108
3.3 如何做好代码评审 / 108
3.3.1 代码评审的常见问题 / 109
3.3.2 代码评审的正确态度 / 109
3.3.3 代码评审的推荐步骤 / 111
3.3.4 对坏代码的简单判断 / 112
3.3.5 代码评审的注意事项 / 113
3.4 如何成为好的代码评审人 / 116
第4 章
“代码的艺术”应用
4.1 需求的分析 / 121
4.1.1 题目说明 / 121
4.1.2 功能分析 / 122
4.2 软件的架构 / 123
4.2.1 模块切分 / 123
4.2.2 系统架构 / 128
4.2.3 软件组装 / 130
4.2.4 crawler 间的数据共用 / 132
4.2.5 数据封装 / 133
4.2.6 crawler 的执行逻辑 / 134
4.3 多线程机制 / 135
4.3.1 数据互斥访问 / 136
4.3.2 临界区注意事项 / 138
4.3.3 任务的分发 / 141
4.3.4 程序的优雅退出 / 143
4.4 其他实现细节 / 146
4.4.1 配置的读取 / 146
4.4.2 种子信息的读取 / 147
4.4.3 import 的使用 / 150
4.4.4 异常处理 / 151
4.4.5 构造函数的使用 / 153
4.4.6 正则表达式的使用 / 154
4.5 延伸思考 / 156
4.5.1 实现对各网站的限速 / 156
4.5.2 从单机扩展到分布式 / 157
第5 章
项目文档
5.1 正确认识项目文档 / 161
5.1.1 项目文档的重要作用 / 161
5.1.2 项目文档的常见误区 / 162
5.1.3 项目文档的常见问题 / 164
5.1.4 什么时候需要写项目文档 / 165
5.1.5 项目文档是写给谁的 / 167
5.1.6 项目文档的基本规范 / 169
5.2 项目文档的编写 / 170
5.2.1 编写顺序 / 170
5.2.2 文档标题 / 171
5.2.3 段落编写 / 173
5.2.4 问题划分 / 176
5.2.5 表述模式 / 177
5.3 项目文档中的图片 / 179
5.4 文档的评审 / 185
5.4.1 文档评审常见问题 / 185
5.4.2 文档评审的方法 / 186
5.5 文档的存放 / 187
5.5.1 文档存放常见错误 / 187
5.5.2 文档存放的建议 / 188
5.5.3 文档索引的例子 / 189
5.5.4 存放工具的选择 / 192
5.6 文档编写工具 / 194
5.7 如何提高文档编写能力 / 195
第6 章
做研究
6.1 什么是研究 / 199
6.2 如何做好研究 / 201
6.2.1 发现问题 / 201
6.2.2 分析问题 / 203
6.2.3 解决问题 / 205
6.3 做好研究的必备素质 / 206
6.3.1 关于做人 / 206
6.3.2 关于做事 / 208
6.3.3 关于做学问 / 209
第7 章
项目管理
7.1 重视项目管理 / 213
7.2 相关基本概念 / 215
7.3 项目管理的过程和步骤 / 218
7.3.1 项目启动和规划 / 219
7.3.2 项目执行和监控 / 224
7.3.3 项目总结与回顾 / 227
第8 章
项目沟通
8.1 项目沟通的重要性 / 233
8.2 项目沟通方式及对比 / 235
8.3 面对面沟通 / 238
8.4 电话沟通 / 239
8.5 会议沟通 / 240
8.6 IM 工具沟通 / 245
8.7 Email 沟通 / 247
附录A
延伸阅读图书推荐
软件工程和编程思想类 / 251
项目管理类 / 252
项目文档编写和阅读类 / 252
产品设计类 / 253
|
內容試閱:
|
本书是笔者围绕软件工程能力所做的系列培训的内容汇编。这些内容来源于笔者20 多年以来对软件工程的学习体会和项目实践,以及对中国工业界软件工程师的观察和教育实践。
关于软件开发的书已经有很多,软件工程师阅读最多的书或许是对某种编程语言的深入解读,或许是对某种架构方法的阐述。或许由于意识上的偏差,很多软件从业者即使已工作多年,但由于对软件工程理论相关图书阅读较少,因此对软件研发的基本理念和原则还是了解得不多。
编写本书的目的是提升软件工程师的基本意识。对于一名软件工程师来说,具备正确的意识比掌握具体的知识更重要。如果具备正确的意识,即使在工作中不记得具体的知识点,也可以在需要的时候进行查阅,而反过来就不是这样了。
本书对一名软件工程师应具备的基本意识和所需掌握的基本方法进行了全貌性介绍,同时内容又不会过于理论化和艰深。由于篇幅限制,本书对很多内容只做了入门性介绍,并向希望继续深入学习的读者提供了相关图书参考建议。
真诚希望读者能够从本书开始,更多地去阅读软件工程方面的专业图书,因为软件工程师对软件研发的学习和深入理解是永无止境的。
本书的目标读者包括:
(1)软件工程师和管理者。本书中的多个章节已经是百度内部软件工程师的必修课内容。笔者也曾多次以“代码的艺术”为题在多家知名互联网企业做过分享,不仅仅是刚参加工作的软件工程师给出了较好的反馈,很多资深软件工程师也反馈良好。
(2)计算机和软件方向的在校学生。本书介绍的很多方法是笔者在大学时就开始使用的。很多本科生和研究生其实在学校就已经开始参加较复杂的软件研发项目了,他们可以将本书介绍的方法立刻应用在这些项目实践中。更早地具备正确的软件研发意识,将为一个人后续的职业发展打下良好的基础。
本书的内容来源于培训课程材料或演讲材料,在章节编排和内容组织上仍然保持了培训课程和演讲的原貌。每一章都有明确的主题,可以独立阅读,而全书的内容又形成了一个完整体系。
第1 章首先说明了什么是软件工程能力,阐述了软件工程能力中的素质要求。
第2~8 章分别从代码、文档和项目管理这三个方面讲解了实践方法。对于代码,第2 章“代码的艺术”对其进行了总体说明。
第3 章重点说明了代码评审,第4 章以Mini-spider 为例说明了方法如何运用。对于文档,第5 章说明了如何写好项目文档,第6 章说明了做研究的基本方法。对于项目管理,第7 章简要说明了如何做好项目管理,第8章重点说明了如何做好项目沟通。
1.1 为什么要重视工程能力
由于行业内竞争加剧、成本上涨和产业升级等形势的变化,工程能力受到越来越高的重视。
1. 形势变化与挑战
最近几年,软件研发企业尤其是互联网企业正面临以下形势的变化和挑战。
(1)行业竞争的加剧。中国互联网经过20多年的发展,早已不是荒蛮之地,竞争的需要逼迫各企业在软件研发的质量和效率上不断提高。
(2)成本的上涨。中国在研发成本尤其是人力成本方面上涨非常快。中国软件工程师的人力成本已超过欧洲,和美国的差距也没有那么大了。在这种情况下,业内对于人均产出提出了更高要求。
(3)产业的升级。中国的互联网企业普遍从toC转向toB,而toB对软件研发的质量提出了更高要求。
2. 如何应对挑战
面对以上挑战,一些企业的应对方法是延长工作时间、增加工作强度。部分公司出现了“996”(早9点上班,晚9点下班,每周工作6天)的工作制度。应该说,这些方法给从业者的身体健康和正常生活带来了严重的负面影响,它们也只能是短期行为,不可能被长期执行。
从现实情况来看,其实国内很多软件工程师的工作效率是比较低的,并有巨大的提升空间。根据笔者多年的访谈反馈,很多软件工程师已经工作了8~10年,但他们的工作方法其实是错误的。在以前人工成本较低、管理方法比较粗放的情况下,这些问题并没有得到足够重视。现在中国很多传统行业在进行转型升级,因此中国的很多软件工程师也需要升级了!
提升工程能力,是应对以上变化和挑战的重要解决之道。
3. 工程能力是制胜之本
在提升工程能力的路上,我们可能会听到一些不同的声音。有些人说,手头的业务很忙,所以没有时间提升工程能力;有些人说,现在的项目进度已经很紧凑了,按照正规的方法来工作会拖慢进度,所以不能对工程能力有严格要求。
从使用不正规的方法到使用正规的方法,一定会有一些学习上的成本投入。更重要的是,工程能力不是锦上添花、可有可无,而是一种生存能力。很多项目的失败,其实是输在从业者工程能力的不足上了!
工程能力首先会影响“打的准不准”。如果从业者不能做好需求识别和分析,缺乏产品方面的意识,那么研发出的软件就没有市场和用户。
工程能力还会影响“是否能打赢”。工程能力会影响软件研发的效率、质量和成本,一个低效率、低质量和成本高的软件项目是没有市场竞争力的。
1.2 什么是工程能力
在了解了工程能力的重要性后,本节说明什么是工程能力。
1.2.1 工程能力的误区
很多人可能会将“提升工程能力”等同于“写好代码”。
代码确实是软件研发的重要产出,但是工程能力的涉及范围绝不仅仅限于编写代码。
软件研发是一个需要多人共同参与完成的工作,提升工程能力也不限于“一个人”能力的提升。
工程能力反映的是团队的综合素质。要提高工程能力,不仅要看单兵素质,也要看团队能力;不仅要提升写代码的能力,也要提升其他方面的能力(见1.3节中的说明)。
工程,不仅仅应用于自然科学,也应用于人文社会科学。只用自然科学的思路和方法来做工程,一定做不好。
在软件研发过程中,很多从业者的大量时间其实并没有用在琢磨技术上,而是用在了其他方面(比如沟通、项目协调、错误设计导致的返工),这些方面的时间消耗往往也没有得到大家的关注。很多项目的失败并不是因为技术,而是因为那些非技术的因素。
1.2.2 工程能力的定义
前面介绍了工程能力的重要性,但是我在这里认真地问一句“工程能力到底是什么?”恐怕没有几个人能回答出来,而如果不解答这个问题,我们是无法在实践中真正提升工程能力的。
在百度内部材料《百度软件工程能力定义》中,将工程能力定义为:使用系统化的方法,在保证质量的前提下,更高效率地为客户/用户持续交付有价值的软件或服务的能力。
|
|