内容选取

大部分都是接近工作的，比如应用层如何访问cache及db、当前项目的重构或某个复杂的算法等。比如一个重构的话题让大家找出项目中目前不合理的若干问题，并分析这些问题存在的历史原因。然后大家分别发表自己认为合适的解决方案并进行讨论。

可以取得的成效

• 团队成员取长补短，获得更全面的技术
• 分享经验，避免成员步入已知的雷区
• 提高分析技术问题的能力
• 认识不足，找到自己需要提高的方向
• 达成团队更多共识，比如什么是好的做法什么是不推荐的做法

后续主题

以后可以进一步考虑的讨论主题，最大的原则是考虑跟近期项目有相关性，比如

• 互联网应用合适的压力测试方式
• profiler 系统性能分析，热点调用的主要消耗点并提出解决方案。
• 工具介绍，可以提高效率或者对工作有帮助
• 某个算法，如粉丝排序

与code review的区别

code review关注代码细节, 团队讨论更关注宏观抽象层面的问题，但部分时候团队讨论也进行一些有代表意义的code改进。

与主题演讲区别

倾向于圆桌式的讨论，需要大家参与的开放式问题。以前也尝试过主题式的，但是由于团队内的主题演讲空间有限，演讲者可能要先精通某个领域才适合讲，如果每周一轮不太可行，比如Facebook Engineering tech talks也是精英演讲的方式，结果也不是非常活跃。因此每周一次更合适讨论一些跟工作相关未达成共识的话题，这样更敏捷，也更容易给参与者带来成效。

-EOF-

广告：我们团队招收各层次技术人才，包括Java后端工程师，数据架构师(MySQL)，PHP工程师, 数据挖掘工程师(如精通Hadoop)等，工作地点是北京，有兴趣可以直接给我邮件。

上次提到的Web 2.0技术沙龙已经与CSDN顺利举行了第一期，由于之前报名的已经非常多，就未在博客上宣传了，第一期活动今天已经结束。

• 广州技术沙龙安排
• 做卓有成效的程序员
• 广州技术沙龙设想
• 为什么优秀开发者进入Google后就不参与开源了
• Web 2.0技术沙龙设想

大部分章节是介绍具体的方法来如何提高程序员工作效率。记住具体的技巧未必有太大价值，很多人都认同一种观点就是，读一本书最终的目标是忘记其中所有的观点，但是它会潜移默化影响了你以后的思维和或观点，包括你的行为。因此我认为此书直接的影响就是帮助思考开发过程的方法和问题，思考以前的惯例是否存在问题。比如最近在设计某个产品删除功能的时候，一位同事突然提到是否产品将来有需要查看行为历史，如果需要记录历史，删除的流程就会变复杂，不但影响删除功能的实现，还会影响后端数据的规模，从而进一步会影响架构的设计。因而我的直觉是这是一个过早优化，也就是书中第9章讲的YAGNT(You Ain’t Gonna Need It 你不需要这个特性)。由于第一时间的质疑，这个可能需要耗费大量开发时间的特性被暂停，对于项目本身或许是一件好事。

此外书中一些敏捷的思路也会带来一些间接影响,我还意识到过去一些非敏捷方法可能会给项目带来风险，一个过去的项目，开发完成之后逐渐变得臃肿，和大部分后端服务相似，需要依赖一些特定的数据库及其他依赖环境。由于不希望开发环境与真实环境差距太大，开发环境也全部按真实环境最小单元的配置来进行，这就导致开发依赖的环境很多

内部依赖
MySQL master/slave
分表
Memcached(多个)

外部依赖
Message Queue(消息队列)
用户及鉴权服务
internal HTTP service

导致的问题
需要特定的环境才能开发，比如公司配好的环境中
无法在家中或咖啡馆干活，因为系统跑不起来，无法看到效果
一旦部分依赖环境有问题，则无法开工，只能等着服务恢复
一旦几天没跟进代码，可能就由于环境设置的变化而无法独自启动工程。

这些问题就导致代码改进的工作令人生畏，要像Google那样做到任何对代码感兴趣的人可以patch代码的意愿都会变成”mission impossible”。因此对于这个项目来说，最急需的一个改进是分析依赖，让项目能够随时随地可以方便的跑起来，大家可以很简单的改进代码，对改进的代码进行测试验证，测试之后新的代码基本可以无风险的运行到线上环境去。否则臃肿的项目只会降低大家的贡献的热情，最后变成一个死气沉沉的工作任务。

你的项目中的惯例是否存在问题呢？比如Java中POJO中无用的get/set方法，比如一些使用c/c++来“优化”项目中的瓶颈而走向时间泥潭的经历，比如贵公司是否又在雄心勃勃要做一个自己的框架，事实上这个框架对于项目本身毫无价值。诸如此类的情况会非常多，这本书主要介绍的是程序员要如何提高自身的效率，但我觉得程序员更多的也应思考团队的效率改进并发出声音。

• 为什么优秀开发者进入Google后就不参与开源了
• 程序员修炼之道-DRY与巧合编程
• 谈团队每周技术交流
• FarmVille(美版开心农场)谈架构:所有模块都是一个可降级的服务
• 谈Linux内核定时器

网络模型研究，09年做的的C, Erlang, Java and Go Web Server performance test得出了一些实验室的结论，打算继续观察各种网络模型在大并发真实网络慢连接的情况下表现的差异。打算比较Scala, Java, Erlang and Go. 关注点也是throughput, latency以及代码的可扩展性及可维护性。

分布式，打算尝试哪些分布式的理论可以适合国内公司使用，而不仅仅作为实验室产品。初步关注点是Cassandra。

比较微博客的一些架构设计模式，不同的设计模式比如推拉方案在high load下的throughput, storage, bandwidth, latency之间的差异。可以利用一些开放的模型来如Jaiku来分析。由于这个研究跟目前公司某产品有关联关系，所以暂时不适合作为公开研究。

由于计划做得越长，出洋相的机会就越大，先暂时想到这么多。

以上几点特点都是一些纯兴趣的东西，未必是有前途或者“钱途”的方向。根据本人从业观察，对前途和“钱途”研究比较透彻的同学在技术行业三五年之后通常就改行干别的去了。我也奉劝有这样想法的同学，改行趁早，技术的从业经验对你以后从事别的行业并没有太大的帮助，而且后来的人要维护你留下的一堆不太优雅的代码也不容易。

• 2010年的技术架构建议
• 广州技术沙龙设想
• 第一期广州技术沙龙活动总结
• 第一期广州技术沙龙预告
• C, Erlang, Java and Go Web Server performance test

技术人员的学习与实践有三个层次

第一层次 了解专业知识与原理

作为一名汽车设计师，在正式上岗之前，首先要了解汽车的各种原理。如引擎、燃料、悬挂，制动、碟鼓，ABS，风阻，油耗，安全防撞等知识，设计汽车目标并不仅是制造一个漂亮的外壳或者让轮子转起来。相反它一个有机的整体，一个系统的工程，你必须有综合的了解才能进行下一步。

软件技术也是如此，在入行之前，我们要了解计算机基础知识、操作系统、内存、网络、协议、TCP/IP、数据库/SQL、存储、数据结构、Web，HTML等专业知识。对于每一种知识你要知其然并知其所以然。比如HTML你不能只象一般的IT人员那样简单的知道它是一种描述网页的语言，而是要知其所覆盖范围，其所长和不所长，为什么有了HTML还要用JavaScript/Flash。

这个层次主要主要目标是知其所用。大部分技术人员应该不局限于长久停留在这一阶段。

第二层次 掌握工具、搭造环境

在汽车设计领域就是你的汽车模型建造工具，验证环境，测试工具，分析工具。你要能清晰的知道它们的特性，了解它们的限制及如何去规避。在软件领域，工具主要是指计算机语言，它是你制造原型及最终产品的工具。不同的场景适合不同的工具，合适的工具能帮助你如虎添翼，但语言也并不是多多益善，通常精通2-3种足矣。了解多种不如精通一种。除了工具还要建立自己得心应手的环境，就像比亚迪要建造自己的的汽车试验场一样，有了合适的环境，才能让你能高效的设计，开发，测试及验证。Jon Bentley，世界著名计算机科学家，被誉为影响算法发展的十位大师之一，他在《编程珠玑》中提到贝尔实验室的环境对他成就的巨大帮助

I came to the Labs because I enjoy balancing the theoretical and the applied, because I want to build products and write books. The pendulum has swung back and forth during my years at the Labs, but my management has always encouraged a wide range of activities.

能熟练使用工具只是对开发人员最低的要求，代表你有能力开发软件产品。但是你是满足一辈子都是重复造一种QQ车还是有更高的追求。比如在国内，某些行业几乎和10年前没什么区别，比如在企业管理应用领域，10年前用VB/Delphi做企业应用，大家都在谈人脉和关系在项目中的关键作用。10年后不用Delphi了，改用Java/SSH，其它一切如旧。这样的领域，开发人员和打一辈子铁的铁匠没什么区别，大家都是把活干得更熟了，除此之外，所获寥寥。

第三层次 学会设计
这时应跳出语言之争与语言迷恋，语言的细节了解得再多，也只是一名工匠，大部分优秀的应用只用到语言及框架不到1/3的特性。你应该寻找有价值的领域深入研究， 就如乔布斯所说

你的工作将填满你的一大块人生，唯一获得真正满足的方法就是做你相信是伟大的工作，而唯一做伟大工作的方法是爱你所做的事。如果你还没找到这些事，继续找，别停顿。尽你全心全力，你知道你一定会找到。而且，如同任何伟大的关系，事情只会随着时间愈来愈好。
所以，在你找到之前，继续找，别停顿。

首先应达到在单个专业领域能够游刃有余，比如如何设计一个简单的网站爬虫。注意有兴趣的设计与干活完成任务的重大区别，你设计的每个产品，它不单是个工作任务，而应该把它看作一个艺术品，这样才能保证你能不断的进步。注意不单要完成功能，否则永远无法达到更高境界。

下一步设计相对更全面领域的产品，比如考虑一个游戏服务器的方方面面或可以设计一个类twitter系统。慢慢的，你才会有自己积累的东西。

最后, 什么是开发人员有意义的方向？
从汽车行业来看，主要任务是学习国外先进公司的经验，在关键领域缩小与其差距，软件开发领域看来也是如此。有些领域虽然高深和有趣，但如果行业暂时需求不大，专注这方面研究难免敝帚自珍。研究业界有需求的领域并寻找有应用需求的场合方可达到开放人员价值的最大化。比如在热门的云存储云计算，虚拟化到不太热门的数据挖掘等都存在一定的空白去填补。最好是在有需求有环境的公司内开展。国内科研机构做表面文章的太多，因此感觉不是合适的场地。

只有找到你感兴趣的方向，才会达到王国维说的第二境界，“衣带渐宽终不悔，为伊消得人憔悴”。至于更高境界，自然是水到渠成。

在这个社会里，你只有做出令人尊敬的产品，才能赢得认可。就像Mini设计在汽车行业流芳百世的榜样，在技术行业里，学识，名望，人脉，金钱带来的价值都是可估量的，不可估量的是对行业留下的创新设计，让你无愧于工程师这个称号。

2009/9/3 on blackberry
(第一次写说教类的东西，由于视界及眼光高度有限，难免思路局限，仅供自勉)

广告：广州技术沙龙已经创建Google Group讨论组，主要关注广州及华南地区技术讨论及线下活动组织，欢迎加入

http://groups.google.com/group/guangzhou-tech-party

• 2010年技术实践计划
• 2010年的技术架构建议
• 为什么优秀开发者进入Google后就不参与开源了
• 5%的神话(关于开发效率与职业方向)
• 国内开放API平台实践的一些问题

Punch Party源于台湾的一种geek聚会，经过2008年网志年会后逐渐被国内的一些团体所接受，它的官方网站这样介绍的

Since 2007.12.01
由數位文化協會所發起舉辦的定期網路聚會，廣邀在部落格上書寫的bloggers上台分享不設限的主題，講員上台簡報形式以輕、快、短、小為原則，期望藉由PP來挖掘出更多在網路上隨手俯拾即是、卻又容易被遺落錯過的精采人事物。

│Punch Rules!
1. 20X20系統－
每個講員將用20張簡報，每張簡報僅有20秒，也就是每人只有6分40 秒的上台時間，一位講員最長以7分鐘為限，時間到，就以任天堂紅白機的金幣轟下台!

2. What are you doing
PUNCH會不定期設定一個活動精神，讓講員依據主軸藉題發揮。若無特定主題，即自由分享你是誰、你曾經做過什麼、你正在做什麼、你想做什麼、為什麼你要做這些事…任何關於工作、關於生活、關於夢想、關於自己，以輕鬆愉快的派對方式展現自己的精采分享。

今天的活动也分为7个话题，每个限7分钟，属于非常典型的Punch Party，话题非常具有多样性。比如周陟(Lytous Zhou)《人人都是设计师》就让我对设计产生了不少兴趣，觉得自己也在某方面具有设计的才能。GuangYao的国内企业缺乏创新的话题也值得大家反思。其他每位嘉宾的演讲都非常精彩，具体的内容可参看它的blog后续报道。

回去的路上我在想，Punch Party对于各种演讲型活动及专业聚会具有什么样的价值？7分钟的限制是否过分追求形式？因为从现场来看讲师的精彩部分都只能集中在前6分钟，6分钟提醒一到，演讲者的思路实际上是会被打断，紧急刹车迅速收场。因此一个成熟的Punch Party实际是需要讲师提前自行彩排，以便抓住重点，梳理观点，准确的传达最需传达的理念。准备不足的讲师往往会出现虎头蛇尾的局面。只有演讲者不断提炼及整理思路才能取得理想的效果。因此7分钟是否会造成对演讲者锻炼的价值大于听众接受传播的价值？讲师如果准备不充分，听众7分钟实际上全都浪费，而不是节约了大家的时间。

传播的内容上，感觉Punch Party适合传播新奇短小的知识类型的话题，比如简介一个新发起的慈善活动，科普知识，演讲者当前正在研究的课题等。个人认为过于专业、说教以及信息量太大的话题不适合在这种场合讲。北京的open party我没参与过，但是看介绍是由参会者投票选主题，然后趣味相投的一帮人进入一个小屋子深入交流，这样的设计对于专业的话题可能更适合。

不管你是哪个行业的人，只要周末有空，可以去参加Punch Party，拓宽你的视野，接触一些你平时永远都不会听到的新奇思想，这就是Punch Party最大的魅力。但是也不要期望过高，Punch Party相对那些专业的活动，它只是一个甜品，而不要期望把它当作主菜。

• 广州技术沙龙设想
• 第一期广州技术沙龙活动总结
• 谈团队每周技术交流
• Web 2.0技术沙龙设想
• 广州技术沙龙安排