数据库一不小心说了四节，自己觉得有点枯燥，那就开一个新系列讲关于编程感悟吧（多一个一级菜单真是一个不错的选择啊）。
我总是建议年轻的程序员（虽然我也很年轻）应该把项目复杂化，尝试各种手段让自己的项目充满过度设计的感觉。然后静下心来做减法，当你会用减法并且理解其中奥秘的时候，才能学到编程的精髓，才能学会用编程的方式思考问题！
而且你会惊讶的发现，解决问题的过程实在是令人着迷，倘若你的工作只是完成需求，那么根据契约精神你只能收获的是工资。罗伯特清崎在《穷爸爸和富爸爸》里写到，“老板发你的工资是保证你不会离职的下限”。我的理解是，在工作中不应该只获得工资，更多的是学习知识！
说到减法，举一个不恰当的例子，暴雪的最新游戏《守望先锋》就是一个做减法的典型，当国内游戏从业者一个劲的往产品叠加功能，例如：每日签到模块，抽奖模块等。《守望先锋》却大幅度精简系统，没有一丝的肉。是他没有能力做类似签到模块么？显然不是，是因为他的终极诉求是为了带来愉快，所以玩守望的每一分钟都没有被浪费的感觉。
为什么这次的题目是《本地方法和远程方法与可见性问题》呢？我发现问题都是连环相扣的，我要用代码可见性问题做引子，推出我的观点，代码本身就是最最好的注释。本地方法就是本地文件夹定义的function，通过本地引用方式调用定义的方法，缺点是调用者和实现者必须相同语言，你无法用java调取ruby写的方法。本篇中我把跨语言的调用都称呼为远程方法，当然可能他不是真的在“远程”，同语言也可能是远程方式调用。
为了进一步说明代码本身是最好的注释，我创造了三个名词，代码可见，文档可见和定义可见来帮助大家阅读。对每个人来说，本地方法使用起来非常便捷，常常得到一个软件包放到项目内就能跑起来，这其实就是代码可见。当你无法理解上下文的时候，只要进入代码里看一眼便能明白有什么问题。代码可见简单直观，只要你有源代码，你就明白他是干啥用的。
远程方法使用起来很是麻烦，我们需要去找实现者写的定义文档，可能是一个json，可能是一个wiki，也可能是一个Markdown文档，里面的描述尽可能的详细，总之按照里面说的定义方法使用肯定没问题。但是糟糕的是，万一远程方法返回了“不该发生的东西”，这怎么办？这往往是因为文档的更新总是落后于代码造成的，也许我们在条件充足的情况下，会精心的制作文档。一旦hotfix来临，谁还会想起在深夜2，3点更新自己的文档呢？常常以来，文档成了第一行代码者的专利。
文档可见看着很美丽，真正用起来，但也别着急否定它。我认为这是一个好东西，因为代码不光面对是的研发人员还有测试人员等。不要有了点缺点就否定它，我们要帮助它变好，只是需要大量的周边去维护，手工维护文档是不科学的！
Github上充斥着大量的RPC框架，基本都是基于某个协议层，支持多语言的服务客户端实现等云云，最最关键的一点是会告诉你，一旦用了它速度提高N个级别等等。毫无疑问，这些性能指标肯定是真实存在的，但衡量服务调用难道就用一个性能指标就够了吗？到底我们需要什么样的框架呢？
定义可见浮上水面，用SOAP举例子。经常听N多人说SOAP好慢呀，没有自己写的简单框架来得快，我永远不参与类似讨论，虽然我不是SOAP支持者，性能太过低下，但我们要理解为什么这样做。SOAP支持WSDL，这就是定义可见，我支持定义可见。支持WSDL的IDE，例如：Eclipse，只要基于WSDL实例化客户端，代码的使用如同本地方法！
WSDL给了我们什么启示？原来定义可见多么的重要，我们的工作方式也会随之改变。先定义我们要的方法，基于定义产生文档，也基于定义实现客户端和服务端。这一切不就是TDD（Test-Driven Development）么？通过现代化的工具（例如：Swagger）帮助你完成“无脑”工作岂不是更好，所有围绕这个方法工作的人们，都能协作无偿提高效率，这就是定义之美。
可见性就是为了让“人”更懂方法，这个人可能是真的人也有可能是电脑（IDE），也可能是以前的你和未来的你，一切的定义都必须显示，他真的能让效率提高。看到这里，你想说你的代码里没有那么多远程调用，但我想说的是，即便很多本地代码也定义含糊不清，静态代码分析在你的代码面前失了效，没有代码提示怎么让你的代码被传播，多利用注解Annotation等等技巧（请关注新的一针灵系列）让你的代码更容易被更多的人读懂吧。
当你调用远程方法和调用本地方法已经完全一样之后，那更抽象的理解方法到底是什么呢？方法是提供某个业务的能力，他需要分层，每一层既是调用者也是实现者更是定义者，到底该怎么分层？怎么描述结果，请支持关注本公众号，死亡皇后岛，老夫会为你做进一步解释。随手转发，关爱优质订阅号！