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

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

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

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

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

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

排版工整 VS 排版不工整

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

命名规范 VS 命名不规范

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

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

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

注释得当 VS 注释不得当

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

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

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

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

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

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

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

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

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

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

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

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

而在过去一年多的时间里，国内的云计算领域发生了很多重大事件，比如：AWS入华、Azure正式商用、阿里云强势爆发、UCloud/青云等独立第三方云服务厂商获得大笔风险投资等等， 种种迹象都表明云计算在国内已经步入加速发展阶段。 对于上述三个现象，我目前的看法是：

IaaS API方面：主流的公有云IaaS厂商都提供了API。 但是， 有了API并不代表其坚持API优先的原则。 API优先要求云服务提供者“Eat your own dog food”，即通过调用基础服务的API来构建各种上层服务，同时给生态圈合作伙伴提供平等的机会。

原生云应用方面： 云的成功案例越来越多，但是大部分集中在游戏等行业， 对传统行业的渗透才刚刚开始。另外，我们还缺少像Netflix这样毫无争议的示范案例。

PaaS方面： Cloud Foundry开始偏向企业私有云领域。由于大部分的公有云用户对云服务器的需求仍在个位数级别范围内，因此他们对第三方自动化管理部署工具、应用生命周期管理、混合云管理工具的需求仍不强烈。

成本费用（Cost）和安全（Security）一直以来都是公有云的两个焦点问题。 本文的主旨就是讨论云服务的计费模式。 下面是笔者观察到的国内公有云计费方面的两个现象，主要涉及计算资源的计费模式。

现象一：包年包月

包年包月对服务提供者和消费者都有好处。云服务提供者可以将包年包月类型的虚机集中起来管理，可提高虚机密度，进而提高资源使用效率；云消费者可以降低使用成本。 包年包月计费方式看似和AWS的预留实例类似，但是实质上有许多不同之处。

1. AWS预留实例不影响用户使用EC2的方式，只是在计费时价格不同而已。当用户创建虚机时，无论用户是用管理控制台、CloudFormation、OpsWorks、命令行工具、还是第三方管理工具，其计费结果都是一样的。但是对目前国内云服务商比如阿里云， 用户只能通过管理控制台才能订购包年包月虚机， 用户无法通过API订购包年包月虚机。
2. 按量计费启动的虚机无任何折扣，其价格比包年包月贵很多。 如果用户订购的是按量付费类型虚机，无论其订购多少、使用时间多长， 用户都无法享受到任何折扣。 任何云服务都是可编程的资源（API），Cloud-Native云应用会充分利用这些API来实现高可用、可扩展、安全的分布式应用。 按量计费的虚机将会是未来的主流，云服务商应该想办法降低按量计费的虚机的使用成本。

从目前看， 降低用户使用计算资源费用的办法主要有三个：AWS的预留实例方式、Google的阶梯使用折扣方式（Sustained Use Discounts， 对于一个虚机，单价在一个计费周期内是随着运行时间的增加而反向下降的）和国内特色的包年包月方式。 它们各自的特点和区别是：

1. AWS预留实例方式不会影响用户的使用方式，但是AWS预留方式帮助用户省钱的前提是用户必须能够准确预测未来计算资源使用量。 由于业务的不可预测性， 准确预测未来资源使用量是很难的。 AWS预留实例采购方式通常是1年或者3年，这使得预测变更加困难。

2. Google的阶梯使用折扣方式不会影响用户的使用方式，同时用户也不需要预测未来资源使用量，最为简单直观。

3. 国内的包年包月和按量计费是互相排斥的方式， 影响用户的使用方式，而且按量付费方式无任何折扣。

本文的重点不是关注云服务商的绝对价格。下表列出了国内外典型云服务厂商一款相似虚机类型（2核8G内存Linux虚机）的月平均费用对比， 主要是想让大家对各厂商计费方式有个直观的认识。

现象二：秒级计费

一些国内新兴的云服务公司把秒级计费做为其特性之一进行宣传， 取到非常好的效果。这是因为Google的计费最小单位是10分钟， 而AWS/阿里云等的最小单位更是高达1个小时， 和秒级计费单位有很大差距。

但如果用户使用云服务达到一定的量，则最小计费单元对用户使用云服务总费用的影响是微乎其微的。从上述的对比表格中我们可以看出， 假如用户使用一个月的时间， 青云的费用并不比其他云服务低。 这和电信运营商对语音通话的计费单位是按照分还是按照秒的道理是一样的。整体性降价对用户更有实质意义。

秒级计费更多还是反映了云服务的使用哲学，即根据业务的变化，用户可以通过API（或者是基于API的管理工具）动态调整资源的使用量， 由此来节省费用。 比如， 晚上的时候，业务量都比白天小，用户可以设定自动伸缩来动态调整资源的使用量。 阿里云的问题在于其提供的包年包月计费方式限制了用户的使用方式（只能从管理控制台启动），限制了用户充分利用云的可编程特性； 另一方面， 其对按量付费的使用方式不提供任何折扣， 用户使用按量付费虚机的成本很高。

总结

在国内，人们热衷于比较各个云服务厂商的价格，却忽略了云服务的计费模式。我认为计费模式将对国内云计算生态圈的发展和促进用户构建云应用的方式转变会起到非常重要的作用。 云服务的定价体系和计费系统是一个系统工程，每个厂商、每个服务有自己的计费方式。但是公有云服务本质上是Utility服务，无论是哪个厂商， 其计费背后的原则应该是一致的，这些原则包括：

1. 按使用量计费。 任何云服务都是可编程的资源（API）， 用户可以非常方便的使用这些资源，按照使用量的多少来计费。

2. 使用越多、需求越稳定， 价格则越便宜。

3. 规模越大，价格越便宜：随着云服务商规模的扩大，其运营成本会下降，这时应该降价让利于云消费者。

4. 无差别原则： 用户创建的资源，无论是通过AWS管理控制台还是第三方管理工具， 其价格是一样的。

5. 费用可视化、可跟踪原则： 云服务厂商提供了费用查询接口， 让费用可视化、可跟踪成为可能，从而帮助用户优化、降低成本费用。

6. 定价依据的是消耗的计算/存储/数据传输等成本。比如， AWS提供了很多免费的服务，这些服务之所以免费是因为其是管理服务，本身不消耗资源，比如Autoscaling服务、OpsWorks、Beanstalk、IAM、CloudFormation。