工作随笔——求人要有求人的态度

本文倒不是认为需要别人协助完成一件事情的时候就要低三下四点头哈腰喊爷爷叫祖宗的求别人。不要字面理解标题的意思，而是说一切沟通要以快速达到自己的目的为目标。

当我这个社恐认为你沟通有问题时，那你的沟通是真的有问题。

某一天某个其他部门的人需要在我们负责的模块中合入类似如下的代码（已脱敏）

进行初步检视后，我发现CONSTANT_A和CONSTANT_B，除了用于运算someThreshold之外，没有任何作用。并且为了保证浮点数的运算精确，又显式创建了2个BigDecimal对象（实际创建了3个BigDecimal对象）。考虑到两个常量没有在其他地方被用到，我提出了以下修改建议：

通常来讲，代码检视意见也不一定就100%是正确的，说不定代码提交人有自己的考量，于是我等待对方给出了解释：

兄弟，行行好吧，现在是你想往我们的模块里塞代码，不是我在求你改成我们期望的代码设计，并且我这样建议又不是为了刁难你，又不是等着你说什么“求求你了XT总，把我这个代码合进去吧，我什么都会做的”。

此时我认为他的解释站不住脚，将建议升级为要求。

就这样，两个人为了短短几行破代码，吵了一整天，甚至最后由双方的Seniors决策，最终还是按照要求进行修改。

我们来简单复盘一下这个事：

            某人找XT申请合入一份代码；

            XT认为这样的写法过于浪费，建议修改；

            某人拒绝修改，并指出是为了可读性必要；

            XT认为某人的写法不仅没有可读性优势，且浪费空间和性能；

            某人认为这不符合他的编程风格；

            僵局；

            5小时后，Senior决定，按照修改建议去修改并合入。

此时总结一下双方的得失：

            XT：获得了一天的坏心情

            某人：代码合入耗时浪费了5小时，并且以后的代码提交会被XT重点审视

对于XT来说，坏心情其实也算不上什么，他可能出去跑个步，回家玩个游戏就忘得精光了，但对于某人来说，这5个小时是实打实的浪费掉了。

在这个情景中，某人处于被动的一方，是需要请求XT来完成一件事情。但面对XT的要求，某人不仅没有拿出更好的解决方案，也没有拿出有力的拒绝要求的条件，导致了双方僵持不下，最后给自己造成了实质意义上的损失。

如果将我带入某人，在我发现没有更好的解决办法，或者没有可以强有力拒绝对方要求的依据时，此时就应该接受对方的要求，以达到完成事情的目的。如果我有更好的建议，我会提出来，但也会优先考虑对方的建议，毕竟主动权在对方。这个过程中不涉及任何所谓的低三下四，一切都是为了更快的达成自己的目的。