第四章名为“流于形式的沟通”，开头引用了韩愈的一句话，即“足下求速化之术，不于其人，乃以访愈，是所谓借听于聋，求道于盲。”，这句话是个比喻，意思是向毫无所知的人请教，是不能解决问题的。也教导我们要学会沟通，学会交流，自己明白不厉害，你能把别人讲明白才厉害。

　　第一节名为“客户不会用C，难道就会用UML吗？”，这一节主要讲的是如何与客户理解客户的需求，当程序员进行一个项目时，需要计算机语言去实现，这对他们来说很简单，但对于客户来说，很难，客户完全没有时间去学习一门计算机语言来跟程序员交流，将他们的要求数据化。所以他们只能用日常生活中的语言来和程序员进行交流，把自己的要求说出来，将其提取出来，并转化成计算机语言，则是程序员的工作，这就需要程序员拥有良好的交流能力，能充分理解客户的要求，如果不善于交流，不能理解客户，那会闹笑话的。

　　第二节名为“项目文档真的可以用甲骨文来写”，这一节主要讲的是如何与客户沟通，不是用计算机语言，而是将程序简化，变得通俗易懂，使外行人也可以明白其中的道理，这样做可以节省很多的资源，跟客户的沟通会更加容易，当然这是一门学问，想要熟练的掌握这种方法，需要大量的实践。

　　第三节名为“最简沟通”，这一节主要讲的是如何通过最简便的沟通，来最大限度的满足客户的要求，做到这一点，需要需找大量的信息，客户公司的经营方面和他们对手的情况，以及当前社会的情况这些都需要去收集信息，制作过程中也需要与客户进行交流，但是不能频繁地进行交流，毕竟客户都不是闲人，被问多了会感到厌烦，可以讲主要的问题都收集好了，再进行咨询，交流需要口头交流，最好不要网上交流，应为表达的不清楚。

　　第四节名为“为不存在的角色留下沟通的渠道”,主要讲的是项目后期的维护，做到这一点则需要历史记录，他与注释是不一样的，代码中的注释是为阅读代码而留备的，而History是为整个项目而记录的。这个历史记录就好比我们在学校学习过程中为每个实验任务所写的实验报告，将我们写程序时的思路，程序流程图，运行结果的截图，对错误的总结和反思结合到一篇文章中，这就是历史，是我们开发这个程序的证据，也方便我们在出错时能找到问题的源头。

　　第五节名为“流于形式的沟通”，流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。在交流中忙着交流感情，将自己的目的放在一边，这是不明确的，浪费时间。