概念、实现和沟通

最近在公司负责技能系统，这块儿想了很长时间了，最先还是在04年荣耀的时候就开始考虑的，因为那时欠考虑太多，被兰大一指头按死。但那之后并没有停止思考，玩了一些游戏，综合考虑了一些情况，结合当前项目的情况形成了现在的方案。

从设计上，瑕疵什么必然是有的，不然我可能现在也去开飞车造火箭了。这里不想谈具体的设计问题，而是想说一些衍生出来的问题。

一个模块，部署实施的时候必然会有多人共同参与，在这些人中，沟通是个很重要，但也很讲技术的工作，这点得承认，自己还有很长的路要走。

沟通的目的并不仅仅是把自己的意思传达给别人，更重要的还有两点，一是从别人那里准确地获知他人的意思，另外一点，是确保参与的所有人对同一个问题的理解是相同的，等价都不行。

由于进度比较紧张，而且自己又有一个特别想做的东西，于是马马虎虎开了两次小会，与参与的同事沟通了几个来回，从他们那里知道了一些他们的想法，根据这些想法修改了一些设计，同时也把自己的想法知会了每位同事。但是，最后一点杯具了。

抽象的概念，最终体现到代码，还有一个过程，就是类似于伪代码的过程。这个过程应该算作是具体细节的设计吧？这个阶段，我忽视了。

只是布下了概念，大略地说了一下实现的模块和接口，但是，没有说清楚某个方法究竟应该在代码中如何体现为具体的类和方法，也没有弄明白几位同事各自的想法是不是有一些不同，就匆匆忙忙铺起了量，结果就是：两个人实现的模块从各自理解的角度上都是正确的，但是却拿不到一起来用……一位同事尝试从A角度来理解，构建了自己的整个接口集合，同时构建了对方的处理方式，而另一位同事同样完成了这个过程，只不过是从B的角度去理解，于是就……

这确实是自己的问题，以后需要注意这些。

还好不是那种大的模块，浪费了一天的时间，又驶回正轨了。

说到细节设计，其实有时候想想，《最后期限》推荐“最后一分钟编码”，就是要求扩大和改进这个过程。但这一点对于习惯用Debug和可见性来描述软件的中国程序员，还是太过于遥远了。我们所接受的教育，以及我们一直以来所维护的传统，都是轻设计而重编码、重调试的。快速部署对我们总是比风暴设计要重要得多。但是，强化的设计还是值得一试。强化到什么地步呢？《最后期限》给出了若干个标准，其中有一个是，设计应该针对模块间的接口，而非重现需求的概念。需求的概念是一个归纳过程，逻辑正常的人们只需要穷举需求集就可以解出来等价的概念。但是接口，作为从概念的演绎，其变化性一下子就上去了，因此，应该得到重点的对待。

现在真的已经不能再像之前那样，自己设计，自己实施，自己发现问题，自己修改了，因为首先，设计的修改导致的工作量，不仅仅是自己的，也是别人的。

所以更需要小心翼翼，安排好接口、流程，留下足够灵活的空间。

希望自己能尽快成长起来。