以亲身经历浅谈软件实现前“凡事三问”的重要性---欢迎大家分享自己的经历和感悟！

        某老板是非常受欣赏和尊重的人， 某次， 在某会议上， 对某副总说： 为什么我的水平比你高， 因为我善于总结和感悟， 做的事情多了， 所以水平就比较高了。 哈哈， 老板确实有水平， 我也发自内心点个赞。

        喜欢埋头Coding的farmer确实不少， 下面我来扯扯Coding前的三问， 如果大家有不同意见， 欢迎切磋， 相互提高。

        第一问：要实现什么功能？            （知in知out, 百战不殆）

        第二问：当前有没有已经实现了的代码。  （拿来主义， 为我所用）

        第三问：如果要自己实现， 那有哪些方法呢？在这些方法中， 考虑兼容性，健壮性， 扩展性， 易实现性等因素， 那种方式最好呢？ （轻松自己， 造福他人）

        简要扯一下：

        第一问：要实现什么功能？

        所有的功能， 不外乎就是  "in------process------out" ， 对于通信专业的同学而言， 要理解这个非常容易。 "信号与系统"这么课程就是专门讲这个的。 输入信号是什么， 经历了一个什么样的系统， 得到的输出信号是什么？ 在这么模型中， in和out就是输入信号和输出信号， process就是系统过程。

       一个人， 要实现一个目标， 其实也是"in------process------out" 的， in就是我们现有的资源， out就是未来的目标， process就是达到这个目标的过程。

       哲人总是说， 我们要了解自身(in)， 我们要有目标(out), 我们要付诸行动(process)去达到目的. 但实际上呢， 在现实中， 我们往往是对自己的现状(in)定位不准， 又不知道自己究竟想要什么(out), 于是就走一步看一步(process), 也不知道这样的process会导致怎样的out.

       在软件中呢？ 也是一样， int fun(int x);就是这个模型的。in和out合起来就称作interface(接口， 说白了， 就是入口和出口)， process称作implementation(实现， 说白了， 就是从in到out的具体变换过程)。在软件开发中， 可千万别不知道out是什么就去做process, 否则估计又要通宵加班了。 我刚入职的时候， 对某些功能和业务场景不是很清楚， 拿到一个需求后， 不知道究竟要干啥， 于是自己就在那里瞎琢磨， 最后也琢磨不透是个啥东东。 不懂的东西太多， 和老鸟们沟通后， 自己还是一头雾水， 不知道要做成啥样的功能， 于是不断纠结啊纠结啊， 终于还是不行了， 还是要问设计人员， 问你这个说的是什么意思， 要做成啥样的？ 我们的目的是啥？ 经过几次软磨硬泡后， 自己就慢慢知道要干啥了。 哎， 沟通很重要的。 不清楚要做什么， 就不要做了， 问他人， 问自己， 搞清楚， 要做什么， 我们当前有什么in, 到底要搞出怎样的out?

       总之， 在没有搞清in和out之前， 就去搞process, 确实不明智。

       第二问：当前有没有已经实现了的代码。

       某次， 我接到一个新任务， 要实现某功能， 接到任务后， 我对in很清楚了， 对out很清楚了， 很明确自己要做什么， 要实现什么样的功能。 于是就开始琢磨怎么实现。 说实话， 这个实现还是有点难度的， 等我搞了1天后， 基本实现了预定功能。 就在我快完成的时候， 就在我满怀欣喜的时候， 我的心情又跌落谷底， 原来， 在代码中的另外一个地方已经有了类似的实现， 只需要复用并略作修改即可。 看看， 这一天浪费了啊， 不过， 没事， 这就是成长的代价。 总会走一些弯路的， 走多了， 就知道什么是直路了。 有些吃了葡萄还说葡萄酸的大牛们经常说： 我真后悔走那些弯路。 我只能呵呵回应。

       所以， 能复用尽量复用， 不要做无用功， 在实现某功能前， 可以大致看看之前有没有类似的实现， 问问相关同事， 做过没。 这一点也不丑， 拿来主义，为我所用， 何乐而不为之呢？ 

        第三问：如果要自己实现， 那有哪些方法呢？在这些方法中， 考虑兼容性，健壮性， 扩展性， 易实现性等因素， 那种方式最好呢？

       急于实现一个功能， 并没有错， 但如果只是为了实现功能而实现功能， 我是不能苟同的。 第一直觉的方法，不一定是最好的。 我相信， 有不少朋友跟我一样， 一旦想出了一个实现方法， 恨不得马上把代码写上去， 立即去验证结果。

       有好几次， 我在要实现某功能前， 我都立即想到了一种必定可行的方法， 按照这个方法去做， 绝对可以出结果， 于是自己就这么做了， 既然会做， 那么剩下的就是时间问题了。 一旦自己会做， 就不会有什么压力， 而且通常倾向这么去干， 哪怕需要花较多的时间， 自己也心甘情愿， 因为目标就在那里， 自己必定可达， 多么诱人啊。可是， 做着做着， 发现好麻烦好复杂， 这样耗下去不是办法， 那怎么样呢？ 只能发扬我司的"优良传统"： 加班， 通宵。其实， 换个角度看一下， 很可能就有省力省时的好方法， 幸好， 用这方法解决了问题， 总算不用通宵了。

       还是那句话， 走弯路， 不是不可以， 但不要两次踏入同一条臭河流。 在动手前， 大致看看有哪些方法， 从兼容性，健壮性， 扩展性， 易实现性等主动方面考虑一下， 选出相对比较好的方法来实现。 比方说健壮性好了，就没有那么多bug了， 扩展性好了， 就为后面的人省事了， 轻松自己， 造福同事， 快哉快哉。

        说白了， 何止是软件实现呢， 做很多事情之前， 都需要这样问问自己。 这让我想起了本文开头老板那句至理名言。

      

        

        扯一点与上面相反的悖论， 话说回来， 有的人， 仅仅知道自己手头有些什么(in), 却不知道未来是什么(out), 凭着兴趣在那里捣鼓捣鼓(process), 最后做出了非凡的杰出成就， 比如：

       1. Linus玩着Minix,  这个自负程度远远胜过乔布斯的家伙， 凭着自己的兴趣对Minix改装改装， 最后搞出了Linux, 改变了计算机业界。

       2. K和R在贝尔实验室，没啥生存压力了， 饭碗也有了， 闲的蛋疼， 在那里玩弄游戏， 捣鼓捣鼓代码,  最后搞出Unix, 而C语言也渗入业界，坚挺40年而不萎。

       3. 当年明月（石悦）憋得不行了， 搞什么重写明史， 掀起了一波读史热潮， 听说书卖得很不错， 我自己都有一套呢， 9本装的。

       4. ...........

       太多了， 就不一一列举了， 内心点个赞。

       

       吃晚饭去咯。