代码整洁之道

1星(超过10%的资源)
所需积分/C币:7 2018-05-31 23:14:29 914KB PDF
2
收藏 收藏
举报

代码整洁之道代码整洁之道代码整洁之道代码整洁之道代码整洁之道代码整洁之道
44.17函数头66 4418非公共代码中的 Javadoc¨66 4.4.19范例¨66 4.5文献 69 第5章格式 5.1格式的目的……2 5.2垂直格式“72 52.1向报纸学习 73 5.2.2概念间垂直方向上的 区隔 73 5.2.3垂直方向上的靠近¨14 5.24垂直距离75 5.2.5垂直顺序79 5.3横向格式¨79 5.3.1水平方向上的区隔与 靠近¨80 53.2水平对齐81 5.3.3缩进¨82 5.3.4空范围…84 54团队规则¨84 5.5鲍勃大叔的格式规则 85 第6章对象和数据结构¨87 6.1数据抽象¨87 6.2数据、对象的反对称性¨ 89 6.3得墨忒耳律 91 63.1火车失事91 6.3.2混杂¨92 6.3.3隐藏结构92 6.4数据传送对象¨93 6.5小结 6.6文献∵ 第7章错误处理¨95 7.1使用异常而非返回码¨¨ ¨96 7.2先写 Try-Catch-Fnay语句¨97 7.3使用不可控异常98 7.4给出异常发生的环境说明¨¨ 7.5依调用者需要定义异常类¨ 99 7.6定乂常规流程¨100 7.7别返回nu值¨101 7.8别传递nu值¨102 7.9小结¨103 7.10文献 104 第8章边界¨ 105 8.1使用第三方代码 106 8.2浏览和学习边界 107 83学习og4 108 84学习性测试的好处不只是 免费 110 8.5使用尚不存在的代码 110 8.6整洁的边界 111 8.7文献 第9章单元测试113 9.1TDD三定律…114 9.2保持测试整洁¨115 93整洁的测试……116 9.3.1面向特定领域的测试 语言¨118 9.3.2双重标准 119 94每个测试一个断言 121 9.5 FIRS,T 122 9.6小结¨23 9.7文献 124 第10章类¨125 10.1类的组织……126 102类应该短小…126 10.21单一权责原则 128 10.2.2内聚129 10.2.3保持内聚性就会得到 许多短小的类 130 103为了修改而组织 136 104文献…139 第11章系统¨141 11.1如何建造一个城市 142 11.2将系统的构造与使用分开 11.2.1分解main 143 11.2.2工厂¨143 11.2.3依赖注入 144 11.3扩容¨145 114Java代理 148 11.5纯 Java AoP框架 150 116 AspectJ的方面 152 11.7测试驱动系统架构 153 11.8优化决策¨¨154 119明智使用添加了可论证 价值的标准¨154 11.10系统需要领域特定语言 154 1111小结155 11.12文献¨155 第12章迭进 157 12.1通过迭进设计达到整洁目的¨157 12.2简单设计规则1:运行所有 测试¨¨158 12.3简单设计规则2~4:重构¨58 124不可重复 12.5表达力161 126尽可能少的类和方法 162 12.7小结162 128文献¨162 第13章并发编程 163 13.1为什么要并发164 13.2挑战¨165 13.3并发防御原则166 13.31单一权责原则 166 13.32推论:限制数据作 用域¨166 13.33推论:使用数据复本¨167 13.34推论:线程应尽可能 地独立 167 134了解Java库…167 13.5了解执行模型168 13.5.1生产者-消费者模型…169 13.5.2读者-作者模型 69 1353宴席哲学家 169 13.6警惕同步方法之间的依赖¨¨¨169 13.7保持同步区域微小 170 13.8很难编写正确的关闭代码¨¨170 139测试线程代码171 1391将伪失败看作可能的 线程问题 171 1392先使非线程代码可 工作¨171 13.93编写可插拔的线程 代码¨172 1394编写可调整的线程 代码¨172 13.9.5运行多于处理器 数量的线程 172 1396在不同平台上运行¨172 13.97装置试错代码 173 13.98硬编码 173 13.99自动化 174 13.10小结¨175 13.11文献¨175 第14章逐步改进 176 141Args的实现¨177 142Args:草稿¨¨183 14.2.1所以我暂停了¨…95 14.2.2渐进¨195 14.3字符串参数…197 144小结……234 第15章 JUnit内幕 235 151υUnt框架¨236 152小结249 第16章重构 Serialdate 251 161首先,让它能工作 252 162让它做对 254 163小结…266 164文献¨267 第17章味道与启发…269 171注释¨270 17.2环境¨271 17.3函数¨271 17.4一般性问题¨272 17,5java¨¨¨¨288 17.6名称291 177测试…24 17.8小结¨295 17.9文献¨96 附录A并发编程Ir¨297 A1客户端/服务器的例子 297 A.1.1服务器“297 A.1.2添加线程代码 298 A.13观察服务器端 299 A.14小结…301 A.2执行的可能路径 301 A.2.1路径数量¨ 302 A.2.2深入挖掘 303 A.23小结……305 A3了解类库 305 A3.1 Executor框架 305 A32非锁定的解决方案 306 A33非线程安全类 307 A4方法之间的依赖可能破坏并 发代码¨308 A4.1容忍错误 309 A4.2基于客户代码的锁定…309 A4.3基于服务端的锁定¨311 A.5提升吞吐量…312 A51单线程条件下的 吞吐量¨313 A5.2多线程条件下的 吞吐量¨313 A.6死锁…314 A.61互斥…315 A.6.2上锁及等待 315 A.6.3无抢先机制 315 A.6.4循环等待…¨ 315 A.65不互斥“316 A.6.6不上锁及等待 316 A.6.7满足抢先机制 317 A.6.8不做循环等待 317 A7测试多线程代码 317 A.8测试线程代码的工具支持 320 A9小结…320 A.10教程:完整代码范例 321 A10.1客户端/服务器 线程代码 321 A.102使用线程的客户端/ 服务器代码 324 附录 B org jfree date Seria dat 327 结束语 389 l 阅读本书有两种原因:第一,你是个程序员;第二,你想成为更好的程序员。很好。我们需要更 好的程序员 这是本有关编写好程序的书。它充斥着代码。我们要从各个方向来考察这些代码。从顶向下, 从底往上,从里而外。读完后,就能知道许多关于代码的事了。而且,我们还能说出好代码和糟 糕的代码之间的差异。我们将了解到如何写出好代码。我们也会知道,如何将糟糕的代码改成好 代码。 11要有代码 有人也许会以为,关于代码的书有点儿落后于时代一代码不再是问题;我们应 当关注模型和需求。确实,有人说过我们正在临近代码的终结点。很快,代码就会 自动产生出来,不需要再人工编写。程序员完全没用了,因为商务人士可以从规约 直接生成程序。 扯淡!我们永远抛不掉代码,因为代码呈现了需求的细节。在某些层面上,这些细节无法被 忽略或抽象,必须明确之。将需求明确到机器可以执行的细节程度,就是编程要做的事。而这种 规约正是代码 我期望语言的抽象程度继续提升。我也期望领域特定语言的数量继续増加。那会是好事一桩。 但那终结不了代码。实际上,在较髙层次上用领域特定语言撰写的规约也将是代码!它也得严谨、 精确、规范和详细,好让机器理解和执行 那帮以为代码终将消失的伙计,就像是巴望着发现一种无规范数学的数学家们一般。他们巴 望着,总有一天能创造出某种机器,我们只要想想、嘴都不用张就能叫它依计行事。那机器要能 透彻理解我们,只有这样,它才能把含糊不清的需求翻译为可完美执行的程序,精确满足需求。 这种事永远不会发生。即便是人类,倾其全部的直觉和创造力,也造不出满足客户模糊感觉 的成功系统来。如果说需求规约原则教给了我们什么,那就是归置良好的需求就像代码一样正式, 也能作为代码的可执行测试来使用 记住,代码确然是我们最终用来表达需求的那种语言。我们可以创造各种与需求接近的语言 我们可以创造帮助把需求解析和汇整为正式结构的各种工具。然而,我们永远无法抛弃必要的精 确性一所以代码永存 12糟糕的代码 最近我在读 Kent beck著 Implementation Patterns(中译版《实现模式》)一书的序言。 他这样写道 本书基于一种不太牢靠的前提:好代码的确重要……”这前提不牢靠?我反 对!我认为这是该领域最强固、最受支持、最被强调的前提了(我想Kent也知道)。我们知道好 代码重要,是因为其短缺实在困扰了我们太久。 20世纪80年代末,有家公司写了个很流行的杀手应用,许多专业人士都买来用。然后 发布周期开始拉长。缺陷总是不能修复。装载时间越来越久,崩溃的几率也越来越大。至今我还 记得自己在某天沮丧地关掉那个程序,从此再不用它。在那之后不久,该公司就关门大吉了 20年后,我见到那家公司的一位早期雇员,问他当年发生了什么事。他的回答叫我愈发恐惧 起来。原来,当时他们赶着推出产品,代码写得乱七八糟。特性越加越多,代码也越来越烂,最 后再也没法管理这些代码了。是糟糕的代码毁了这家公司。 你是否曾为糟糕的代码所深深困扰?如果你是位有点儿经验的程序员,定然多次遇到过这类 困境。我们有专用来形容这事的词:沼泽( wading)。我们趟过代码的水域。我们穿过灌木密布、 瀑布暗藏的沼泽地。我们拼命想找到岀路,期望有点什么线索能启发我们到底发生了什么事;但 目光所及,只是越来越多死气沉沉的代码 你当然曾为糟糕的代码所困扰过。那么一为什么要写糟糕的代码呢? 是想快点完成吗?是要赶时间吗?有可能。或许你觉得自己要干好所需的时间不够;假使花时间 清理代码,老板就会大发雷霆。或许你只是不耐烦再搞这套程序,期望早点结束。或许你看了看 自己承诺要做的其他事,意识到得赶紧弄完手上的东西,好接着做下一件工作。这种事我们都干 我们都曾经瞟一眼自己亲手造成的混乱,决定弃之而不顾,走向新一天。我们都曾经看到自 己的烂程序居然能运行,然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日 再回头清理。当然,在那些日子里,我们都没听过勒布朗( Leblanc)法则:稍后等于永不(Lat er equals never)。 13混乱的代价 只要你干过两三年编程,就有可能曾被某人的糟糕的代码绊倒过。如果你编程不止两三年, 也有可能被这种代码拖过后腿。进度延缓的程度会很严重。有些团队在项目初期进展迅速,但有 那么一两年的时间却慢如蜗行。对代码的每次修改都影响到其他两三处代码。修改无小事。每次 添加或修改代码,都得对那堆扭纹柴了然于心,这样才能往上扔更多的扭纹柴。这团乱麻越来越 大,再也无法理清,最后束手无策。 随着混乱的増加,团队生产力也持续下降,趋向于零。当生产力下降时,管理层就只有一件事可做了:增加 更多人手到项目中,期望提升生产力。可是新人并不熟悉系统的设计。他们搞不清楚什么样的修改符合设计意图, 什么样的修改违背设计意图。而且,他们以及团队中的其他人都背负着提升生产力的可怕压力。于是,他们制造 更多的混乱,驱动生产力向零那端不断下降 00 6 时间 图1-1生产力vs时间 131华丽新设计 最后,开发团队造反了,他们告诉管理层,再也无法在这令人生厌的代码基础上做开发。他 们要求做全新的设计。管理层不凨意投入资源完全重启炉灶,但他们也不能否认生产力低得可怕。 他们只好同意开发者的要求,授权去做一套看上去很美的华丽新设计。 于是就组建了一支新军。谁都想加入这个团队,因为它是张白纸。他们可以重新来过,搞出 点真正漂亮的东西来。但只有最优秀、最聪明的家伙被选中。其余人等则继续维护现有系统。 现在有两支队伍在竞赛了。新团队必须搭建一套新系统,要能实现旧系统的所有功能。另外, 还得跟上对旧系统的持续改动。在新系统功能足以抗衡旧系统之前,管理层不会替换掉旧系统。 竞赛可能会持续极长时间。我就见过延续了十年之久的。到了完成的时候,新团队的老成员 早已不知去向,而现有成员则要求重新设计一套新系统,因为这套系统太烂了 假使你经历过哪怕是一小段我谈到的这种事,那么你一定知道,花时间保持代码整洁不但有关效 率,还有关生存。 132态度 你是否遇到过某种严重到要花数个星期来做本来只需数小时即可完成的事的混乱状况?你是

...展开详情
试读 60P 代码整洁之道
立即下载 身份认证后 购VIP低至7折
一个资源只可评论一次,评论内容不能少于5个字
东晨雨 完全是骗积分
2019-04-22
回复
您会向同学/朋友/同事推荐我们的CSDN下载吗?
谢谢参与!您的真实评价是我们改进的动力~
上传资源赚钱or赚积分
最新推荐
代码整洁之道 7积分/C币 立即下载
1/60
代码整洁之道第1页
代码整洁之道第2页
代码整洁之道第3页
代码整洁之道第4页
代码整洁之道第5页
代码整洁之道第6页
代码整洁之道第7页
代码整洁之道第8页
代码整洁之道第9页
代码整洁之道第10页
代码整洁之道第11页
代码整洁之道第12页

试读结束, 可继续读6页

7积分/C币 立即下载