《程序员》杂志官网

HTML5是不是解决跨平台问题的终极密钥

baiyuzhong — Mon, 13 Feb 2012 09:51:10 +0800

文 / 郑金条

不同平台的生态圈、技术障碍等壁垒阻碍了开发者快速发展，而HTML5虽被寄予厚望，但目前还缺乏有说服力的产品，HTML5的潜能仍需在探索中被继续挖掘。

Beau Hindman在解析自己理想的游戏状态时，认为好的游戏除了在创意环节（Originality，包括题材、玩法、交互方式）、游戏玩法环节（Gameplay）、风格类型（Style）、声效环节（Great Music）让用户有更好的体验外，适配性（Flexibility）也将成为一个核心的考量环节，用户希望能够在随时有游戏意愿的情况下就能获取的设备上进行游戏。

当然，在目前的条件下，不管是用户的游戏需求还是开发者的游戏发行布局，Beau Hindman的设想更多还只是相对理想的状况。

平台和分裂性问题

在当前状况下，开发者可能遇到的分裂问题包括：发行平台困扰、不同系统平台的技术障碍、不同平台的审核差异和限制差异、跨平台的人力成本和运维成本、平台用户调研和适度改编。

第一个问题，发行平台困扰。不同的操作系统、不同的用户定位形成了不同的商业生态圈，对于开发者来说，iOS、Symbian、RIM、J2ME、Android和Windows Phone就成为必需要面对的选项，要么选择自己合适的站队，要么在不同的平台之间游走，至于哪一种方式更好，只有特定的开发者才能明白。但事实上，更多开发者选择兼顾各种平台和用户，特别是现在更具主导性价值的苹果App Store、Google的Android Market和微软的Windows Phone Marketplace；苹果App Store以将近30亿美元的年度营收成为开发者的首选，而Google的Android Market则以超级日激活量，Windows Phone Marketplace则以游戏的名义再加上和Nokia联姻的方式获得市场的认可。

第二个问题，不同系统平台的技术障碍。技术语言之间的开发障碍相当明显，iOS应用需要Objective-C语言；Android应用则需要兼具java和C语言；Symbian应用需要C++语言；而Windows Phone应用则需要C#语言。Anat Resnick在解析这个问题时认为这种技术语言之间的超级跨度、游戏测试跨度给游戏平台匹配等带来各种困难，类似于Rovio将一款《Angry Birds》做到极致，在不同平台之间广泛布局同样不是一件容易的事，在App Store上受到用户的青睐并不意味着在Nokia Ovi Store也能春风得意（特别是如何保持应用的高质量）。
第三个问题，不同平台的审核差异和限制差异。不同平台对应用的审核标准（适用性、受众适宜度、是否有攻击成分）、审核流程时间、烦琐度等都存在差异，苹果App Store的审核相对更具效率，如果只是更新版本可能更快些，甚至被拒绝的情况都会给出相关解释；而像Android Market的审核性就弱一些，只要提交的应用符合要求即可生效（根据手机操作系统版本、API范围来划分支持运行的手机平台），但Google可以对上线应用进行远程操控，出现问题就会被下架。对于开发者而言，同样一款产品，哪怕只是一次更新都需要在不同的应用商店之间不断重复提交、重复审核。

第四个问题，跨平台的人力成本和运维成本。前文提到，不同技术语言门槛和不同发行渠道需要更多的专职人才负责打点不同的App方向，这对开发团队来说是很耗人力的行为；此外，因为平台的障碍和分裂，也为应用的运维带来各种不必要的重复劳动，再加上不同市场有不同的定位和用户属性，这种技术和人为区隔也将给产品的运营带来各种不确定性。这就是我们需要提到的管理风险，如果选择了错误的平台或者缺乏市场渗透性及市场回报率，给开发者带来的就可能是失败的打击。这层困惑是很明显的，没有充分的数据分析导致开发者只能凭借感觉判断哪些游戏适合投放的平台，而缺乏实力的小型开发者在强者林立的市场获得更合适的平台机会则渺茫得多。

第五个问题，平台用户调研和适度改编。从Xyologic和Distimo以及Flurry监测到的数据可以很明显看到不同平台之间用户对应用的选择倾向性还是相当明显的，比如Android Market的App下载更多而App Store的游戏应用下载更多，即便是同一款游戏应用在App Store和Android Market也因为用户付费环境和支付便捷性等问题而产生极大差异。Flurry的数据认为同一款应用在App Store的营收能力一般是Android Market的4倍，这就意味着在iOS和Android激活量越来越接近的现在，如何权衡用户的直接需求才是开发者需要关注的重点，而平台之间的这种差异直接导致了开发者在开发问题上存在更多的权衡因素。

HTML5游戏大作《GT Racing: Motor Academy》

中间工具和HTML5技术

其实开发者并不是单纯地只根据不同的平台解决问题，看市场上出现的各种中间解决方案就知道了，开发者并不想在跨平台的问题上耗费太多的精力。在目前面向开发者的各种中间解决方案中可能包括Zipline、Moblyng、Epic、MoMinis、Ansca Mobile、Sibblingz、GameSalad、Unity Android或者cocos2d-x。

HTML5被整体市场所观望的除了技术标准和规范不够成熟外，最大的盼头就是出现一款重磅作品给市场打入强心剂，虽然磊友、Spil或Facebook在推动这个趋势，但都不如一款有说服力的游戏来得有价值。

另一个解决问题的方式可能来自最近最受关注的HTML5，脱离App束缚成为应用研发最偷懒的方式。Ben Savage曾经做出2012年关于HTML5的14个预言，其中就包括基于HTML5的应用将大规模出现，此外用户体验可能将慢慢向iPhone应用看齐。而同样利好的消息是各种浏览器都在支持这项技术（Chrome、IE、Safari、Mozilla、Opera等），尽管目前还只是适用于高级别的浏览器版本，但随着浏览器的各种升级，这个用户受众面的困局也将迎刃而解。

所以早些时候Appcelerator和IDG联手做的关于开发者平台选择的调查（取样2160名开发者）就显示HTML5的选项为66%，和Android Tablet的68%相当，甚至高于WP7的38%、BlackBerry Phone的21%。当然，在现阶段的开发者热情还并不能和拥有91%支持率的iPhone、88%支持率的iPad和83%支持率的Android Phone相提并论。

Funzio的Jamil Moledina代表了这种观望心态，他认为开发者并不会和某种技术捆绑，而会根据面向用户的需求做多重选择（优选方案），同样Google+的Todd Kerpelman也认为Flash和HTML5之争并非零和游戏。Zynga的HTML5游戏《Mafia Wars Atlantic City》最后为Mafia Wars Shakedown所取代，并未能有力佐证这个市场的价值，现在Popcap也推出HTML5游戏《Bejeweled》（Chome Web Store）、Gameloft也向Google+平台发布基于HTML5的3D赛车游戏《GT Racing: Motor Academy》，这些举动或许能慢慢和早先的《Angry Birds》（只针对Google Chrome）、《Chain Reaction》、《Sand Trap》一起带动全新的希望。

Zynga负责移动端的高级副总裁David Ko认为HTML5是Zynga在手机端拓展社交游戏的一个重要途径，而Popcap的Giordano Bruno Contestabile则在GDC Online上称HTML5或许是突破平台割据局面的希望（HTML5 might be the hope）。

至于情况如何，至少李开复和磊友对HTML5的未来充满信心，他在HTML5 in China分享会议的开场致辞中就称HTML5所支持的兼容精神将在未来获得更大的展示空间。其实大部分人对于HTML5最大的底气不是来自于对技术的预测，而是来自于行业分析数据的支撑，就比如ABI Research认为到2016年全球将有21亿部手机（占手机总数的30%）支持HTML5浏览运行支持，在手机操作系统的战局中，HTML5将以中间调和者的姿态迅速获得发展。

当然，更有一些人看起来超级乐观，比如Chrome操作系统项目主管Sundar Pichai就认为HTML5最终会超越原版手机应用模式（Spil games首席执行官Peter Driessen认为应该不会超过三年的时间）；Mike Rowehl则认为这种趋势会让用户和开发者忘记自己是经过了原版应用时代，才走上了移动网络之路。

至于HTML5技术支持的应用最理想化状况到底是怎样，恐怕还只能在继续探索中被挖掘。Scott Hyman认为在制作完善的作品中，应该让多数玩家都不会察觉内容是基于浏览器的。

HTML5也让浏览器之间的竞争更为激烈

HTML5的技术差异特征理解

Matt Marshall曾在《How HTML5 will kill the native App》一文中仔细探索过HTML5的相关技术内涵。

其一，Touch/gestural interfaces。据称图片轮播、scrolling lists、disclosure panels和相关小部件等需通过触摸、划动手指来控制的UI组件，均可在HTML5网页上实现。Keith Stuart在《Touchscreens、smartphones and the haptic future of games》一文中指出触屏技术将是未来游戏发展的动向。
其二，HTML5已可根据屏幕大小、图片大小和分辨率的情况，提供Visual Scale的用户体验。
其三，在Graphics & FX问题上原生应用可能更胜一筹，在图像质量要求较高的内容上尤其如此。高图像质量的游戏在HTML5上的渲染效果暂时还比不上原版应用（从目前现有的HTML5游戏看，画质本身还是一个问题）。
其四，HTML5在Accelerometer access问题上也能够有效实现。
其五，关于游戏的离线运行功能。Dan Rowinski曾对此进行过解析，HTML5应用能够在未联网的情况下继续运作。离线缓存的概念相当新颖，是有待网页应用深入挖掘的HTML5重要性能，拓展空间很大，其主要优点是让网页应用能够在未连网的情况下继续运作。可能是很多人认为这是令原生应用走向消亡的一大原因。换句话说，如果得到了用户许可，HTML5可以通过application cache API向用户提供离线存储功能，让HTML5网页应用在离线状态下运行。早在两年前，Google就通过HTML5技术实现了离线Google Map和Gmail（无须接入网络的浏览体验）。游戏邦曾编译过Alex Kessinger的文章，就是以《俄罗斯方块（Tetris）》为例，如何制作iOS离线游戏应用【注：具体可以参阅：http://sixrevisions.com/web-development/html5-iphone-app/】。
其六，屏幕和各种游戏的适配问题。Dan Rowinski提到了响应式设计，这种让游戏或者应用内容自动去适配设备屏幕尺寸可以有效处理尺寸问题。Epic Games公司Tim Sweeney曾称Google Android平台（分裂）无法满足游戏相关开发者为手机设备提供无差别体验的需求，就是出于这个原因（Android本身的分裂和不同平台之间的差异是相似的）。Baird Research的开发者取样调查也显示了开发者的这种顾虑，这和我们在前文提到的问题相似，跨平台除了技术门槛，屏幕适配也同样是个难题。Daniel Cook认为这种情况将给没有跨平台投放经验带来困扰，特别是缺少商务运营积累或者过度重视引擎技术（一劳永逸的）以及缺乏盈利解决方案的公司将更具压力。
其七，中间过渡手段。Ron Perry提到过渡阶段的混合应用，就是开发过程既采纳了原生应用功能，同时融合了更具前瞻性的HTML5技术。这种混合应用仍然需依靠应用商店下载，但因为有部分或所有用户界面植入了浏览器元素的程序，对开发者来说，就意味着他们无须针对各个手机操作系统重新编写应用，而是可以选择用HTML、CSS和JavaScript编写其中一部分代码，并在多个平台上运行应用程序。除此之外，混合应用的另一个特点在于，它与网页应用又有共通之处。混合应用并不像原生应用那样，直接使用手机操作系统所支持的图像API和UI，其多数页面采用的是浏览器的渲染引擎，这与网页应用一致。

事情的发展可能会如EA Sports高级副总裁Andrew Wilson所说，未来的游戏概念是Game3.0，那些收获巨大的胜者将是成功创造跨平台游戏体验的公司。因为一切都处于用户便捷性的考量范畴中，以用户体验的名义一切都处于Creative Destruction（创造性破坏）的局面，惯常的思维正在慢慢滞后于需求的探索，在往后的体验中，跨平台的服务将成为全新的界定Gaming 3.0。回到我们前文说的Beau Hindman所谓的用户希望能够在随时有游戏意愿的情况下在就近能获取的设备上进行游戏，而浏览器模式则无障碍地实现了这一趋势。2010年的这个时候，Moblyng首席执行官Stewart Putney就宣称HTML5是社交游戏（特别是手机社交游戏）的未来，Heyzap联合创始人Jude Gomilla也称HTML5在整个社交游戏/手机社交游戏上将具有重要的影响力。

作者郑金条，游戏邦负责人，游戏邦主要关注和解析国内外社交游戏和手机游戏领域，并定期做深度行业阐述。

本文选自《程序员》杂志2012年02期，更多精彩内容敬请关注02期杂志

《程序员》2012年杂志订阅送好礼活动火热进行中

网络身份安全中的数据策略问题

baiyuzhong — Mon, 13 Feb 2012 09:19:36 +0800

文 / 江海客

当摩尔定律成为灾难

讲到破解对抗问题，要从攻防两方面所拥有的资源说起。之前我们基于一台普通的戴尔笔记本进行了一个小测试：在笔记本里装了一个虚拟机进行相应的Hash次数计算，发现这么普通设备里的虚拟系统，大概每秒钟可以完成50万次以上的标准MD5散列计算，这个结果得益于摩尔定律。我们要注意，这既是散列计算的速度，也是破解所需的数据资源生成的速度。这样的计算速度不仅为我们所拥有，也为神秘河对岸的攻击者所拥有，而且他们的有可能比我们更多。

首先，当前的云资源非常廉价，且都有开放式的计算服务可以借助。据我们所知，在很早以前俄罗斯的破解组织就可以使用俄罗斯科学院的大型机来进行相应的计算。其次，不容忽视的就是GPU的快速普及，对于生成彩虹表所需的配套数据，这可谓个人超算。GPU刚推出不久，就可以达到非常强大的能力：基于8台插有GPU加速卡的机器，在一些适合并发处理的计算中，可以模拟大约400台左右的标准x86节点的运行。这同样是攻击者非常容易获得，且便于他们之间相互分工的一种计算资源。另外攻击者拥有既有计算能力又有节点能力的资源—僵尸网络，它们有的数以万计、十万计，同时他们也进行节点的互动和买卖。这种僵尸网络不但可以承担一定的计算任务，而且可作为可控终端来使用，进行大量基于不同IP地址的所谓探测、撞号，甚至攻击等，还可以尝试控制当前网站流行采用的水印码。很多网站的水印码都会很快被攻击者找到相应的OCR SDK破解，并被分发到所有僵尸网络上。

基于目前的防护条件，网站想做到不被脱库是非常困难的，必须基于数据可能被窃取的前提来考虑整个安全策略，让被拖到的数据库对攻击者来说分析代价很大。

同时，我们也应该注意攻击者手中已经或可能掌握的明文口令资源，应该说这是具有较高价值的口令资源。比如在2002年底，陆续发现一些基于RPC口令猜测的蠕虫，并研究其密码档。那些口令猜测更多还是基于攻击者的经验，而当前的攻击者手中拥有的最优势资源是大量已泄露的口令。其中比较有代表性的是2011年上半年发生的索尼事件，约有超过一亿用户身份泄露，其中就有大量的明文密码，后来的世嘉，约130万用户，连花旗银行都有20万用户信息被泄露。虽然不包括口令等敏感信息，但也带有其他有效的用户信息。这样大量的明文资源为攻击者实现高速碰撞提供了帮助。

我们再来看一下计算资源，包括这些海量明文口令是通过哪些方式被利用的，这里就涉及到了目前已经为公众所知的彩虹表。当前整个基于彩虹表技术制作的大量查询资源，已达到少则几个GB，动辄几十个TB的规模。攻击者可以提供标准的Hash算法、一些场景中固定盐值的Hash算法，还有一些密钥固定的对称算法，完全都可以在这些资源中获得相应的查询。所以说本次事件不是一个简单的是否加密Hash，是否做了MD5的问题，而是在具备上述这些资源的前提下，使用标准的单向算法加密的结果实际上比明文好不了多少，根据我们的测试其被快速破解率可能在50%。所以说，使网站相应的加密策略达成到一定强度必须经过推敲，而且比较困难。

密文攻击方法及应对分析

基于目前的防护条件，网站想做到不被脱库是非常困难的，必须基于数据可能被窃取的前提来考虑整个安全策略，让被拖到的数据库对攻击者来说分析代价很大，这样攻击者可能就会放弃。那么就需要看看攻击者会对获得的数据做什么。

攻击者获取数据的方法很多，有的是自己拿到数据，有的是他人分享。很多时候，他们连同网站的整个代码一同拿到，这种情况很多，因为很多漏洞本身就是网站应用上的漏洞，而不是数据库上的漏洞。基于这个前提，我们必须了解，如果拿到的信息加密了的话，可能会遭到哪些威胁。首先要注意一点，为什么我们一再强调所谓“一用户一盐”这个问题，“一用户一盐”要达到的目的就是即使不同用户在同一个网站上使用了相同的口令，所保存的结果也不相同，因为如果相同的口令被单独保存且结果相同，就会遭到统计攻击。

这就意味着，在假定攻击者没有拿到源码和相应算法的情况下，他只需要少量尝试破解，就可以得出大量密码，从而使大约5%～15%用户密码被破解。注意，我们说的还是在没有拿到网站代码的加密方法的基础上，所以我们认为能够抵御统计分析和高频碰撞是作为整个后端加密系统的基础条件。同时，也要想到当攻击者拿到了相应的算法，包括拿到网站程序时，不管网站管理者做了什么样的修改，整个网站的算法已经公开。由目前整个网站的安全机制所限，原则上很难找到一个可以安全存放密钥的地方，也就是说我们所面临的最不利的条件是算法、密钥、密文完全遗失。在这种情况下，如果仅靠单向函数本身的特性很难完成，因为实际上在攻击者拿到一个仅对口令保存的密文之后，如果网站没有做到“一用户一盐”，实际上攻击者并不是基于生成一个穷举式的大表来查询的，而是基于网站所使用的相同的程序算法。他可能完全不理解网站的算法，但也完全能够调用网站加密的部分，首先把高频口令加工一部分，碰撞一次，比如Top 100，就有可能碰撞出20%的用户，之后完全可以基于上述的，以非常惊人的速度来实现对现有手中约千万级的已知明文口令，依托网站的算法生成密文完成碰撞。

由于网站不能做到不同用户相同密码的加密结果不同，所以这些用户都是通过一次碰撞出来的，碰撞时间相当短，而且这种碰撞我们还没有考虑到GPU加速的情况。基于这些我们可以评估一些错误的实现，它们包括：

单独使用标准Hash算法；
联合使用Hash；
使用非单向算法；
加一粒盐（SALT）；
自己设计算法。

基于以上种种情况，经过研判，我们基本的思想是“一用户一盐”。

要做到其中的差异化，如下两点比较重要。第一、怎么做到“一用户一盐”，这个盐如何生成，如何取得对应关系呢？其实就是为每个用户基于随机数生成一个盐值，这个随机数基于时间，然后建立一个盐表，比如和UID是对应的。第二、一定不要在整个Hash计算中单独加密密码，要把个性化量加进来，比如说用户名。我们最近与一些同行交流经验，他们有的用了比较多的个性化量，比如注册时间、UID等。但是不是加得越多越安全呢？从数学意义上讲，在网站代码库被人获得的情况下，意义并不是特别大；但从分析意义上，它确实增加了分析者的成本。

在这种情况下，实际上并不能避免碰撞，能做到的是避免一次密文碰撞出所有结果，因为网站采用了“一用户一盐”的密码保存策略，包括个性化量，攻击者必须拿出整个常用的高频率码，基于网站当前用户的个性化量和盐，为这个用户生成一个加密结果，再和已有的加密结果比对。

如果网站把相关的思路，与禁止或者提醒用户避免使用高频密码相结合，甚至自身内嵌一个在线查询，不仅禁止使用高频密码，只要泄露过的密码都建议用户慎用，那么两个策略组合就会产生良好的反破解效果。

图1 密码保存策略

图1所示的APM中还有一个保存原始密码的功能，因为可能有些网站不希望重置密码，而是真的为用户找回密码，所以我们还是利用RSA给他封装了找回密码的应用。但我们讲了在当前的安全场景下并不具备单独保存密钥的安全可靠性，所以我们坚决提醒网站开发者，如果没有绝对必要的理由，要坚决慎用非单向方式来保存密码。
这里我们有一件最失落的事情，就是解决不了一号通的问题，有些用户在所有网站都用相同的密码和ID。此时攻击者在最开始时没有必要做高频或者海量碰撞，他只需要把现有的用户名和口令对应关系，依托当前的网站的设置，取到相应的个性化量，比如UID和注册时间，然后算一遍，直接碰撞出来。一号通的碰撞是比较难避免的。我们建议的另外一个方案就是不保存用户ID，但网站要知道这个人谁，不保存用户ID怎么显示呢？那么用户要设置一个昵称，可以建议昵称不允许和用户名相同，这样就增加了攻击者一定的复杂度，比如还需要用其他信息进行关联。但无论如何我们认为从前台机理上看，比如一号通的用户是要允许登录的，而这种情况在后台是我们无法解决的一个问题。

拒绝伪安全

我的同事张栗伟提出任何用于Web/DB场景的登录策略设计必须以下列因素的必然性为前提：

算法必然是公开的；
Hash必然是飞快的；
彩虹表必然是只受存储制约的。

这也就是说攻击者是锐不可当的，但仍然可以采用以下的方式：第一个是口令规避，来增大攻击者加工的整个空间，我们也提供了一个云的查询方式，可以让网站封装在里面，用它来规避已泄露密码；第二个是可以考虑微软采用的动态均衡策略，当一个密码达到一定比率时就不允许再用了，这样就会使空间均衡，但这就有一个弱点，就是密码是要单独保存的，如果这个统计文件被拿到了，这也是灾难性的。同时我们最近也在尝试寻找是否有适用于Web/DB场景的加密硬件，由于整个加密参数的接口是不可以通过PCI槽来读写的，这样就能够从逻辑上无法获取加密参数，以体现保存问题。这里也有一定的问题：第一个是我们必须假定登录是一个常见操作，所以它应该具有一定的加速能力；第二个是当前很多网站是基于虚拟机的，所以这个加密卡必须支持虚拟机里面的系统。

当然还建议从运维策略进行调整，我们认为这里问题特别大的是包括网银和柜台交易有关的系统，虽然加了数字认证保护，但为了兼容它的柜台系统使用这种四位、六位或八位的数字密码，这里我认为它基于网络系统和柜台系统应该口令分支，网络系统可以输入长口令，在网络系统上无法获取它的柜台口令。同时我们在相关文章中也建议既然僵尸网络可以到网站注册垃圾用户，网站也可以自己注册，如果每有一个合法用户，网站运维者自己就注册10个假用户的话，攻击者很难把其中的合法用户挑出来，且对他的时间迟滞有一定的意义。同时网站可以在这些用户的存储密码值的地方放一些误导型算法，攻击者如果用这些Hash和常用口令碰撞，即使碰撞出来，也无法登录；而这种用户一旦用密码登录了网站就知道被脱库了，而攻击者发现无法登录，就会不再登了，这当然要看攻击者的耐心，或者攻击者会发现的情况，但这样的扰动因素有可能比本身在加密上的策略更有效。

作者江海客，安天实验室首席技术架构师，研究方向为反病毒和计算机犯罪取证等。

微博：weibo.com/seak

本文选自《程序员》杂志2012年02期，更多精彩内容敬请关注02期杂志

《程序员》2012年杂志订阅送好礼活动火热进行中

设计之命题

baiyuzhong — Thu, 09 Feb 2012 13:55:22 +0800

无论是软件开发、工程还是建筑，有效的设计都是工作的核心。作者揭示优秀设计的过程和模式并指出，大胆的设计决定会产生更好的结果。

（新思想来自于）将对一门艺术的领悟联系并应用到另一门艺术中，历经若干次这样的经历而有所悟，脑海里自然就孕育出了（新思想）——弗朗西斯·培根（1605）

《学术的进展（全二卷）》卷二第10章

很少有工程师和创作者……能够通过探讨对方的专业领域而互有所得。我的建议是，他们可以相互探讨设计……（然后）彼此分享在这种专业的创造性设计过程中的经验。——赫伯特·西蒙（1969）

《the Sciences of the Artificial》

培根所言是否正确

弗朗西斯·培根爵士的假设正是我们所面临的挑战。设计过程本身是否存在那些适用于广泛设计载体的不变的属性？如果答案是肯定的，那么在一个设计载体中，设计人员就可能在攻克该载体特有的困难的过程中积累经验，从而具有比其他人对一些原则的更为清晰的理解。此外，某些载体比其他载体拥有更长远的设计及元设计（即设计之设计）的历史，比如建筑。如果这些都是正确的，并且培根的结论正确，那么不同载体中的设计人员就可以通过比较自己的经验与见解而在他们自己所处的技艺领域中学到新知识。

什么是设计

《牛津英文词典》对设计这个动词作了如下定义：

To form a plan or scheme of, to arrange or conceive in the mind … for later execution.

对……形成计划或模式，运用思维整理或考量……以便后续执行。

这一定义的精髓在于计划、思维和后续执行。所以，一个设计（名词）是一种被创造出来的事物，它先于被设计的事物出现且与之相关，但又有所区别。英国作家、戏剧家Dorothy Sayers在她那本发人深省的著作《The Mind of the Maker》里，将创作的过程分为了三个不同的阶段，她称之为构想（Idea）、精神（Energy）（或实现（Implementation））以及交互（Interaction）。这代表着：

概念性构想的形成；
在真实的媒体中实现；
在真实的体验中与用户交互。

在这一概念中，无论是一本书，或是一台电脑、一个程序，首先是一种概念性的构造，它独立于时间和空间，而其精髓是在作者的脑海中完成的。然后通过钢笔、墨水和纸或者硅和金属在真实的时间和空间中得以实现。当某人读到这本书、使用了这台计算机或运行了此程序时，用户与创作者的思想达到了交互，这种创作就完成了。

在我之前的一篇文章中，我将构建软件的工作分为根本的（essence）和次要的（accident）。（这一亚里士多德语言并非要贬低软件构建的次要部分。在现代语言中更易理解的术语应当是essential和incidental。）我称之为根本的软件构造部分是形成其概念性结构的心智过程，称之为次要的部分是其实现过程。交互，也就是Sayers所说的第三步，发生在软件使用之时。

因此，设计就是脑力的构思，即Sayers称之为“构想”的部分。它可以在任何的实现开始之前完成。曾有一次，莫扎特的父亲询问他关于三周内要交付公爵的一部歌剧进度如何，莫扎特当时的回应既让我们感到震惊，又清晰地阐明了这一概念：

一切都谱成了，只是还没写下来而已。——给利奥波德·莫扎特的信（1780）

对大多数的创作者来说，构思的不完整性和不一致性只有到了实现的时候才变得明显起来。因此，记录、实验和“解决”成为了理论家们的关键原则。构想、实现和交互这三个阶段的操作是循环进行的。实现为另一轮必须完成的设计周期创造了空间。因此，莫扎特使用钢笔和纸实现了他的歌剧构思，而指挥家通过与莫扎特的作品进行交互，理解并形成了自己的演绎，又通过乐队和歌手将其实现。最终通过观众参与的交互而完成整个过程。

一个设计是一个被创造出的事物，与之相关的是一个设计过程，我将此过程称之为设计，不加任何修饰。还有一个是动词意义的设计，即进行设计。这三者是紧密相关的，我相信在具体的环境中就不会混淆它们的含义了。

何为真实？设计的概念

如果许多个体有着共同的名字，那么我们可以认为它们同样有着相应的概念或形式—明白我所说的吗？

明白。

让我们以任意一个普通的事物为例。我们的世界中有许许多多的床和桌子，是吗？

是的。

但这里仅仅存在两个它们的概念或形式：一个是床的概念，一个是桌子的概念。

确实如此。

而任何工匠都是遵循这种概念来制作我们所使用的床和桌子的。——柏拉图（公元前360年），《理想国》第十卷

在2008年的第7届设计思想研讨会上，每个发言人都对四个同样的设计小组会议作报告。视频和打印件都提前很好地分发下去了。来自雷丁大学的Rachael Luck在架构会谈中提出一个之前没有引起任何人注意，而后又被大家一致认同的实体：设计概念。

毫无疑问，架构师和客户总是不断提到这一共享的不可见的实体。演讲者时常会对着画面作出各种含糊的手势，但显然他们并不是在指向画面的某一部分或者那其中的某一特定事物。通常，他们所关注的是开发中的设计概念的完整性。

Luck的见解让设计概念拥有了其自身的地位，这于我本人的经验有着强烈的共鸣。在开发IBM System/360大型计算机家族的单一架构的时候（1961～1963），尽管从来没有正式命名过，但这样的实体始终存在于架构小组内部。得益于Gerry Blaauw的远见卓识，我们将System/360的设计活动明确地分成了架构、履行和实现三个部分。其基本思想是整个计算机家族对程序员呈现统一的接口，即架构；而根据性能和价格的不同可以有多个并行的实现。

多个实现的同时性伴随着几个工程经理的竞争，这些驱动着形成一个统一漂亮的架构，并且避免了为节约成本而作出较小的妥协。然而这种力量仅是来自于架构师们的本能和愿望，他们每个人都想做出一台漂亮的机器。

随着架构设计的不断发展，我发现了一件乍一看很奇怪的现象。对于架构小组而言，真正的System/360是设计概念本身—一台柏拉图式的理想机器。那些在工程车间建造中的机械式的或电子的Model 50、Model 60、Model 70和Model 90等，只不过是模仿那台真正的System/360的柏拉图式机器的影子。真正System/360的最完整最忠实的体现，不在那些以硅、铜或者钢的形式组成的物理计算机上，而是存在于《IBM System/360操作原理》这本程序员的机器语言手册的文字和图表里。

后来在View/360海滨小屋（见第21章）的建造中，我也有类似的体验。它的设计概念在构建活动开始的很早以前就已经成型。历经了许多版本的绘图与纸板模型搭建，其概念始终贯穿其中。

非常有趣的是，我从未在OS/360软件家族中感觉到这样的设计概念实体。也许它们的架构师有这种感受，又或许我对其概念框架的理解还没有到了如指掌的程度。也许设计概念没有在我这里萌发的一个原因是OS/360实际上是分别由四个部分混合而成的：一个主控制器、一个调度器、一个I/O控制器以及一个庞大的编译器和实用工具软件包（见第25章）。

价值何在

在设计对话中将不可见的设计概念转化为真正的实体是否会带来积极的价值呢？我认为是的。

首先，良好的设计具有概念性的完整性—统一、经济、清晰。它们不仅可以工作，而且能带来快乐，正如维特鲁威首次阐述的那样。8 我们使用诸如优雅、利落、漂亮这样的术语来形容桥梁、奏鸣曲、电路、自行车、计算机以及iPhone。辨析出设计概念这样一个实体，可以帮助我们在自己独自设计时去追寻这种完整性，有助于在团队设计时围绕这一概念一起工作，也有助于将它传授给年轻人。

其次，以这样的方式经常提及设计概念，对于一个设计团队内的沟通有极大的帮助作用。概念的统一是一种目标，它只有通过大量的对话才能达到。

就设计概念本身而言，比起由它衍生而出的表达或是部分细节，会话要直接得多，也是焦点所在。

因此，电影制片人使用故事板来保持其设计会话始终关注设计概念而不是实现细节。

关注细节，当然就会将不同版本的概念之间的冲突暴露出来，并迫使其得到解决。例如，System/360架构需要一个十进制数据类型，以桥接拥有成千上万用户的IBM十进制机器。我们所开发的架构中已经有了几个数据类型，包括32位的定点补码整数和可变长的字符串。

十进制数据类型可以被定义成类似于这两者当中的任意一个。那么哪一个才更适合System/360的设计概念呢？两方面对此都拿出了强有力的论据，这背后的力量直接依赖于个人对于设计概念不同的理解。一些架构师脑海中的设计概念反映的是早期的科学计算机，而其他架构师脑海中的概念反映的是早期的商务计算机。System/360有明确的设计目标，对于这两种应用都应提供良好的支持。

我们选择以字符串数据类型为基础来建模十进制数据类型，对于绝大部分特定的十进制数据类型用户群体，即IBM 1401的用户来说，这是最熟悉的数据类型。如果再给我一次机会，我仍会做出这样的决定。

对于设计过程的思考

关于设计的思想由来已久，至少可以追溯到维特鲁威（逝于公元前15年）。他于古典时期（Classical period）写就的《建筑十书》（De Architectura）被奉为设计的奠基之作。而随后达·芬奇的《达·芬奇笔记》（Notes）（1452—1529）及Andrea Palladio的《建筑四书》（Four Books of Architecture）（1508—1580）则可称作是这一领域里的里程碑。

而对于设计过程本身的思考则是近现代的事。Pahl和Beitz将其追溯到1852年由Redtenbacher所带来的德国思潮，这一思潮是由机械化的兴起而激发的。9 对于我本人而言，关键的里程碑要数Christopher Alexander的《形式综合论》（Notes on the Synthesis of Form）（1962）、Herbert Simon的《人工科学》（The Sciences of the Artificial）（1969）、Pahl和Beitz的《机械制造》（Konstructionslehre）（1977），以及设计研究学会（Design Research Society）的成立和《设计研究》（Design Studies）（1979）这本杂志的创刊。

Margolin和Buchanan所编撰的《The idea of Design》（1995）收录了来自《Design Issues》期刊的23篇文章，大部分是关于设计评论与理论的，并“对理解设计有所影响的哲学问题作了少许探讨”（p.xi）。

我的《人月神话》（1975, 1995）反映了IBM OS/360的设计过程，它后来发展成为了MVS及其后继的产品系列。这本书着重描述该设计与开发项目中人、团队与管理等方面的内容。与当下工作密切相关的是这些文章的第4～6章，阐述了如何在团队设计中从概念性上达到完整与统一。

Blaauw及Brooks（1997）的《计算机架构：概念与演化》这本书对IBMSystem/360（以及System/370-390-z）的架构设计和相互关系，乃至许多设计决策背后的理论都作了广泛的讨论。该书并未全面涉及设计中的过程与人工活动。但该书1.4节关于良好的计算机架构性设计标准的讨论，与这部分工作有着特别密切的关系。

设计类别

系统设计与艺术设计

这本书介绍的是关于复杂系统的设计，并且是从工程师的视角出发的。工程师关心效用和功能，但同时也注重效率和优雅。

这与艺术家和作者所做的许多设计形成了对比，他们更强调设计所带来的愉悦和所要传达的意境。当然，建筑师和工程设计师同时属于这两种阵营。

常规、适应性、原创设计

我们通常认为桥梁设计是高超的工程设计之一，在桥梁设计中，概念或者技术的突破无论从成本、功能，还是审美的角度都能带来非常明显而又具有戏剧性的影响。

然而，一大部分的高速公路桥梁都较短，推出一个50英尺的混凝土桥梁设计已是一种常规且自动化的过程。对于短桥梁，土木工程师成竹在胸，很早以前就将各种决策树、约束变量和必要条件编撰成册了。同样的情况对于为成熟的语言设计新平台下的编译器也成立。在许多领域都有这种常规的自动化设计。

这本书重点强调的是原创设计，这与因参数变更而进行的对目标的重新设计，或者对先前的设计或目标进行修改以适应新目标的适应性设计，有着明显的区别。

本文节选自《设计原本：计算机科学巨匠Frederick P. Brooks的思考》，作者Frederick P. Brooks，译者InfoQ中文站、王海鹏、高博，由机械工业出版社发行。

Mac OS X 背后的故事（九）半导体的丰收（上）

baiyuzhong — Thu, 09 Feb 2012 09:52:03 +0800

文/王越

在美国宾夕法尼亚州的东部，有一个风景秀美的城市叫费城。在这个城市诞生了一系列改变世界的奇迹：第一个三权分立的国家——美立坚合众国，就在第五街的路口诞生；举世闻名的费城交响乐团，1900年在市中心的Academy of Music奏响了他们的第一个音符。而写这篇文章时，我正坐在三十四街的宾夕法尼亚大学计算机系的一楼实验室，面前摆放着世界上第一台电子计算机——ENIAC。

1946年2月14日，ENIAC问世，每秒可运行5000次加法运算或500次乘法运算，面积达170平方米，重约30吨，拉开了计算机处理器革命的序幕。这场革命是各处理器厂商长达数十年的竞赛，而摩尔定律从一开始就准确地预测了这场比赛的走势。根据摩尔定律，同样价格的集成电路上可容纳的晶体管数目，每隔约18个月便会增加一倍，性能也将提升一倍。但事实上，并无法用老路子来保持这个增长速度，因为会遇到包括能耗、散热等各种技术瓶颈。所以每隔几年就会有用来绕过这些瓶颈的新一代产品推出。如采用超纯量（superscala）、指令管线化、快取等。这些技术通过一定程度的高效并行来挖掘计算机处理器的速度所能达到的高度，以促使用户更新换代。

世界上第一台计算机ENIAC，1946年2月14日诞生于宾夕法尼亚大学

和66年前的ENIAC相比，今天的处理器已有了质的飞越。而21世纪的前十年，我们更是见证了个人计算机处理器的三次重大革命——64位处理器、多核心和高效图形处理器在个人电脑出现。在这样的背景下，乔布斯在2008年WWDC（苹果全球开发者大会）上，宣布下一代Mac操作系统Mac OS X 10.6将被命名为Snow Leopard（雪豹）来适应硬件架构的革新。就在那天下午，Bertrand Serlet在一场开发者内部讲座上透露，和先前两个发行版包含大量的新功能（10.4 Tiger包含150个新功能，10.5 Leopard包含300个新功能）不同，Snow Leopard不含任何新功能，仅是对Leopard中诸多技术的重大更新，以使其在现代架构上更稳定、高效。在这十年的最后一年，2009年8月28日，苹果发布了Mac OS X 10.6来有效地支持这三项技术，而本文将为读者介绍其对应的三项软件技术——64位架构、Grand Central Dispatch，以及OpenCL。其他Mac OS X 10.6技术更新，如全新的QuickTime X和跳票的ZFS，有着更复杂的历史背景（以后再为读者介绍）。

64位架构出现的缘由

前文提到，根据摩尔定律，同样价格的集成电路上可容纳的晶体管数目，约每隔18个月便会增加一倍，性能也将提升一倍。事实上，存储器的容量增长可能更快，每过15个月就会翻一番。有了更快更强的电脑，可能会让数值计算的科学家们喜出望外，但对普通大众来说，摩尔定律给普通消费者一个假象——如果你觉得1000美元的苹果电脑太贵，那等上18个月就可以用500美元买到同样的电脑。十年前你在用电脑写Word文档，十年后你还在用电脑写Word文档，反正计算机不是耗材，一台电脑只要不坏，就不用去买新的。计算机产业的巨头们自然知道摩尔定律对他们造成的致命打击，因此，一个阴谋被以Intel和Microsoft为首的巨头们构想出来—Intel负责把硬件越做越快，而Microsoft则负责把自己的软件越做越臃肿、越做越慢—至于你信不信，反正我是信的。因此，使用软件、服务等，直接促进计算机产业的消费，使得计算机产业走上可持续发展的道路。这在计算机产业被称为Andy-Bill定律，分别以Intel和Microsoft总裁的名字命名。

当然，软件公司未必真心欺骗消费者，故意把软件做大做慢——为了实现一个新功能，软件势必会比原先庞大。但现代软件的速度、大小和其增加的功能并不成比例。比如对最终用户来讲，Windows Vista到底比Windows XP多了多少功能呢？可能只有20%~30%。Word 2007对比Word 2003多了多少功能呢？可能也只有20%~30%。但Windows Vista、Word 2007占用的CPU、内存、磁盘空间，却比Windows XP和Word 2003翻了几番。究其原因，为了能赶快把新功能带给用户，我们不惜使用更方便但低效的编程语言（.NET、Java等依赖虚拟机的语言就要比C慢许多，Python等动态语言比C慢的不是一星半点）、快速开发（我们原先处理一个大文本，先分块，一点一点读到内存中，然后把处理完的部分写回磁盘，清空内存；而现在直接把它全读进来处理，开发方便，执行也快）。而用户必须为这些新功能买不成比例的单。64位就是在这个背景下迅速走入寻常百姓家的——程序占用越来越多的内存，而32位的寻址空间已不能满足软件运行的需要了。

64位 CPU是指CPU内部的通用寄存器的宽度为64bit，支持整数的64bit宽度的算术与逻辑运算。早在1960年代，64位架构便已存在于当时的超级电脑，且早在1990年代，就有以RISC为基础的工作站和伺服器。2003年才以x86-64和64位元PowerPC处理器架构（在此之前是32位元）的形式引入到个人电脑领域。从32位元到64位元架构的改变是一个根本的改变，因为大多数作业系统必须进行全面性修改以取得新架构的优点。

成功的迁移

苹果向64位处理器的迁移花了整整6年时间，远长于该公司其他技术的迁移——向Intel的迁移仅用了一年时间，从经典Mac OS到Mac OS X也仅用了三年时间。总而言之，这场迁移是非常成功的：一方面，用户基本无痛苦，老的32位程序在目前最新版的Mac OS X Lion中依然可以完全兼容地执行；另一方面，对开发者而言，基本只需做微小的调整，重新编译程序，而且若干技术如Universal Binary，使他们发布程序非常方便。当然，对于某些大量使用过时技术的公司，如Adobe和Microsoft，这场迁移则要折腾得多。

这场迁移整整用了四个发行版的时间（10.3至10.6），不同于Windows或Linux，Mac OS X对64位的迁移自下而上，再自上而下。先是内核扩展，逐渐上升至Unix空间，然后上升至用户界面，再上升至整个应用程序生态，最后完成内核的迁移。要提醒读者的是，Mac OS X的32位和64位内核空间与用户空间的分配和实现，和Windows存在本质的区别，但在本期介绍中，我们尽可能少地把Mac OS X 的64位迁移和Windows进行比较，不拘泥于技术细节，对此区别有兴趣的读者，请移步AppleInsider的系列专题。

2003年，苹果发布了其第一款64位计算机工作站Power Mac G5。同期发布的Mac OS X 10.3也因此增加了非常简单的64位支援，于是XNU内核开始支持64位的寄存器和整数计算。但对于用户空间而言，程序可见的地址依然是32位的。程序当然可以使用大于4GB的内存（Power Mac G5最高可达8GB寻址空间），但这要求程序手动地在两个32位内存空间中来回转换。

两年后，苹果发布了当时最成功的Mac OS X发行版Mac OS X 10.4 Tiger。10.4的内核是革命性的，除了增加对内核并行多线程的支持，它把用户空间可见的地址空间扩展到了64位，因此理论上用户程序可以以64位方式执行。当然，在这个时期，几乎系统内的所有程序，哪怕是内核，依然是32位的。系统中唯一带的64位二进制文件是名为libSystem.dylib的系统库。它是Mac OS X上对C标准和POSIX标准的支持库，由libc、libinfo、libkvm、libm和libpthread五部分组成。但这仅有的libSystem.dylib理论上就能让所有仅使用C标准库和POSIX标准库的程序以64位模式运行。当时，用户对64位的需求较少，主要限于科学计算或图形处理等需要大数组的领域。因此，10.4能较好地满足这部分用户的需求。但如果程序需要调用除BSD Unix以外的系统调用，比如想用Cocoa来画图形界面，那么该程序仅能以32位方式运行了。对于一些需要64位寻址空间的科学计算程序，比如Mathematica，就需要采用一些比较麻烦的做法：用一个进程调用32位的Cocoa画图形界面，用另一个进程调用64位的libSystem来进行运算和Unix系统调用，并用Unix管道或进程间通信的方式管理两个进程间的输入/输出。

苹果在Mac OS X 10.4发布同期的另一项重要决策是向Intel平台x86及x86_64架构的迁移。为了帮助开发者和用户顺利迁移，苹果正式公布了Universal Binary。Universal Binary 技术是Mach-O二进制文件早就具有的特性，只是在这个场合作为一个商业词汇进行宣传。NeXT时代NeXTSTEP操作系统就支持许多种不同的硬件架构，自然可以要求开发者对每个平台发布一个独立的版本，但这样的分发模式很麻烦，消费者也需要搞清到底购买哪种平台的软件。因此NeXT的Mach内核所支持的Mach-O二进制文件格式引入了一种叫fat binary的特性，说白了就是在一个平台架构上分别交叉编译所有平台的二进制格式文件，然后把每个文件都打包成一个文件。Universal Binary就是指同时打包Intel平台和PowerPC平台的二进制文件。Mac OS X 10.4最终支持四个平台的BSD系统调用——32位Power PC、64位PowerPC、32位 x86和64位x86_64。作为最终用户，无须搞清这些区别，因为使用Universal Binary技术，买回来的软件直接会解出相应平台程序的二进制文件并执行。这是苹果很成功的一步——不像Windows系统中要用不同的路径（\Windows\System、\Windows\System32、\Windows\System64）分别存放不同架构的二进制库，并且用户还需在32位版和64位版之间犹豫不决。

Mac OS X 10.5 Leopard经过一系列跳票终于在2007年末发布，跳票主要原因是当时苹果投入了大量人力和物力去做iPhone，以至于10.5跳票了整整一年。10.5包含了约300项新功能，而最重要的一项是苹果把对64位的支持带入了Cocoa层面。因此，几乎系统中所有的库都有四个平台的版本。在WWDC上乔布斯亲自向与会者介绍迁移到64位的好处，而能使用更大的内存自然是一项重要优势，程序可以申请更大的内存，把所有数据一并读入内存中操作，而无须分块后来来回回地在内存和磁盘搬运数据。另外，对Intel平台来说，x86架构只有8个寄存器，而x86_64平台有16个寄存器，这也就意味着，对该平台来说，只要重新编译程序，程序就能自由调度比原先翻倍的寄存器数量而无须快取或在内存中来回查找和读写。根据粗略估算，一般涉及大量数值计算的程序会加快一倍。所以他很开心地劝说所有的开发者都迁移到64位架构。

历时整整6年时间，苹果完成了向64位处理器的迁移，同时这也给苹果提供了良好的清理门户的机会——清理过时的技术和API。

彻底的清理

同时，苹果做出了一个大胆的举动——Carbon框架并未出现在这次迁移中。Carbon是Mac OS X诞生之初为了帮助Mac OS开发者把老程序迁移到新的Mac OS X操作系统上所提出的一个兼容API，这套API长得很像经典Mac OS的API，但能够得到Mac OS X平台提供的一切新特性，Adobe、Microsoft等都是通过Carbon把它们经典的Mac OS程序移植到Mac OS X上的。苹果的本意是希望开发者用Carbon迁移老程序，用Cocoa开发新程序，但在Carbon诞生之初，其受关注度远大于Cocoa，据TeXShop开发者Dick Koch回忆，在Mac OS X 刚诞生的开发者大会上，Carbon讲座的教室挤满了人，而Cocoa相关的讲座上听者无几。维护两套雷同的API的代价自然很高，所以砍掉一个是大势所趋。Carbon和Java的热度甚至一度让苹果产生索性把Cocoa或Objective-C砍掉的想法。大量苹果自家的程序如Finder、iTunes、Final Cut、QuickTime等也都是用Carbon写成的。不过在此后由于大量涌现在Mac OS X平台上的新程序都是Cocoa写的，导致Cocoa技术不断走高。2007年的iPhone也完全依赖于Objective-C和Cocoa的一个裁剪版Cocoa Touch。因此在WWDC2006上，苹果在Mas OS X Leopard 10.5的开发预览版中包含了测试版本的64位Carbon库，甚至还有讲座教如何开发64位的Carbon程序。但苹果却在2007年告诉Carbon开发者，他们的程序将不可能再被编译成64位，要做到这点，必需先把程序用Cocoa重写。

这个突然的决定激怒了很多开发者，尤其是以Microsoft和Adobe这些巨头为代表的公司。Adobe全套的Creative Suite和Microsoft全套的Microsoft Office是很多苹果用户必备的软件，数百万行代码全是用Carbon写的。所以直到今天，除了Adobe Photoshop等少数程序终于在2010年全面移植到Cocoa后做出了64位版，其他大部分程序依然停留在Carbon的32位模式。

苹果也花了很长时间来重写Finder、FinalCut、iTunes、QuickTime等程序或技术，耗费了大量精力。当Adobe发布64位的Lightroom 2.0时，苹果还在手忙脚乱地重写Aperture。不过公正地讲，长痛不如短痛，砍掉对Carbon的支持能够使苹果把更多精力放在该做的事上，也使得Mac OS X的结构更简洁，并且事实上，64位的迁移为苹果提供一个砍去老API的机遇，哪怕对Cocoa也是。一方面，Cocoa框架中很多类不是使用类似Carbon的API，就是依赖于用Carbon实现（注意，和传统观念不同，Carbon和Cocoa在早期Mac OS X上是相互依赖的，比如菜单NSMenu就使用了Carbon的菜单管理器），这些API在64位得到了彻底清理，QuickTime相关的C接口全被砍去。Cocoa经过很长时间的发展，自然也保留了很多过时的API以保证和原先的产品兼容，而这次机会给苹果足够的理由彻底推翻原先的设计。在Mac OS X 10.5中， Objective-C的运行库libobjc更新到2.0，提供了全新的并发、异常处理、自动内存回收、属性（property）等新机制，其中很多新特性只供64位享用。同时，所有int都被改为NSInteger，Core Graphics中的float都改为CGFloat，以保持API统一，这些都是64位架构上的改动。因此64位迁移给苹果一个很好的清理门户的机会。

作为相反的例子，这次清理也有不彻底的地方。比如从老版Mac OS中混进来的Keychain库，甚至具有Pascal风格的API，由于没有替代品，它也得到了64位的更新。所以类似keychain这样的库成了现在Mac OS X程序员的噩梦。我每次用到Keychain都有痛不欲生的感觉。

而2009年发布的Mac OS X 10.6 Snow Leopard则是对64位真正完整的支持。Unix层虽然10.4就提供了64位的libSystem，但所有的Unix用户空间工具包括ls、Python等，以及Xcode中的gcc，也都是以32位二进制的模式发布的。图形界面层，在10.5 Leopard中，虽然整个系统的库都迁移到64位，以32位和64位的混合模式发布，但用户应用程序依然是32位的。只有Chess、Java、Xcode套件等少数程序以64位编译。但在10.6中，基本所有的应用程序都被迁移到64位，不管是Safari、Mail、Dock，还是TextEdit。当然，各种Unix工具包括LLVM、GCC等也都以64位的模式发布。10.6只有四个Carbon程序（Front Row、iTunes、DVD Player以及Grapher）未得到64位升级【2009年查阅，现页面已更新至10.7】。其中， Front Row在Mac OS X 10.7 Lion中被砍掉， iTunes在10.7发布时依然以32位模式发布，在2011年末的更新中才迁至64位。

为了使应用支持64位，苹果不遗余力地改写了大量代码，Snow Leopard中最重要的重写当属Finder，这个程序自Mac OS X发布以来就一直是一个Carbon程序，并且苹果一直不停地改进它以展示Carbon无所不能。但自从10.5时代苹果下决心砍掉Carbon后，该程序被完整地重写。新的Finder和Carbon版的Finder看上去并没有太大差别，但Finder使用Cocoa重写后，不仅速度更快，而且增加了许多Cocoa新特性，比如加入了更多的Core Animation特效来平滑过渡动画。总之，虽然苹果在10.6期间没有提供太多新功能，但这样大规模的重写，为今后代码的可维护性奠定了良好的基础。

Mac OS X 10.6发行版也完成了64位化的最后一步——内核的64位化。我们将在下期杂志中和读者仔细讨论。

作者王越，美国宾夕法尼亚大学计算机系研究生，中国著名TeX开发者，非著名OpenFOAM开发者。

本文选自《程序员》杂志2012年02期，更多精彩内容敬请关注02期杂志

《程序员》2012年杂志订阅送好礼活动火热进行中

产品创新的秘诀

baiyuzhong — Wed, 08 Feb 2012 09:18:50 +0800

文 / Marty Cagan 译 / 黄捷文，韦文凯

Marty Cagan是享有世界声誉的产品管理专家，曾经担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来从事软件产品管理工作的总结和经验分享，谈到了产品创新应该注意的问题，以及在大公司创新的方法。

创新就是这样被扼杀的

我拜访了两家软件技术公司（都不在硅谷），它们近期都引入了六西格玛顾问。我非常惊讶，我本以为六西格玛的思想在高科技公司早已销声匿迹了。我希望这只是个别现象，但“忘记历史的人注定重蹈覆辙”，因此我认为有必要在此讨论一下六西格玛这类以质量为中心的方法。

在制造业，尤其在公司深陷质量或成本问题时，六西格玛是非常合适的解决方案。它基于一套质量管理的方法和实践经验，可以有效地降低成本及缺陷率。

不幸的是，很多宣扬六西格玛的人认为这套原则应该适用于公司的所有业务流程。但这些能在制造流程中去除质量缺陷的方法，却是扼杀创新、摧毁产品探索和开发的罪魁祸首。

对于有些公司而言，创新意味着企业的全部，也许你的意愿是好的，但六西格玛的实施绝对会让你误入歧途，甚至毁掉整个公司，而这绝对不是在耸人听闻。在我们这个行业，创新能力就是企业的命脉。质量固然重要，但只有创造出顾客需要的产品后，才有资格讨论质量问题。

还记得摩托罗拉，那个曾经靠创造力发展的公司吗？还记得3M，那个曾经靠鼓励员工主动创新的公司吗？还记得通用电气，那个确实曾经“将伟大的想法注入生活”的公司吗？还有Sun，那个曾经极具创新能力的公司？Intuit，那个在建立之初就承诺要取悦客户的公司？

曾经，它们都是广受赞誉、持续进行科技创新的公司，直到六西格玛介入，它们的创新能力几乎统统被扼杀了。只能靠小幅的增量优化在行业里“苟延残喘”。当然六西格玛的本意绝不是充当创新“终结者”，但一个组织尝试采用六西格玛取代原本适合的产品管理流程，无疑会造成“副作用”大于“疗效”的后果，尤其是随着时间的推移，“副作用”会更加明显。你固然可以在短期内降低一些成本，但你很快会看到后果，例如新产品推出慢如蜗牛，客户对你的产品越来越失望。

人们一向对大公司里的创新嗤之以鼻，认为唯有创业型公司才可能创新，大公司只能复制创业型公司的成果，或者干脆收购那些成功的创业型公司。不可否认，创业型公司的氛围更适合创新，但不代表大公司做不到这一点。

你会发现在采用六西格玛管理方式的高科技产品团队中，具有创造力和主动性的人才会快速流失掉。他们受不了严苛制度的制约，更受不了所谓的“制度”将自己的创意行为描述成“离经叛道”。因此，别指望在六西格玛的高压下留住有这类人才，而没有了他们，你的企业也就失去了未来。

高科技公司的首要工作不是排除缺陷、提高效率，而是探索并创造出客户喜爱的产品及服务。不要误入歧途——把“正确地创建产品”当作“创建正确的产品”。

如果你的目标是夺得美国波多里奇国家质量奖（Malcolm Baldrige National Quality Award），那么六西格玛可能对你有用；但如果你的目标是要创造成功的产品，你需要在产品探索、鼓励创新及主动性方面优化你的组织，激发员工“离经叛道”的创意。

在不适合的领域强行推广不合适的工具，不只是六西格玛咨询师犯这样的错误。某些过度狂热的Scrum（一种迭代开发流程）宣扬者在不适用Scrum的领域推行他们的流程，结果乱得一塌糊涂。但坦率地说，在扼杀创新的“能力”上，六西格玛排第二，就没谁敢排第一了。

因此，假如在你的高科技公司里发现了六西格玛咨询师，建议快快把他们扫地出门，一刻都不能耽误。

大公司如何创新

有困难，但值得一试。

没在大公司工作过，你想象不出在大公司里创新有多难。随着规模变大，公司会不可避免地变得更加保守，不敢冒险。因为一旦失败，比起小公司来，大公司的损失会惨重得多，所以只要情况允许，他们会尽可能维持现状。但大公司也需要创新以谋求发展，何况大公司还有自己的优势。

有两大因素影响着大公司的创新氛围：企业文化和老板的观念。依我看，任何一家大公司都有潜力为自己的员工营造创新氛围。如果你发现在公司里难以实现创新，可以尝试以下方法。

20%法则

你也许听说过，谷歌的程序员有20%的工作时间可以用来从事创新研究。20多年前我在惠普工作时就这样做过，这个方法最早是从施乐帕克研究所学来的，至今仍然行之有效。在惠普实验室，我们的工作任务是技术创新，然后和产品部门合作“孵化”出产品。我所在的小组一共完成了五款产品，有四款是20%法则催生的，剩下的一款产品是公司高管命令我们完成的，结果只有这款产品被市场淘汰了。

人们误以为优秀的产品是战略规划的结果，或是来自公司高管的创意。其实，最好的创意大多来自于普通员工。20%法则鼓励普通员工自己尝试各种想法，发挥大家的主观能动性，让员工打心底里愿意倾注更多的激情和汗水去创新。

20%法则不仅适用于开发人员，也同样适用于产品经理和交互设计师。遗憾的是，大部分公司没有采用20%法则，我建议产品公司尝试这个方法。如果公司实在不同意在工作时间创新，那我们只好私下开展“臭鼬工程”了。

臭鼬工程

臭鼬工程是工程界的行话，原指秘密军事行动，现指在受限制的条件下，利用自己的时间，低调地进行创新研究。臭鼬工程拯救了很多大公司。

在大公司里，普通员工很难凭空获得允许从事创新研究。如果你能拿出阶段性的成果来，获得许可会容易得多。在这种情况下，只要不耽误本职工作，管理层通常会支持你的做法。

有一点要提醒大家，有些公司规定在职期间研究出来的成果都归公司所有，所以不要随意拿研究成果自行创业。如果公司因为某些原因不愿意帮助你，你才能尝试谋求其他途径来实现自己的创意。了解硅谷历史的人知道，当年斯蒂夫·沃兹尼亚克（Steve Wozniak）因为惠普公司不愿意进入个人电脑市场，所以离职创业，才有了后来的苹果公司。

主动观察

观察和倾听是最简单的创新途径。仔细观察用户使用公司产品或同类产品的一举一动，留心他们欣喜和失望的表情，假以时日，你肯定能想出办法更好地满足他们的需求。再找一位熟悉技术的开发人员合作，你们就可以着手改进产品了。

注意，应该选择实际用户作为观察对象，不要选择产品尝鲜者，更不能选择公司同事。测试产品用不着正式的可用性测试实验室，你可以去用户的住所、办公室、购物场所，请他们就地体验你的产品。不仅要观察软件能否正常使用，更要留心软件能否满足他们的需求。即使软件可用，他们真的需要吗？究竟什么是他们想解决的问题？

记住，创新不是发现新问题，而是用新方法解决已有的问题。观察人们对现有产品的不满，是创新的最佳途径。

改善用户体验

另一种创新途径是跳出技术局限，完善用户体验。改善用户体验不仅要提高产品的工作效率，更要剔除多余的功能，明白哪些功能是用户必须的，哪些是设计和开发带来的衍生物。

每款产品都有特定的实现模型，但用户脑子里装的是概念模型，他们对产品要解决的问题，以及如何解决问题有自己的想法。如果实现模型与用户的概念模型不一致，用户就会感到失望。找到用户失望的地方，就找到了创新的机会，至少是改善产品的机会。

收购小公司

最后，我们来谈谈“收购”别人的创意。虽说有些产品经理看不起这种做法，但收购确实是有效维持创新的手段。创业型公司如雨后春笋般出现，经过市场淘汰，留下来的通常都有其特长，可以作为收购对象。收购创业型公司不仅可以引入新技术，而且可以引入创新型人才，为公司注入新鲜的血液。

我建议大公司的产品经理多和业内活跃的创业型公司建立联系，互相帮助，互相学习。这种人脉关系也许能替公司节省上百万的资金。从以往的经验来看，创业型公司在选择收购自己的东家时，并不是只看收购价格，他们往往会选择有过合作关系的公司。

妥善安排收购来的新员工，让他们继续发挥特长，才能拓展产品线，保持市场领先地位。但很遗憾，多数公司没有处理好这个问题。

建议大家尝试以上的方法，帮助公司保持创新。德鲁克曾说过：“公司的核心竞争力在于创新。”我相信大公司一样可以创新，苹果公司就是最好的例证。

在大公司工作经常会感觉到束手无策，施展不开。然而，如果能够参照文中给出的十大秘诀并懂得合理利用资源，就会发现在大公司工作其实有一些明显的优势。

在大公司施展拳脚的10大秘诀

我曾与许多大公司合作，他们的产品经理向我抱怨工作时束手束脚，施展不开。我也在大公司工作过，知道其中的难处，但我相信只要懂得利用资源，在大公司工作有明显的优势。

也许你工作的公司目前规模尚小，但随着业务发展，总有一天你会面临同样的窘境。如果你的合作伙伴是一家大公司的话，那么你们实际上是在一条船上。了解大公司的运作方式，对双方的合作都有益处。在讨论如何顺利展开工作，让整个公司支持你的产品，协助你设计、开发、发布产品前，我先介绍一下大公司的现实情况。

首先，大公司都遵循一条潜规则——尽量规避风险。这并非偶然，随着业务规模变大，公司会不可避免地变得保守。因为大公司承担的风险更大，如果出现问题，损失也比小公司惨重。所以创新更容易发生在小公司里。在大公司工作，首先要面对的是公司现有的流程、规定和条条框框。

其次，多数大公司都采取矩阵式的管理方式，核心部门（如设计部门、开发部门、QA部门、运维部门、市场部门）是共享资源，产品经理要确保争取到足够的资源才能研发出产品。采用这种组织结构不是因为它的效率高，而是为了节约公司运营的成本。

充分理解这两点后，我来介绍在大公司施展拳脚的十大秘诀。

了解公司制订决策的方式

每家公司的企业文化各不相同，制订决策的方式也千差万别。如果公司制订决策的方式不符合你的习惯，不要老想着改变大家来适应自己，要学着融入其中。

虽然有些公司有明确的民主决策制度，但最终决策还是要请某位大人物拍板。你千万不要纠缠大家有没有没按照制度办事，与其抱怨，不如主动利用这一点。知道决策权在谁手里，你的工作目标就更明确了。了解他制订决策的方式，他是更看重原型演示、市场数据，还是客户的承诺和评价。如果你需要公司的支持，那么只需要说服他就可以了。

建立人脉网络

在大公司工作必须与人合作，你需要同事的协助才能完成设计、开发、发布工作。如果你喜欢单枪匹马的工作，创业型公司更适合你。

主动与各个部门的同事结交朋友，聊聊工作的事，向大家介绍你手头的项目，不要等到有事才去找人家。主动帮助他人，积累人脉关系。

拥抱“臭鼬工程”

在大公司里，凭空申请创新资源很困难。想靠几张画着产品构想的幻灯片就能说服老板是不切实际的。更可行的方法是找三五个志趣相投的同事在工作之余把产品原型做出来。你会发现产品原型具有超出想象的说服效果，比起枯燥的陈述，生动形象的演示更有吸引力。数不清的优秀产品就是这样诞生的。

自己顶上

说出来你也许不信，虽然大公司里员工众多，但真正需要帮手时，却总找不到人。即使是公司高管重视的项目，也难免资源不齐。遇到这种情况，你就得自己想办法了，比如，打电话找人帮忙，甚至自己顶上。在凡事都需要提交材料，有严格流程要求的大公司，与其对抗流程，不如自己主动填写、提交需要的材料。

很多时候产品经理还要协助编写技术文档，组织销售培训，提供客户服务。一切为了推出产品，不要计较个人得失。

有选择地据理力争

在大公司工作，多一个敌人不如多一个朋友。如果你不满意同事的工作，或者与他人意见不同，不要随便发脾气，除非这件事对你来说确实重要，值得你为之据理力争，撕破脸也在所不惜。与人辩论，要小心措辞，做到对事不对人，不要把对方逼到死角。你的目标是完成产品，别为了一场战役输掉整场战争。

会前沟通，形成默契

在重要的决策会议上，如果有人公开反对你的提议，你会变得非常被动。在这种公开场合下发表的意见，反对者很难改口，你想再挽回就很难了。与其临渴掘井，不如未雨绸缪，设法在会前达成一致意见。会议的主要作用是让与会者认识到大家取得了一致意见。因此会前应该逐一找与会者聊聊，了解每个人的立场，如果有不同的意见，对症下药及时化解，确保他们会投赞成票。

合理分配时间

大公司频繁开会，有些人每天忙于参加大大小小的会议，深夜回家还要回复邮件，忙得不可开交，产品却毫无起色。产品经理应该重新检查会议日程，划掉无关紧要的会议；学会充分信任同事，让他们自己拿主意。产品经理应留下时间完成自己的本职工作：制订产品战略，构思产品路线图，研究产品原型，分析竞争对手。

分享信息

不管在哪种组织里，沟通都是难题，大公司尤其如此——信息俨然变成了某种货币，大家只想获取，不愿支出。许多人把它看成私有财产，藏起来不愿与人分享。其实有舍才有得，分享信息会让你获得更多的朋友和资源，作为交换，别人也会毫无保留地分享信息给你。充分共享信息对你自己和公司都有好处，这叫共赢。

向上司借力

学会利用上司的关系，可以更好地开展工作。如果你的上司在公司里威望很高，你应该学会向他借力，利用他的人脉关系，传播你的理念，多向他请教，了解公司文化和组织结构。如果需要上司出面说服公司高管，你一定要事前做好充分的准备，为他提供翔实可靠的资料和信息，用实力取得他的信任，让他放心地当你的说客。

传播你的产品理念

多向同事传播你的产品理念，向大家描绘产品愿景，介绍产品策略，演示产品原型，分享用户反馈。不要低估了内部宣传潜移默化的作用。让大家（包括没有直接业务联系的部门同事）不遗余力地支持你。

结束语

不可否认，在大公司里工作得克服重重阻碍，为产品争取支持和资源实属不易，但大公司也有大公司的优点，产品会获得媒体和用户的高度关注，这是小公司望尘莫及的。一旦你掌握了充分利用大公司资源的方法，将会如鱼得水。我的朋友David Weiden说过一句话，形象地描述了人们在大公司工作的状态，我引用他的话作为本文的结尾：“大部分人游荡在黑暗里，他们只知道抱怨，却从不想办法寻找电灯开关。”

Marty Cagan，作为负责定义和开发产品的高级经理人为多家一流企业工作过，亲历了个人电脑、互联网、电子商务的起落沉浮，致力于通过写作、演讲、培训帮助客户打造富有创意的产品。

本文节选自华中科技大学出版社《启示录：打造用户喜爱的产品》一书和作者的博客。该书从人员、流程、产品三个角度介绍了现代软件（互联网）产品管理的实践经验和理念。特此感谢华中科技大学出版社与Marty Cagan先生授权。

本文选自《程序员》杂志2012年02期，更多精彩内容敬请关注02期杂志

《程序员》2012年杂志订阅送好礼活动火热进行中

随波而逝的巨星Jim Gray

baiyuzhong — Tue, 07 Feb 2012 13:30:40 +0800

文/刘江

1990年代初，微软计划进入企业数据库市场，开始给圈内的高手打电话挖角时，发现所有人都会提及一个名字，更令人惊讶的是，所有人都会说这个人比我更强，或者他已给我打过电话谈论此事。

这个奇人，就是Jim Gray。1998年，他因为数据库尤其是事务处理方面的开创性贡献而获得图灵奖。

1944年1月12日，Jim Gray生于美国旧金山一个普通人家，母亲是教师，父亲在军队服役。大概七岁时父母离异。因为家里穷，1961年Gray选择进入公立的加州大学伯克利分校就读。第一学年他曾因化学成绩糟糕一度放弃学业，跑到General Dynamics做实习生。六个月后对公司感到厌倦回到校园时，他选择了数值分析、离散数学等很多计算机方面的课程，凭借不错的数学功底，他开始如鱼得水，最后以优异成绩毕业，获得了数学和工程双学位。

之后Gray曾短时在贝尔实验室工作，参与过Multics项目，与Ken Thompson共事。很快他又返回伯克利，只用了三年就拿下该校历史上第一个计算机博士学位。期间对他后来学术影响较大的是，与一组同事一起将计算机科学应用于社会问题研究，比如失业、城市规划等。现在看来，这正是大数据的萌芽。

1969年博士毕业后，他在IBM研究院工作了十年。期间最著名的工作是参与了Edgar Codd和Don Chamberlin等在关系型数据库、SQL上的开拓性研究与实现。但实际上RISC之父John Cocke对他的影响最大。在1971年，Cocke和他已经在研究可以无限灵活扩展的架构（云计算！）。这使Gray能在当时争论纷繁的数据库学术大战中独辟蹊径，转向底层，同时思考各种数据库都面临的并发和故障恢复等基本问题，厘清了事务的基本概念以及现在已经成为常识的ACID属性，并给出了许多具体的实现机制。今天，所有电子化的商业和金融系统的可靠运作都离不开Gray的成就。

此后他先后在Tandem和DEC从事软件研发工作，并在事务和数据库性能、分布式系统等方面继续取得诸多研究成果。1995年，微软为了将其罗致帐下，首次在总部之外开设研究院。而在微软研究院宽松的环境下，他主持和推动的许多项目都极具科幻色彩，致力于应用计算机海量数据处理技术解决各科学领域的问题。2009年出版的《第四范式：数据密集的科学发现》一书是他这一思想的绝佳体现。他是大数据浪潮当之无愧的先驱。

不幸的是，2007年1月28日，喜爱户外运动的Jim Gray独自驾船在海上失踪。消息传来，彼此竞争的各大公司、无数爱戴着他的同行和门生都行动起来，将搜寻变成了一个大型的社区协作科研项目，并让全世界网友也能参与进来，还获得了不少学术成果，情景非常感人。只不过，这些努力最后并没有召回这位天才。

有才之人一般不易相处，但Jim Gray却是个大大的例外。他有着神奇的魅力和精力，在为数不多的时间内，全身心地倾听他人的诉求，给予点石成金般的指点和帮助，往往从此改变对方的一生。他热心审读大量各种领域的技术论文，给出自己的权威评论，还坚持给众多同行发送有价值的论文或者研究成果。正因为如此，在技术界竟然有成百上千人认为Gray是自己亲密的朋友或者导师。

仅仅数据库专家这个评价，完全不足以概括他多方面的成就和广泛的影响。Sendmail开发者Eric Allman说，Gray学识极为渊博，几乎知道任何事情，是堪与图灵、Dijkstra相提并论的计算机科学超级巨星。Gray的图灵奖演讲纵横捭阖，视野开阔，充分体现了这一点。曾任微软CTO的Vaskevitch认为Gray的最大贡献在于几十年不知疲倦地通过无私培养、提携和学术合作，影响和连接着成千上万的同行，跨越了公司的界限，帮助塑造了整个计算机科学社区。而Gray倡导的eScience理念则将这种影响扩大到更多科学领域。

需要过多少年，才会再出现一个Jim Gray？

本文选自《程序员》杂志2012年02期，更多精彩内容敬请关注02期杂志

《程序员》2012年杂志订阅送好礼活动火热进行中

阿里云服务综览

baiyuzhong — Mon, 06 Feb 2012 17:27:54 +0800

阿里云经过三年艰苦的探索与实践，参考业界的领先技术，独立开发出一套完整的云计算平台，并初步形成了一套比较完整的开放服务。我们将多角度介绍阿里云开放平台关键服务，希望向读者展现阿里云平台的全貌，进一步体验云计算的魅力。

弹性计算平台

弹性计算平台是最为接近传统用户需求的云计算产品，产品包括云服务器（虚拟化服务）和辅助的云负载均衡。阿里云的云服务器更支持用户以API的方式来灵活构建一个具备伸缩性的服务器架构。

ACE开发者平台

相比弹性计算平台，阿里云ACE开发者平台进一步为用户简化了网络应用的构建和维护过程。ACE平台系统基于云计算基础架构的网络应用程序托管环境，可根据应用访问量和数据存储的增长自动扩展。ACE支持PHP、Node.js等语言编写的应用程序。

开放存储服务和CDN

开放存储服务（Open Storage Service，OSS）是互联网的云存储服务。当用户面对大量静态文件（如图片、视频等）访问请求和数据存储时，使用OSS可以彻底解决存储的问题，并且极大地减轻原服务器的带宽负载。使用CDN可以进一步加快网络应用内容传递到用户端的速度。

开放结构化数据服务

开放结构化数据服务（Open Table Service，OTS）适合存储海量的结构化数据，并且提供了高性能的访问速度。当数据量猛增时，传统的关系型数据需要资深的DBA才能搞定；而使用OTS，数据再怎么增长，它都自动默默帮你搞定所有事情。这是时下热门的NoSQL在线服务！

开放数据处理服务

想深度挖掘出海量数据（如HTTP Log）中蕴藏的价值？开放数据处理服务（Open Data Process Service，ODPS）就是为了这个目的而存在。不用羡慕拥有几百甚至几千台机器的大公司数据仓库平台，也不需要写MapReduce程序，把你的结构化数据存储到ODPS中，使用SQL语句就能完成相同的事情。

云应用平台

使用HTML5、CSS3和JavaScript就能在移动平台上开发出用户体验优秀的移动应用？没错，云应用平台结合了本地应用和互联网应用的优点，便于开发功能强大的移动应用，并且还能非常容易地使用各种云服务。

体验云平台

在这些看起来很不错的服务的背后，有一个强大的大规模分布式系统作为基础平台。这个平台里的分布式文件系统、分布式调度系统等解决了各种各样的硬软件不可靠问题。我们提供了一个在线环境，来试试随意杀掉一台机器的感觉吧！不用担心，我们的分布式文件系统根本不在乎一两台机器宕机。

本文选自《凌云》杂志第1期，更多精彩内容敬请关注《凌云》专区

《程序员》2012年杂志订阅送好礼活动火热进行中

用云存储和CDN轻松搞定网站图片

baiyuzhong — Mon, 06 Feb 2012 16:56:12 +0800

文 / 倪浩

“无图无真相，有视频更好”。一般来说，网络用户都喜欢图片和视频，而不喜欢读干巴巴的文字。这看似单纯的意愿，却让网站的开发者和维护人员叫苦不迭——图片、视频等内容占用了一个网站的很多存储、带宽资源。是时候把图片、视频迁移到云存储，来释放被压得喘不过气的服务器和带宽了！

下面以一个网站的图片存储为例，来逐步了解如何使用开放存储服务（Open Storage Service，简称OSS）。

开放存储服务

要使用OSS，需要先在http://oss.aliyun.com网站上注册，注册成功后，即可在网站上的OSS管理中心创建bucket，上传、下载自己的object。

bucket是用户数据的命名空间，例如图片可以放到一个bucket中，视频放到另外一个bucket中。一个bucket存储的总数据量和文件个数都是无限制的。存储在bucket中的每个文件，称之为object。存储在object中的数据可以是任意内容，OSS不会去处理object中的数据。

对于每个bucket，OSS容许设置三种访问权限，即私有读写（private）、公开读私有写（public-read）、公开读写（public-read-write）。对于私有读写和私有写的权限，OSS使用API密钥对（AccessID/AccessKey）来保证你的数据只能被你自己安全访问，所以千万不要向任何人泄露你的安全加密对。API密钥对可以从OSS的管理中心获取到，如图1所示。

图1 OSS管理中心

初阶：使用命令行工具

对于开发人员来说，使用命令行工具可以更容易地操作OSS。命令行工具随Python SDK包一起发布，从开放存储主页http://oss.aliyun.com可以下载到。

安装好Python SDK包后（安装指南参考主页的SDK使用向导），首先用osscmd来配置你的安全加密对（以下以Linux环境为例，Windows用户需要用python path_to_osscmd来指定osscmd的路径）：

$ osscmd config –id=AccessID –key=AccessKey

配置完即可开始创建一个bucket，使用命令行工具键入如下命令创建一个叫做myimage的bucket，创建完调用osscmd的ls命令来列出已经有的bucket：

$ osscmd createbucket myimage

$ osscmd ls

由于bucket名字是全局唯一的，因此你创建的bucket可能和已存在的bucket冲突。建议使用公司的网址作为前缀来创建bucket，如com-abc-img。默认情况下，osscmd创建的bucket权限是private。对于Web图片访问，可以设置bucket的权限为public-read以将存储在OSS中的图片直接嵌入网页。可以使用osscmd的setacl命令来设置bucket权限为public-read：

$ osscmd setacl myimage –acl=public-read

接下来，上传一个图片到myimage中。为了使浏览器正确解析图片，设置它的类型为图片（image/jpg）：

$ osscmd put –content-type=image/jpg /path/to/top.jpg oss://myimage/

这样就成功地将图片文件top.jpg存入到了myimage中。这个文件的URL地址是http://storage.aliyun.com/myimage/top.jpg。对这个URL：域名地址是OSS的服务地址htpp://storage.aliyun.com，myimage是bucket的名字，接下来就是刚刚上传的图片名。可以将这个URL直接嵌入到HTML页面中的img元素中：

这里需要提示的是：在使用osscmd的put命令时加入-p参数，在上传完文件后，会打印出URL。

直接键入osscmd，不加参数即可输出全部支持的命令。

进阶：使用SDK通过程序来操作OSS

OSS提供了Python、PHP、Java、C、C#五种语言的SDK包，如果觉得直接调用OSS的REST API麻烦的话，可以使用官方提供的可靠SDK。

我们选择用时下流行的Python语言来操作OSS。上一节安装完Python SDK后，我们已经不需要更多的配置了。打开文本编辑器或者vim，你用EMACS？佩服你，是个牛人！

下面代码的作用是打印出自己的所有bucket列表：

接下来，用SDK向刚刚创建的myimages中写入网页的导航图片nav.jpg。代码如下：

如果没有报错的话，文件已经上传成功了。可以使用osscmd的ls命令来查看这个文件是否已经存在：

$ osscmd ls oss://myimages/

看到nav.jpg了吗？还可以用osscmd的meta命令来查看nav.jpg的属性：

$ osscmd meta oss://myimages/nav.jpg

输出中的第二列是nav.jpg的etag（即md5值）。回到SDK，接着再用这些代码继续传一些文件，然后用SDK来查看有哪些文件存在。

继续写下面的代码就可以列出myimages中的所有文件：

网站大量的图片，需要使用文件夹的方式来组织。在OSS里如何建立文件夹呢？非常简单，只需要在文件名之前加上文件夹名，OSS会自动为你创建出文件夹。使用osscmd来上传文件到myimages中的2012这个目录，并且用ls命令列出：

$ osscmd put /path/to/sidebar.jpg oss://myimages/2012/

$ osscmd ls oss://myimages/2012/

而使用SDK的代码如下：

用代码列出2012目录下的文件：

高阶：安全签名的URL和自定义header

对于有些设置为private的bucket，有时需要容许其中的某个文件能够被公开访问，但又不希望把bucket的权限设置为public-read而导致其他数据有泄露的危险。对URL进行签名能够有效地解决这个问题。使用osscmd对一个文件进行签名：

$ osscmd signurl oss://myimages/2012/sidebar.jpg –timeout=600

命令最后的timeout参数的含义是生成的链接在600秒内有效，超过600秒就不可访问。使用SDK来生成URL：

对于某些网站，如果要防止盗链（或防止搜索引擎爬虫导致的网站流量飙升），可以使用生成的URL嵌入页面，生成URL的过程不需要和OSS进行交换。

如果想在读取文件时，OSS支持返回一些自定义的响应头（response header），需要在上传这个文件时就设置好。目前，除了前面介绍的Content-Type以外，OSS还支持设置如下几种常用的HTTP响应头：Expires、Cache-Control、Content-Disposition和Content-Encoding。这些Header的具体含义，可以参考RFC 2616标准。使用API来设置这些响应头的方法如下：

经济、无需运维的云存储

以上介绍了OSS的基本功能，与传统的存储如NAS等解决方案相比，OSS更经济，并且为用户彻底解决了繁杂的系统日常运维、备份等工作。

传统存储系统随着业务规模的增长，必须不断地预先扩容，同时还要对存储系统中的数据不断备份，以面对可能突然发生的硬件故障。而使用OSS，用户上传的数据自动会有多份拷贝冗余，数据安全性达到99.99999999%。OSS在维护用户数据高可靠性的同时，也保障了服务的高可用性，承诺最低99.9%的可用性，所有繁杂的存储备份和硬件故障不再是用户的问题。

在网络方面，OSS的网络响应速度非常具有优势，保证了全国绝大多数地区的良好访问体验。

但当用户网站的访问量非常大，需要服务全国各地用户，特别是部分静态图片成为访问热点时，使用CDN服务，能够更快地将数据传递到终端用户，并且网络流量的开销也更为经济。接下来，让我们了解一下阿里云CDN的情况。

使用CDN加速内容加载的速度

阿里云CDN服务是一个遍布全国的分布式缓存系统，能够将网站文件（如图片或JavaScript代码文件）缓存到全国多个城市机房中的服务器上，当一个用户访问你的网站时，会就近到靠近TA的城市的服务器上获取数据，这样最终用户访问你的服务速度会非常快。

阿里云CDN服务在全国部署超过100个节点，能提供给用户优良的网络加速效果。当网站业务突然爆发增长时，无需手忙脚乱地扩容网络带宽，使用CDN服务即可轻松应对。和OSS服务一样，使用CDN，需要先在aliyun.com网站上开通CDN服务。开通后，需要在网站上的管理中心创建你的distribution（即分发频道），每个distribution由两个必须的部分组成：distribution ID和源站地址。

举例来说，需要对刚刚存储在OSS中的myimages这个bucket中的数据进行加速，那么源站地址即为http://storage.aliyun.com，CDN服务会自动为用户创建一个distribution ID，服务创建完成后，即可使用http://distributionID.aliyuncdn.com/myimages/someimage.jpg来访问原来存储在myimage这个bucket中的someimage.jpg文件。如果不想使用阿里云CDN生成的域名，那么可以将自己网站的二级域名，如cdn.abc.com，加入一个CNAME记录到distributionID.aliyuncdn.com。

创建distribution需要在阿里云网站的CDN管理页面操作。而当distribution创建好之后，即可使用SDK来对distribution进行操作，代码非常类似OSS的使用方法，接下来的代码列出了用户的distribution列表，并且将其中一个ID为myID的distribution中的一张图片从CDN缓存中删除。

由此可见，使用阿里云OSS和CDN，可以简单、经济地解决服务的存储和网络问题，毕竟，大多数网站或应用的存储和网络带宽多半是被图片或视频消耗掉的。

从整个业界来看，最近这样的面向个人用户的云存储如国外的DropBox和Box.net非常受欢迎。非常期待大家能在阿里云服务如OSS平台上开发出这么棒的应用！

本文选自《凌云》杂志第1期，更多精彩内容敬请关注《凌云》专区

《程序员》2012年杂志订阅送好礼活动火热进行中

MongoDB最佳实践

baiyuzhong — Mon, 06 Feb 2012 14:54:33 +0800

文 / Ines Sombra 译 / 李刚

将MongoDB加入到我们的服务支持列表中，是整个团队年初工作计划中的首要任务。但我们感觉如果先添加一项对NoSQL存储的支持，而不是先升级已支持的关系型数据库，可能对用户不太好，毕竟目前的用户都使用关系型数据库。

所以我们决定将引入MongoDB这项工作放到升级MySQL和PostgreSQL之后来做。到目前为止，MySQL 5.5的Beta版已在进行中，而PostgreSQL的9.1 Beta版也将进入流程，因此我们打算在2012年第一季度中应用这两个版本。

由于我们对MongoDB的关注，我们选择性地为几名使用MongoDB的用户提供了技术支持。在这个过程中，我们了解到了很多可能出现问题的地方。所以想借此文与大家分享Engine Yard眼中的MongoDB最佳实践。

如果你的MongoDB是定制化安装的，我们强烈建议你将自己的设置与本文讲到的内容进行对比，并进行必要的设置修改。

通常意义上的NoSQL最佳实践

已有很多文章对NoSQL选型方面进行过讨论。在选择一个数据库产品时，通常可能需要考虑以下因素：读写吞吐量、持久化、一致性以及延迟等。在Nathan Hurst的文章《Visual Guide to NoSQL Systems》中对这些方面都做了详尽的介绍。

数据库的选择是个大问题，本文不打算就这方面深入介绍，但希望读者能够自己去了解这方面的知识。一旦开发者了解得足够多，最后的结论永远都只有一个：没有任何一个数据库能够满足所有的应用场景。本文内容是基于选择MongoDB作为数据库存储上来说的。Engine Yard在这方面提出了如下四点建议。

全面测试。测试一定要使用切合实际场景的数据，并且需要尽量模拟业务场景的数据操作情况。否则，开发者会发现在上线后的实际场景下，可能导致一些性能瓶颈甚至发现整体架构上的设计缺陷。因此，尽可能使用实际场景的操作使用来进行测试，然后收集足够的测试数据。

千万别以为在关系型数据库上的使用方法可以被直接移植。MongoDB并不支持一些关系型数据库的功能，所以开发者最好先搞清楚MongoDB支持哪些功能。为了获得更好的性能，开发者最好多看10gen官方建议的文档设计和操作方法。另外，在使用MongoDB前，建议开发者做好对整个架构进行重构以适用新的存储模型的准备。为了更好地理解数据迁移的代价，建议阅读《The cost ofMigration》一文。

明确数据需要的一致性和可靠性。对MongoDB来说，可靠性不再过度地依赖将数据写入到磁盘的操作，更多的是通过将数据同步到其他节点的方式解决可靠性问题。绝不建议开发者在真实环境中使用没有备份的节点单独工作。这一点很重要，所以建议开发者了解其中的原因。

明确你对EBS的期望。如果你是Engine Yard云平台的用户（AWS EC2），那么应该知道，EBS的性能不太稳定。所以在测试时，你最好收集足够多的EBS设备吞吐数据以做考量。Engine Yard本身并没有对用户在EBS性能上做限制。

MongoDB最佳实践

以下是我们将MongoDB引入到服务支持列表过程中所遵循的原则。

总是使用Replica Sets。Replica Sets通过自动failover机制提供MongoDB的高可用性。在应用中，如primary机器出现故障，那么某一台secondary机器就会通过选举成为新的primary，整个集群仍然能够提供正常服务。我们的服务不会支持无同步机制的MongoDB布置方案。如果在开发者自己的环境中同步机制的代价过高，我们建议其使用一些云存储服务。Engine Yard目前已经与MongoHQ和MongoLab都建立了合作关系。开发者可以在合作者页面找到更多这方面的信息。

保持版本更新。保持版本更新很重要，10gen在每个版本中都会修复一些问题，使MongoDB的运行更出色。比如在2.0.x版本中，MongoDB的存储性能和并发性能就有极大提高，同时还包括索引优化、Bug修复以及compaction命令等一系列改进，以便开发者更方便地扩展其集群。如果你还在使用1.6.3版本，那就快升级吧。

不要在32位系统上使用MongoDB。在32位机器上，MongoDB只能存储约2.5GB的数据。因为MongoDB在内部实现上是通过内存映射的方式来提高性能的，所以在32位机器上其内存地址本身就限制了数据容量。在Engine Yard云服务中使用MongoDB，请使用Large instance来部署MongoDB。在实际产品中，我们也只支持64位的MongoDB。

默认开启journaling日志。MongoDB支持在写操作前记录journaling日志来提高节点的可用性。强烈建议在部署时开启journaling日志。注意数据文件的存放位置。在使用时，请确认你的数据文件处于一个持久化存储中（比如/data/mongodb目录）。也可以使用非持久化的设备进行数据文件存储，不过你最好小心再小心，因为这可能会对你的集群架构造成影响。推荐使用EBS进行MongoDB的数据文件存储。热数据最好能放在内存中。能够保持热数据（以及索引数据）一直放在内存中，这一点非常重要，它将对整个集群的性能造成影响。如果通过监控发现page fault的数量增加，那么很可能就是热数据量超出了可用内存大小。当热数据量超出了可用内存量时，通常有两种解决方法：增加内存和数据分片。建议先增加内存，再考虑通过数据分片的方式解决。

压力过大升级配置。如果机器负载达到65%，那么应该考虑升级机器配置。在日常使用中，最好保持负载低于65%。同时这也对数据恢复和纵向扩展有影响。当需要升级配置时，AWS建议按下面的顺序来做：Large、Extra Large、High Memory 4XL。而在更高配置的机器上，网络延迟也会更小。

分片需谨慎。分片策略会受数据访问特点的影响，所以在进行数据分片前，最好先理清楚数据的访问特点，并想明白是否确实需要分片。分片字段对性能的影响非常大，所以选择一个好的分片字段是非常重要的。Config节点对整个集群的健康运行是至关重要的，所以一旦你选择使用分片机制，就一定要保证有3个Config节点。永远不要删除Config节点的数据，要确保频繁地对这些数据进行日常备份。如果可能，通过域名来指定节点的地址，比如在/etc/hosts文件中指定相应的本地域名，这能让你在集群配置上更灵活。Config节点的压力很小，但还需运行在64位机器上。千万不要把3个Config节点都放在同一台机器上！

另外，如果你要部署一个分片集群，那么可以向Engine Yard专家服务预约咨询服务。

使用Mongo MMS图形化监控服务。如果你还没有完善的MongoDB监控，可以尝试Mongo MMS。Mongo MMS是10gen官方发布的一个监控服务，可以将集群的各项健康指标以图形化的方式汇总展示。

感谢Ines Sombra的翻译授权。Ines Sombra，Engine Yard数据工程师，关注大数据领域。

原文链接为http://www.engineyard.com/blog/2011/mongodb-best-practices/

本文选自《程序员》杂志2012年02期，更多精彩内容敬请关注02期杂志

《程序员》2012年杂志订阅送好礼活动火热进行中

管理你的老板

baiyuzhong — Mon, 06 Feb 2012 14:01:05 +0800

文 / Michael Lopp 译 / 何逸勤，卞斌

怎样评估自己老板的风格？怎样与他高效协作？本文作者具备20多年IT管理经验，以自己在生死攸关时刻所做的抉择为例，为广大IT工作人员提供积极的建议。

每个人都意识到不对劲儿。高层主管失踪了。会议不是被取消了，而是被无视了。这气氛像是公司重组，但这家创业公司目前经营得还不错。我们刚刚完成第二轮融资，全体会议描绘的前景也很乐观。那么，高层主管都干嘛去了？最后，我被仓促地安排与高层主管和高级经理开会。

“我们决定辞退工程副总裁。”我老板托尼？他表现得还好吧。我想不通为什么会这样。

事后回想，谁都没有清楚地解释这位副总裁与其他高层主管之间有何嫌隙，但董事会里的勾心斗角不是本文的重点。尽管如此，从这件事中我们还是可以学到两点：首先，你喜欢的老板和其他人不一定能相处融洽；其次，准备接受意外。

公司很快就安排了一个可靠的人选替代托尼。作为新上任的老板，吉姆利的工作过渡得还算顺利。新官上任三把火，他很快和我安排了一次面谈，并且清楚地说明这是专属于我的时间，我有整整20分钟可以畅所欲言。“有什么话就说出来，兰兹，我洗耳恭听。”

这次面谈不是为了解决问题，而是要获得对公司环境的大致了解。作为老板，他想了解你的情况。吉姆利没说太多话，只是频频点头。不过，面谈即将结束时，他已准备好发出行军命令，总共只有一句话，一开始我还对这样的简洁有点失望。

“兰兹，我不喜欢意外。”

这是一个表面上简单的要求，而我越揣摩越觉出它分量不轻。它的涵义是：兰兹，我相信你明白何时该及时向我通报情况。

评估你的老板

有一件事是我可以确定的：你和你的老板之间存在很多不同。所有这些不同之处足够写成另一本书了，但本文重点将放在你和老板的沟通上，因为只有学会这一点，才能了解你们有多么不同。不管是刚换了新老板，还是已与现任老板相处了3年之久，下面的这一系列问题都有助于你洞悉他们的沟通方式，以及他们偏好哪种信息。

有一对一的面谈吗

关于你的老板，第一个问题就是：他是否抽出时间与你进行单独的谈话？一对一面谈是指你和老板之间的频繁的定期交谈，如果你们没有这种安排，那么我真不知该从何说起了。

老板要对你职业的健康发展负责，而一对一面谈是他例行检查并跟进事态发展的时机。没错，一对一面谈也是了解团队和项目状况的时机，但那些信息还可以从公司的其他渠道获取。一对一面谈中，应该定期开诚布公地讨论你工作中的表现。类似谷歌等成功大公司员工对经理的比率极高，也就意味着定期的一对一面谈无法实际操作。随之而来的问题是：“这些员工如何成长？”没错，编写代码、连续工作27小时以赶上最后期限，这些都会给你很多经验。但此时此刻，在你老板的脑袋里，很可能正好就有可供参考的免费宝贵经验。老板还要扮演导师的角色。他比你见多识广，意味着可以将任何问题、想法或者困难摆在他面前，而他会就此发表意见……很可能是有价值的。

缺乏一对一面谈，也就是缺乏指导，意味着你需要到工作第一线去获取经验。当事事都需要亲身体验时，试问你老板的价值体现在哪里？如果没有花时间把自己的已有经验传授下去，他的作用不就只是一个项目经理吗？如果你们没有安排一对一面谈，那就提出要求。也许没办法每周一次，那就每月一次，但这是重要时间，可以思考你的工作和事业，并进行规划。

部门会议是随意的还是事先安排的

老板对信息的偏好可以从他主持部门会议的方式来辨别。通过分析他如何安排和主持一次会议，你可以很清楚地看到他希望如何呈现信息。我有一套用于评估工程师的分类方法，同样适用于管理者。这套方法将管理者分为两类：有机型和机械型。接下来我会对两者进行简要的说明。

有机型管理者大量地使用“感觉”这个词。他了解团队中每个人的性格，原因当然是他会跟团队成员定期进行一对一面谈。他希望了解你的感受，因为他很清楚，一个人本性中的缺点会很大程度上影响团队和项目。
机械型管理者通过事物的结构认识世界。和任何典型的极客一样，他精神上遵循着“事物如何运行”的流程图来与世界互动。机械型管理者看重的是可预测性、一致性和事实。

根据这些简单的描述，让我们看看这两种人将会如何安排部门会议。

会议有议程？机械型。
会跟进？机械型。
鼓励自由辩论？有机型。
会在管理者不参与的情况下进行辩论？有机型。
辩论限制在指定的时间内？机械型。
分配给会议的时间都被塞得满满的？机械型。
可以搁置某些议题？有机型。
经常会搁置某些议题？有机型。
是一次有趣的会议？有机型。

了解你的老板是有机型还是机械型，只是大方向上的分类，而不是绝对的。我就是有机械型倾向的有机型管理者。你的老板也是两者的混合体，而且他性格的不同方面会在不同场合表现出来。我上一个老板是非常强烈的有机型；而当高级管理层开始倚重他后，他转变成了彻底的机械型。

如果想和老板沟通顺畅，就要搞清他是哪种独特的有机型/机械型混合体以及他会如何表现出来。

对偏向于有机型的管理者，你无需费心思调整或者改变自己的沟通方式来适应他，因为无论你的性格和沟通方式是怎样的，他都会主动地适应你。有机型管理者非常了解人性，而且可以熟练地引导谈话方向以得到他们需要的信息。机械型管理者要求结构性和可预测性。我曾经遇到这样一位老板，他的机械型是如此之典型，以至于我只是改变了一对一面谈时情况汇报的顺序，他都会明显地不安。和机械型在一起时，不要临场发挥。你要让他们知道计划是什么，然后按计划提供信息，最后确认信息接收无误。

截然不同的沟通方式会妨碍有效沟通。机械型认为有机型热衷于唠叨不休，而有机型则认为机械型是冷血的机器人。他们都错了。如果你和老板之间恰巧有这样一道沟通的鸿沟，请记住，架起一座桥梁既是你的责任，也是他的责任。

要求状态报告吗

职业生涯中，对于状态报告是否有价值这个问题，我的态度一直来回摇摆。我内心的机械型倾向喜欢这种每周定期安排的节奏，对工作进行回顾和交流；内心的有机型倾向则提醒我，如果过度依赖状态报告来了解公司动态，那说明我在办公室窝得太久了。

状态报告是机械型管理者的标志。要求状态报告的可能不是你的老板，可能是老板的老板，但这不是我们感兴趣的。我们假设是你的老板要求状态报告，从中你能得到什么信息？

在我看来，状态报告是一种迹象，说明老板觉得组织内的信息流通不顺畅。不是说他是偏执狂，只是他获取信息的需求没有得到满足。所以他将状态报告看做填补自己感觉到的信息真空的手段。

你要搞清楚这个问题：为什么他会觉得存在信息真空？也许他是典型的机械型，不具备从走廊谈话中收集情报的社交技能。也许状态报告只是他惯用的信息收集方式，或者他其实更愿意从和你的一对一面谈中获得更多信息？

如果状态报告是公司更高层的强制性要求，或者就是公司文化的一部分，那你很可能无法摆脱，我建议就欣然接受吧。带有消极抗拒情绪的、枯燥无味的流水账不是优秀的状态报告。你应该把它当做一个机会，记下这一周发生了哪些事情，它们有哪些重要之处，下一步要怎么做。

如果你的老板不是出于任何有价值的目的，只是固执地要求状态报告，那你有必要让它停止。为此，首先你要搞清楚他是想填补哪个沟通缺口。

他是机械型，不喜欢进行面对面的沟通。好吧，确定好议程，提前发给他，并严格遵守议程，按时完成会谈。这算不上真正的一对一面谈，但这是一个开端，随着时间的推移，也许他会放松下来。
他有太多的直接下属，没有足够的时间。也没问题，不妨对部门会议进行调整，让它在某些方面变得像良好的一对一面谈？

我强烈建议进行面对面的直接沟通，因为虽然状态报告可能是有条理的、可靠的，但与对方四目交接时能够了解到的信息是其他任何方式无法比拟的。

安排什么类型的会议

评估你老板对信息偏好的另一个办法是，观察在一对一面谈和部门会议之外他都安排了哪些会议。这里所说的不是他出席的会议，而是那些他花时间安排的定期或一次性的会议。这些都不是他被迫参加的会议，而是他想参加的会议。你会发现这些会议分两种类型。

技术会议：对技术的深入探讨。这种类型的会议上，老板会乐意深入到技术中去。这种会议不是评审已做出的技术决定，而是经过讨论后作出决定。你的老板安排和主持技术型会议，是为了提醒自己曾经也是工程师。

协调会议：项目会议、状态会议、全体会议——协调会议有几万种不同的名称，但其目的都是一致的。它们是为了解答这个问题：“我们的步调是否一致？”这些会议通常是项目经理和产品经理负责的，用来为跨部门的项目把脉，所以问题是：“你的老板为什么要安排一次协调会议？”谁的步调不一致？

在对老板进行上述评估时，我们感兴趣的不是某一次会议，而是某一段时间内的所有会议。你需要回顾一下前两周老板安排的会议。有很多技术会议？说明他仍然认为自己是工程师。很多协调会议？你的老板正在试图协调公司中某些部门的不同意见。

传统观点认为，当成为管理者后，就要跳出自己职业生涯的技术层面去看问题，让那些和代码直接打交道的人做艰难的决定。但我认为在这个问题上需要取得平衡。完全技术型管理者将看不到项目大全景，遇到和人事有关的棘手问题挡道时会摔跟头。但过于专注项目的管理者则可能已经忘掉了那些能够激励工程师的基本原则。和有机型/机械型分析一样，在你对老板的会议进行评估时，要观察他们落在技术/协调倾向型的哪一段上，这样你才能判断他们喜欢得到什么信息，你应该向他们描述技术细节还是项目细节。

会越俎代庖吗

如果一切顺利，老板可以从直属员工、自己的老板和同级别的同事身上得到想知道的一切。然而，“一切顺利”是很罕见的情况。公司里，有众多的影响因素，使信息传播的速度各不相同。有些时候，不知何故，你的老板“越俎代庖”。“越俎代庖”是一种比喻的表达，表示老板跨越了他不应该跨越的组织界限。典型的“越俎代庖”举动是，一名高级管理者绕过他的直接下属，与下属的直接下属对话。对这名管理者的举动，完全会有合情合理的解释，但这同样会从很多方面破坏团队的沟通和士气。

我来解释一下。假设高级经理弗兰克手下有一名叫鲍勃的经理，鲍勃手下有一批员工，其中一位名叫亚历克斯。某天，弗兰克为鲍勃的团队中一个未解决的Bug而忧心，但通过各种方式都联系不到鲍勃。万分沮丧之下，他直接找到了Bug的负责人亚历克斯，并询问Bug的解决进度。亚历克斯恰好检查过这个Bug，并且已检验出它属于用户错误，他马上就帮弗兰克解决了烦恼。皆大欢喜，不是吗？如果单就这件事来看还好，只是人与人之间的沟通过程。但现在弗兰克明白他可以即时从亚历克斯处获得Bug解决的进展，而亚历克斯也觉得自己获得了大老板的赏识。现在的问题是：他们把鲍勃放在哪儿了？军队中，要严格地令行禁止，但软件开发行业中不是这样。然而，组织架构图，以及管理者和员工的关系之所以存在，是有某种原因的。这些关系规定了每个人负责什么。前面的越俎代庖例子中，弗兰克的错误在于孤立了应该知情的人员。

越俎代庖侵权行为可能发生在组织架构图的任何方向上。它是指在信息流动和决策过程中，故意绕开某些人。如果你的老板是越俎代庖的侵权者，那么，不是因为他没有得到想要的信息，就是他不明白在团队中人们应该如何沟通。

基本要素

大事不妙。三楼的公司总部里，你在参与跨部门会议，有一名副总裁站起来说了几句无伤大雅的话。这几句话他只是轻轻带过，但你听出了弦外之音，看清了整体的局势：他想要对你老板手下的一个团队及其员工做出调动。噢，糟了，大事不妙。

获得这个信息后，下一个问题是：“你打算怎么将这个关键的、刻不容缓的、有争议的信息呈现给老板？”是的，假设你喜欢你的老板，并希望尽快告诉他这个消息。你该如何包装这条信息，以便有效地传达？有机型管理者想要在第一时间听到充满激情的表达：“他正在窃取你的团队！”机械型管理者则希望你在适当的时机慎重地、有条理地递交一份材料。

信息的包装不止于此。哪些不该说？哪里该补充上自己的想法？你本能地想和老板分享所有信息，这很好，但如果这就是你的策略，那你的行为和把资料从A点移动到B点有何不同？用即时通信软件、微博甚至对讲机就能做到同样的事情。

诀窍是将事情的基本要素提炼出来，在适当的地方加入自己的观点，并根据老板对信息的偏好，用适当的方式传达。你可以省略细节。相信我，他曾经听过这件事情，并不是完全一样的说法，所以他会问很多问题。他会凭着自己的经验，弄明白你讲的事情跟别人的有何不同。

及时通报

吉姆利表面上看来是有机型，但有着消极抗拒的机械型倾向。这意味着他会定期举行富有成效的一对一面谈，他能胜任走廊里的谈话，他能与各种性格的人良好互动。但当他感到压力，或者走投无路，或者生气时，他就变成了狂怒的机械型，他会细查每一个细节，自告奋勇参与代码编写，重新回归工程师的身份。

他一开始做出“我不喜欢意外”的要求，是因为他知道自己的性格会突变。他知道当有大事发生时，他会越过平常的界限，所以他说“我不喜欢意外”，其实是在暗示：“如果最后我措手不及，那你不会喜欢你自己需要承受的后果。”

本文节选自人民邮电出版社《你就是极客！—软件开发人员生存指南》一书。该书是软件工程师的职场指南，以虚构的人物和情景描述极客的日常工作，并巧妙回答了他们遇到的各类棘手问题。特此感谢人民邮电出版社图灵文化发展有限公司授权。

本文选自《程序员》杂志2012年01期，更多精彩内容敬请关注01期杂志

《程序员》2012年杂志订阅送好礼活动火热进行中