优良软件架构基石--高质量代码

®

优良软件架构基石-高质量代码

Evolve by case

Topic

源代码就是设计 是谁把代码变烂 技术债务与破窗效应 代码评价标准-价值观 重构-改善既有代码 代码管理之道

软件设计与建模 在最近的10年中，很多人都在提倡模型构建，包括Ivar Jacobson,他宣称：“软件开发就是模型构建”。 对于模型的关注阻碍了软件的开发。构造模型不是项目的目的。

设计与施工的分离害了软件工程 设计看做软件开发的关键环节,而把编程看做机械式的低级劳动.设计就像画工程图纸而编码就像施工.但是这是错误的!!!!!软件的可塑性更强,而且完全是思想产品. 一些项目中，设计也许可能会详细到能够让编码工作近乎机械化，但很少有如此完整的设计——程序员(指编程)通常也要对部分程序进行设计，也许是正式的，也许不是。 有了设计,我可以编程更快,但是其中充满小漏洞---Alistair Cockburn

木桶原理---代码成为了我们的短板

Topic

源代码就是设计 是谁把代码变烂 技术债务与破窗效应 代码评价标准-价值观 重构-改善既有代码 代码管理之道

Why Code became bad? It might began with something good But after several versions, it becomes bad Original functionality becomes hidden

Topic

源代码就是设计 是谁把代码变烂 技术债务与破窗效应 代码评价标准-价值观 重构-改善既有代码 代码管理之道

(Break破窗效应(Break Pane Law) 破窗效应：没修复的破窗，导致更多的窗户被打破。所谓“破窗效应”,是关于环境对人们心理造成暗示性或诱导性影响的一种认识。“破窗效应”理论是指：一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙的被人打破；一个很干净的地方，人会不好意思丢垃圾，但是一旦地上有垃圾出现之后，人就会毫不犹疑的拋，丝毫不觉羞愧。这真是很奇怪的现象。

惯性定律 简而言之，好的代码会促生好的代码，糟糕的代码也会促生糟糕的代码。别低估了惯性的力量。没人想去整理糟糕的代码，同样没人想把完美的代码弄得一团糟.

技术债务(Technical Debt ) 开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案，但从长远来看，这种方案会带来更消极的影响，亦即开发团队所欠的债务。 Ward Cunningham

烂代码对公司的伤害--1

烂代码对程序员的伤害--2 "破窗理论"与"变成惯性理论"有着宏观的联系。 编程社区就好像一个现实社区。每个作品都是一个开发者的缩影。如果你不去努力编写优秀、整洁和稳定的代码，那你每

天都将和糟糕的代码相伴了。 从此养成的一种恶习,到时你想改正的时间都很困难,这是已经成为一种习惯.

Topic

源代码就是设计 是谁把代码变烂 技术债务与破窗效应 代码评价标准-价值观 重构-改善既有代码 代码管理之道

What is good code?

编程价值观 价值观是编程过程的统一支配性主题.有3个价值观: 沟通---珍视与他人沟通的重要性 简单—把多余的的复杂性去掉 灵活-保持开放,应对变化 ----Kent Beck语。

代码要人能够读懂-Martion Fowler 任何一个傻瓜都能写出机器能懂的代码，好的程序员应该写出人能懂的代码 Martin Fowler《重构》

案例-某电信设备项目代码复杂表达式

随着年龄的增长，我逐渐意识到编程不仅仅是让程序运行而已；编程是创造一个易于理解的、可以维护的、高效的作品。一般来说，干净整洁的代码，往往运行起来更快。这与流行观点正好相反。而且即使它们不快，也可以很容易地让它们变快。正如人们所说的，优化正确的代码比改正优化过的代码容易多了。 Google公司首席Java架构师Joshua Bloch

Bjarne Stroustrup, inventor of C++ and author of The C++ 我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。

Grady Booch,Object Oriented Analysis and Design with Applications 整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句

Topic

源代码就是设计 是谁把代码变烂 技术债务与破窗效应 代码评价标准-价值观 重构-改善既有代码 代码管理之道

重构的定义 使用一系列的重构准则，对软件内部结构的一种调整，目的是在不改变软件之可察行为的前提下，提高可理解性，降低修改

成本。

重构是持续进行的,不要先编写烂代码再重构 重构是持续进行的，而不是在项目结束时、发布版本时、迭代结束时甚至每天快下班时才进行的.重构是我们每隔一个小时或

者半个小时就要去做的事情。通过重构，我们可以持续地保持代码玛尽可能干净,简单并且具有表达力.

重构是小步骤的 重构就是在不改变代码行为的前提下，对其进行一系列小的改造，旨在改进系统结构的实践活动。每个改造都是微不足道的，几乎不值得去做。但是有了这些改造叠加在一起，就形成了对系统设计和构架显著的改进。

重构面临的问题 如何发现重构点 如何去重构—重构方法 如何知道重构的目标---去除坏味道 or重构到模式 如何保证重构的正确性-单元测试

坏味道 代码坏味道(code smell),是指在代码之中潜在问题的警示信号.代码坏味道是需要重构的症状。或者潜在的问题(Potential Problem)或者缺陷(Flaw). 代码坏味道(Code Smell)-坏味道名称 症状(Symptoms)-有助于找出问题的线索 原因(Causes)-对问题如何会发生的说明 采取的措施(WhatToDo)-可能的重构 收益(PayOff)-在哪些方面有所改善 不适应情况-在哪些情况下不适用的情况

症状和治疗的手段---坏味道和对应重构技术

Topic

源代码就是设计 是谁把代码变烂 技术债务与破窗效应 代码评价标准-价值观 重构-改善既有代码 代码管理之道

持续集成

本文来源：https://www.bwwdw.com/article/moc4.html