• Feeds

  • Posts Tagged ‘DRY’


    程序员修炼之道-DRY与巧合编程

    DRY(Don’t Repeat Yourself)是架构设计中经常用到的一句话,这一原则应用非常广泛,在程序设计中同样会用到,不少代码或许不知不觉中违反了这一定义,如《程序员修炼之道》一书中就有如下一题,重构下面一段代码

    if (state == TEXAS) {
            rate = TX_RATE;
            amt = base * TX_RATE;
            calc = 2 * basis(amt) + extra(amt) * 1.05;
    } else if ((state == OHIO || (state == MAINE)) {
            rate = ((state == OHIO) ? OH_RATE : ME_RATE);
            amt = base * rate;
            calc = 2 * basis(amt) + extra(amt) * 1.05;
            if (state == OHIO)
                    points = 2;
    } else {
            rate = 1;
            amt = base;
            calc = 2 * basis(amt) + extra(amt) * 1.05;
    }

    可能很多人读此代码都有似曾相识之感,不错,我们身边不少程序员就是如此编程的。这段代码就是由于太多Repeat造成罗嗦难懂,结构复杂,维护困难。大家可能都会迅速想到两点重构方法
    1. amt, calc 可以移出来
    2. 第2个if可以拆分

    但是这样就完美了吗?4个if/else是否让人闻到一股不对劲的气味?这段程序是否还是传统结构化编程思维?if条件中state再增多程序会怎样?因此虽然是一段很短的代码,但是重构优化实际是无止境的。

    再谈巧合编程(Don’t Programmer by Coincidence),在很多项目中其实也很常见,巧合编程就是有问题的代码在开发过程中恰好能运行通过,但是运行在别的环境很容易就出问题,比如下面的C++代码

            a = 2;
            b = 3;
            if (a + b != 5) exit(1);

    什么情况会exit(1)?

    传统智慧认为,项目一旦进入编码阶段,工作主要就是机械的把设计转换成可执行语句。这种态度是许多程序低效、不可维护的最大原因。

    我们大多数人都能够几乎自动地驾驶汽车,我们不用明确的命令我们的脚踩刹车,或是命令手动方向盘,我们只是想“减速并右转”。但是,可靠的司机会不断查看周围的情况,检查潜在的问题,并且让自己在万一发生意外时处在有利的位置上。编码也是这样。

    因此开发过程质量问题非常重要, 有经验的程序员懂得如何避开前进过程中的各种雷区。Code review就是在你的驾驶过程中,由另外一名有经验的驾驶员坐在副驾的座位上,帮你纠正各种危险的驾驶习惯,避免在当时或以后踏入各种已知的雷区。

    本文读后感已先前在新浪微博发出,收到过几十条转发及评论。微博的内容或许更有灵感并及时,欢迎关注http://t.sina.com.cn/timyang

    做卓有成效的程序员

    最近阅读了《卓有成效的程序员》(The Productive Programmer) 一书,此书虽是2009年出版,但是介绍内容的价值并不会随着时间过去而降低,相信5-10年后对于大部分开发者仍然具有借鉴价值。

    大部分章节是介绍具体的方法来如何提高程序员工作效率。记住具体的技巧未必有太大价值,很多人都认同一种观点就是,读一本书最终的目标是忘记其中所有的观点,但是它会潜移默化影响了你以后的思维和或观点,包括你的行为。因此我认为此书直接的影响就是帮助思考开发过程的方法和问题,思考以前的惯例是否存在问题。比如最近在设计某个产品删除功能的时候,一位同事突然提到是否产品将来有需要查看行为历史,如果需要记录历史,删除的流程就会变复杂,不但影响删除功能的实现,还会影响后端数据的规模,从而进一步会影响架构的设计。因而我的直觉是这是一个过早优化,也就是书中第9章讲的YAGNT(You Ain’t Gonna Need It 你不需要这个特性)。由于第一时间的质疑,这个可能需要耗费大量开发时间的特性被暂停,对于项目本身或许是一件好事。

    此外书中一些敏捷的思路也会带来一些间接影响,我还意识到过去一些非敏捷方法可能会给项目带来风险,一个过去的项目,开发完成之后逐渐变得臃肿,和大部分后端服务相似,需要依赖一些特定的数据库及其他依赖环境。由于不希望开发环境与真实环境差距太大,开发环境也全部按真实环境最小单元的配置来进行,这就导致开发依赖的环境很多

    内部依赖
    MySQL master/slave
    分表
    Memcached(多个)

    外部依赖
    Message Queue(消息队列)
    用户及鉴权服务
    internal HTTP service

    导致的问题
    需要特定的环境才能开发,比如公司配好的环境中
    无法在家中或咖啡馆干活,因为系统跑不起来,无法看到效果
    一旦部分依赖环境有问题,则无法开工,只能等着服务恢复
    一旦几天没跟进代码,可能就由于环境设置的变化而无法独自启动工程。

    这些问题就导致代码改进的工作令人生畏,要像Google那样做到任何对代码感兴趣的人可以patch代码的意愿都会变成”mission impossible”。因此对于这个项目来说,最急需的一个改进是分析依赖,让项目能够随时随地可以方便的跑起来,大家可以很简单的改进代码,对改进的代码进行测试验证,测试之后新的代码基本可以无风险的运行到线上环境去。否则臃肿的项目只会降低大家的贡献的热情,最后变成一个死气沉沉的工作任务。

    你的项目中的惯例是否存在问题呢?比如Java中POJO中无用的get/set方法,比如一些使用c/c++来“优化”项目中的瓶颈而走向时间泥潭的经历,比如贵公司是否又在雄心勃勃要做一个自己的框架,事实上这个框架对于项目本身毫无价值。诸如此类的情况会非常多,这本书主要介绍的是程序员要如何提高自身的效率,但我觉得程序员更多的也应思考团队的效率改进并发出声音。