最近的一些想法

最近有机会带着两个弟兄做一个老产品的技术改造。起因是测试发现产品的并发性很差,反馈回开发部门作下一个版本的改进。一查代码发现在网络通信时,原本异步的NIO,发送线程居然被强行加了wait同步等待远程返回。线程不能被释放,前端的请求被排队,吞吐量根本上不去。

这是root cause,其实进了代码里面的问题更多。于是产生了对这种feature driven development的怀疑。我曾经觉得列出 feature,做好代价估计,然后大家各自去实现的方式很理性很可控。如果宏观地看,黑盒地看,这种方式对项目管理很友好。但是最近看这种方式下开发出来的产品,问题还是很多的。当开发人员面对一个feature却缺少对产品整体架构的足够了解,他很容易倾向于用quick and dirty的方式\打补丁的方式解决问题,而忽略新feature对架构整体的挑战。长期下来,软件的功能不断演进,架构却停留在早期,维护成本越来越高,神秘的陷阱越来越多。这时,每次发布都要通过测试部门的蛮力测试,这个过程中除了修bug还要克服无数的invalid的bug。What the hell!!!

另一方面,从开发人员的角度,我认为Don’t repeat yourself是每个程序员必须牢记在心的编程行为准则。无论技术好坏,经验是否丰富,只要坚持这个原则,程序员总会趋向于做一些抽象做一些设计,我想是不会写出太让人发指的代码的。最近查看遗留代码,里面实在是太多copy/paste了。对新增的功能,甚至通过重载加copy/paste来实现。如果不能怀疑同事能力的话,只好认为这是工作态度问题了。管理者往往是不会看到这么细节的问题(其实是严重的问题)。

面对这样的系统,我最初的想法是通通推倒然后模块化。虽然考虑了工作量,可是尝试了一周还是发现老的基础根本无法剥离开,多年前的设计者根本就没有考虑模块化/解耦合的问题。有句话说得好: if you cannot split it, you cannot scale it. (对数据显而易见,对程序其实也一样)然而放弃这么大规模的久经考验的代码又不现实。这周开始又只好改变策略小步快跑,虽然不治本,但是就这个阶段来说,看到改造的效果对我们这个小组意义更大。这是在内心的洁癖和现实的局面间做的不难的取舍。

尽管困难重重,还是争取抓住这个机会能对自己有个提升。需要驱动弟兄们接受和实现自己的想法,和自个一个人闷头干是完全不同的。

Take my coffee

是coffee不是Java也不是CoffeeScript。买了两个月的咖啡机,到今天才终于把磨豆机和拉花杯都制备齐了。我上周用搪瓷缸打牛奶场面真是残不忍睹。不过我发现其实设备区别不大,蒸汽的掌握还是很重要的;牛奶的选择也很重要,鉴于家里没有其他牛奶可选,这部分跳过。蒸汽喷嘴与牛奶的举例很重要,我的咖啡机上还有个橡胶嘴我今天把它彻底扔掉了,直接用金属的喷嘴即可。按照某视频介绍,蒸汽嘴距离牛奶表面3毫米。这个距离如果太大就会导致牛奶乱喷,如果直接把喷嘴伸进牛奶我还没有尝试。

打好的牛奶就是这个样子,对不住大家的是,焦点跑了。
IMG_0647

加上我们刚喷好的咖啡
IMG_0650

就变成了这个样子
IMG_0651
(我晕,焦点又跑了)

这个算是cappuccino吗。。。

最后还有一点咖啡,不要浪费了,搞点艺术创作:
IMG_0652
焦点你最后终于来了。

去西安

除了02年在北京打了几天酱油,我还没有因为打着去玩的旗号出过远门(到镇江这里就不算远门了)。今年五一痛下决心,卷入五一滚滚洪流,抱着轻度腹胀不下火线的精神,突破了我所到达的经度下限。

View Larger Map

我坐的K560是一趟开到延安老区的车,老区人民伤不起,一路上尽给到乌鲁木齐到拉萨的车让道了。晚上在上铺作原地翻滚,发现铁皮太厚根本没有信号,为了不虚此行,早晨7点就从上面跳下来,在窗边占个座位打开GPS。抬头一看已经到了开封,不对,才到开封。
http://www.openstreetmap.org/user/Sunng/traces/1001751

到了西安已经是下午三点半,找到老支书,见到身强体壮的新版寇巨头。晚上我们就在曲江新区迷了路,冥冥之中深夜里摸到了我国第一个官二代并富二代,胡亥长眠的地方。最后还好老支书迷途知返,及时拿出诺基亚表明自己身份,与二代们划清界限,我们才又绕道大雁塔回了住处。
DSC_0018

第二天是逛城墙。逛城墙之前先说一下出发前吃的腊汁肉揪片,太好吃了,就是油有点大:我当时就指出如果是吃面条吃出高血脂脂肪肝什么的,跟那帮大鱼大肉的比起来实在是有点冤枉。扯回来,西安现存的城墙是明代以后的,保存完好,不过不大,GPS显示周长在15公里左右。从城墙的东西南北四个门上去都可以租到自行车,默认是100分钟,基本上可以很宽裕地把全程骑行下来。
http://www.openstreetmap.org/user/Sunng/traces/1001753
DSC_0025

那天天气不太好,本来想拍拍城墙上夕阳斜照点点余辉什么的,结果相机没有被淋雨已经万幸了。况且西安经度比较低,太阳落山的时间要晚不少,执着于点点余辉的话,挑个好天先去吃一顿在上城墙吧。
DSC_0035

主题来了,下了城墙我们直奔鼓楼后面的回民街。用老支书的话说,这都是硬菜,花样繁多个个顶事,瓶颈不再别处,在你的胃。去了才发现战斗力低下,我们前后去了两次,吃了羊肉馅饼、羊肉串、镜糕、桂花糕、灌汤包、小酥肉。我就不一一描述了,说得再好吃也得真正去了才能体会。去不了就看看吧:
DSC_0056
DSC_0059
DSC_0058
DSC_0067
DSC_0069
这个是卖桂花糕的大叔,pose很专业,但是遇到不专业的人拍照。大叔我对不起你啊!
DSC_0077

更多照片请移步到flickr。此外您应当理解,在这种环境下,是没有心思好好拍照的。

最后感谢老支书无微不至的接待。

"Update ${new Random().nextInt()}"

多少年没写Update体了,看Samson的Update Series都到了53了,咱就只好来这么个标题了。

  1. 头等大事,officially announce 一下艰难决定,经过慎重考虑我决定离开上海了。从09年3月第一次到上海到张江,现在整好两年的时间。一方面是获得了大城市的工作机会,另一方面也被在这里边缘的生活闹够了。于是这个悲喜交加的本命年春天决定告老还乡卸甲归田,过没有追求没有房东的土著生活。
  2. 雁过留声踏雪留痕,我在晨晖路1001号半年最大的影响就是让这里又多了两个kindle用户,其他嘛,惭愧了。。。
  3. 要说在上海有什么舍不得的话,就是这里的朋友了,同学同事真不少。有一起干活的,有一起吃饭的,有一起听歌的,各种都有,回了南京就没有这种条件了。不过其实大家在上海很忙一个月也聚不上一回,这么想的话没什么区别,赶上什么RubyConf之类的就又过来了,给沪宁线作贡献是咱的宿命。(话说今年的这些会什么时候开啊,我夏天的衣服还没有攒够呢)
  4. 新赛季中超3号就揭幕了,今年舜天队的比赛可能连电视转播都没有了,你说不回南京能行吗!!能行吗!!从96年开始,今年就是第16年了。
  5. 本来想说最近一两个月荒废得厉害,我回家以后要怎么怎么的,在这还是改为此处省去多少多少字吧。。。

Continuous Learning

一直想总结一下学习的方法,今天看到Programmer的97件事里,作者叫做Clint Shank的Continuous Learning这篇,感觉比较靠谱,跟大伙分享一下。

阅读书籍、杂志、博客、Twitter和各种网站。如果希望深入了解一个主题,可以加入一些邮件列表。这个比较基本,程序员需要有开放的、稳定的、最新的信息渠道。除了上面提的方式,我比较推荐dzone和reddit上的相关频道,这两个书签网站可以帮你过滤排序每天技术圈的热点和新闻。

如果你确实希望沉浸于一种技术,那么你需要着手写一些代码。这个不说了,如果还认为自己是Programmer的话,写一些代码是最最基本的事情。要了解一种技术,写一些代码,跑一个demo是最最基本的。

尽可能和一位导师,或者一个顶尖的家伙一起工作。尽管从任何人身上学到东西,但是你可以从一个更聪明更有经验的人身上学到完整的(a whole lot more)。这个体会比较深,刚搬进工作室的时候坐在@samson959旁边,虽然只有短短几个月,但是跟着入了门,少走了很多很多弯路。再后来在盛大也从老大身上学到不少东西。这样的机会并不是在哪里都有的。

找一位虚拟导师。这是在上一条无法满足的情况下。在Web上找一位自己喜欢的作家,订阅他们的blog。这条比较有意思,你可以拜一位网上的大牛为师,关注他的博客、Twitter以及Github,关注大牛关注的事情、做的事情。这点很有帮助,最早做前端的时候我关注过当时还在雅虎的陈贤安,后来在盛大关注过新浪的杨卫华,以前他们的博客、Twitter质量不错而且经常更新。不过现在前者转行做了苹果开发的Freelancer,后者也许是太忙了,不好找了。其实就是这样,真正牛的人几乎是没有时间做这样的分享的。技术圈毕竟不是娱乐圈,整天在twitter上大放厥词从早说到晚的往往不是你需要关注的,这需要你有一些辨别能力。

去了解你使用的框架和库。了解他们的工作原理可以帮助你更好的使用他们。如果是开源的,你可以用debugger单步跟所有的代码了解内部的工作原理,你可以看到由优秀的程序员编写和审察的代码。这也是很重要的,好在现在有了github让这变得更简单。我自己曾经花过一些时间在redis上,用gdb单步跟踪来浏览程序确实是学习的好方法,尤其是对于向C这样本身程序结构并非非常清晰的项目,通过调试器来了解程序的组织事半功倍,远远高效于单纯的阅读。

无论合适遇到问题或修正了一个bug,尽可能去了解其后真正发生的事情。可以通过Google去了解网上已经存在的相似问题。这又是很重要的一点,现在除了Google,你还可以直接到StackOverflow上去搜索、提问和解答。

分享一些东西本身就是最好的学习方法。当有人将要听你介绍或问你问题时,你会拥有很大的动力去学习。在盛大的时候,每个部门定期会有分享会,在其他很多公司肯定也有这样的活动。我也曾经去做过这样的分享,真要说收获不是这种活动搞的多成功,而是之前准备的阶段。

参加一个学习小组、本地用户组。这个我没有经验,不过各地的LUG都很活跃,一定是很多人乐在其中的。

参加会议,或者看会议录像、slides。这也很有趣,我参加的第一个活动是08年北京的Perl&PostgreSQL会议,后来在上海参加过KongfuRails,RubyConf还有Apache Road Show。不过会议上能获得什么特别有价值的东西也有限,主要还是开阔眼界,了解社区的动态,了解同行的关注点。我们还可以从InfoQ上看到SpringOne, QCon, StrangeLoop等等会议的视频,既可以了解一些技术,又可以锻炼一下听力。能够收录在InfoQ里的Session质量应该都还是不错的,除此以外,还可以通过Slideshare搜索一些特定主题的slides。

收听podcast。

使用静态检查工具提高你的代码质量。

遵循Pragmatic Programmers中的建议,并每年学习一门新的语言。至少是一种新的技术或工具。这种发散可以给你新的想法,运用在你现在的技术栈中。如果你今年还没有什么想法的话,推荐clojure或者nodejs,一个是函数式一个是全异步。(如果你已经都精通了别说我老土啊)

不要局限在技术中,了解一些你工作的领域知识,可以更好地了解需求,解决业务问题。技术的方向很多,SAP在这方面是个典型。SAP的优势不是基础技术,了解行业了解业务是SAP成功的最重要因素。这点在SAP圈子里容易有更深刻的体会,大部分技术人员更希望能够直接面对客户,了解客户的真实业务,并以此为提升自身价值的途径。

回学校返工。不用说了,从工作岗位回到学校的,一般都有明确的目标。系统地深入地学习还是得在心无旁骛的校园里。