近年来，AWS一直被公认为是最大、最好的云计算平台。不过随着谷歌和微软等竞争对手的加入，市场竞争愈加激烈，一些人也开始质疑AWS的旧习惯对于商业的影响。Foundry集团的执行合伙人及TechStars的创始人之一Brad Feld作为质疑人群中的一名评论家，用形象的比喻方式描述了AWS的现状：蝎子的本性是蜇人，即使这不会给它带来最佳利益。

本周，Feld接受了Structure节目的采访，作为本期节目的重点，他不仅介绍了他公司旗下公司的基础设施趋势，同时详细的解释了他对AWS的比喻，重点说明了AWS和所有的云供应商如果想保持在IT基础设施候选榜中的位置应当占据的三个领域。本期节目内容都很有价值，你可以更多的了解云计算经济现状，以及创业公司在面对大公司消费者和合作伙伴时的调整策略。

当扩展发生时，每一分钱都有意义

“传统服务的扩展持续增长……你的网络服务的卓越运营，或任何围绕基础设施的商业行为都会成为商业中的重要特征。”Feld解释说：“基于AWS云服务平台，你没有享受到你所认为的成本降低服务，而且还需要别人来管理你的资源……因此，以前炒作公有云服务但没有运维的人们沉默了。”

他还补充到，在这之前，一些对AWS价格和体验服务失望的公司已经开始测试SoftLayer、Rackspace等其他公司的云服务，这些公司能使客户在使用云服务的同时对自身的资源具有更多的掌控权。越来越多的用户开始尝试其他公司的云服务，尽管他们只是在colo云中心安装装置，但是他们却看到了令人印象深刻的结果：

“当你体验到另外的服务时，就会感觉很棒。因为在你直接控制的情况下，所有纠结的问题都消失了，只剩下一个原始的经济学视角……我们见到了20%的利润提升……这意味着33%的毛利润提升。所有的成本都似乎直接跌到了底线。”

不过，Feld说道，进行价格竞争，成为最低成本的供应商是亚马逊的优势之一，这也会为他带来益处。也就是说，AWS使用低成本来避免Google过多、过快的扰乱亚马逊经济，虽然不久前Google就这么扰乱了微软。“要站在一个非常强有力的位置才有资格说：‘我们将改变这场定价游戏的局面，’”他说：“如果你回顾15年前，微软的Office可以获得很多利润……但是好像一下子之间，今天的人们开始质疑‘为什么我们要为这个东西付费？’”

自服务和昂贵服务之间的妥协

Feld承认近年来AWS的服务已经变得越来越好了，但是这些进步是以增加用户的AWS账单为代价的，许多创业公司认为AWS的价格太高了。如果越来越多的公司觉得他们为服务支付了高额成本，那么他们也应该理所当然的认为应该得到顶级服务：

“这种挑战对AWS是很失败的。也就是，AWS感觉很良好，但是用户实例化的某些地方出现了问题，而且这些问题是消费者无法解决的，这就是一个黑盒子，即使服务人员在努力的尽快解决问题，但是他们在这种情况下找到问题的所在之处就是延迟。这种情况真的很糟……试想你有14万的付款用户，此时出现了一个离你很远很抽象的问题时，虽然你支付了高额的服务费，但服务还要延迟，这真的很不爽。这种情况即使出现的不是很频繁，我也会觉得‘这不适用于我们公司’”。

当服务中断发生后公司不得不以支付赔偿或者某种形式进行售后服务，此时公司高管就开始寻求替代方案。Feld说这种情况发生在“我们所投资的70家公司中的部分公司，至少是多于1家少于10家”。

市场上的声誉至关重要，管理市场上的声誉

Feld说，随着这种抱怨公司的增多，公司的声誉开始受到影响。突然间为其它公司开辟道路的那家公司开始受到用户的不满回应，因为用户有其它IT供应商可以选择：

“有趣的是，一些有规模的公司开始给亚马逊施压了。他们一边付着高昂的费用，一边说：‘我们真的，真的，真的不需要这些。’这是一个转折点，这些公司不再是高兴的消费者了，也不再是那些由衷赞扬AWS的消费者了。他们是那些你不想要的消费者，他们虽然被迫接受你，却是满腹怨言。”

大公司和他们的小公司合作伙伴也可能落入挑拨合作伙伴生态系统的陷阱——AWS被控告参与其中的一部分。Feld在90年代初是微软的早期合伙人，对这种情况十分了解。也可能是客户需求或者只是贪婪的原因，不过大公司仿照小公司合作伙伴提出廉价、次的产品可不是什么好事。

“渐渐地，创业公司开始互相交流：‘你要小心点，因为我们和亚马逊进行了管理层会话，结果是这样的’”Feld说：“两个月后他们推出了一款有竞争力的产品，就像这样，我们觉得这对我们非常不利，我们花费了很多时间告诉他们我们所做的一切，准备和他们进行深层次的合作，但是他们却推出类似的产品与我们竞争。”

“首先是为人编写程序，其次才是计算机”，这是软件开发的基本要点，软件的生命周期贯穿于产品的开发、测试、生产、发布、用户使用、版本升级和后期维护等长期过程中，只有易读、易维护的软件代码才具有生命力。

在实际的软件开发过程中，可能是由于工作很忙的原因，很多开发人员只注重实现程序的基本功能，而忘记了编程规范，因此写出来的代码只能让计算机看懂，人要看懂很不容易。更有甚者，有些项目组为了赶进度，明确要求组员以实现产品功能为主，代码能够运行起来就可以了。低要求产生低质量的代码，既然“上头”都这样要求了，那还有必要写出“让人能够读懂”的代码吗？

如果不为人编程，带来的后果是？

进度是赶上了，产品也交付出去了，一切看来是OK的，但问题也就来了。前方产品故障频发，后方开发人员不停地扑火。这个时候，他们才发现之前别人写的代码很难读懂，甚至连阅读自己写的代码都十分的困难，真是悔不当初。如果开始的时候能够将代码写规范一点，文档配备齐全一点，何至于此？

“好”的代码和“不好”的代码给人的感觉是千差万别。当我们看到优美的代码时，会有一种想继续研究下去的欲望，甚至会有一种觉得很享受的感觉。相反，当我们看到丑陋的代码时，就会咬牙切齿，因为它不仅不利于阅读，还会浪费我们很多时间，降低我们做事的效率。

一般说来，“好”的代码和“不好”的代码给我们的印象有如下几种：

排版工整 VS 排版不工整

我们打开一个代码文件的时候，最先看到的就是其排版怎样，这也是最直观的感觉。当代码排版工整时，我们很容易找出其条理和逻辑，会很快理解其到底要实现什么功能；而排版不工整的时候，我们的眼睛会觉得很累，进而影响了我们的思维。

命名规范 VS 命名不规范

在看完排版之后，我们就会看到每个函数和变量的命名。由于一般项目的代码行数都比较多，我们不可能花很多时间去理解每个函数和变量到底是何用意，到底是拿来做什么的。这就要求我们在编码的时候，使函数和变量的命名具有自说明性，让它们自己告诉读者是做什么用的，而不是要别人花大量时间去研读后才能知道。这在一定程度上反映了开发人员的态度和专业化程度。

例如，一个处理消息的函数，命名为ProcessMsg和FunctionA，哪个更好呢？显然是前者。我们只要一看到其名字，就知道它是做什么用的。

再如，有三个变量，命名为ReturnValue、MaxNum、SumOfTwoNum，我们就能一下子明白它们有何用途。第一个变量用于作为返回值，第二个变量用来存放最大数，第三个变量用来存放两个数之和。这太明显了，你都可以不用去问元芳，自己就能搞清楚。而如果同样三个变量，命名为i、j、k，你就无法一眼看出它们到底有什么用，还要花大量的时间去阅读代码，甚至用几个小时的时间，你还不知道它们有何用途。这时，你的老大来问你事情做得怎样，你照实一说，他便说你无能。其实你是“哑巴吃黄连”，怪就怪别人没有把代码写好。

注释得当 VS 注释不得当

阅读代码，我们还会注意到其是否有注释，注释多还是少。这也是很直观的。

如果代码实现的功能较为复杂，那么添加注释是必不可少的。在恰当的地方，使用恰当的注释，能够让读者觉得思路豁然开朗，他们会默默地在心里感激你。注释过少或没有注释是不行的，就像我们吃饭一样。如果一碗青菜里面什么也没有，你会觉得很乏味，没有食欲。如果放上一点辣椒酱，就会觉得食欲倍增。不管你信不信，反正我是信了。

但是，注释也不能过多，不能将有用的代码掩盖住了，不能够喧宾夺主，让真正实现功能的代码成了陪衬。

为人编程：如何才能写出让“人”看得懂的好代码

那么，我们如何写出让“人”能够看懂的“好”代码呢？这个过程不能一蹴而就，要循序渐进，要从我做起，从身边做起，不断地提升个人编程的境界。

个人认为可以考虑从以下几个方面入手：

第一，对新入职的员工进行软件编程规范的培训。在刚开始工作中的时候，让他们严格参照编程规范来编写代码。越早开展编程规范的训练，越是能够早地养成编写规范代码的习惯，写出的代码也就越清晰。顺便说句题外话，很多IT公司没有这方面的意识，只顾对企业文化进行培训，以为这样就能够让员工的忠诚度增加。实际上，这只是个异想天开的做法。

第二，定期在项目组开展编程规范方面的主题讨论，强化大家的意识。老员工写出的代码对新员工有示范的作用，如果老员工写出的程序都是可读性很差的，那么新员工会怎么想呢？他们又会怎么做呢？很多开发人员每天只顾埋头苦干，却忽略了一些最基本的东西，因此能力很难再次得到提升。在编写完代码之后，不要就以为事情做完了，还要编写一些项目文档，如详细设计文档、单元/集成测试文档等。在这些文档里面，把自己的思路写清楚，方便以后自己或他人查阅起来能够很快理解程序思路。

第三，开发人员严格按照公司制定的编程规范来书写代码。变量如何命名？函数如何命名？注释如何写？代码如何排版？这些都有严格的要求，作为一个合格的软件开发工程师，编写规范的代码是基本的要求。当我们阅读到书写优美的代码的时候，是不是心里面会觉得很爽？从某种程度上来说，代码编写的规范程度可以体现一个程序员的态度和专业素养。

第四，项目组要严格执行同行评审流程。大部分IT公司为了提高产品的质量，都有一个叫做“同行评审”的流程，也就是让项目组成员相互检查各自的成果，大家相互学习、取长补短、共同提高。但是，可能是中国文化的影响，大家都比较顾及面子，因此不愿意将对他人真实的想法表达出来，也使得“同行评审”流于形式。当然，也许你对别人的程序确实没有意见，那就另当别论了。对他人开诚布公地提意见并不是冒犯，而是大家相互学习的一种很好的方式。

第五，最重要的是，个人要有编写规范代码的意识，要不断地学习各种提高编程能力的技术。不管别人对你怎么说，如果你本人不想把程序写好，那么纵使万般外力，又如何？程序员虽然工作很忙，但也要抽时间来学习新的技术，这样才不会被新技术淘汰掉。

“长风破浪会有时，直挂云帆济沧海”，对于很多人来说，编写出能够让计算机读懂的程序就已经足够了，但如果想要成为一位优秀的软件开发工程师，那么就要力求写出让“人”能够很容易看懂并领会的代码。这是一个长期的过程，大家要有“万里长征”的准备，要有“愚公移山”的精神。