十年生死两茫茫，白天忙，晚上忙，写程序，到天亮。千行代码，Bug何处藏。纵使上线又怎样，朝令改，夕断肠……

白 明

东软云科技架构师
2017年Gopher China大会讲师
《七周七语言》译者之一
拥有10年编程工作经验
多年电信领域产品研发和技术管理经验
目前主要研究领域包括：
Go、Kubernetes、Docker和儿童编程教育等

一直以来，大家对程序员的固有印象是什么？刻板低调游戏宅？钱多话少无情趣？还是格子衬衫双肩包？无论哪种印象，都是对这个群体最偏激的总结，就像没见过海，总以为海是蔚蓝的。

一百位程序员有一百种样子，如果非要给程序员群体划分出派系，那白大师非禁欲系莫属。

话少有内涵，明明帅到颠倒众生，却高冷禁欲不屑一顾

Go语言 – 未来企业级软件领域第一语言

就在上周，2017年Gopher China大会结束后，我们趁机“抓”住了被大会邀请担任讲师的白大师。希望能从这位颜值高、品味高、气质高的“三高”程序员身上，了解一些Gopher China这个“神秘组织”的信息。

Q：上周被邀请作为2017年Gopher China大会的讲师，能向我们简单介绍一下Gopher China的江湖地位吗？

A：Gopher China是中国大陆地区规模最大，也是最具影响力的Go语言技术大会。这个大会从2015年开始举办，今年已经是第三届了，其影响力已经扩展到了港澳台和东南亚地区。今年在大会上就有一些来自宝岛台湾、中国香港以及东南亚地区的Gopher。Gopher在Go圈里专指Go程序员，因为Go语言的吉祥物是Gopher（地鼠）。

　
另外，关于Go语言这门开源编程语言未来的发展，白大师也给出来了自己的看法。

“Go语言在中国大陆受欢迎程度非常高，甚至超出了全球平均水平。目前很火热的区块链技术的底层基础框架和平台很多也是由Go语言实现的，比如：以太坊。个人认为Go语言在未来发展前景一片光明，更有取代Java语言成为企业级软件领域第一语言的势头。”

兴趣才是第一生产力

像汤姆汉克斯为表演而生，恰克·帕拉尼克为写作而生一样，白大师为代码而生。他们这群人是天生的创造者，具有强烈的好奇心，且能把兴趣转化成终生事业。

Q:是 什么原因让你决定从事编程工作？

A: “兴趣。”

Q:您觉得对于一位软件工程师来说，最重要的特质是什么？

A:“热爱编程。”

在外行人看起来枯燥无味的代码，对他们来说也是满屏的成就感。

“编程工作是为数不多的创造性智力劳动，未来世界编程将会变成普通公民的基本技能和能力，就像现在的语文、数学、物理、化学一样。”

都说“知识改变人生”，但现实往往是“兴趣改变人生”。如果说动力是一个人坚持下去的力量，那兴趣就是为动力提供能量的永动机。而白大师的“编程十年”就是源于最初的兴趣以及兴趣产生的无限能量。

代码外的世界

一位优秀的人之所以能称为优秀，最重要的原因就是你能从他身上不断寻找到惊喜。

惊喜不断的白大师

当我以为白大师用了十年的时间钻研编程，沉浸在代码的世界里，他告诉我他也用了十年的时间写博客，现在仍孜孜不倦。

当我以为他只是用文字记录生活、消磨时间，他却告诉我自己也翻译过一本编程类的书，叫《七周七语言》。

当我以为这些经历已足够填满他这十年的时间，他说自己还是个“绝对梅吹”。喜欢阿根廷队，关注阿根廷球星，尤其在2005年看到了天赋异禀的梅西后，就一直膜拜至今。

白大师和他的那些经典理论

当然，白大师带给我的惊喜，远远不止于他的爱好，还有一些“经典理论”。

比如“年轻心态产生论”。

Q：“为什么会选择加入运营拍档技术团队呢？哪些地方吸引了您？“

A：“因为运营拍档技术团队所在的部门女同学平均年龄最低、平均颜值最高。在这样的环境下工作，心态都会变得年轻。这才是年轻心态产生的根本原因。
（说好的高冷禁欲系呢？）

比如，“挑战收获论”。

Q：“您之前参与翻译过《七周七语言》，为什么会去做这项工作？这样的经历给您带来哪些收获？“

A：“参与翻译工作，主要是想挑战一下自己。收获自然是有的，最大的收获是让我认识到翻译书这事儿真的很难，投入产出比很低。“

其实，兴趣不只是对事物表面的关心，任何一种兴趣都是由于获得这方面的知识或成就感使人的体验在情绪上得到满足而循环产生的。很多时候我们觉得，一旦将兴趣变成工作，它最单纯的本质就变了样。可事实上，白大师用自己的经历向我们证明了：兴趣，才是第一生产力。

微博：@tonybai_cn
微信公众号：iamtonybai
github.com: https://github.com/bigwhite

© 2017, bigwhite. 版权所有.

（一）
每天早晨起来都有一种强烈要上班工作的冲动；
一到公司，立即感觉精力充沛，并希望尽快开始做事，不能浪费一分一秒；
每天下班前回顾一天的工作时，都能感觉到收获和进步，并带着笑容下班；
每天回到家里，暂时忘记工作，与家人共度良霄，养足精力；
生活与工作保持一定距离，这始终让你与工作之间有美的感觉。

（二）
每天早晨一想到要上班，就愁云遮面，总想在床上多睡一会，拖延上班时间；
一到公司，就精神萎靡，思维闭塞，浑浑噩噩；
每天下班前回顾一天的工作时，毫无感觉，只是感觉忙乱中时间就流逝了；
回到家里，却仍被工作压力驱使，埋头伏案，远离家人；
生活和工作如稀泥一样搅和在一起，工作让你感到恐惧。

千万不要觉得以上内容是我杜撰出来的，这是真切发生在你我身边的事实。同样是在工作，状态却为何能有如此天壤之别呢？不同的人给出的答案也许不同，而这里我要说工作幸福感使然：前者显然是工作幸福感富足的结果；而后者则是缺乏工作幸福感在作祟。

俗话说“乐也一天，烦也一天”，每个人都希望自己每天都能快乐的活着。如果你目前正处于第二种状态或者说有向第二种状态转移的迹象，那是时候考虑如何调整一下自己了。恰逢新年伊始，这里我来说说如何提升工作幸福感，做一个善于驾驭工作的人，而不是被工作牵着鼻子走的人。

以下观点来自本人亲身体会，不一定完全正确，仅供参考和讨论。

* 选择可以产生幸福感的工作

世上没有绝对地无法产生幸福感的工作，但对于大多数平常人来说，一些种类的工作的确无法带来幸福感，比如富士康生产线上的零件组装工种，实难想像在那种岗 位上如何产生幸福感，因此跳楼事件频发也就不足为奇了。我无法枚举出所有可以产生幸福感的工作种类，但至少程序员这份工作还是具备产生幸福感的属性的。虽 然我们中国程序员总是习惯自嘲地称自己为“码农”，可“码农”也有收获的幸福时刻啊。程序员这份工作还是需要有创造性的，主观因素对结果的影响比例还是蛮 大的；编码也被认为是一种匠艺，这说明其中有一定艺术的成分。有艺术，就会有美丑的评判。追求和收获美的代码是会让人感觉到幸福的。不过这个世界是现实和 残酷的，为了生存而选择了那些幸福感无几的工作是十分普遍的，当然这种社会问题不是本文所能解决的了的。

* 做自己愿意做的事情

在中国，公务员这种工作想必大家都会认为会产生幸福感。传统印象中，公务员是广义的“官”的现代叫法，而老百姓大脑中的“官”的形象无非是坐在办公室里抽 烟、喝茶、看报纸，这确是一份旱涝保收的工作，但坐在办公室无聊地度此一生是否是你真正愿意去做的事情呢？这只是一个生动的例子罢了，我要说明的是即便是 从事着可以产生幸福感的工作，也不见得就会有工作幸福感，还要看这个事情是否是你真的愿意去做的，是否真的是你感兴趣去做的，是否是真正全心投入去做的。 微观上来看，即便从事了愿意去做的工作，但涉及到具体的事情，也会有好恶之分。以程序员这个职业为例，也分为不同角色，你是愿意做Coding还是愿意做 tech manager；你是愿意做产品还是愿意做项目？时刻记住只有做自己愿意做的事情，幸福感才能眷顾到你。Steve Jobs的一句话教育了我们：“跟随你的内心”。

* 明确的工作目标

很多人在工作当中时常感觉空虚和迷茫，这显然会降低工作幸福感。反思一下这种感觉究竟来自什么？就我个人的体会来说，每当工作目标不明确时，我就会有这类 感觉。反之，明确的目标犹如大海上的灯塔，为你指明前进的方向；让你有的放矢；让你的付出充满了确定性，让你对预期更加有信心，它会让你的心中由衷产生一 种愉悦。

* 工作成果有及时反馈

就如小学生第二天看到作业本上老师的评语那样，我们也希望能尽快看到工作成果的反馈：正面的反馈给人以鼓舞；负面的反馈给人以警醒。反之，零反馈则让人气馁，失去了继续的动力，自然没有幸福感可言。

* 挑战带来幸福感的波峰

在职场中，每天的情形不同，收获不同，体味到的工作幸福感的强弱就有不同。俗话说：有付出就有收获。付出的越多，一旦收获，得到的也就越多。因此只有那些有挑战的，值得让你付出更多的工作才能带来巨大的成就感，从而催生出幸福感的波峰。

* 帮助他人解决工作中的问题

“予人玫瑰，手有余香”，积极地帮助他人解决工作中的问题，会让你的工作幸福感油然而生。让你的工作幸福感弥漫在工作的环境当中，让这种氛围感染熏陶更多的人，以营造一个幸福的工作氛围，提升团队的整体工作幸福感。

* 与志同道合的人一起工作

看看你周围的同事，是否和你是一路人。“道不同不相为谋”，别花时间和心思在那些和你不对路的人的身上了，年纪也不小了，脑细胞也是有限的，吐沫星子也不 是白来的。那些通过一个眼神、一个手势就能知你意的人才是你真正的工作伙伴，和他们一起工作才能有幸福感。能选就选，能避就避吧。

* 定期回顾，潜意识中进行自我肯定

无论是否得到了上级或同事的反馈，定期的工作回顾和总结对保持工作幸福感总是大有裨益的，尤其是回顾过程在潜意识中的自我肯定会很大程度上提升你的工作幸福感。

* 与幸福生活相互映衬

中国人讲：“家和万事兴”。工作之外我们是离不开家庭生活的。我们要学会平衡，把握生活与工作的间距，学会让两者之间互相保持美感。幸福的工作下映衬的是幸福的生活，反之，在幸福生活的的映照下，工作幸福感也会显得更加强烈。工作和生活是相辅相成。

演喜剧的，不见得他每天的生活都是喜剧。最近感觉工作幸福感有所流失，这直接促使了我进行了如上的反思。新年伊始，我也在自我调整中。

© 2013, bigwhite. 版权所有.

如果要大家投票表决组织内部最低效地活动环节，估计大多数人会将选票投给会议。关于内部会议的组织和实施，有很多反模式，这里列举一二：

- 会议组织人突然发出会议通知，两个小时后举行某会议；
- 会议通知中没有会议的agenda信息，也没有任何有关会议的资料；
- 会议的干系人选择不恰当，有些人本无需参会；
- 会议实施过程中主持人无准备，无整体思路主线，想到哪里，就说到哪里；
- 所讲内容与会议类型不匹配，无有效价值传达；
- 会议无决议，无后续行动计划，大家无所获 – 三无会议。

这里谈到的会议的效率不仅在于实施时的时间上的长短，更重要的是会议主题内容在单位时间内传递给相关干系人的程度。其实细致高效地组织和实施一次组织内部会议，并非是件多难的事情。一个会议，无非准备、实施、会后跟踪落实三个部分，而每个部分其实又都是有章可循的。

一、准备阶段

* 提前预定好会议室

注意会议室的Size要适宜，别到时侯人多没地儿坐；而人少又显得空旷，显得人气不旺，气氛不足^_^。对于有限时的远程视频会议室，要预留足够长的时间，避免会议超时带来的意外情况。

* 会议通知

在明确会议主题、类型、目标和Agenda之后，可提前数天或更长时间在组织内发出会议通知，这样可以便于干系人安排好自己的任务列表；通知中应说明会议 的主题、目标与Agenda，如果有初步的资料的话，最好能附上，让相关干系人可以更深入了解；会议的干系人选择要谨慎，哪些人必须参会，哪些人需要知道 有这个会议，自由选择参加等等都要明确。

* 会议资料准备

会议的主讲人或主持人(因会议不同而定)需进行精心的资料准备。准备阶段，主讲人应充分考虑会上要向与会者传达哪些信息与价值，要有贯穿会议的清晰的思路 主线。有条件的情况下，可以请相关人评审这份资料，主讲人最好自己做些模拟讲解，以保证在会议上能产生最好的表达效果，以提高与会者的信息接收和理解程 度。另外有些类型会议(如总结会)需要一些第三方提供的资料或需第三方讨论确认的事情，这些务必在会议举行前完成，避免在会上进行细节的讨论，降低效率。

* 参会提醒

会议主持者应提前一天再次发出会议提醒，如果此时已经准备好最新资料了，可将资料附上；但少数主讲人希望保持神秘感，只发提醒也就是了。

二、实施阶段

* 当天的会议提醒

会议举行当天，再次做会议提醒，这次仅一个通知即可。

* 会议室准备

会议的主持人或组织者或主讲人应根据会议类型和具体情况，提前一些时间到达会议室做好各种准备，包括确认会议室的设备完好情况，至少连上投影，插上网线看 看是否可用；若是远程视频会议室，则更是要提早联系管理员做设备调试，确保会议准点开始时，设备是好用的，远程是接通的；类似一些架构讲解会的会议，可能 还需要提前在会议室白板上做板书。总之，这些准备工作目的就是让会议可以准时开始，而不是让与会者坐在那里白白浪费时间。

* 会议进行

不同类型的会议有不同的进行方式。在组织内部，例会、总结会和评审类会议居多。但总体来说，无论哪种会议，如果要高效地进行，都应该按照主持人/主讲人的 思路主线进行，围绕着会议要传达给与会者的主题为中心，详说重点，有理有据，略说细节，避免细节讨论；必要讨论时，主讲人也应引导与会者的讨论，避免跑 题，并及时打断讨论，回到正题上。

* 控制会议时间节奏

在某件事情上，常人保持集中精力于其上的时间是有限度的，超过这个时间，常人肯定会溜号，信息接收和理解的效率自然就会降低。因此为了让与会者可以保持集中精力的投入，主持人需要控制好会议的节奏，适当予以休息。组织内的大部分会议，应不超过一小时为宜。

* 会议要有结论，并与与会者达成一致

会议是以高效地传达某种信息为目的的，这些信息可能是知识、技巧、最佳实践、思路、工具或某种结论，与会者在后续的工作中会用到信息。因此虽然会议类型不同，但会议均应有相关结论，作为后续的行动计划；并且与会者需要这些结论上达成一致。

三、会后跟踪落实

会议的效率更多体现在前两个阶段。最后这个阶段更多是用来检验和评估会议后的信息传达效果。另外会议主持人/主讲人需要通过这些跟踪和落实情况，总结信息传达情况；回顾和反省会议是否组织和实施的足够高效；发掘和发现问题，并做持续改进和改善。

© 2012 – 2013, bigwhite. 版权所有.

我们每天都会发出和收到几十封甚至上百封Mail，但这并不意味着我们写的Mail就都是合格的。一些人的Mail，无论从格式还是内容，都会让人看起来直皱眉，不知所云；而另外一些合格的Mail，则会让人读起来感觉如沐春风，特别舒服。

如何写好Mail是有原则可循的，这里就结合本人的实践来谈谈这些所谓原则，一家之言，不一定完全正确，仅供参考^_^。

* Mail的使用场合

在运用Mail之前，首先要判断你所在场合下Mail是否是最佳的沟通方式。如果是很紧急、需要对方立即给予回应的事情，那还是用IM或打电话吧；如果是涉及到较多干系人的紧急事情，则可能需要召集会议。

* 选择一个好主题

人们总是首先通过Mail主题来判断这封Mail是否与自己相关，并通过主题猜测Mail内容，初步评估Mail的处理优先级别。因此一个好的Mail主 题是格外重要的。Mail主题不要太长，否则易让人产生反感；Mail主题应含义清晰明确，让人一目了然；Mail主题最好能体现出些额外的信息，比如该 Mail的重要级别，若是重要mail，可在主题中标明【重要】；以及Mail属于何种类别，是通知、分享、总结还是求助、讨论、报告，可以在主题中嵌入 一些“关键字”来体现这些，比如“【分享】如何写好Mail”。

* 谨慎选择干系人，清楚不同类别地址列表的含义

一般Mail会用于多方沟通，因此涉及的干系人多数情况下不止一个。在如何选择沟通干系人时要做到不遗漏干系人；不让无关的人为你的mail而浪费时间； 合理划分干系人类别，放入不同地址列表。干系人若在收件人列表中，意味着他需要重点关注该封Mail的内容；若在抄送人列表中，他只需通过该Mail了解 相关事项的进展；若是在密送列表中，显然是发件人有隐私考虑，但干系人可能需要重点关注该封Mail。
      
* 良好的内容结构

良好的内容结构是一封好Mail不可缺少的要素，个人觉得工作中的Mail内容可大致遵循如下结构：

    – 背景/目的，务必清晰、简明、扼要。
    – 你的观点和支撑你的观点的论据。如果不止一条，观点和论据可分段、成对出现。
    – 结论、其他安排、注意事项、附言。
      
至于如何遣词造句，那是从小学一年级就开始学习的东西，这里就不解释了^_^。

* 尽量避免携带附件

对带有附件的Mail，我个人总是保持厌恶的态度。附件导致Mail Size变大，接收困难，占用较大空间；附件内容无法被mail工具做关键字搜索；不适合移动设备接收和打开阅读，虽说现在的移动设备硬件和功能都很强 大，网络流量价格也很便宜；需要二次打开附件才能全面了解Mail内容，体验不好。因此，如果在不是很必要的情况下，尽量将内容写到Mail的body 里。如果有其他沟通平台，可在内容中赋上相关地址链接，也比打开一个word或ppt的附件要好些。

* 其他属性

除了主题、内容、附件外，Mail还有一些属性影响接收者对Mail好坏的评价。这包括称谓和署名、优先级以及要求回执等。在正式的商业邮件中，有着明确 的称谓和书名规范要求，这方面我就不提了，有兴趣可以翻看一些商务邮件写作的资料和书籍；优先级一般采用默认的“正常”级别，但也要学会合理运用“高优先 级”来表明你的Mail的重要性，吸引收件人的关注。另外要谨慎使用回执属性，我个人就比较讨厌回执，这不是收件人的义务，所以尽量不要强求，除非你是领 导，在给下属发Mail而且又希望下属都能读过这封Mail。

写好Mail是良好工作习惯的一个组成部分，因此养成良好工作习惯，就从写好mail开始吧！

© 2012, bigwhite. 版权所有.

一、技术布道结果的影响因素

我个人也算是组织内部的一个技术布道者，经过多年的碰壁和反思，感觉技术布道的结果好坏与下面的一些因素或多或少有些联系。

* 布道者的资历

无论国内国外(国内可能尤甚)，职场资历这个因素在任何职场活动中都会是一个影响因素，技术布道也不例外。如果你是一个职场新人，也许工作年头不超过一两 年，甚至是刚刚进入职场，你势必人微言轻，并尚未在组织内建立起信任，更重要的是你可能并未深入理解大家面对某种新技术或新实践时遇到的真正困惑以及问题 是什么，这时如果你在组织内尝试大力推动某种技术或实践，效果可能不甚良好：你会发现关心你的提议的受众会很少(除非之前就赢得了上层领导的支持)，你会 受到大家对你的资历的质疑："你才刚来，这东西你自己用过吗？你怎么就知道这东西会对组织带来价值？你讲的这些我都知道，但我们遇到的问题你并没有真正解 决"。记得2007年一位刚刚入司不到半年的新同事(我们得承认这位同事很有技术潜质，也很有技术热情)就在项目组内部大力推广设计模式，并多次在项目组 内部以技术沙龙的方式分享设计模式相关的知识，但效果并不好，以至于若干个月后，这位同事离职后，大家依旧如故的行事，设计模式也并未真正被用到产品代码 设计中。

相比之下，一些组织内资深的布道者反倒更容易推动组织内的技术变革。

* 布道者的角色

一般来说，技术布道的发起者多为组织内的纯技术人员或技术管理者，但也不能排除非技术人员(如：过程改善人员或高层管理者)发起技术或优秀实践的布道。纯 技术人员或技术管理者因其技术背景并深处其中，布道过程中其同理心更强，布道思路更符合大家的胃口，但效果因人因地而异；而过程改善人员或管理人员多半采 用是行政命令的灌输式的方法，强行推进技术或过程改革，这样做常常会遇到抵触或反对意见，短期内可能有效果，但长期结果却往往不佳(当然也有例外)。

* 组织文化的开放度

如果你所在的组织内的成员都抱有一个Open的心态，那恭喜你，你真是太幸运了。你的布道实践一定是相对顺利的。但实际情况中，大多数组织的文化可能没有 想象中的那么Open，大家对变化的第一反应就是"抵触和反感"– 好好的，为什么要变？你也可以说这是人的天性 – 习于安乐。显然在这种文化下进行布道，阻力将会较大，布道者需要做足准备，方可开始实施，即使如此也未必能取得很好的效果。

* 布道路线的选择

布道的路线无非两种：自上而下和自下而上。普通技术人员(包括一部分技术管理者)，多是自下而上，通过布道，说服项目组成员以及管理层使用新技术/新实 践。爬坡总是困难重重的，要想取得良好效果，需更多努力；技术管理者或其他管理人员可能采用自上而下的方式，告诉大家我们应该更换技术，采用新优秀实践， 多半相对顺利。如果你的技术的确解决了大家的问题，让大家平时的工作更"舒服"，自然就更受欢迎，推行起来也就水到渠成。

* 布道时机和对象的把握

变化是需要用成本买单的，既有人力成本，时间成本，甚至包括机会成本。如果你非要向一个下周就要发布的项目组推广JUnit，非要向一个工期仅有三个月且 交付后无需维护的产品线推广持续集成/交付，那你肯定是自找苦吃。这些例子都说明了一点：把握好布道的时机和对象。人家都忙得脚打后脑壳了，你还给人加添 乱，显然时机掌握错了；你推广的东西除了增加成本并未带来任何好处，显然对象选择错了。正如《布道之道》一书中提到的那样：你推广的成果(技术或工具)应 该可以让受众至少感觉到如下价值之一才行：提高了效率；降低了风险；增进了理解。否则你就找错了推广对象。

二、技术布道的有效实践

弄清楚上面的影响因素后，我们就可以谈谈一些利于收获良好结果的技术布道的有效实践了。

* 从问题出发，选择要布道的技术/工具

前面说过，你布道的成果(技术/工具/优秀实践)是需要给大家带来价值的，这其中主要的方面就是为了解决大家目前所面临的问题，比如开发效率不高、系统部 署繁琐、人工回归测试工作量巨大等等。因此只有当你觉察到这些问题，并对这些问题深入理解后，再去选择你要布道的技术/工具/最佳实践；否则如果只是为了 引入新技术而引入新技术的话，那么引入的技术和工具就好比无源之水、无本之木，没有长久的生命力。

* 选择合适的受众与时机

布道所推广的技术和工具多不具有普适性，它在一定受众范围内是有生命力的。因此在谋划布道之前就要考虑好对象。甚至可以在布道之前先深入到选定的受众当 中，对受众以及他们所遇到的问题进行相关的调查和分析，这样做才能事半功倍，布道的结果才可能更佳；另外在确定受众后，就是选择布道时机的问题了，时机的 选择因情况而异。但无论如何也不能犯上面提到的那些错误，否则你的努力将付之东流。

* 以点及面，划分阶段

受众面越大，布道的结果可能越不易理想。因此，最好先在小范围内布道并给予持续支持，直到该技术/工具/实践在小范围内变得不可取代并看到了成果，再向更 大的受众范围推广，此时之前那些已经尝到甜头的受众将会成为你下一阶段布道的强力助手。另外阶段性的布道还有助于你进行自我挑整，修正之前的不足，找到更 为合理的策略和方法。

* 利用局部布道成功结果的影响力说服更广范围的受众

人们都信奉"眼见为实"，因此将前期小范围布道的成功结果会让更广范围的受众相信你推广的技术/工具/实践将会给自己带来价值。这要比你口若悬河般的说教好上百倍。特别是在说服管理者时，这尤为有用，甚至决定成败的那个最重要的因素。

* 建立信心和耐心，潜移默化中布道，甚至先斩后奏

对于一些之前布道失败(无论是否是你推广的，包括那些被管理者否定的)的技术/工具/实践，只要你认定(在对问题的深入理解的前提下作出的判断)它会带来 价值，那就不要放弃，要有些耐心。并运用上面那条实践，先在局部尝试，影响小范围受众；收到显著成果后，再扩大受众面，用现有的成果说服他人，或甚至直到 当管理者问及你是如何取得这个成果时，你再告诉他：是因为我用了XX技术/工具/实践。

* 降低目标预期

最后这点算不上什么有效实践。对于布道者而言，如果要想保持一个持续向前的心态，保持持续关注前沿技术的动力，降低布道结果对你的负面打击，那就在布道之前降低你的目标预期吧。

最后切忌犯一个错误，那就是：只懂皮毛，就去布道推广(多数都并非出于解决问题之目的)。这样做的结果只能是失败，并很可能让大家失去对你的信任。这个错误自己犯过，见过职场新人犯过，也见过牛人犯过。

© 2012, bigwhite. 版权所有.

而今天我要说说身边的事，说说项目上的事。

在一个项目(或者叫产品也不为过)上持续做了整整三年，说长不长，说短也真的不短了。三年间见证了系统从杂乱变为有序和规范的历程，也见证了自己逐渐成长和成熟的过程。而整个系统的架构也在经历着不断的演进。去年年末我们策划并对系统进行了有史(历史<=3年)以来最大的一次架构调整，今年下旬实现了部分调增的新架构系统上线。但我们心里知道架构演进还远没有达到我们期望的结果，演进还没有接近终点。对于一个中等规模的后台服务系统而言，高性能、大容量以及良好的稳定性和良扩展性一直是终极目标，达到这个目标谈何容易。

记得04年入司时，部门的一个核心产品A正在做革新性的架构调整，听更资历老一些的同事说：A产品在2000年诞生后在线运行了4年，问题也伴随了四年，随着客户业务量的增长，亟需对A的架构进行调整，部门也决定投入大量人力在这个拳头产品上。就这样新架构迭代式的做了近三年，人也换了一批又一批，终于在07年A产品上线了。A产品的架构演进走的是从无到有的革新路线，即整个产品基本都是重写的。这样的路线风险较大，新代码较多，测试过程中发现的缺陷势必也较多，为了保证产品研发人员能专心于研发，且保证现有产品维护能及时，部门还另分出一组人单独做既有产品维护。A的新架构上线后，也出了较多问题，但是架构本身经受住了考验，但是随着系统的运行，也发现了架构的一些弊端。

我所从事开发的产品B应该与A算是姊妹产品，第一版的B产品的一个子系统B-1就是从A未进行架构调整之前的系统修改过来的,也就是说B-1等价于A产品前身。与A产品不同的是，B产品增加了另一个核心系统B-2。这里用图示更直观。

A产品    A前身      — 演化 —> 新架构A
B产品:   B-1        — 演化 —> 新架构B1
            B-2        — 演化 —> ?

B产品初期，我一直投入在B-2上，完成了B-2初始版本的开发以及后期一年半的演化。在将B-2当前架构演化到一个高度后，我退了出来，开始负责B-1的研发。现在回头看来B-2最大的架构有点就是简单清晰，但是由于前期的经验不足，在内部代码结构上留下了比较恶劣的smell，后来人也“效仿”了我的风格，以致现在我再看B-2代码，只能用“惨不忍睹”来形容了，Dreamhead的fanfou中曾经提到过“给予程序员最佳的惩罚便是让他维护自己一年前编写的代码”。当然这都是我的错误，与后人无干。可惜的是我现在没有精力再去精化B-2的结构了。

前面说到B-1就是A产品前身，同样与A前身遭遇问题相同，B-1在处理能力上遇到了瓶颈。B-1的架构进化也就从此开始了。由于有了A产品架构演化的经验与教训，B-1采用了与A不同的架构路线，这期间A产品开发负责人给了我们莫大的帮助，提供了我们所缺少的经验和教训，可以说我们的架构演化是站在“前人的肩膀上的”。而且与A架构调整的轰轰烈烈不同的是，我们B-1后台的核心开发人员一直就保持在三人左右，再带着两三个新员工。人力虽少，但是效率却不差，小步快跑，达到相同目的。我们在去年年末架构演化方案确定后，制定了阶段发布计划，架构调整分阶段进行。一个阶段release后，deliver给客户，上线运行调整，虽说每个版本都不完美，有缺憾，有局限，但是风险也降到了最低，这种平滑过度对客户体验的影响也最小。更重要的是阶段性的deliver，加快了反馈的频率，使我们开始对前期架构演化的优缺点的了解也更多了。架构演化计划也随之调整。但随着对架构理解的深入，我们遭遇到了处理能力和扩展性上遇到了“天花板”，不得不暂停下来反思和讨论。

曙光就在昨天的那次反思和讨论中得以重现，在这之前我们的眼光一直停留在B-1架构蓝图的内部，无论我们如何调整都无法让大家满意，始终觉得“别扭”。这时A产品负责人的一个观点，让我们茅舍顿开。一个虚拟域或组的概念将蓝图组合、叠加和交叉，一副更大的图景展现在我们面前，而这幅图似乎让我们看到了架构演化的终极目标，以至于我昨晚连夜画出了一副架构草图。

这篇文章用“曙光”作为题目也许只有我自己才能体会到其深意吧。

© 2008, bigwhite. 版权所有.