• Feeds

  • Archive for June, 2010


    Web 2.0技术沙龙设想

    到北京后做了不少代码堆砌和纸上谈兵的架构设计工作,有点怀念之前搞的珠三角技术沙龙。由于北京技术方面活动也不少,如果有一些互补的Topic就锦上添花了,看到杭州一些垂直的技术或产品论坛就非常不错,因此打算在北京也组织一些专业的垂直话题,由于近期工作和微博架构及平台有关,考虑到国内很多新兴的web 2.0网站或应用也是微博或者facebook这样的方向,大家面临的技术问题类似,如果能组织一些交流可能对社区更有帮助。

    Social platform话题

    • Feed架构, 讨论feed在微博及sns如何高效的投递
    • Cache, RAM is the new disk, cache使用近几年已经发生了不少变化,可以进一步探讨cache架构如何设计
    • 分布式key value面临的挑战,如尝试cassandra心得
    • Realtime search
    • Social数据分析(如hadoop)

    Social app话题

    Social app方面我也不太擅长,不过公司有不少开发无线以及产品设计的geek在闲聊中比较有兴趣,先列进来,效果不好随时cancel。

    • HTML5 app
    • LBS (Location-based Services) 技术
    • OAuth 前几天在微博上戏称OAuth是一种典型的过度设计,用于解决非HTTPS环境第三方受信问题。

    主要考虑在北京搞,Twitter上立即有不少回应表示意向,有兴趣的可以进一步交流。联系方式可看博客首页或者关于页。

    程序员修炼之道-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