梦断代码读后感

Posted 2021-06-20 Java小白2333

发布日期：2021.4.09

误区1： 加强沟通就是多和人说话。

这一点最大的问题，就在于狭义了的理解了沟通的意义。对于技术人来说，沟通的方式是多样化的，比如说，书写技术方案文档，每日工作邮件，添加代码注释，提交代码的时候是否有完整的git comments等等。而且，以上这几点对技术人而言，比直接说话沟通更重要，因为如果已经有技术文档，就不用每次来一个新人，就需要重新语言沟通一遍，提升时间效率；如果有代码注释，其他程序员就可以快速的知道API中的输入输出和参数的含义，做到快速接入，而不需要找到原作者交流一遍。

对于技术人而言，真正的沟通其实早已经融入到他自身的工作中去了。

沟通是桥梁, 但沟通并不单纯是自下而上的。在技术团队内部,沟通很多时候,是和团队里的其他"技术"进行的。需要通过合适的方法，将信息在技术团队中同步开来。这也是为什么，越来越多的技术团队开始引入JIRA,Confluence, Code Review Board等各种工具，帮助大家做好沟通。

误区2： 沟通是为了取悦别人

这个问题还是比较常见的，实际工作中，一些技术的同学，在需求评审过程中，对于业务或者产品提出的需求，没有经过认真的准备和思考，就一味的答应，认为这就能得到产品或者业务对自己的认可，以为这就解决了沟通的矛盾和问题。

在我看来，沟通的第一要素，就是输出确定性。这就意味着，准确的回答比满足对方的要求更重要，将偏差暴露在早期，远比最后无法达到，带来的失望好太多，更别说，早期问题可以有时间去找其余的解决方案。对于个人而言，沟通的确定性是个人专业的一种体现。

沟通能力与代码量积累成反比。沟通不好会多写好多冤枉代码，而且还没有得到满意的结果。

误解3：沟通能力=会聊天

技术人的沟通能力绝对 != 会聊天，而是拥有足够的专业能力+会聊天， 技术水平是"沟通能力"的基础。如果没有扎实的技术基本功, 对每个环节都没有深入认知的前提下,即使会聊天, 善于沟通,所传递的信息也可能是错误的，我也见过很多沟通伶俐的工程师，进度汇报非常漂亮。但是，他代码的质量可能糟糕到我不得不考虑重新更换一次人员。

反过来说，如果一个技术人总是能用一个简短的比喻,或者小故事,让完全不懂技术的业务人员知道他在做什么, 能讲明白引入某一项技术的优势和作用。那么他的沟通能力就是很强的。

工作本身分两种，一种是“社会化”的，就是跟人打交道的，比如销售、市场，还有一种是“非社会化”的，做技术开发的明显是属于这一类。那么“社会化”和“非社会化”之间的沟通，说白了，就是学会用别人的语境沟通，这是个很重要的技巧。

程序员尽管不合群，却真的需要与他人倾谈——形式越随意越好。

为了完成工作，程序员得有办法随时询问和得到解答，在团队内部传播答案，并保存答案豫备不时之需。