4.4 用户推荐指数
互联网
类型
7.1
豆瓣评分
可以朗读
语音朗读
129千字
字数
2020-06-01
发行日期
展开全部
主编推荐语
程序员修炼代码整洁之道，101个编程原则独立成文，涵盖程序员都需要了解的编程方法、思想和习惯，指导读者进一步提升编程能力的行动指南。
内容简介
本书介绍了软件开发领域101个重要的编程原则，涉及编程中的永恒真理，指导方针，编程思想，程序员的视角、习惯和工具，以及编程的反模式等内容。
书中以“这个原则是什么”“为什么要遵循这个原则”“具体应该怎么做”为中心，对各个原则进行介绍，简明扼要，通俗易懂。这些原则凝聚了前人的智慧，经过了历史的考验，是指导程序员改善代码、进一步提升编程能力的实用指南。
本书适合各层次软件开发人员和项目管理人员阅读，也可作为高等院校计算机相关专业师生的参考读物。
目录
- 版权信息
- 前言
- 序章 本书导读
- 0.1 原则的分类
- ① 前提 编程永恒的真理
- ② 准则 编程的指导方针
- ③ 思想 编程的意识形态
- ④ 视角 程序员的视角
- ⑤ 习惯 程序员的日常
- ⑥ 手法 程序员的工具箱
- ⑦ 法则 编程的反模式
- 0.2 介绍方式
- ① 原则的名称
- ② 是什么
- ③ 为什么
- ④ 怎么做
- ⑤ 扩展
- ⑥ 关联信息
- ⑦ 出处
- ⑧ 相关图书
- 0.3 编程术语在本书中的用法
- ① 软件
- ② 代码
- ③ 编程
- ④ 程序员
- ⑤ 函数
- ⑥ 模块
- ⑦ 软件架构
- 0.4 注意事项
- ① 重复只因重要
- ② 自己思考实用的代码范例
- ③ 若原则之间的主张相悖则取其平衡点
- 第1章 前提～编程永恒的真理～
- 1.1 编程没有银弹
- 编程没有特效药
- 软件在本质上具有难度
- 研习历史，勇斗“复杂”
- 软件非本质部分的改善
- 1.2 代码即设计文档
- 代码才是设计书
- 改善对象是代码
- 优秀的程序员必不可少
- 罗塞塔石碑
- 1.3 代码必然被修改
- 代码总是要修改的
- 代码是无常的
- 编写经得起修改的代码
- 第2章 准则～编程的指导方针～
- 2.1 KISS原则
- 保持代码简洁
- 代码会越来越没有秩序
- 不要画蛇添足
- KISS 原则的适用范围
- less is more
- 奥卡姆剃刀
- 2.2 DRY
- 严禁复制粘贴代码
- 代码无法得到改善
- 将代码抽象化
- DRY 的适用范围
- DRY 与编程技术
- 不得已的重复
- WET
- OFOP
- OAOO
- 遗留代码
- 2.3 YAGNI
- 只写所需最低限度的代码
- 代码无法预测
- 只写当前需要的代码
- YAGNI 的适用范围
- DTSTTCPW
- 2.4 PIE
- 表达出代码的意图
- 代码是唯一的线索
- 把提高代码可读性作为第一要务
- 避免打地鼠式的开发
- 要写注释
- 文学编程
- 2.5 SLAP
- 统一代码的级别
- 使代码具有概括性和可读性
- 将函数结构化
- SLAP 的适用范围
- 实现 SLAP 的步骤
- 代码与图书
- 2.6 OCP
- 代码的修改不相互影响
- 灵活应对代码的修改
- 给代码设置接口
- OCP 的适用范围
- OCP 的实现与设计
- 受保护变化
- 2.7 名字很重要
- 命名是代码最重要的课题
- 名字是面向代码阅读者的“用户界面”
- 写代码前先决定名字
- 避免心理映射
- 环回检测
- 第3章 思想～编程的意识形态～
- 3.1 编程理论
- 指导编程的思想
- 将编程理论展示的思想作为技术的选择基准
- 通过六个原则将编程理论展示的思想应用于代码
- 视点
- 现有的工具是如何形成的
- 3.2 交流
- 代码是交流的场所
- 顺利的开发源于顺利的交流
- 从代码阅读者的角度出发
- 3.3 简洁
- 消除代码的复杂性
- 代码的复杂性是罪魁祸首
- 分清代码中的“玉”与“石”
- 3.4 灵活性
- 代码易于修改
- 代码必然会被修改
- 提高代码的可扩展性
- 3.5 效应局部化
- 减少修改带来的影响
- 更易于修改和确认
- 整合关系紧密的代码
- 3.6 重复最少化
- 消除重复
- 将修改带来的影响局部化
- 对代码进行分割管理
- 3.7 逻辑与数据的一体化
- 将数据与逻辑放在相近的位置
- 数据与逻辑往往需要同时修改
- 将数据与逻辑放在相近的位置
- 3.8 对称性
- 让代码具有一贯性
- 可以类推其他部分
- 相同的东西用相同的形式表现
- 3.9 声明式表
- 声明式编程
- 没有流程方面的限制，可读性更高
- 采用声明式的表达方式
- 3.10 变动率
- 按修改理由进行分组
- 能缩小修改范围
- 根据修改理由分配位置
- 单一职责原则
- 3.11 软件架构基本技法
- 优质代码的基本原理
- 优质代码都有“型”
- 掌握“型”
- 3.12 抽象
- 在概念上“划清界限”
- 抽象是对抗复杂的手段
- 使用“舍象”和“一般化”
- 3.13 封装
- 给数据和逻辑分组
- 不混淆抽象概念
- 将相关元素封装在一起
- 3.14 信息隐藏
- 只展示必要的信息
- 整理关系以达到简洁
- 隐藏内部信息
- 封装与信息隐藏的区别
- Parnas 原则
- 3.15 打包
- 给模块分组
- 降低模块群的复杂度
- 自下而上地设计包
- 3.16 关注点分离
- 根据关注点分离代码
- 修改以关注点为单位
- 以关注点为单位模块化
- 面向切面编程
- 3.17 充足性、完整性、原始性
- 表达要充足、完备且精练
- 准确表达抽象概念
- 完美表达模块的抽象概念
- 3.18 策略和实现的分离
- 策略和实现不同时存在
- 实现稳定但策略不稳定
- 将策略与实现存放在不同的模块中
- 3.19 接口与实现的分离
- 模块由接口和实现组成
- 使用者只需理解接口
- 针对接口编程
- 3.20 单一引用点
- 只定义一次
- 使编程无副作用
- 单一赋值
- 通过控制变量提升代码质量
- 引用透明性
- 3.21 分治
- 将大问题分割成小问题
- 大问题无法控制
- 将问题分割后逐个击破
- 3.22 软件架构的非功能需求
- “功能之外的功能”的观点
- 非功能需求在软件发布后具有很大的影响力
- 从非功能需求的观点进行设计
- 非功能测试
- 非功能安全性需求
- 检验安全性
- 3.23 易变性
- 轻松修改软件的能力
- 软件的寿命比预想的长
- 可维护性、可扩展性、重组和可移植性
- 灵活性的取舍
- 软件老化
- 3.24 互操作性
- 与其他软件交互的能力
- 软件间协作
- 选择标准规格
- 3.25 效率性
- 高效使用资源的能力
- 资源是有限的
- 活用资源
- 间接化与效率性的平衡
- 3.26 可靠性
- 维持功能的能力
- 软件对可靠性的需求各不相同
- 冗余化、故障弱化和故障安全
- 3.27 可测试性
- 有效进行测试的能力
- 测试的质量即产品的质量
- 在设计产品时兼顾测试
- 3.28 可复用性
- 重复使用与被重复使用的能力
- 能不做就不做，提高开发效率
- “插件”软件架构
- 重复使用的“三之法则”
- 可拆装组件的框架
- 3.29 七个设计原理
- 代码有效性审查的观点
- 代码价值观不遗漏且不动摇
- 将七个设计原理应用于代码的编写
- 3.30 简单性原理
- 追求简单
- bug 喜欢出现在复杂的地方
- 编写自然的代码
- 3.31 同构原理
- 力求规范
- 不同的东西会更显眼
- 编写符合规范的代码
- 3.32 对称原理
- 讲究形式上的对称
- 帮助读代码的人推测后面的代码
- 编写有对称性的代码
- 3.33 层次原理
- 讲究层次
- 层次结构有助于提高代码的可读性
- 编写有抽象层次结构的代码
- 3.34 线性原理
- 处理流程尽量走直线
- 直线处理可提高代码的可读性
- 尽量不在代码中使用条件分支
- 3.35 清晰原理
- 注意逻辑的清晰性
- 消除不确定性
- 编写逻辑清晰的代码
- 重复使用代码的风险
- 修复代码故障的风险
- 3.36 安全原理
- 注意安全性
- 防止故障发展成重大事故
- 编写安全的代码
- 代码的必要条件与充分条件
- 3.37 UNIX思想
- 根植于UNIX 中的约定俗成的规则
- UNIX设计判断的正确性
- 遵循UNIX思想
- 3.38 模块化原则
- 以精简的模块为单位
- 模块间的关系应简洁
- 减少模块的接口
- 3.39 清晰原则
- 代码要清晰
- 读代码的是人，不是机器
- 不清晰的地方要进行改善
- 3.40 组合原则
- 软件是能组合的过滤器
- 相互连接可产生协同效应
- 创建一个用于输入输出文本的命令
- 3.41 分离原则
- 从机制中分离出策略
- 机制稳定，策略不稳定
- 改善分离出来的策略
- 3.42 简单原则
- 代码要简单
- 代码会自然而然地变得复杂
- 营造“简单即美丽”的文化氛围
- 3.43 简约原则
- 不写大代码
- 大代码无法控制
- 不额外添加代码
- 3.44 透明性原则
- 让软件运行变得可见
- 有助于调试
- 编写“软件运行可见化”功能
- 3.45 健壮性原则
- 使软件具有健壮性
- 软件必须足够坚固
- 让代码透明化和简单化
- 3.46 表达性原则
- 尽量用数据表达信息
- 数据比逻辑更好控制
- 把复杂的部分交给数据
- 3.47 最小意外原则
- 接口的设计要符合使用者的想象
- 降低学习成本
- 活用用户的已有知识
- 3.48 沉默原则
- 软件应“沉默寡言”
- 能更好地传达重要信息
- 只输出重要的信息
- 3.49 修复原则
- 修复失败时停止处理
- 出错时继续运行容易扩大损害
- 错误提示要“震耳欲聋”
- 软件输入输出相关的箴言
- 3.50 经济原则
- 珍惜程序员的时间
- 程序员的时间很宝贵
- 对设备进行投资
- 3.51 生成原则
- 编写“用于生成代码”的代码
- 生成出来的代码成本低且质量高
- 编写代码生成器
- 3.52 优化原则
- 代码的正确性优于运行速度
- 在较早的阶段追求运行速度会破坏设计
- 先确保代码的正确性再想办法提高运行速度
- 优化试制品
- 3.53 多样性原则
- 容许有多样的选择
- 人的想象力是有限的
- 不懈追求更好的方案
- 3.54 可扩展性原则
- 设计时留有扩展的余地
- 软件必须扩展
- 可插拔式设计
- 具有自我描述性的数据格式
- 3.55 UNIX哲学
- 支撑UNIX的哲学
- UNIX哲学具有普遍价值
- 活用UNIX哲学
- 3.56 小就是美
- 软件规模越小越美丽
- 规模较小的软件比较好用
- 不论开发还是维护，软件都要保持较小的规模
- 3.57 工作唯一
- 一个软件只负责一项工作
- 让软件变得纯粹
- 专注于一项工作
- 3.58 尽早创建原型
- 尽早着手创建原型
- 不经历失败就做不出好软件
- 借助原型提高可靠度
- 第三系统
- 3.59 可移植性优先于效率
- 可移植性优先于效率
- 维持软件的价值
- 编写不依赖于硬件的代码
- 3.60 文本数据
- 文本文件优于二进制文件
- 文本文件是万能的
- 标准文本文件
- 3.61 充分利用软件的杠杆效应
- 通过软件的杠杆效应增大力
- 用较少的劳力获得巨大的成果
- 将手动作业自动化
- 3.62 活用shell脚本
- 通过shell脚本进行连接
- 加大杠杆效应
- 将shell脚本用作胶水语言
- 胶水语言
- 3.63 避开交互式用户接口
- 避开交互式用户接口
- 交互式用户接口会束缚用户、机器及软件
- 将控制权还给命令解释器
- 3.64 过滤器化
- 把软件设计成过滤器
- 软件的意义就是输入输出
- 使用标准输入输出
- UNIX哲学中的准则
- 第4章 视角～程序员的视角～
- 4.1 内聚度
- 模块要“纯粹”
- 有杂质的模块很脆弱
- 以实现高内聚的模块为目标
- 4.2 耦合度
- 模块间应“疏远”
- 相互依赖的模块很脆弱
- 以实现低耦合的模块为目标
- 混合耦合
- 耦合的个数与方向
- 幂等性与安全性
- 4.3 正交性
- 代码独立
- 正交的代码更牢固
- 代码层次化
- 层次化的好处与坏处
- 关系的正交性
- 关系的定义
- 4.4 可逆性
- 选择可以“UNDO”的方案
- 不存在所谓的最终方案
- 不依赖于特定技术
- 架构的可逆性
- 4.5 代码中的“坏味”
- 不要放过代码的凶兆
- 嗅觉是重构的必要条件
- 了解代码出现“坏味”时的征兆
- 4.6 技术负债
- 问题代码是“欠款”
- 技术负债会恶性循环
- 管理问题代码
- 技术负债用于说明代码整洁的意义
- 问题代码出现的原因
- 技术病
- 临时解决方案
- 第5章 习惯～程序员的日常～
- 5.1 程序员的三大美德
- 程序员要懒惰、急躁和傲慢
- 懒惰、急躁和傲慢可以让工作结构化
- 自动化、雏形化、模块化
- 高强度工作对程序员而言没有意义
- 5.2 童子军规则
- “打扫”完代码再离开
- 抑制代码腐烂
- 代码要改善之后再提交
- 编程讲究“稳中求胜”
- 5.3 性能调优的箴言
- “好”的代码胜过“快”的代码
- “快”的代码得不偿失
- 先写高质量的代码
- 软件的性能
- 架构的性能
- 性能调优的流程
- 5.4 无我编程
- 舍弃自我
- 抛弃自我，提升质量
- 遵守无我编程的十诫
- 自我的度
- 5.5 一步一步走
- 循序渐进
- “步步为营”更有效率
- 不一次性处理多项工作
- 思考也要一步一步来，一点一点想
- 逻辑思考的秘诀
- 5.6 TMTOWTDI
- 工具具备多样性是好事
- 对象多样方法也应多样
- 多准备一些方法
- TMTOWTDI 与简单性
- 第6章 手法～程序员的工具箱～
- 6.1 曳光弹
- 留在最终代码里的“骨骼代码”
- 在黑暗中照亮道路
- 先编写能够运行起来的基础部分
- 与原型的区别
- 原型、样品与试制品
- 6.2 契约式设计
- 调用方与被调用方的契约
- 尽早发现理解上的偏差
- 通过注释和断言缔结契约
- 不变式
- 断言
- 继续执行代码不如让软件停止运行
- 6.3 防御性编程
- 防患于未然的程序设计
- 开发与运维中的“安全驾驶”
- 路障战术
- 断言与错误处理的区别
- 错误处理的变种
- 错误处理中的“正当性”和“坚固性”
- 将输入数据转换为正确的格式
- 不忽视错误代码
- “到语言中”编程
- 6.4 内部测试
- 试尝软件的“味道”
- 从用户的角度出发
- 以用户的身份使用软件
- 6.5 橡皮鸭调试法
- 借助“说明”完成调试
- 促使自己解决问题
- 向没有生命的物品说明问题
- 6.6 语境
- 在语境中对话，结合语境思考
- 防止对话与思考失去方向
- 展示语境
- 语境与工作委托
- 语境的传导能力
- 团队要有高语境意识
- 代码通用化应注意语境
- 程序员的语境切换
- 系统思维与领域驱动设计
- 实践知识与整体优化
- 关系主义与故障应对
- 第7章 法则～编程的反模式～
- 7.1 布鲁克斯法则
- 增员等于“火上浇油”
- 人数和月数是无法交换的
- 重新制订时间表
- 生产与生孩子
- 人与人也不可交换
- 反模式
- 7.2 康威定律
- 架构服从于组织结构
- 架构以信息交流为基础
- 先设计架构再编排组织结构
- 组织结构与过程
- 7.3 破窗效应
- 不好的代码是“蚁穴”
- 不好的代码会带来邪念
- 保持代码整洁
- 人会模仿人
- 7.4 熵增原理
- 代码会自然而然地开始腐坏
- 代码会向着混乱的方向转变
- 抓住代码腐坏的征兆
- 在敏捷开发中代码不容腐坏
- 营造不允许代码腐坏的团队文化
- 7.5 80-10-10原则
- 编程没有万能药
- 编程的问题领域太广
- 工具要用在合适的地方
- 对症药比万能药好用
- 80:20 原则
- 7.6 约书亚树原则
- 没有名字的东西“不可见”
- 知道名字才知道其存在
- 使用通用语言
- 巴别塔
- 7.7 第二系统综合征
- 第二次发布总会出现功能过多的情况
- 人在适应开发后会倾向于“多功能主义”
- 考虑用户
- 第二系统后综合征
- 功能蔓延
- 7.8 重新发明车轮
- 制作已有的东西
- 不知道车轮和想制作车轮
- 关注车轮之外的东西
- 允许重新发明车轮的情况
- 7.9 给牦牛剃毛
- 抓不住问题的本质
- 问题会接二连三地出现
- 尽早收手
- 勇于面对“给牦牛剃毛”
- 编程中的“给牦牛剃毛”
- 后记
- 谢辞
- 作者简介
- 看完了
展开全部
评分及书评
4.4
5个评分
给这本书评了5.0读书新习惯，敢于做自己！读这本书，我是当作哲学来读的，惊喜地发现，任何事情，写软件，写论文，做销售，道理很相近啊。因为目的不是把该书与软体挂钩，为的是打通写程序与干其他事情的关系，我自己文字能力还不错，很快读完，受益很大。收获很大，第一，读书，要自主，独立，根据个人需要，不要被书籍吞没压垮。第二，勇于改变自己的旧习惯（应试教育的逐字逐句，分崩离析，总是微言大义，害的我根本无法整体理解和感受！根本无法阅读文学。这种还原分析的思路，皮里春秋，春秋笔法，左传思路，特别害人！！！坚决改掉。）第三，我大大增强了学习编程的信心。以后，数学建模和产品经理的书也可以读读。没有学不会的东西，成年人，有经验，有学历，不太受激素冲击，学习，更加厉害。
出版方
人民邮电出版社·图灵出品
图灵社区成立于2005年6月，由人民邮电出版社投资控股，以策划出版高质量的科技书籍为核心业务，主要出版领域包括计算机、电子电气、数学统计、科普等，通过引进国际高水平的教材、专著，以及发掘国内优秀原创作品等途径，为目标读者提供一流的内容。
