Browsed by
月份:2012年6月

写出更好的代码

写出更好的代码

最近想看两本书<<数学之美>>和<<暗时间>> 其实这两本书的内容都有零散的看过一些,不过当可以买到纸质书的时候,还是有很想买的欲望. 再次在看暗时间的是否不幸的我点进了这个链接: http://www.joelonsoftware.com/ 更不幸的是我点进了下面的一篇文章: The Joel Test: 12 Steps to Better Code

看了一下时间,这篇文章已经是2000年的时候写的了,在那个时候就已经用到了下面的这些技术,我只能说程序员的世界发展真的很慢,因为这些技术现在都还在用. 而且有的开发可能现在都还没有完整的run他的这些步骤.

我想来回答Joel的这些问题,在现代的一个背景下面,在我的知识范围内来看看我能想到写什么?

  • Do you use source control?

    这个必须有.如果你相对比较怀旧一点,用SVN吧. 如果你又不想依赖于中心服务器,不想看没有个commit log都要从服务器拉取,用分布式的hg 和 git. 如果想更加的现代,可以看看bitbucket.org 和 github.com. 或许这样的合作方式,是十年前没有想到的.

  • Can you make a build in one step?

    这个可以有,拿设计模式来讲我愿意把这个叫做facade.你做的越少,犯错的机会就越少.

  • Do you make daily builds?

    这个应该有.我不知道在十年前用什么工具,但是现在做这个的开源工具还是不错的,比如jenkins,buildbot

  • Do you have a bug database?

    这个必须有.很多私有的系统.开源的也不错: readmin, trac 这样的工具其实很多,对于一个团队来说,果断选择一个,尽快的熟悉起来.

  • Do you fix bugs before writing new code?

    这个应该有.就想GTD里面说的,如果一个事情在两分钟之内可以完成,为什么不马上就做呢? 我觉得作为一个开发人员怎么能够忍受最近的代码里面有bug呢?

  • Do you have an up-to-date schedule?

    这个对于开发来说貌似是家常便饭.开发人员真的很喜欢:”It will be done when it’s done!” 不要问我什么时候能完成,我真的不确定? 这篇文章还是不错的: Evidence Based Scheduling 如果现在让我来评估:经验+风险评估

  • Do you have a spec?

    这个可以有.看过别人写的spec,感觉需要有比较高度的认识才能完成,这是我需要的技能.

  • Do programmers have quiet working conditions?

    这个比较困难吧.

  • Do you use the best tools money can buy?

    best的定义其实不好说,现在很多不要钱的工具用的好同样够威力.

  • Do you have testers?

    这个问题不是在问我.不过我觉得tester还是必要的,毕竟需要术业有专攻.

  • Do new candidates write code during their interview?

    必须.

  • Do you do hallway usability testing?

    这个貌似是为GUI程序或者网页程序来的问题啊?

通过读者个感觉我必须要从理论上去解决两个问题:

1, 怎么更好的进行schecule

2, 如何写spec.

最近对编程的一些感想

最近对编程的一些感想

1, 测试很重要.

接手一堆没有测试的代码,感觉有点害怕. 现在每当拿到一个代码,喜欢干的事情就是先跑他的单元测试. 单元测试全部通过,说明什么呢? 我认为至少说明基本想要完成的功能是没有问题的.

有了测试代码,其实都可以不需要有太详细的文档了, 合适的命名,加上恰当范围的测试覆盖如果你想对代码有个基本认识应该很简单 而且你对你仅有的认识会比较有信心,写代码的人自己都在怎么用这样一些接口,自己也可以沿袭这个风格进行.

同样的,如果你要把一部分代码给别人,怎么告诉他你代码当前的状态呢?

如果你的代码有测试,那么你将会很自信.

现在我的回答会是: 我的测试覆盖90%,如果文档不能满足你的需求,麻烦你看我的测试,如果你发现了测试没有测的好功能,恭喜你这是个suprise!

2, 设计模式无处不再.

手上有本设计模式的书,一遍一遍的看,每个模式每次看都有不同的认识. 其实代码中真的已经用了很多和模式对等的东西,只是有了这么一个理论摆在这里感觉真的很方便和别人交流. 对于再次利用总结出来的牛逼设计模式,也比较能给自己信心.

3, 期待c++0x早日进入产品代码

当前产品代码中还是有大量的用到boost::function, bind, shared_ptr等,毕竟不太需要编译器对新语言的特别支持. 期待完全支持c++0x的编译器出来,期待以后产品代码中都用这些东西.现在让自己开始熟悉这些.

今天和朋友讨论了一个问题, 感觉很有意思: 什么样的特性应该或者可以被加入新的标准中?

我的一个认识就是:

一旦一个语言已经标准化,就意味着这个语言的核心集合已经确定,并且在以后的发展会考虑强烈的需求向后兼容. 所以新的标准不会加入太多的东西,而且加入的都是一些对广大开发者共同的需求,这些新加的特性要么改进语言的用法,要么适应当前业界的一个强烈需求. 而且不回break以前的代码. 比如auto, lambda, concurency. 核心语言要足够的简单(当然c++当前已经很不简单),一些更高级的用法用库来实现.比如STL, boost