会用辩证思维法，你就掌握了团队协作的效率利器

        我们技术团队在讨论技术方案的时候，经常会有不同的意见，据我观察，75% 的情况下，很多人思考解决方案的角度有待优化，总结下就是没能站在一个正确的角度去运用辩证思维。

        举例子：业务系统的代码中有常量，其中有些是平台级的常量，有些是少数系统的公共变量，我们是用 common 包呢， 还是各自写各自的？

        答案是什么？老实说我没有标准答案。如果一定要给个结论，那我的结论是：

        在不同的阶段、不同的背景下，我们的选择是不同的。

        例如一个人维护两个系统的时候，我主张两个系统代码中共用的代码分开写， 各自写各自的，哪怕是完全一样的 DTO 也不要写 common module，因为写 module 增加了代码模块，放项目里简单不用多想，复制粘贴麻烦点， 但是思维清晰，而且符合项目解耦原则，将来有人接手了，也不用特意叮嘱什么， 一切有接口文档约束就好。

        再例如每个人维护一个子系统，遇到多数人会用公共变量的时候 ， 应由大家坐一起讨论，最终由专人维护比如基础组或者是架构组去维护统一版本。

        我一向主张在讨论解决方案的时候，要想说服其他人，那么首先你得先说服自己， 自己把自己辩明白了，跟别人讨论的时候才更有说服力，而且沟通效率高

        其实任意一个解决方案一定是有优点有缺点的， 突出自己方案的优点， 贬低别人方案的缺点这对于解决问题是不利的，决定取舍的是我们思考问题的角度而已，假如你把自己放到团队协作的角度上来，如何做到两个团队在物理上不会相互影响？这就有很多点可以去讨论了了， 很多问题在不同的阶段不同的背景下，答案是不同的：

        假如你是一个 coder，你可能会想，这样干我的麻烦就多了， 能甩就甩出去，挖坑了也是别人跳（其实有时候挖的坑也会是自己跳），我必需要把我的常量写在 common 里面，这样别人就不用一直来烦我问我了，看代码就能看到。

        假如你是一个团队的 leader，你一定会思考这些问题：
        迭代效率、版本管理、团队解耦、协作方式 、工作效率、沟通、消除信息屏障等等。

        这就是角度的不同。

        举个例子：我写了 common 如果没发版，那别人合了项目代码的时候，会拉不到 common 里面的最新变量，然后发版就报错了。再找人发 common ，人家说 common 发了呀，再查哦原来是 common 分支没合又哐哐哐的去合代码，发 common 。万一包仓库还有多个环境，那简直就是悲剧。

        总结：辩证思维法、解决方案是阶段性的、效率工具