11 May 2012
自从开始做产品之后，我就成为了产品运营人员的一部分。每天，我与行政收到同样多的邮件。出差请求，感谢，抱怨，我都一一看在眼里，记在心里。得益于之前出了无数的差，因此对于出差人员的感受非常直接，然而在行政这边，估计许多人如我一般，对她/他们了解甚少。与程序猿不同，她们（多数是女性）的时间被扯得稀烂，最新来的事情优先级最高。她们善良体贴，乐于帮助他人，一点点的工作失误自己会难过得不行，而来自同事的称赞则能让她们高兴好久。
这种真实的体验让我对产品与用户之间的距离有了更深刻的理解。产品还在试运营。一天行政苦笑着跑来找我：网页出错了，500 Error。我立刻几乎可以想象，她正在使用着软件，点着界面，突然之间这个恐怖的、白色的、带着几行红色粗体的错误信息页面出现在面前，对于一个没有任何编程经验的用户，是多么恐怖的体验。一种无法解释的内疚油然而生，我看着她说：对不起，理解你的感受，我马上修复。
她楞了一下，迅速说：没事，不着急。
几分钟之后修复好了。她在IM上回复说：太感谢了！
这些让我对软件的价值重新考虑。我们需要真正的使用这些软件，才能够得出真正的体验，并能够在使用不便、出现问题时真正感同身受的说：说：对不起，我理解你的痛苦。我们正在修复。
很多软件忽视这个过程。软件的设计者、制造者、销售者、客服与用户之间，通过各种部门、KPI隔离开来，然而又妄图通过各种制度来标准化服务流程。可惜，销售者不用自己的软件，客服也没用过自己的软件，制造者根本见不到用户使用的样子，又如何能够真正体会用户的感受，制造出贴心的软件，提供贴心的服务呢？
早在写《架构腐化之谜》的时候，我就意识到，造成架构腐化的根本原因是系统复杂度变大的必然趋势以及人类遗忘的天性。延缓项目腐化最好的方法，是根本不给腐化的机会。生活中，自然通风、阳光透亮、家具摆放合理的、不留死角的房间出现虫子的可能性很低；代码也一样，一份简单、符合直觉的代码，放在复杂度完全可控的代码库中，能够极大的降低学习的门槛以及避免腐化的可能。
包括自己在内，很多人当然以为这只是美好的想法。绝大多数开发者仅仅能尝到项目早期的甜头，在后期则进入了愈发沉重的深渊。对于文中所说的似乎只是一个遥不可及的想法。为了证明这个是否真的可行，从去年10月开始，我在自己的产品中进行了一个尝试：在保持功能正常增长的前提下，项目总体功能代码不超过2000行。
现在是什么情况呢？从去年10月到现在，git统计数据如下
414 files changed, 42824 insertions(+), 698 deletions(-)
430次总共提交
Code LOC: 1568 Test LOC: 799 Code to Test Ratio: 1:0.5
功能代码总共不超过1600行代码（当然未包含大量的CoffeeScript以及HTML/Sass代码），完成了大部分的核心业务逻辑。未来可见的功能也应该能够在400多行的空间里完成。系统中也存在不少能够提取为独立Gem的地方，可以继续进行隔离简化。
应该说得益于Ruby简洁的语法，以及在rubygems社区提供的各种高质量的gem，让以前不可想象的麻烦变得几行代码就能搞定。
我们得到了什么好处？今天新加入了一名程序员，花了点时间介绍产品背景之后，在不到2个小时的时间里，就完成了一个典型的功能。并且还顺带修正了一些代码上的Bug。
Rails固然是特例。但推广到其他的语言，只要遵循以下原则，应该是毫无问题的：
- Don't Repeat Yourself - 绝对不要重新发明轮子。github上fork数量多的项目基本上已经相当成熟了。即便有问题，fork, fix, pull request的响应时间比以往任何一种方式都要迅速，还能回馈社区。
- 遵循约定，遵循约定。在某个时候总忍不住自己写了类似于get 'cities/edit'在routes.rb中，但随着类似的代码越加越多，最终索性就变成了resources :cities. Rails是经过许多工程实践的框架，其中的最佳实践很多时候是经过验证的。对于其他技术框架也应该一样。有时候发现了异常情况，不要为这种异常情况特殊处理，约定化也许是更好的方案。
- 隔离，隔离。凡是与核心业务无关的功能代码，在找不到开源替代的时候，想办法将其通用化。比如我们用到了解析openflights的机场数据。这部分与核心业务毫无关系，将其隔离为Gem，再引用，能够减少无关代码干扰，形成知识分界，对于专注了解系统有莫大好处。
- 警惕未经使用的功能、代码、注释、甚至数据库字段。保持代码库总在最精简的状态下。
这个产品已经上线。在可见的未来，2000行的界限还是够用的。等到超过的那一天，我再写写看看。也许那一天可能永远都不会到来。
大约几个星期前，同事找我帮忙看看一个关于类似于TODO/Action的手机UI如何设计。看到他们的正在工作的界面之后，我完全没有感觉：在TODO List界面上，零星的放着abc, def, dfsg之类的随意字符；顺着链接点进去，里面放着的是完全无法建立情感联系的blabla文字。我完全无法想象如何在这种场景下进行UI设计——软件本身只是生硬冰冷的工具，用户贡献的数据才是血肉之源。数据被粗心的对待时，作为开发人员你与用户之间基本失去联系。这种状况下我们如何能最起码保证设计是贴心的？
之前在自己开发的个人项目中也有不少需要用到人名的情况。当然不会采用类似于ABC之类的随意字符，但仍然采用了类似于张三丰、任盈盈之类的名字。发布之前用户都笑了：这是什么啊。把名字换成类似于李键、赵文斌（如有雷同纯属巧合）之类的名字之后，用户开始更为慎重的对待这个系统。
设计师在这方面做得很好。他们会很耐心的抽象出一些典型的用户（Personare），取个典型名字，放到真实的业务场景中，所用的词汇和数据看起来几乎跟真的一样。而程序员则在这方面疏于修炼——大多数仍然满足于仅仅将功能完成。一些更为惫赖的公司则索性把开发阶段的产品截图放到自己的产品介绍中，随处充斥着客户姓名是张三、一张机票100.00元、留下了一段内容是abcd123的留言等等截图。用户在看到这样的粗糙的车间半成品的时候，他们如何能够想象这个软件能够与自己真正的业务过程集成呢？
软件是给人使用的。从软件构建到软件递交到用户手中的时间应当越短越好。真实数据——作为最直觉、用户应该最关心的部分，却经常被开发人员忽视，而这部分是开发人员最直观了解用户如何使用系统的途径。如果你无法想象真实的数据，很大程度上意味着你根本不了解你的用户。
PS. 在准备给学生的作业中，我专门查找了国家农产品的价格数据库，以及最近的购物小票，以期给学生更为真实的开发体验。构建计算机思维与自然界的联系，构造更有用的软件，从身边的数据开始，应该是最简单的切入点吧。
陈金洲，工作于