博客园_Colin的技术

2012新年愿望

2012-01-08T14:17:00Z

时间就像一个杀猪刀，2011过去了，2012来了。给自己列几个目标：

工作方面：

1. 将SSL顺利发布

首要工作是将SSL的第一个版本顺利的按时发布。SSL从刚开始筹划到最终发布经历了近一年半的时间。很多兄弟为这个项目付出了心血。虽说大家都对产品平台持悲观态度，但我还是希望这个产品能够有一个不错的市场回报。

2. 提炼SSL的架构

新的一年，SSL产品可能会在新的平台上寻求一些突破，如果我继续负责这个新产品的开发工作，我希望能够将SSL的架构进行一些提炼。我希望新的平台下可以做到：

a) 在两个平台之间共享代码
现有SSL中的大多数代码进行一些提炼，就应该可以在两个平台之间共享。我希望能够做到让90%的数据层代码和80%的服务层的代码在两个平台下共享。

b) 共享代码的高单元测试覆盖
高单元测试覆盖率一直是我的一个理想，过去的项目中，总有很多的遗憾。目前SSL的结构性耦合已经比较清晰。再做一些重构，应该就可以实现更多的单元测试，高覆盖率还是完全有可能的。我希望能够在下一个版本上实现这一夙愿。

3. 完成CommentStudio，并且在项目中应用

CommentStudio将是一个开源工具，用来编辑产品的接口文档。我一直认为将产品文档揉在产品代码中不是好的方案。做这个工具是为了分离这两块，从而减少产品文档的编写和维护的工作量。

希望我能够抽出足够的时间完成这个工具。并把它在SSL产品中使用。如果效果不错，希望能够推广给其它产品团队使用。

技术方面：

1. 继续关注NodeJs

在可以预见未来，JavaScript社区会越来越活越和发达。2012年，我希望自己能够继续关注NodeJS的发展，如果可能，希望能够参与到一些开源的项目中去。为自己汲取营养，也为社区做出一些贡献。

另外，CommentsStudio将是一个基于纯JS+HTML的工具。我希望能够通过这个项目来掌握JS的使用。

2. 适当关注Android的开发

消费类电子产品的崛起是一个不争的事实，新年里还是适当的关注一下这一块。别让自己成了奥特曼。

3. 继续关注“编译即服务”

这可能是最费脑子也最有意思的部分了，不知道自己是否还有精力关注他了。

个人方面：

1. 多读书

最近才逐渐的体会到了什么是“读书可以让人快乐”。新的一年，一定要挤出时间来多看看书。尤其是《高效能人士的7个习惯》，这本书绝对是一个应该每年读一遍的好书，2012年一定要把这本书完整重读一遍。

2012年的目标，争取每个月读一本书，（什么？做不到，至少一年读4本书总可以吧 :-) ）

2. 多写博客

最近发现自己表达能力越来越差，亟待改善。2012年，争取做到每个月写一篇博客，不管内容如何，每篇写完都要复查两遍，确保自己表达的清晰准确不罗嗦。

3. 多自省

微博客的兴起，让我们独立思考的事件越来越少了。2012年，尽可能让自己多关注自己的内心。腾出更多的精力进行自省。具体的操作方法还没有想好。想好了再来更新吧。

4. 多运动

我不爱运动应该是在同事中出了名的吧，2012年开始，多多也要上幼儿园了。争取以后每天早上起来和老婆一起走路去上班。

家庭方面：

1. 每天给多多讲故事

争取做到平均每周5天吧。

2. 和多多一起完成两到三个手工

要多培养多多的动手能力，比如和他一起组装他的小床。哇嘎嘎~~想一想都让人兴奋。接下来呢，做什么还没有想好。

3. 坚持每周至少向老婆汇报一次工作

两个人在一起的时间久了，感觉共同话题越来越少了。是该有一些改变的时候了。

好了，这些就是我的2012愿望，写出来，督促自己去实现他们。无论世界末日是否属实，有目标才能快乐。努力，为了自己内心的快乐。

本文链接

100%测试覆盖率真的有用吗？

2011-05-15T06:17:00Z

背景

最近看到一篇博客，作者是一名ThoughtWorker，文中提到要在他的项目中贯彻100%单元测试覆盖率。我在留言中对100%测试覆盖提出了一些质疑。看到“透明"的回复并且阅读了他的《Why is 100% test coverage easier to achieve》（需翻墙）。有些想法，但是Blogbus的评论有字数限制。因此，贴在自己博客里面，希望和dreamhead和透明继续讨论

@透明

拜读了你的博文。翻墙确实很辛苦。对ThoughtWorks的敬仰又进一层。

但是，对你的观点依然有一些质疑。你认为没有测试覆盖的代码就是不必要的（MUDA）。例如：getter, setter。我想还有一个例外，是健壮性代码（包括必要的断言检查和容错处理）。

我认为这里存在两类问题：1. 保持接口的语义清晰。2.保持模块健壮。

对于接口的语义清晰，我认为对于产品的可维护性会很有帮助。毕竟你写的模块，应该让使用者更易用。既然我们在产品的外部接口上应该精雕细琢。没理由在内部接口上如此惜墨如金啊。

对于模块的健壮性，理论上可以通过添加最够的单元测试后达到你所说的程度（没有单元测试覆盖的代码都是MUDA）。但是，添加单元测试也是成本，很多时候，我们添加这样的容错代码仅仅是两行代码。但是，为了证明这行容错是必要的，却要花费更多的时间和精力。这样真的值得吗？我们新写的这些单元测试是不是MUDA呢？

本文链接

“外部质量”还是“内部质量”

2011-02-14T08:45:00Z

这几天看了看《硝烟中的Scrum和XP》，其中作者将产品质量分为两种——“外部质量”和“内部质量”。作者认为，在项目工期紧的时候，外部质量是可以妥协的。而内部质量是不容妥协的。但是，哪些问题属于内部质量呢？
作者并没有详细的论述这个问题。下面，我列出了一些常见的场景和划分。 你怎么看待这个问题呢？

外部质量

可扩展性
我一直认为，一个没有明确的目标的可扩展性设计往往会变成过度设计。因此，我觉得可扩展性相关的质量问题应该作为外部质量看待。敏捷中强调 做的刚够就好。
功能不完整的实现
有些时候，对某个功能模块的实现中存在 明显的 功能不完整。这一点我认为也是外部质量。因为，我们采用迭代式开发的目的就是可以逐渐的完成这个功能。但是，我认为这种功能不完整应该是 显而易见 的。否则，我认为就属于内部质量中的“逻辑严整性”和“语义清晰性”的问题了。
性能
性能优化往往会牺牲架构的简单性和代码的可维护性。而且，我个人认为从实际的产品角度来看，性能只有“能够接受”和“不能接受”的差别，而没有“好”和“不好”的差别。因此，我认为它是产品是否能够验收的一个重要指标。但不是一个我们应该时刻关注的质量问题。

内部质量

代码规范
混乱的代码意味着更加难以维护。划分外部质量和内部质量的一个重要标准是：对产品的可维护性有很大影响的质量问题应该称之为内部质量。因此，我认为代码规范为“内部质量”。
设计和实现的逻辑严整性
例如：你设计了一个集合类，就应该确保集合的基本增删改操作正确。你可以在集合的删除操作中抛出“NotSupportException”或断言错误以标示该集合是一个只增集合。但是，你不能通过忽略删除方法的实现来达到同样的目的。
另外一个逻辑严整性问题的例子是：Equals方法和GetHashCode方法实现上。你可以同时不实现这两个方法。如果实现，就一定要实现正确。不能因为目前没有需求将该对象作为Hashtable的Key，而忽略GetHashCode的实现。
一个逻辑上不严整的设计往往会对将来使用该模块的开发人员造成误导。 最终造成可维护性问题。因此参考上面的原则，我认为这一条应该归为“内部质量”。
语义清晰性
这一条和“逻辑严整性”类似。不能在方法命名等地方出现语义上的不清晰。对将来的使用者造成误导。

关于划分原则的思考

对产品未来可维护性有影响的点应该归为内部质量
正因为“可维护性”往往是一个不易被觉察的问题，我才觉得可维护性是团队最应该关注的质量问题。是不能够放弃的底线。相对而言，“可扩展性”和“可维护性”如此相似，却恰恰相反，它看起来如此美妙。但，过度设计往往都是因为对“可扩展性”的追求而导致的。它反而是我们程序员应该时刻警惕的东西。
内部质量往往比较虚，而那些清晰明确的问题或目标个人认为归为“外部质量”比较好。
人的精力是有限的，正因为这种有限性，让我们需要建立一些简单的原则来帮助我们将精力放在更重要的问题上。尽可能减少我们关注的范围，会让我们在这个范围内做的更好。因此，我觉得应该尽可能的将那些显而易见的问题排除出“内部质量”问题之外。这样，我们才能够更好的控制“内部质量”。那些显而易见的问题，其实，往往都不是问题。
性能
这一点我一直很犹豫，因为往往一个不好的架构会导致难以修复的性能问题。但是，就这个话题而言。我还是更加倾向于将性能看做是外部质量。因为它往往是显而易见的。产品的Master，Customer等等很多人会关注与这个问题上。很多时候，在产品前期准备的时候就已经提出了明确的性能要求。因此，它是一个重要的产品测量点，但是，不是“内部质量”

本文链接

使用SvrAny和InstSvr将应用程序作为Window服务启动

2010-08-13T09:59:00Z

如果你想让一个任意的执行文件以Windows Service的方式执行，可以使用微软Windows 2000 Resource Kit中的InstSrv和SrvAny来实现。

为了方便期间，你可以直接从这里下载到这两个执行文件。

第一步，你先要在系统中注册一个新的服务，并且指定服务的执行文件为SrvAny.exe。通过命令行执行如下的命令：

instsrv [服务名] c:/path/to/srvany.exe

注意你需要为自己的服务起一个唯一的名字，并且确保路径正确。

这样，通过“控制面板/管理工具/服务”打开服务管理界面，就可以看到你新添加的服务了。

接下来，需要配置这个服务来执行你指定的应用程序。这一点需要通过修改注册表来实现。在注册表“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\”目录下可以找到你新添加的这个服务。

为这个目录添加一个“项”，命名为“Parameters”。并在Parameters项下添加一个字符串值，命名为“Application ”，值为你的执行文件的完整路径。

在“Parameters”目录下添加一个新字符串值，命名为“AppDirectory”，值为你期望的执行程序的当前文件夹。一般为这个执行文件所在文件夹。

如果你需要为执行程序指定参数，可以新建一个字符串值“AppParameters” ，值为你期望的参数。

最后，你可以通过“控制面板/管理工具/服务”面板配置这个服务的更多的设置。然后启动这个服务即可。

本文链接

收到Google Wave要求，想要的留下信箱。

2009-10-30T14:03:00Z

前几天收到Google Wave的邀请。今天抽时间激活了一下。看到有一些邀请。这里放出10个。要的，请给我发站内短信息，告诉我你的邮件地址。我会以接到短信的顺序发放。强调一下：Google Wave的邀请很奇怪，并不是我给你了，你就可以得到。似乎是Google还有算法来决定是否给你。我会在留言中标明都给了谁邀请，你能不能得到就看造化了。-----------------------2009-10-...

简哲，请让我的生活简单一点。——批《输入法破局研究——联盟推广》

2009-09-14T15:31:00Z

今天看到“月光博客”转载一篇用户投稿《输入法破局研究——联盟推广》，看后让我很不以为然，在做深入的思考后，反而有种义愤填膺的感觉。于是，写了下面的文字。本想在原文中回复呢，结果，月光有字数限制。那就贴在自己博客里吧。-=-=-=-=-=-=-=-=-=-=- 不明真相的分割线 -=-=-=-=-=-=-=-=-=-=-=-简哲，你观点和你的名字正好背...

[经验总结] 关于单元测试

2009-08-26T01:33:00Z

今天看到@jeffz_cn在twitter上问：“私有方法真的不应该单元测试吗？为什么？我觉得有的组件只是逻辑复杂一些，因此会提取私有方法，并且测试这些私有方法的逻辑。如果把这些内容统统从外部“注入”，这样私有的逻辑就变公开了……但是这样难道没有过渡设计的味道吗？”。然后就想起来我在项目中推动单元测试的经过。觉得还是应该总结一...

程序员的全新全新兼职工作平台的设想。

2009-08-25T03:51:00Z

今天看到@金色海洋的《程序员的全新的兼职工作方式》一文，勾起了我一直期望实现的一个平台的想法。基于我这个人“只想不干”的特性，看来我实现和完善这个想法的可能性也很低了。这里发布出来，也许能够为别人带来好的启发。我的想法，就是建立一个《软件开发项目承接平台》。任何人都可以在这个平台上注册并发布自己的需求。任何人都可以在这个平台上注册并实现别人的需求。完成交易。听起来是不是和现...

智能播放器，也许有商业价值。

2009-08-13T01:00:00Z

几天前在路上想到一个点子，也许有些价值。和一些现有的音乐网站结合起来应该会有一个不错的发展空间。生产一个自动通过网络下载歌曲，随机播放的播放器。这个播放器会根据用户的喜好来下载音乐进行播放。（这一点，目前已经有网站实现了这个功能，为了避免成为软文，所以就不说网站名字了。这个播放器就需要利用这些网站现有的算法进行用户喜好分析）现在，山寨mp3播放器很多，大家功能基本一致，而且容量都很大。我不确定在播...

谁来代替博客园 —— C社区

2009-04-17T05:03:00Z

上一篇博客，我也掉到了首页之争中去了。这一篇，我就介绍一个可能替代博客园的社区。