大道至简第四章的主题是沟通。
这一章涉及到了我上的一门课，UML。我过去一直觉得这个东西难懂，或者目的性我尚不太明确。这一章解决了我的一些疑惑。
在以后面对客户的时候，我们首先要了解客户的需求，我们才能围绕着客户的需求进行扩展工作。那么仅仅了解不够，还需要通过自己的理解，来和客户的需求进行对照，看是否一致，那么沟通就来了。
编程不是客户需要去了解，客户需要了解的是简单直白的解释，不需要任何多余的言语，只需要用双方都懂的方式，进行思维的交流。
鉴于最近学习的UML，我些许了解到这个东西的作用。
建模。
用着图像和文字的方式，层层结构，像树枝分叉开，由主干到枝叶，将整个产品解释清楚，由概括到细节，让客户或者创造者都能从中了解自己所需求的东西，心中有个大概，用起来也有细节。
用这种方式，大概算是现今互相了解之后，共同创造的东西吧！一座桥梁，一种通用的语言。当然，这仅仅是一种语言。人有区别，并非绝对统一。
所以，沟通并非流于形式，并非一定得用一种方法。行之有效，简介明了的方式才是最好的。除了会UML，也得会其它的方法，只要能够理解项目的内容，也是可以的。
在沟通的时候，客户也是有他自己的工作，也是又自己的事的，他并非天天能够站在程序员旁边，时时刻刻交流，时时刻刻改正。所以沟通也有了条件和限制。在限有次数的沟通中，绝对没必要在吃饭喝酒中去了解客户的需求，浪费大家的时间，且浪费精力。所以，力求“最简沟通”。在向客户提出问题前，就先设计问题，争取最大的信息，最全的信息，最主要的信息。这也不是扣着字眼，用着文言文的方式去问客户，我们可以将项目过程中，最需要解决的问题（不是技术上的问题）进行交流。
在编程的时候，沟通不只是和客户，还有自己、团队。
“为不存在的角色留下沟通的渠道”
我们在做项目的时候，要留下历史记录。让其有着故事，有着继承性，不然等别人来看这个项目，就将是两眼一抹黑，若是换人，或者时间上过了很久，再看这个项目，也只能终止，无法继续过去智力和努力留下的结果。
我相信做项目，并非一次完成，在过程一定会有很多创新，当我们为这个无数个失败品留下注释，也许以后用到时候，才能得心应手，成为永远的素材。我现在做的程序、例题上面的注释，都有反复学习的用处。
沟通永远都是获取信息的方式，无论与他人，与自己，都有着理解的加深伴随。所以我总结出：常和自己沟通，留下自己的历史，能将成为素材；善于和他人沟通，能够加深理解，使项目更加完美。