境界之二-归纳

归纳，我认为是软件设计的第二个境界。

最近几年，做设计或者coding时经常要犹豫，总感觉不是好的方案，于是怀疑是不是老了--也的确老了。今天设计几个功能时，思考再三，还是决定先停下来，晚些时候再做决定。其实这几个功能不难，而且以前也做过，如反馈，举报，如果以前，我可能很快就做出来。对比之下，感觉现在慢是因为需要系统考虑，不是单一功能，要从整体考虑如何实现。

于是引出境界一：实现功能。

我2001年开始系统做java项目，分析jivebbs，分析turbine，分析struct，然后仿写，真是仿写，很快从一个菜鸟成为一个自认为的高手。当时编程只能用一个字：快。年轻气盛、初生牛犊不怕虎、无知者无谓，这些词用到我身上感觉一点不为过。分析经典代码-修改-运行-看效果，我认为是初学者最好的学习方式，然后对着设计模式，把最常用的几种熟练运用，做到这几点，你一定会成为2080中的20。前提是你能逼自己读懂代码，会有几天十几天几十天的痛苦期，取决于你的智商，一定要逼自己，就像跑长跑，过了适应期就一帆风顺了。

说个例子，当时公司有个程序员，算是好学，也有工作经验，自视也不错。当时我让他做个单例的实现，讲了道理，感觉他云里雾里，他埋头苦思，一会和我说无从下手。我一边讲一边写，把代码写出来。那个人的情况应该还在境界之外，因为他不能用自己的知识组合运用来实现一个功能。

再回讲归纳。用开始的例子。

用户反馈、举报这些功能，app中、网站上一般都有，究竟用户能否使用，我做2b的项目多，2c还没有几个上规模的项目，不好下结论，但是既然是通常的配置，客户也有要求，就做到设计中。开始觉得很简单。客户端做个录入的ui，管理端做个处理的ui。后来仔细分析，有这样一些初级问题：

1、不是闭环，用户需要能查询

2、用户可能需要再次对处理结果进行交互

3、是否需要通知用户处理结果（邮件、短信、微信）

再者，管理控制台要单独处理吗？谁来使用这个功能？要两个组分别处理吗？这两个是否同属于客服呢？那么客服难道在客服平台意外还需要到另外一个系统中来处理这些事吗？客服使用saas的云客服吗？如果那样我们怎么接？如果客服我们自己开发，还要接微信、web、电话？还要有工单、工作流？这两个实体和工单是什么关系？是触发工单做关联还是就是工单？

我分析了几个互联网上的流行的saas客服，还是不能做决定。做出这个功能很容易，应该说打个箱子很简单，但是组合成家具不容易，美观易用利用好空间。所以，我决定等等，根据客户购买意愿和我们的投入产出比再说。

能做出来一个能用的功能的程序员应该是合格的。我曾经听过这样的言论，把菜单拆看，看我们有这么多功能不能多卖钱吗？我最近完成了100多个报表。我只能呵呵了。有一种人是贪图小便宜，反应到生活工作的各个方面，而且他会把这种思维加到别人身上；有一种人是不想动脑，或者说没有多少脑子，有个要求我完成就ok了。都会导致产品臃肿混乱，犹如一团乱码，用户无从入手。

归纳，还谈不上创新，但是总是进一步，至少能看到一些实质，能运用逻辑打扫下混乱的桌面。引用一句诗吧：删繁就简三秋树 领异标新二月花。