类似推荐
编辑推荐
程序员修炼代码整洁之道，101个编程原则独立成文，涵盖程序员都需要了解的编程方法、思想和习惯，指导读者进一步提升编程能力的行动指南。
内容简介
本书介绍了软件开发领域101个重要的编程原则，涉及编程中的永恒真理，指导方针，编程思想，程序员的视角、习惯和工具，以及编程的反模式等内容。
书中以“这个原则是什么”“为什么要遵循这个原则”“具体应该怎么做”为中心，对各个原则进行介绍，简明扼要，通俗易懂。这些原则凝聚了前人的智慧，经过了历史的考验，是指导程序员改善代码、进一步提升编程能力的实用指南。
本书适合各层次软件开发人员和项目管理人员阅读，也可作为高等院校计算机相关专业师生的参考读物。
作者简介
作者上田勋，毕业于日本横滨国立大学经营学部。任职于Canon IT Solutions公司，从头参与了Web应用程序自动生成工具Web Performer的开发。在担任技术负责人、技术规范负责人、架构师和设计师的同时，自己也参与编程。喜欢读书，读过的技术书不少于800本，其运营的技术书读书博客上已有超过1500条博文。
章节目录
版权信息
前言
序章 本书导读
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 给牦牛剃毛
抓不住问题的本质
问题会接二连三地出现
尽早收手
勇于面对“给牦牛剃毛”
编程中的“给牦牛剃毛”
后记
谢辞
作者简介
看完了
编程的原则是1970年由人民邮电出版社·图灵出品出版,作者[日]上田勋。
得书感谢您对《编程的原则》关注和支持，如本书内容有不良信息或侵权等情形的，请联系本网站。
