谁才是 Programmer

　　很多的非程序员（如产品经理、运营、交互设计）并没有意识到，他们同样会参与代码的写作过程，并且，其影响力可能会远远大于程序员。技术人员都知道，历史的发展注定了要逐步使用高级编程语言而不是底层编程语言去解决问题，这不仅意味着效率，还意味着清晰而正确地分解问题的形式。但很多技术人员可能没有意识到的一点是，最高级的编程语言，就是人类的语言。所以，要说高屋建瓴、高级语言指导底层语言，产品经理和设计师无疑对代码具有更高的影响力。

　　代码的写作，其实无关乎编程语言，更多的是对信息流的逻辑把控。陈天大神说过：“写代码是一个非线性的过程，很多时候，想明白了，写，只不过是把思路翻译成某种具体的语言上的实现而已”。表面上，画一张设计稿、提出一项产品功能或者用户的行为路径是一件极其简单的事情，只需要一拍脑袋来上一句“我要这个”就可以了。但魔鬼藏于细节之中，稍微深究提出的整个行为过程，就会发现会自己不可避免地被各种逻辑所限制。

　　很多人不太理解“写代码”这个事情为什么会被称作信息工程学，不就是把图片或者数字放到一块屏幕上显示么，这个和打印店的小哥做的事情有什么不同，怎么会有资格被称作工程学？

　　这其实很容易理解，任何事情只要不深究、不细细考察，都会觉得很容易（这就好比是很多人不理解，为什么像 Google 这样的公司，不就提供了一个输入框和按钮么，怎么可以那么值钱，有没有？！）。事实上，要体会到写代码的复杂性，你甚至根本不用掌握某种特定的编程语言，你只需要能够系统而清晰地地描述出从一个页面跳转到另一个页面的详细过程就行了（事实上，这个活儿就是产品经理和设计师真正需要干的）。尝试着对运行在PC、手机上的产品多做几次这种不涉及代码的描述性分析，你便可以感受到冰山之下的细节。

　　事实上，UI 上的一个功能或者引导用户的一种产品行为，其背后所隐藏的是对各种数据流、信息流的细密建设。某种意义上讲，程序员被称作码农还是有些道理，因为他们就是一个个的建筑工人在构筑宏达而复杂的建筑。只不过，这个建筑是无形的由信息流所构成。这些信息流和数据流不能胡乱地放在一起，这就好比是不能把接入厕所的管道连通到洗手池是一个道理。

　　之所以可以被称作信息工程学，原因就在于你必须科学地、系统性地去把控信息流，在你的精心设计之下让最终构筑起来的虚拟产品能够按照自己的意图流动起来。这有点像是伟大的南水北调工程，目标听起来很简单，不就是把南方多余的水资源调度到缺水的北方地区吗？

　　但如何设计运输的管道，运输管道所能承受的合理压力是多少，在哪些地方应该安排水源的中转地，中转地的施工是否会影响正常的交通枢纽，运输中的水资源是否会被污染或者盗取等一系列的问题，则不会被大多数人所考虑。

　　同样的，提出 App 上的一个功能似乎很容易，不就是在界面上多增加一个按钮么，又或是不就是顺便携带一点别的数据么，如同南水北调那般目标清晰。但是否真的容易，这取决于这个问题本身是由多少子问题构成、这些子问题本身的复杂度有多高、结合这些子问题有多大的复杂性所决定。

　　而 programmer 的真正价值也就体现在：如何能够看到一个事情背后隐藏的复杂信息过程，并恰如其分地将其分解为子问题，再以系统而清晰地方式将各种子问题的解决方案连接起来。如此种种的科学而细致的考虑，才能够称之为工程学。

　　再回到一开始所提出的问题，谁才是 programmer ？按照我们上面的讨论，所有对构筑这个信息流组成的建筑有所影响力的人都可以称之为 programmer 。如此，产品经理和设计人员无疑都涉及其中。因为他们的每一句话，都决定了其背后所隐藏的工程细节是复杂还是简单、是纷乱还是简洁。甚至，如果不经细细考察，他们很可能不会意识到自己所提出的方案潜藏了矛盾。

　　从这个角度来讲，这才是 programmer 和产品经理/设计人员沟通和交流的价值所在。如果大家能够仅仅使用人类的自然语言把问题的模糊性澄清、把不合理的问题砍掉、把复杂的意图分解为清晰可见的优雅解决方案，那么接下来的代码实现，不过是把已经成型的思维结果翻译成具体的代码罢了。

　　但如果非得等到代码已经成型时才发现细节中的矛盾，一切也就晚了。因为你很难像人类的自然语言那样，只是轻飘飘地被忽略就可以另起炉灶地再说一句话，并不需要付出什么高昂的代价。从一种代码实现的方案切换到另一种，很可能意味着要重新构建整个信息虚拟建筑的底层架构，要把所有的解决方式推倒重来，而这种代价高昂到难以想象：稀缺的时间、团队的士气以及战斗人员的集中力。

　　在这个意义上讲，写代码的核心不在于掌握某种具体的编程语言，而是对问题的分解、信息流合理的逻辑构建。而这个事情，仅仅是用人类的自然语言书写一遍，也可以完成。