一. 开篇废话
很多年前，我写过一篇文章叫《关于阅读代码 》。是在2014年写的，那时候刚开始写博客。根据后台统计数据显示，这篇文章这些年来也没什么人看。
其实文章分两种，一种是给自己看的，一种是给别人看的。就像写代码一样，有的代码你自己写的爽就行了，也没打算给别人看；还有一种，写出来的目的就是为了给别人看的。
所以回到《关于阅读代码》这篇文章，当时写的时候更多的是因为随着职业经历的积累自己有一些了感悟，觉得自己有一些绝妙的想法，想记录下来。这篇文章也一样。
作为程序员，工作职责中，可能写代码只占很小的一部分，不过因人而异。如果作为Salesfoce从业者，工作职责中80%以上都是写代码的话，我倒是觉得这其实是一件挺可悲的事情。应该考虑换一个平台或者试试别的角色。
但是，单就开发这部分来说，由于标准功能的存在，代码在Salesforce开发中的比重也不再如传统开发的100%。可以说我们的目标就是要干掉所有代码。
虽然说我们要干掉代码，但是代码却极其重要。毕竟所有标准功能无法实现的功能还是要代码去实现。这时候“对人友善”的代码在Salesforce开发活动中就格外的重要。毕竟在梳理业务流程的时候，谁也不想面对方便面一样的代码皱眉头。或者，被问到头上的时候，只能╮(╯▽╰)╭说：“这个功能好用但我不知道为什么。”
二. 不容易阅读的代码怎么来的
这些年我发现一个现象。习惯疯狂抽象分层的Java程序员，在转Salesforce开发之后往往更容易写出散文诗式流水账代码。然后再进行几次需求变动，代码就变成了方便面。
那么，为什么一个优秀的coder做salesforce之后会写出方便面代码？我觉得原因是接受到的信息的不同。
在Java时代，代码写手在动手之前接受到的信息为具体的功能模块，已经有架构师或同等角色的人将功能完全拆解或者绘制好蓝图。代码写手要做的是实现规划好的功能模块，将自己的模块成功嵌入到大框架内。而Salesforce代码写手接受的信息往往是业务描述——只是说了要做哪些事情，而不是严谨的功能模块划分。
举个例子，就像做意大利面，非Salesforce的厨师被提供了一个精确的食谱和严格的验收标准，要做的是用规定的食材严格按照食谱在指定地点把意大利面做好就行。而Salesforce的厨师只是被告知要做一盘什么味道的意大利面，可能连食材都还没买，到做好上桌之前都要自己搞定。
如果有自由发挥的空间，就像在饭店点蛋炒饭，每个厨师都会做出不同的味道。