登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

秒大刀 博客

好好学习 天天向上

 
 
 

日志

 
 
 
 

读《代码整洁之道》  

2010-10-07 19:50:27|  分类: 读书 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
[读]代码整洁之道 - 秒大刀 - 秒大刀的城堡

    封面很漂亮,观点我也是很赞同——细节之中自有天地,整洁成就卓越代码。
    讲编码和设计风格的,类型上和《代码大全》、《重构-改善既有代码的设计》、《重构与模式》等书类似。如果仔细读过此类其他的书并有时间允许,本书也是可以浏览一下的。如果以前从未读过任何讲编码设计风格的书,那就必须读了,不容错过。
    翻译的不咋地,各种语法错误,一堆人脑编译警告...
    感谢卢伟星赐书一读。


    细节之中自由天地,整洁成就卓越代码
    代码质量与其整洁度成正比
    大量工作并不在于生产而在于维护——或避免维护
    质量是上百万次全新投入的结果——而非仅归功于任何来自天堂的伟大方法
    制造上的返工导致成本上升,但重做设计却创造出价值
    应当试代码为设计——作为过程而非终点的设计

前言
    习艺之要有二:知和行。你应当习得有关原则、模式和实践的知识,穷尽应知之事,并且要对其了如指掌,通过刻苦实践掌握它

第1章 整洁代码
    将需求明确到机器可以执行的细节程度,就是编程要做的事。
    当时他们赶着退出产品,代码写的乱七八糟,特性越加越多,代码也越来越烂,最后再也没法管理这些代码了。是糟糕的代码毁了这家公司
    我们穿过灌木密布、瀑布暗藏的沼泽地,我们拼命的想找到出路,期望有点什么线索能启发我们到底发生了什么事,但目光所及,只是越来越死气沉沉的代码
    勒布朗(LeBlanc)法则:稍后等于永不
    随着混乱的增加,团队生产力也持续下降,趋向于零。
    花时间保持代码整洁不光有关效率,而且有关生存
    他们没花时间让自己做得更快
    糟糕的代码引发混乱,别人修改糟糕的代码时,往往会越改越烂
    整洁的代码只做好一件事。糟糕的代码想做太多事,它意图混乱、目的含混
    果断决绝,就事论事,没有犹豫或不必要的细节
    没有测试的代码不干净。不管它有多优雅,不管有多可读、多易理解,微乎测试,其不洁亦可知也
    应用人类可读的方式来写代码
    不要重复代码,只做一件事,表达力,小规模抽象
    语言是冥顽不化的,是程序员让语言显得简单
    读代码与写代码花费的时间比例超过10:1,写新代码时,我们一直在读旧代码。不读周边代码的话就没法写代码。编写代码的难度,取决于读周边代码的难度。
    光把代码写好还不够,必须时时保持代码整洁

第2章 有意义的命名
    名称应该告诉你,它为什么会存在,它做什么事,应该怎么用。
    如果名称需要注释来补充,那就不算是名副其实

第3章 函数
    编写函数是为了把大一些的概念拆分到另一抽象层次
    每个函数只做一件事,函数中的语句都要在同一抽象层次上
    如果每个例程都让你深合己意,那就是整洁的代码
    函数越小、功能越集中,就越便于取个好名字
    长而具有描述性的名字要比描述性的长注释好
    有足够特殊的理由才能够用三个以上的函数参数,太多的参数说明其中某些参数应该封装成参数对象了
    尽量避免输出参数
    使用异常替代返回错误码
    大师级的程序员把系统当故事来讲,而不是当做程序来写

第4章 注释
    别给糟糕的代码加注释——重新写吧
    什么也比不上放置良好的注释来的有用;什么也比不上乱七八糟的注释更有本事搞乱一个模块;什么也不会比陈旧、提供错误信息的注释更有破坏性

第5章 格式
    代码格式不可忽视,必须严肃对待。代码格式关乎沟通,而沟通是专业开发者的头等大事
    应该放弃列表式代码的对齐,如果有较长的列表需要做对齐处理,那问题就是在列表的长度上而不是对齐上
    每个程序员都有自己喜欢的格式规则,但如果在一个团队中工作,就团队说了算

第6章 对象和数据结构
    要以最好的方式呈现某个对象包含的数据,需要做严肃的思考,傻乐着乱加get和set是最坏的选择
    过程式代码,便于在不改变现有数据结构的前提下添加新函数。面向对象代码便于在不改动既有函数的前提下添加新类
    过程式代码难以添加新数据结构,因为必须修改所有函数。面向对象代码难以添加新函数,因为必须修改所有类
    Public的get和set把私有变量公开化,诱导外部函数以过程式程序使用这些变量
    对于数据传送对象,不应该将业务规则塞入其中,这会导致数据结构和对象的混杂体

第7章 错误处理
    错误处理很重要,但如果它搞乱了代码逻辑,就是错误的做法
    你抛出的每个异常,都应当提供足够的环境说明,以便判断错误的来源和所在。应当创建信息充分的错误消息,并和异常一起传递出去
    返回null,基本上就是给自己增加工作量,也是在给使用者添乱。只要一处没有检查null,整个程序就会失控。如果你打算在方法中返回null,不如抛出异常,或返回特例对象。

第8章 边界
    第三方代码帮助我们在更少时间内发布更丰富的功能
    对第三方库的学习和整合上可以采用编写学习型测试的方法,这些测试代码应该被保留

第9章 单元测试
    覆盖了生产代码的自动化单元测试程序组能尽可能的保持设计和架构的整洁
    测试带来了一切好处,因为测试使改动变得可能
    如果测试代码不干净,你改动代码的能力就有所牵制,而你也会开始失去改进代码结构的能力。测试越脏,代码就会变得越脏。最终,你丢失了测试,代码开始腐坏。
    每个测试一个断言,每个测试一个概念。

第10章 类
    系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责,只有一个修改的原因,并与少数其他类一起协同达成期望的系统行为

第11章 系统
    复杂要人命,它消磨开发者的生命,让产品难以规划、构建和测试
    延迟初始化/赋值只是一种优化手段,而且可能是一种不成熟的手段
    “一开始就作对系统”纯属神话。我们应该只去实现今天的用户故事,然后重构,明天再扩展系统,实现新的用户故事
    软件系统和物理系统可以类比,它们的架构都可以递增式的增长,只要我们持续将关注面恰当的切分
    最好是授权给最优资格的人
    延迟决策至最后一刻,能够基于最有可能的信息作出选择。提前决策是一种预备只是不足的决策
    无论是设计系统或单独的模块,别忘了使用大概可工作的最简单方案

第12章 迭代
    使设计简单的规则:(按重要性排序)
        运行所有测试
        不可重复
        表达了程序员的意图
        尽可能减少类和方法的数量
    不可测试的系统即不可验证,不可验证的系统绝不应部署
    测试消除了对清理代码就会破坏代码的恐惧
    下一位读代码的人最有可能就是你自己
    多少尊重一下你的手艺吧。用心是最珍贵的资源

第13章 并发编程
    对象是过程的抽象,线程是调度的抽象
    并发防御性编程原则
        分离并发相关代码与其他代码
        谨记数据封装;严格限制对可能被共享的数据的访问
        可以考虑复制对象并以只读方式对待
        尝试将数据分解到可被独立线程(可能在不同处理器上)操作的独立子集
    不要将系统错误归咎于偶发事件

第14章 逐步改进
    毁坏程序的最好方法之一就是以改进之名大动其结构。有些程序永远不能从这种所谓的“改进”中恢复过来。问题在于,很难让程序以“改进”之前的方式工作
    代码能工作还不够,能工作的代码经常会严重崩溃。满足于仅仅让代码能工作的程序员不够专业
    没什么能比糟糕的代码给开发项目带来更深远和长期的损害了。进度可以重订,需求可以重新定义,团队动态可以修正,但糟糕的代码只是一直在发酵,无情的拖着团队的后腿。
    不要匆匆的搞出一片代码沼泽,从此之后命运再也不受自己控制
    保持代码持续整洁和简单,永远不让腐坏有机会开始

第15章 JUnit内幕
    模块都能再改进,我们每个人也有责任把模块改进得比发现时更整洁

第17章 味道与启发
    让注释传达本该更好的在源代码控制系统、问题追踪系统或任何其他记录系统中保存的信息,是不恰当的。注释只应该描述有关代码和设计的技术性信息
    值得编写的注释,也值得好好写。如果要编写一条注释,就花时间保证写出最好的注释,字斟句酌
    较低层次的概念和较高层次的概念不应该混杂在一起
    如果你找到死代码,就体面的埋葬它,将它从系统中删除
    让程序可读的最有力方法之一就是将计算过程打散成在用有意义的单词命名的变量中放置的中间值
    对于给定的选择类型,不应有多于一个的switch语句。在那个switch语句中的多个case,必须创建多态对象,取代系统中其他类似的switch语句
    不要用匈牙利命名法污染你的名称


  评论这张
 
阅读(2230)| 评论(2)

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018