代码整洁之道1-26

代码整洁之道1-26

推荐书及原因

• 我们永远抛不掉代码,因为代码呈现了需求的细节
• 推荐书:imlementation Patterns (实现模式) 重点提到了好代码的作用
• 推荐书:Grady Booch, Object Oriented Analysis and Design with Application(面向对象分析与设计)
• 推荐书:Lord of the Rings(指环王)非技术
• 推荐书:Micheal Feathers, Working Effectively with Legacy Code(修改代码的艺术)
• 推荐书:Ron Jeffries, Extreme Programming Installed (极限编程实施)
• 推荐书: Extreme Programming Adventures in C# (C#极限编程探险)

出现糟糕代码的主要原因:

想要快点完成,赶时间,
觉得时间不够,假如花时间整理,老板会大发雷霆,
或许不耐烦搞这套程序,期望早点结束,
或许是想着自己承诺其他事,意识到自己得赶紧完成,手上的工作

Leblanc法则:稍后等于永不(Later equals never)

• 我们会瞟一眼自己亲手造成的混乱,然后决定弃之不顾,面向新的一天.我们看到曾经的代码居然能运行,会断言:能运行总比什么都没有强,而且会认为有朝一日会回头清理的,结果…
• 团队避免前期开发迅速,后期慢如蜗牛, 这将是填坑的表现,后期的坑代价是几何倍数的增加的.
  花时间保持代码的整洁不但有关效率,还有关生存

混乱的代价

• 只需要几小时完成的却花了几周去梳理
• 之需要修改一行代码的,却需要涉及到上百个模块
• 会出现抱怨
• 需求背离了初期设计
• 叹息进度紧张
• 问题归结那些催命的经理,苛刻的用户等等
  于是出现以下情况:
• 用户指望验证需求是否在系统中实现
• 项目经理指望我们遵守进度
• 经理会捍卫需求与进度,那是他们的职责,我们则当以同等的热情护卫我们的代码

假设我们是医生,病人要求你在给他做手术前别洗手,因为那会花太多时间,
你会照办吗?本该病人说了算,但医生绝对会拒绝遵从,因为医生比病人更清楚的了解疾病与感染的风险,
医生如果按照病人说的办,将是不专业的态度.
同理,程序员遵从不了解混乱风险经理的意愿,也是不专业的做法

什么是整洁代码

• 有多少程序员,就有多少定义
  Bjarne(C++语言发明者):

我喜欢优雅和高效的代码,程序逻辑应当直接了当,
叫缺陷难以隐藏,尽量减少依赖关系,便于维护;
依据某种分层战略完善错误处理代码,性能调至最优,
省得引诱别人做没规矩的优化,搞出一堆混乱来

整洁的代码只做一件事
正如破窗理论中说的一样:

• 窗户破损了的建筑让人觉得似乎无人照管,于是别人不再关心,他们放任窗户继续破损,最终自己也参与破坏活动,在墙上涂鸦,任垃圾堆积,一扇破损的窗户开辟了大厦走向倾覆的道路.
• 在细节上花心思
• 整洁的代码从不隐藏设计者的意图,充满了干净利落的抽象和直接了当的控制语句

简单代码原则:

1. 能通过所有的测试
2. 没有重复的代码
3. 体现系统中的全部设计理念
4. 包含尽量少的实体,比如类,方法,函数等

下一篇:代码整洁之道27-41