修改代码的艺术_修改代码的艺术 侯伯薇 PDF
这是一本半小时即可读完的书,内容不多,不抓细节,阅读体验挺好。书中亮点“晚点弄”等于“再也不弄”。程序员遵从不了解混乱代码风险的经理的意愿,这是不专业的做法。编写整洁代码的程序员就像是艺术家,他能用一系列变化把一块白板变作优雅代码构成的系统
这是一本半小时即可读完的书,内容不多,不抓细节,阅读体验挺好书中亮点“晚点弄”等于“再也不弄”程序员遵从不了解混乱代码风险的经理的意愿,这是不专业的做法编写整洁代码的程序员就像是艺术家,他能用一系列变化把一块白板变作优雅代码构成的系统。
糟糕代码的理由:一、需求变化背离了初期设计;二、进度太紧张,没法干好活糟糕代码的作用:一、维护周期越来越长;二、修复后无法发现的 bug 越来越多;三、最终被时间拖死了产品读与写的比例大概为10:1让代码比你看的时候更干净。
糟糕代码造成的时间/生产力曲线,如下。

糟糕代码造成的时间/生产力曲线整洁代码不同人员的定义:Bjarne Stroustrup C++之父:代码逻辑应当直截了当,叫缺陷难以隐藏尽量减少依赖关系,使之便于维护依据某种分层战略完善错误处理代码性能调至最优,省得引诱别人做没规矩的优化。
糟糕的代码引发混乱!别人修改糟糕的代码时,往往会越改越乱细节上花心思,如内存泄漏、静态条件代码、前后不一致的命名方式整洁的代码力求集中每个函数、每个类和每个模块都全神贯注于一事,完全不受四周细节的干扰和污染。
Grady Booch《面向对象分析与设计》作者整洁的代码简单直接整洁的代码如同优美的散文整洁的代码从不隐藏设计者的意图,充满了干净利落的抽象和直截了当地控制语句Dave Thomas,OTI 公司创始人,Eclipse 战略教父。
它应当有单元测试和验收测试它使用有意义的命名它只提供一种而非多种做一件事的途径它只有尽量少的依赖关系,而且要明确地定义和提供清晰、尽量少的 API代码应通过其字面表达含义,因为不同的语言导致并非所有必需信息均可通过代码自身清晰表达。
没有测试的代码不干净不管它有多优雅,不管有多可读、多易理解,微乎测试,其不洁亦可知也Michael Feathers《修改代码的艺术》作者整洁的代码总是看起来像是某位特别在意它的人写的Ron Jeffries《极限编程实施》及《C#极限编程探险》作者。
能通过所有测试没有重复代码体现系统中的全部设计理念包括尽量少的实体,比如类、方法、函数等消除重复和提高表达力让我在整洁代码方面获益良多减少重复代码,提高表达力,提早构建简单抽象命名花时间命名,因为省下来的时间更多。
如果有更好的命名,则尽快替换,这样后续读者会更加的愉悦如果命名需要注释,那么这个命名就是糟糕的不要无意义的命名前后缀如 account === accountInfo,theAccount === account,这样的就是无意义的前后缀。
特定用途的数字使用命名特指,起码好找不是么?let tempFour = 4 与 const TEMP_FIVE = 5 这样难道不是更好整理与查找么?专业程序员明确是王道,专业程序员善用其能,编写其他人能理解的代码。
类名不应该是动词方法名应该是动词或动词短语统一概念词如HTTP、Fetch、Controller、do、get、post等,不要多词同义使用解决问题领域名称命名比如做数学工具,总不能使用杀猪词吧如果混淆语境,则最好封装成class。
比如属性state,都叫这个就分不清了,套个class挺好不要乱加语境命名就是 China 的项目,还要给私有类加上 China 前缀么函数函数的第一规则是要短小第二条规则是还要更短小函数应该做一件事做好这件事。
只做这一件事尽量单一参数,不要超过三个参数。尽量保证函数有返回值,方便拓展为纯函数。少用标识参数,如true,false这种。可以干脆分裂为两个函数。同样的入参返回同样的结果。避免副作用。
脑图整理
免责声明:本站所有信息均搜集自互联网,并不代表本站观点,本站不对其真实合法性负责。如有信息侵犯了您的权益,请告知,本站将立刻处理。联系QQ:1640731186