分类 读书吧 下的文章

读'代码修改艺术',可观其大略

早在几个月前就从网上下载到了"Working Effectively With Legacy Code"这本书的E版,之所以下这本书是因为看到了"Legacy Code"这两个单词了,说实话当时我并不知晓这本书的价值,只是想当然的认为:这本书可能会有助我改善我所从事的项目中的"Legacy Code"。早在上个月去逛书店时,就看到了书架上的这本"修改代码的艺术",遗憾的是没有给予足够关注。在最近看到这本书译者刘未鹏的博客以及Dreamhead关于这本书的评价后,才又从电脑中找到这本书开始翻看。从与这本书几次"擦身而过"的经历来看,自己识书的能力实在是差劲。

我需要这本书,首先是因为我目前的项目中就有大量大量的"Legacy Code",所以我已经开始迫不及待的想看完这本书了。但是翻看一些后,我觉得作为使用C的开发者独观其大略即可。为什么呢?书中代码多以面向对象的语言Java或C++作为例子代码,很多细节对使用结构化语言的开发者意义不大。毕竟结构化的思想与面向对象的思想有着较大的差别。

作者提出来的修改软件的四个起因基本上大家都是应该认同的:
(1) 添加新特性;
(2) 修正bug;
(3) 改善设计;
(4) 优化资源使用。

同时作者又给出了为了减少修改行为带来的风险而应该考虑的三个问题:
(1) 我们要进行哪些修改?
(2) 我们如何得知已经正确地完成了修改?
(3) 我们如何得知没有破坏任何(既有的)东西?

在第一部分第二章的最后作者给出了一个解决这些问题的算法:
以下算法可以用于对遗留代码基进行修改:
(1) 确定改动点;
(2) 找出测试点;
(3) 解依赖;
(4) 编写测试;
(5) 修改、重构。

看完这些我觉得就可以直接进入第二部分了,作者给出了细致的、具体的面对不同情形应该如何去做。建议:在读每一个章节之前先回顾一下自己是否遇到过类似情形,自己当时是如何做的,当时的做法是否有改善的地方,哪些是值得发扬广大的,哪些是应该摒弃的,如果是现在我还会如何去做?之后,再看看Michael Feathers是如何去做的,这样效果应该是很好的。有如下这些情形值得我们去考虑:
(1) I Don’t Have Much Time and I Have to Change It 时间紧迫,但必须修改
(2) It Takes Forever to Make a Change 漫长的修改
(3) How Do I Add a Feature? 添加特性
(4) I Can’t Get This Class into a Test Harness 无法将类放入测试用具中
(5) I Can’t Run This Method in a Test Harness 无法在测试用具中运行方法
(6) I Need to Make a Change. What Methods Should I Test? 修改时应当测试哪些方法
(7) I Need to Make Many Changes in One Area. Do I Have to Break Dependencies for All the Classes Involved? 在同一地进行多处修改,是否应该将相关的所有类都解依赖
(8) I Need to Make a Change, but I Don’t Know What Tests to Write 修改时应该怎样写测试  
(9) Dependencies on Libraries Are Killing Me 棘手的库依赖问题
(10) My Application Is All API Calls 到处都是API调用   
(11) I Don’t Understand the Code Well Enough to Change It 对代码的理解不足
(12) My Application Has No Structure 应用毫无结构可言
(13) My Test Code Is in the Way 测试代码碍手碍脚   
(14) My Project Is Not Object Oriented. How Do I Make Safe Changes? 对非面向对象的项目,如何安全地对它进行修改
(15) This Class Is Too Big and I Don’t Want It to Get Any Bigger 处理大类
(16) I’m Changing the Same Code All Over the Place 需要修改大量相同的代码
(17) I Need to Change a Monster Method and I Can’t Write Tests for It 要修改一个巨型方法,却没法为它编写测试
(18) How Do I Know That I’m Not Breaking Anything? 降低修改的风险
(19) We Feel Overwhelmed. It Isn’t Going to Get Any Better 当你感到绝望时

当你看到这些具体情形的列表,眼前是否浮现出是曾相识的经历呢?"代码修改艺术"应该说是一本实用主义的书,如果你是使用面向对象语言的程序员,那你很幸运,建议你将一本"修改代码的艺术"放在你的办工桌旁,随时翻看、思考和领悟;如果你和我一样是结构化语言的使用者,也没有关系,观其大略,品其思想,细读你兴致之所在。

以上的书中文字的中文翻译部分摘自于刘未鹏的中文译文。

设计心理学

其实说到'设计心理学',自己还没资格谈,按照'疯狂的时候'里的说法'自己还不够专业',今天说到它,是另有原因的,下面道来。

周末写了一篇未完的blog,今早趁机将其补充完整并予以发布,不过在发布时发现Blogbus的一处问题:即我在发布文章页面的分类下拉框中居然找不到我若干月前就已经增加了的分类,以致我无法选择对应的分类就发布了。事后我问及Blogbus的客服小伙:TTSummer,在一番问题陈述之后,TTSummer马上联系了开发人员,很快给了我答复:Blogbus的分类列表项最多支持20个Item,接着他说他们开发人员马上就修改这个问题,将最大表项数目增加到25个。在中午十分这个问题解决了。从这件事里看得出Blogbus的客服还是很好的,表扬一下TTSummer,呵呵。

之后我也和TTSummer谈了我对这件事的想法,因为我也是软件设计开发人员,也遇到过类似的问题。我不清楚Blogbus是如何实现这个列表的,也不知道列表项目多少是否影响系统资源的占用或者影响美观之类的,也不知道Bus的设计人员为什么初始时设置了20这个数字,但是在软件开发领域有这样一条潜规则:软件开发中最大的不变量就是变化。一切皆有可能,其实我在平时开发中也是有想当然的时候,比如认为用户不能怎么做,不会怎么做,但是事实上用户是不给你面子的,他偏偏就那么做了。TTSummer反驳了我一句,也许是从他客服的角度理解的吧:'有时候给用户的更多,反而会让用户无所适从',他还说到:'这个是设计心理学的问题咯'。就这样我们谈到了设计心理学。其实后来TTSummer给我解释了他们的这个列表数目是根据一段时间运行后的统计来修改的,这也算是折衷的一个好方法。但是理论上是应该允许用户无限增加的,blogbus在分类管理页面并没有给用户明确提示只允许添加20个分类表项,那么既然没有明确说明,我添加了第21个就应该给我显示出来,这里说来说去也涉及到了与用户交互设计的这个问题,不知道算不算是'设计心理学'的范畴。

如果是Blogbus的老用户,大家都知道blogbus的后台程序做了很多次升级,其中一次就是增加了分类功能和分类批量修改工具,因为此前的blogbus只是支持Tag,而不支持分类,像我这样的用户都是用Tag来替代分类对文章进行管理的。当分类功能被推出后,我势必要对我的文章重新进行分类管理,最简洁的方法就是做Tag到分类的一一对应。而Tag一般都有很多,超过20个也是很正常的事情,这时像Bus这样只支持20个分类表项的问题就会暴露,还好那时我的分类没有这么多,所以也就没有发现该问题,呵呵。

谈到'设计心理学',TTSummer说其正在看那本有名的'The Design of everyday things',中文翻译为:设计心理学,这本书我是只有电子版的,下了之后就扔在电脑里,也没有时间看,呵呵,没有时间啊,也没什么办法。今天还和TTSummer说到:'人长大后烦心事太多了,时间就这样被肢解了,除了必要的睡眠外,留给看书的时间就太少了'这样的牢骚话。^_^

平时和TTSummer的交流应该不算少,作为Bus的用户,在交流中逐渐体会到:服务的提供者和服务使用者需要共同改进,互相体谅,做到双赢,只有服务商提供更加优良的服务,服务使用者才会得更优良的服务;服务使用者体会到优良服务后,服务提供商的口碑越好,其使用者也就会越来越多,在IT行业口碑一样很重要;相反一出现问题就骂个不停,那可决不是解决问题的正确方法。

有些文不对题,看题目好象是一篇技术类文章,其实不然啊,呵呵。

'Write Great Code'书中的一处错误

今天看中文版’Write Great Code’第3.4.4小节的时候发现作者的一处笔误,估计应该是笔误。

第3.4.4小节讲的是如何使用’位与’创建一个模-n的计数器(modulo-n counters),在其举例中,作者意图创建一个模-32的计数器,按照作者的理论,建立一个模-32的计数器,需要这样一个’位与掩码’,n = 2^5-1 = 31,31的十六进制应该是0x1f,而作者一时失误将之写成了0x3f(63d),显然这是个模-64的计数器。中文版的翻译显然也没有发现这处笔误,这里提醒大家看书时注意一下^_^。我已经在chinapub上提交了勘误。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多