我被我们公司的一个年轻程序员给PUA了，他竟然跟我说：“你知道吗？有人说跟你沟通非常累！”，他说这句话的背景，是我在跟他一起为了一个我写的小的旧项目过代码，他觉得我的写法不对，但是我又不想跟他纠结对与不对这件事情，所以他才说了这句话。

项目逻辑比较绕

这个项目背后的业务逻辑比较绕，经过数次迭代，稳定下来的版本的代码逻辑是我、项目经理和研发副总共同定下来的，有些事情一时半会儿是讲不清楚的。

而且，绕的部分属于程序框架部分的代码，现在的写法比较利于拓展、通过配置参数的方式避免下次业务出现变动而大动代码。

可能不看代码很难解释清楚，我打个比方吧，它就像一个充电器的插头，不管插头内部多么复杂，但是始终会有一个“C口”，只要是“C口”的充电线，都可以往里插。

换言之这个年轻程序员他只需要写一个“C口”的充电线，往里插就可以了，他应该关心的是“线”，而非“插头”。

代码框架的思路类似于插件式开发，但又不是插件式开发。

因为这个项目他没接触过，所以我跟他过项目的时候选择了快速过了一下框架部分，然后再详细过一下业务实现部分。

但是，这个年轻程序员始终对于框架部分的代码耿耿于怀，于是他直截了当地问我：“我可以重构整个项目吗？”。

年轻程序员想重构代码

项目给他的时候，其实有一个拓展开发，开发完成时间就一天，这一天还是因为我们公司研发时间是按天算的，实际上这个拓展开发可能一两个小时就能搞定了。

所以，他说要重构这个项目，我当时就呆在那里了，过了一会儿我跟他说：“你别看这个项目小，整个项目可能一两个星期就开发完成了，但是这个项目从立项到客户验收经历了快一年时间，其中有大部分时间都在跑数据测试和验证数据，你如果重构这个项目，那么可能之前耗的时间又要重来一次，即使我们愿意，客户也不愿意！”。

年轻程序员感觉比较无奈，于是跟我说：“反正我是接受不了你的这种写法！”。

我看他还在纠结框架部分代码写法问题，根本不关心我所说的重点，有点失去耐心了，我反复强调他所认为的代码逻辑无法理解的地方，他不需要关心，他只需要关心业务部分。

然后他说：“我不搞懂这部分的代码，我怎么能写好接下来的代码呢？”

他这么说从研发角度其实是对的，但是当下留给他的时间不多，我的时间也不多，所以并不符合实际情况。

然后我就跟他说：“你如果真想搞懂这部分的代码逻辑，你可以先把当下的事情完成，然后我们找个时间专门过这块的代码，把这其中的逻辑和这么写的背景说给你听，到时候你再看看是不是还是你现在的想法！”

猝不及防的PUA

说完这句话，他就爆出了开头的那句PUA我的话，我不知道他为什么突然提那么一句，显得很突兀。也许是他执意不想动我的代码，甚至认为我的代码是“屎山”？宁愿重构也不愿意在我的代码基础上进行拓展。看我油盐不进，所以才说的这话？

这句话实际上是我们研发副总说的，当初说这句话的时候，其实也是因为这个项目，因为这个项目的逻辑非常绕，我和研发副总在数据对接上存在沟通障碍，当时对于业务都不熟，所以我和研发副总经常因为认知问题沟通困难，所以有一天研发副总才说了跟我沟通起来特别累这种话。

所以，研发副总说这句话的背景是我们双方沟通存在业务认知障碍的情况下，其实，我当时的想法是跟研发副总是一样的，我也觉得跟研发副总沟通困难。

所以，我觉得既然我和研发副总是因为对业务不熟，话总说不到一块，那么我就找一个对业务熟地做我俩的“话事人”。于是，我找了我们公司懂业务的项目经理在我俩之间做“传话筒”，这才让沟通变得顺利。

当这个年轻程序员旧事重提，似乎想以“我不好沟通”这个理由来让自己站在上风，我觉得他这种行为类似于人身攻击了。

对于他这种攻击性的言语，先是一惊，想不到自己被一个年轻程序员给PUA了。

我尽量克制自己的情绪告诉他：“这个项目由你接手是公司的决定，我也无法改变。我该说的都已经说了 你如果真要重构项目，我也无话可说，但是这个项目如果你重构了，出现任何问题可就与我无关了！”

最后，我还是给他指了指他需要拓展的代码部分，并且告诉他：“客户要求尽快开发，并且我们的软件实施已经去客户现场了，如果你实在不想接这个项目，你可以跟公司提！”

总结

并且，我觉得程序员在项目沟通中，遇到代码思路的碰撞产生不同意见很正常，甚至有的时候因为意见不和面红耳赤也很正常。但是，良好的沟通方式应当是对事不对人，一旦在沟通过程中开始针对项目人员的问题指手画脚，那么最后这种沟通就很难友好的进行下去。

而且，很多程序员在写代码的时候是喜欢看起来比较优雅的代码的，但是时间久了，会发现，有时候代码开始看起来是比较优雅的，因为后期的更新迭代，即使再优雅的代码结构，可能最后也会变成“屎山”。

如果一遇到类似这种代码结构就要重构，虽然代码看起来会因为重构重新变得优雅，但如此一来是不是一直要做重复性的工作？