这是个隐喻。
在敏捷软件开发的原则中，其中一个原则就是使用隐喻。我在这里也仿照了它的做法。
程序员是个群体，当我们说一个群体，一定意味着它有一些共通点，不然不能称之为群体。而每一个群体必然有一个大家都认同的价值观，否则不能形成群体。
什么叫大家都认同的价值观？
举个例说，信仰基督教的人，它们归为一个群体，那它们的共同的价值观是什么？或者换个说法，是什么在指引他们行事？
当然是圣经，对吧。
每一个基督教徒都把圣经做为最神圣的事物，遵守圣经的教导是基督教徒的行事标准，对吧。
与此类似，理所当然的，我们程序员也会有自己的"圣经"。
那做为一个程序员，当你在写代码时，你有没有思考过，自己的"圣经"是什么？
从本周起，我将阐述我对编码之道的理解与思考，这是第一篇：程序员的"圣经"
技术只是工具
由于我过去的经历，我编码的经验遍历后端，移动端以及前端，所以我清楚几乎每一个方向的程序员的日常工作是怎么样的。
当然，如果我们就每一个方向来谈论它们所涉及到技术，它们肯定是各不相同，甚至是技术上没有太多交集。
后端的人大多使用的Java，并且与Java生态打交道，他们的词汇是：并发，集群，缓存，性能等
移动端的人则分为几类，iOS,Android原生开发，React Native或Flutter等跨平台开发等，它们用到的技术也各不相同，比如OC,Java或JavaScript等
而前端则主要是与JavaScript或TypeScript打交道，他们更关注的可能是兼容性与体验，样式等
似乎没有太交集？
完全不是，在我看来，这些工作其实毫无区别。无论是我在从事哪个技术方向的开发时，我遵守的原则几乎一致。
想像一下，你怎么看待技术？
你会发现，在你编码的职业经历中，你会遇上各种各样的技术，新的语言，更好的框架，更函数式的语法，面向大数据的技术等，你可能会认为自己熟悉某些特定的语言，认定自己使用这些语言会更好。
我认为这是一个完全的错误。
我把所有的语言，框架或各种各样的开源的玩意当成工具，它们都是我的工具。把自己想像成一个建筑师，我拥有很多工具，这些工具都是我在建造建筑时可以考虑使用到的东西。
我从不会限定自己只使用什么，我这些年也是这样做的，从一个后端架构师，使用的Java，再去用Java编写一个Android程序，再去用OC去编写一个iOS程序，再去用TypeScript去编写一个跨平台桌面程序，又去用Kotlin+Vert.x投入到响应式编程的世界中，这些语言也好，技术也好，框架也好，都是我的工具而已。
我有一大堆工具，我意识到了，当我要编写下一个程序，解决下一个问题时，我其实有非常多的工具可以选择了。
做为一个程序员，我从来不对特定的语言表达虔诚，但我想程序员也得有自己的虔诚，我想要寻找一个编码的"圣经"，它足以让我虔诚的遵守它，守护它，捍卫它。
这便是程序员的"圣经"
三个原则
我认为做为一个程序员，最神圣的就是三个原则，它几乎能完整无误的定义做为一个程序员应该如何去编码。
它也不是空洞的理论，每一个原则都是可以通过技术实实在在的做到。而是否遵守这些原则，也是区分一个程序员是否优秀的标准。
这三个原则就是程序员的"圣经"，
它们分别是：
- 编写满足需求的代码
- 编写可维护的代码
- 编写易于阅读的代码
编码满足需求的代码
这应该非常易于理解。
我们要编写的代码不是凭空产生的，一定是为了解决某种特定的需求。
当然，需求的来源可以有许多种，比如来自于客户，来自于产品经理，或来项目经理，也许来自于自己的一些想法。这些都无所谓。
但是，最起码的原则就是：我们要写出满足需求的代码
编写代码就是实现契约的过程，提出需求的一方是期望我们理解并实现他们的需求，他们并不明白与理解我们是如何用代码实现他们的需求的，但重要的是他们认为与我们定义了一个契约，这个契约就是：
请你们用代码来实现我们的需求吧，拜托了
连这一点都做不到的，我认为就不要称自己是程序员了。
编写可维护的代码
写出能运行的代码这个太简单了，但编写出可维护的代码，则是个巨大的挑战。
想必很多程序员都经历过类似的痛苦，可能进入了一份代码中，这份代码在可维护性上已经差到令人发指了，但还是得要继续。于是常见的现状是：修改一个BUG越来越困难，而且会引发更多的BUG，添加一个稳定的新功能越来越不可能。那些不懂代码的管理者也不知所措，于是往这个糟糕的项目中添加新的人员，或延长每日工作时间成为了必然的选择，但绝大多数情况下，情况压根不会好转，可能会更糟糕。
很多程序员想必理解我在说什么对吧，我也经历过类似的项目，记得当时整个团队花了几乎几个月的时间就是去修复BUG，每天有专门人统计每日的BUG修复情况，领导们也为大家打气。
但最终项目不可逆转的失败了。
当然，我们不去谈论具体原因，但无论是什么引发这种情况，做为程序员，我们都不能否定一个事实就是：
那些由我们负责编写的一行行代码，当它们合在一起的时候，分工协作与合作却越来越困难，如同一群相互嫌弃的人硬被我们堆在一起一样。
这是典型的不可维护的代码的表现。
做为一个程序员，你有责任让自己的代码具有可维护性，在技术的所有特性中，我认为最重要的一个特性就是：
代码一定要具有可维护性
做为一个程序员，你要努力写出可维护的代码。
编写易于阅读的代码
代码的可阅读性我把它分为三个层次：
- 机器能读懂的代码
- 自己能读懂的代码
- 别人能读懂的代码
无论你的代码写的多差劲，只要它接受一个输入，并能输出一个符合期望的结果，那你这份代码就达到了机器能读懂的境界了。
再往上一层的要求就是让自己读懂。可能很多人会认为自己写的代码怎么会自己读不懂？
当然，我说的不是让你去阅读自己上周写的代码，而是说让你去阅读你过去的，你已经有一段时间没有参与的代码中，我相信一定有一些人可能对于自己过去写的代码可能不是非常理解了，得费劲思考一下才能明白当初自己写的这份代码是干什么的。
要求最高的就是让别人读懂,在我们程序员这个群体中，几乎有一个共通性，就是不太愿意接手别人的代码。我想这之中一个很重要的原因就是，别人写的代码我们不太容易读懂。
这也从反面反应出，写出一份能让别人读懂的代码，其实是有着一定的难度的。
想要写出易于阅读的代码，就得写出简洁的代码，写出优雅的代码，能做到这种程度的程序员实在不多。
它们是"圣经"
理所当然的，能遵守并做到上述三个原则的程序员，都可称之为优秀的程序员，反之则不是。
所以，我把这几个原则称为"圣经"。
只要稍微思考下，无论你是后端，前端或是移动端还是其它什么技术方向，这几个原则几乎无一例外的能覆盖到你编码这件事情上。
这便是我所思考的程序员的最高原则。
我将它们时刻牢记在心，虔诚的遵守它们，守护它们。
你做为一个程序员，有没有思考过自己的原则?
有了原则，再谈谈使命
这就是我这一次要讲的原则，做为一个程序员，你一定得有你觉得对你而言，你不得不去遵守的原则。
一旦你能为自己确立一个正确的原则，那它将迫使你成为一个越来越优秀的程序员，因为只有足够优秀才能守护你的原则。
我很难想像一个不优秀的程序员能做到编写满足需求的代码，编写可维护的代码以及编写易于阅读的代码。
你的原则时刻守护着你，有了原则之后，下一步是什么？
你有没有思考过这一个问题，做为一个程序员，编码是用来做什么的，它会产生什么价值？
下一篇，继续谈编码之道：编码之道（二）：软件的价值