我看“结对编程”

在公司的一个项目的第二次迭带中,团队决定尝试使用结对编程的方式。我从未尝试过这种编程方式,但仅从想像中去衡量,其实我并不喜欢这种方式,也不认为这种方式会提高我个人的工作效率,又或者对我个人成长真的有那么大的利好,以至于我们要迫不及待的去进行。但团队中几乎全部同事同时认为这是一件大好事,因此我决定还是用一天的时间去试试,去体验一把,再做定论。

当我结束一天的结对编程后,回到家里小总结了一下,虽然跟上面提到的想像中的场景不太一样,但结论仍然是:我个人对这事不太感冒。但出于这样的考虑,可能是由于初试这种工作方式,不得要领,又是戴着些许情绪的,所以结果会比较负面,我决定再去尝试一天,而且努力去适应它,但如果一天工作结束后,结果仍然很不乐观,那么我认为这是一中不好的工作方式,至少对我来说是不好的。

------------以上是周一晚上记录在google docs上的------------

今天白天我再次让自己尝试结对,一个上午的时间...我下午决定放弃结对,中午跟Team吃饭的时候,讨论到这个话题,谈到了“因人而异”,确实这个工作法真的是因人而异。

------------以上是周二晚上的记录------------

题记:今天周五,team周会,我们谈到了“结对编程”的问题,还有之前我查了一些关于“结对编程”的资料,这里我就说说我对“结对编程”这种工作方式的看法。

首先,我们要明确,“结对编程”这仍然是一个处在试验阶段的工作方法,我去查了一些学术资料,无一例外,所有的文章对“结对编程”的介绍都是持试验态度,分别介绍其优劣。另外一些文章中,虽有对“结对编程”大肆追捧的,却也在一部分,没有一边倒的迹象。但在国内的一些文章中,这个比例的确较高。

本文,我也不讲“结对编程”的优劣势,网上到处都有,稍后文章后面附上一些资料,只聊聊这一周我的感受。

在我看来,“结对编程”作为一种工作方式的诞生,是对“编程”这个工作本质的一种转移。或者说在某些变成活动中“结对”并不合适,而在另外一些则可以。“结对编程”的优势无非在于:提高代码可读性,减少项目个人依赖,降低错误率,促进个人成长。但我们看这些特性,事实上并不属于一个绝对意义,或者说纯粹意义上的编程(hack理念的编程),而是一种代码工业化的最需要具有的性质。

但这种工业化需要的性质,通过“结对”方式也不能保证达到,因为不同的程序员有着不同的工作习惯,有些人就是喜欢单独工作,不希望别人的干扰,当“结对”时,会大大降低他的工作效率和工作质量,这就适得其反了。

说道具体的工作中,往往我们容易使用一些极端做法去做事,这明显是存在问题的。例如在项目中大规模使用“结对编程”的工作方式,而没有考虑到这种仍然处在试验中的工作方式到底是否适合我们这个团队,到底是否适合团队中的每个人。

在工作方法的选择上需要因事而异,更需要因人而异,谨慎选择。

- 阅读剩余部分 -

白天看书,晚上乱画

难得一个清闲的周日,睡到中午,下午认认真真的看了几个小时书,从1点到7点,中间小睡了十多分钟,吃了一吨晚饭,其余时间都在认真读书。这个下午,充实!很爽!

晚上回来看tencent cdc的blog,突然觉得做视觉的那帮家伙太coooool了,我羡慕嫉妒恨啊...突然想到抽屉里还有一个手绘小车的坯子,于是拿出来准备画画。

可是悲剧...没有笔,于是就用记号笔+餐巾纸凑合了半面...

很不满意的效果,虽然累的够呛。

照片小贴一下:

- 阅读剩余部分 -

[译]最终一致性

前几天在网上看到了这篇amazon CTO Werner Vogels的文章,讲分布系统最终一致性的,特意翻过来,学习

Eventually Consistent – Revisited

最终一致

By Werner Vogels

http://www.allthingsdistributed.com/2008/12/eventually_consistent.html

I wrote a first version of this posting on consistency models about a year ago, but I was never happy with it as it was written in haste and the topic is important enough to receive a more thorough treatment. ACM Queue asked me to revise it for use in their magazine and I took the opportunity to improve the article. This is that new version.

一年前我首次发表这篇关于一致性模型的文章,但郁闷的是那篇文章写得太仓促,而且这个主题很大,本应该投入更多精力。ACM Queue(一本很牛B的杂志,ACM办的,http://queue.acm.org/ )希望我能够修改一下这篇文章,他们杂志可以用。我答应了他们,一举两得,这样还可以有机会去完善我的文章。以下是这篇文章的新版本。

Eventually Consistent - Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.

最终一致——在世界范围搭建一个可靠的分布式系统,就要求我们在一致性和可用性上进行权衡,取舍。

At the foundation of Amazon's cloud computing are infrastructure services such as Amazon's S3 (Simple Storage Service), SimpleDB, and EC2 (Elastic Compute Cloud) that provide the resources for constructing Internet-scale computing platforms and a great variety of applications. The requirements placed on these infrastructure services are very strict; they need to score high marks in the areas of security, scalability, availability, performance, and cost effectiveness, and they need to meet these requirements while serving millions of customers around the globe, continuously.

创建亚马逊云计算的时候我们的定位是,一个像亚马逊S3(Simple Storage Service)、Simple DB和EC2(Elastic Compute Cloud)一样的基础设施,他可以提供资源,搭建全网范围的计算平台和大量应用。对这些基础设施的要求是很苛刻的,他们需要在安全性、伸缩性、可用性、性能和性价比上都有上佳的表现,而且要知道,所有的这些要求是建立在不间断的为全球数百万用户提供服务的基础上的。

Under the covers these services are massive distributed systems that operate on a worldwide scale. This scale creates additional challenges, because when a system processes trillions and trillions of requests, events that normally have a low probability of occurrence are now guaranteed to happen and need to be accounted for up front in the design and architecture of the system. Given the worldwide scope of these systems, we use replication techniques ubiquitously to guarantee consistent performance and high availability. Although replication brings us closer to our goals, it cannot achieve them in a perfectly transparent manner; under a number of conditions the customers of these services will be confronted with the consequences of using replication techniques inside the services.

在这些服务的背后是一个存在于世界范围的庞大的分布系统。这种庞大的规模带来很多额外的挑战,由于当一个系统要处理数以万亿计的请求时,正常情况下的小概率事件在这里就可能被认为是必然事件,而且要在设计和构建系统之前就考虑到。考虑到这些系统是世界级规模的,我们无处不在使用冗余技术来保证一致性能和高可用性。虽然冗余让我们更容易达成目标,但这不是一个完美的,清晰的方法;在大量不相同的条件下,这些服务的用户将会面临服务内部冗余技术带来的不良结果。

One of the ways in which this manifests itself is in the type of data consistency that is provided, particularly when the underlying distributed system provides an eventual consistency model for data replication. When designing these large-scale systems at Amazon, we use a set of guiding principles and abstractions related to large-scale data replication and focus on the trade-offs between high availability and data consistency. In this article I present some of the relevant background that has informed our approach to delivering reliable distributed systems that need to operate on a global scale. An earlier version of this text appeared as a posting on the All Things Distributed weblog in December 2007 and was greatly improved with the help of its readers.

解决这个问题的一个途径就是在系统提供的数据一致性类型中声明自己,尤其是当底层分布式系统为数据冗余提供最终一致性模型的时候。在亚马逊设计这些大规模系统,我们使用了一系列的定向原理和大规模数据冗余的抽象关系,并且关注高可用性和数据一致性之间的取舍。本文我提到了一些有关背景,这些是我们即将应用在全球规模的分布式系统上的。本文2007年12月,较早的那个版本在读者的帮助下有了很大的提高。

- 阅读剩余部分 -

爱每一个人

从没有一个人如此突然的离开
离开的人们从未如此真实
让我不得不开始想
我们已不再是我们
生命也不再如从前那般永恒

路如此短
终点却又飘忽不定
可能就在下一个转角
在这有限的途中
善待每一个路旁的人
向每一个与你对面的人微笑
爱与你同路的人们

迈出去的每一步
是自己的,也是别人的
感谢大家与我同在
让我的路不孤独
不会再茫然时迷失
也不用害怕时来的黑暗

感恩的走接下去的路
爱每一个人

我的2009

每每年末,总是有很多想法从四处冒出来,整个一年的最后一天了,总要留下一点什么东西。

回首过去的一年,发生了很多事,自己也变了…
离开了学校,离开了那种无牵无挂的生活,走上这个操蛋的却又让人期待的社会。
学会惦记那帮曾经朝夕相处的兄弟,会觉得天南海北的聚到一起,很好。
公司动荡,换了团队,又换了团队,终于还可以做一个喜欢的工作。
中国互联网发生了很多事,本来不政治的我,开始变得忧国忧民,变得愤青起来。

回首过去的一年,也有很多事一如既往,自己还是那样…
父母身体也还健康,他们一如既往的生活着,为我操着心。
我也还是那么理想主义的相信很多东西,期待着,追求着。
周围的兄弟们还是像以前一样,会叫我老高,会跟我说一些事。

总之过去的这个2009,值得记录的东西很多,值得回忆的也很多,姑且都放进记忆吧,在这个时候,我想,感谢一些人,再去期待一个美好的2010才好。

感谢父母,给我这么多的理解和支持,让我有足够的空间按照自己的想法去成长
感谢朋友,对我如此信任,给我强烈的存在感
感谢团队,让我不用去压抑什么,而可以做自己喜欢的事
2010,我会做我能做到最好的,去感谢你们,去回报你们。

期待2010。
有能力为父母做点事情,让他们开始感觉儿子长大了。
还可以为朋友做点事情,他们的信任是应该是正确的。
能给团队带来一些变化,团队给我了那么多,我要回报。

2010,我期待一个美好的2010,一切都会向着好的方向发展,一切都会越来越好!