程序员进阶之道—快速理解设计

软件开发的流程：需求调研，架构设计，开发实现，测试以及后期的维护工作。

任何一个做过项目的人，无论专业或非专业程序猿都会接触以及熟知的流程。

在此声明，非专业程序猿，代指软件开发流程完全都是自己操作，自己设计，自己开发。

专业的程序猿，代指软件开发流程不是完全参与，而是参与其中一个环节。毕竟是程序猿嘛，开发实现肯定避免不了。别人设计，自己开发实现。

专业或非专业最主要差别是：一个是别人设计，自己开发实现；另一个是自己设计，自己开发实现。

说实话，需求设计与开发实现，绝大部分不是同一人。在公司，都有相应的人员来负责软件开发流程中一部分。公司中有牛X的架构设计师，苦X的程序猿。程序猿首先理解架构设计师的意图，然后才能进行开发实现。

理解架构师的设计，也是一件不容易的事情。那如何更好地理解架构师的设计呢？

首先，设计人员，设计一个东西，当然经过深思熟虑的，如此这般设计，肯定有他的理由。一个好的架构师在整体就会决定一个项目质量的好坏。好的架构师，不仅体现他的设计上，同时也体现他的交流上。即使设计的再好，开发人员理解不好，那项目可想而知。设计完毕，下一步就是他与开发人员的交流上了或者说他开会演讲他的设计了。

架构师设计师开会讲述他的设计时，我们应该注意以下几点，目的是为了促进程序猿很好理解设计，便于开发实现。

第一：做好及时记录。

这点不可或缺。因为程序猿不是自己亲手调研需求，更不是自己亲手设计的东东。所以初步理解别人的设计，必须做好记录。第一次开会听不懂，不可怕。可怕的是听不懂而不去记录。即使听的懂，当时理解其设计，也许做好笔录，这次听懂，不代表会后理解。

其实，设计师讲述，不能说完全正确，但是一般情况是百分之九十五以上正确。他的讲述，也许会帮助你少走很多弯路。此时，设计师，就是一个巨人。站在巨人的肩膀上，既然有免费的巨人，为何不抢占呢？

Ps：此时，小弟正在做一个项目，我们在已有的设计上，编码实现。编码之前肯定理解其需求设计，第一次当专业的程序猿，所以这次有点吃力，不像原来自己设计自己开发。其中吃力的原因之一，是没有做好及时记录。

比如，在编码实现，突然对一个问题疑虑，脑子用曾有过对这个问题的讨论，但是对其当时的结论想不起来了。然后回头找记录，却没有找到相应的记录。所以必须不得不重新交流，重新花费时间与合作者交流，与架构师交流。

第二：积极思考，及时消化理解。

架构师开会后，积极思考其设计的原因，并且及时消化理解架构师的讲述。趁热打铁，会后，顺着架构师的讲解，自己理顺思路，分析场景。因为时间一长，虽说有第一步的记录，但是回忆，重新拾起思路，还是需要大量的时间。

Ps：接着说自己接手的项目。设计师讲述完后，由于各种原因，一直没有进入状态。所以后期理解消化时间长。

第三：记录实现思路。

思考后，应该把实现的思路记录下来。随着思考的深入，对一个功能的实现思路有所变化。不仅可以对比思考深入后的区别，同时也可以为编码实现做基础。设计与编码实现，若是间隔时间长，没有相应的思路记录，是不是感觉很费力。若是原本你负责的却有事离去，那若没有相应的思路记录，是不是你有点不负责呢？

第四：不断沟通交流。

沟通交流，无论何处何地处于何种职位，都是不可缺少。更何况对于程序猿来说，因为公司企业全部是团队开发，不可能一人独战。所以合作能力之一沟通尤其重要。憋了好几天的问题，也许队友的一句话会启发你。所以不可闭门造车，正所谓三人行必有我师。

以上几点都是本次实践中的点点觉悟以及理解。只有更好的理解设计师的设计，才不会一遍遍推到重来。对了，程序猿不要急着开发实现，只有把思路理通理顺，对于模棱两可的问题，要及时沟通讨论，否则会面临重新开发的风险。