做什么事都要讲道理，今天我说说软件开发中开发人员的”讲道理“。
开发人员写代码之前，一般都会做几件事：
编写详细设计文档 ： 有些开发人员，或者公司要求写详细设计文档，用来对自己将要进行的开发工作做一个详细的设计。
参加系分，概要设计宣讲和评审 ： 有时候，是没有详细设计的，直接听了系分宣讲，理解一下需求和系统实现的大概思路，就动工了。
仅仅理解需求 ： 这种情况下，没有系分，设计文档，直接理解需求后，直接开始编码。
以上几种场景，都是很常见的。依不同组织，不同团队，不同的紧迫程度而不同。
设客户理解的软件为C，需求分析人员理解的软件为R，设计人员理解的软件软件为D，开发理解的软件为P。
理想情况下： C=R=D=P，这是理想，限于时间，成本，不可能完全相等。
我了解的日本外包，C=R=D≠P，他们通过大量的时间，将软件用语言描述为文档，但到实现层面，开发人员理解还是可能产生误差。保证了C=R=D≠P
这里，我不说其他的环节，只讨论开发人员完成编码工作需要的前置条件，换句话说，开发人员做了什么事情，他就可以开干活了，并且保证理解的正确，返工率低。
有人赞成编写详细设计文档，有人说详细设计文档写了也没用，浪费时间，设计变了，还得改文档，麻烦。
设想一个场景：
我让我儿子去打酱油，我话音刚落，他已经出去了，不一会，回来了，拿了一袋酱油。我说：”你怎么买袋装的，我想要瓶装的，用起来方便啊“。话音刚落，我儿子出去了，买了一瓶酱油回来。我说：“我要黄豆酱油，你这个太淡了啊！”。
此故事纯属虚构，我儿子目前还不会打酱油。我想说明的是，如果在打酱油之前，他能够问一下：“爸，你想要什么样的酱油啊”，就尅有避免这种事情的发生，包括返工。
但，仅仅问就足够了吗？ 说着可能溜号，口不对心，想要A，说成了B。听着也可能把A听成B。
回到软件开发场景，开发和上游的理解偏差可以表示为，即：
ΔPD = P-D
如何让ΔPD = 0呢？
大家都有这个体验，洗澡的时候，开热水，不热，再拧，tmd太热了，拧回来，又太凉了，反复几次之后，终于水温合适了。
这就是负反馈回路，又叫平衡回路。
在这里，就需要开发人员和上游有多次反馈，不能只听不问，只听不讲，只讲而不做确认。
如果你刚开始程序员的工作，编码，你需要做的就是不断的听，问，讲。大多数开发人员听的多，问的少，讲的就更少了。 如果要在职业生涯更近一步，成为资深开发工程师，一定要学会讲，积极的讲。这道坎迟早要迈的，不仅要讲，而且要讲的简明扼要，要抓住关键，要让别人很快就能明白你的意图，你的设计，你的方案，你的问题等等。
这就是我说的讲道理，作为软件这条线上的蚂蚱，不仅仅是开发，其他角色也一样，一定要多讲。
从这个角度，讲道理可做如下解释：
“讲“，然后”道“就”理“清楚了，只有讲了，思路才能更清楚，你能讲的出来，说明你已经理解的非常透彻了。详细设计文档，系分宣讲，需求文档无非都是媒介，终极目的是作为开发人员，你理解了多少。
今天你讲道理了吗？