妥协

妥协

黄弘 作于 2015/11/02 01:20

零. 完美主义者的自我意识

不隐瞒的说，我是一名重度“拖延症”患者。也许从我出生开始就在自己跟自己较劲、拧巴，拒绝妥协却从不表态，因为我也不知道我在坚持什么。

小时候爸妈以异常节俭的方式表现在我面前，他们偶尔“大方”一下要给我买点什么裤子、鞋子，我总是坚持不要。我不知道我为什么不要，总之我就是不想要，所以他们就猜测到底是没满足我什么，是颜色还是款式，觉得我很犟。

我的确很犟，因为我女儿也这样。所以我反而懂她了——很奇怪的反应。

有时候我对自己要求完美，要么满分要么鸭蛋。高中时跟语文老师对着干，只要是他的课我就不上；要么不交作业，要么写完一整本的作文。与其斗，可谓其乐无穷。

后来也知道自己不是那块料，就不再写文章了，改写代码。但可惜的是代码总有个时效，你总得依赖某个环境而存在，而环境总是在变。Java 1.4 用到现在 8，PHP 4.3 用到现在 5.3，据说 7 都出来了。其他喜欢的 Perl, Python 亦如此。我想写个长久的东西，但过不了几年再看就是垃圾，或代码样式陈旧得让人难受。

比如我的开源项目之一 HongsCORE 从 11 年底启动到现在都 4 年了，总共规划的 4 个系统只勉强出来这么 1 个管理系统，大量的时间在折腾框架上，而且越折腾还越来劲。

尤其是在命名和代码对齐上，耗费的时间可能就占了一半，为此没完没了的重构。命名倒不是因为用的词意思不对，而是——不能对齐，或不能呈现某种简单的规律。比如都是 6 个字母，或依次 3、4、5 个字母，或按功用某些类必须排列在一起且有先后顺序，恨不得想给类名都加上 01、02 的前缀。

这可能就是有些人还大赞的“完美主义”吧。而我却深受其害，进度受此拖延。为了缓解自己的“症状”，我就去开发了一个“数据管理”的模块，这下建表、字段爱叫啥叫啥了，因为底下都是代号，一串无特定意义的 36 进制数字（0~Z），而且还故意设计成不可人为指定；展现上某份数据、某字段今天叫张三明天改叫李四无所谓，再也不用为命名纠结了。

但总有其他的事萦绕在你脑海——只要你没“治疗”好你自己。好在现实总是在该让你醒醒的时候就给你浇一壶凉水，2012 年就被猛的浇了个透心凉，然后居然就特么大彻大悟了，悟出了一剂良药：妥协。

一. 我们要妥协什么

因为自己嘴笨，每次讲这个话题都讲不清自己心里的意思，结果给人的感觉就是：他这个老油条，又在讲买菜理论，要讨价还价了。而我在家根本不买菜也从不砍价。

过去在不同的单位观察，总结成功的项目和失败的项目，发现一个大家都知道的没鸟用的现象：成功的项目往往有个“老家伙”在“管事”。相反新提拔起来的开发人员去做项目管理通常会出问题，要么成员不服做鸟兽散，要么经常没法按期交付，尽管你看他是那么的努力。

是“管理”经验问题？我从来不相信对开发人员有何“管理”经验，这是一群聪明透顶的人，喊口号、讲人生、画大饼、立规矩那套压根行不通，如果你相信他有用我告诉你有效期是半小时。唯一对所有人同样有用的我相信只有利益，实实在在的东西——这是帮绝顶现实的家伙。

他们要妥协什么、可以妥协什么呢？基于预期收益对目标的妥协。现在都是一条绳上的蚂蚱，你好我好他也好，其他部门都眼巴巴的看着，大家都等着了，能做出来你的代码就没白费，休假、腐败、奖金、加薪，打脸也要去申请。不谈利益瞎扯淡的那都是耍流氓。

要别人妥协什么呢？定稿、定稿、定稿，重要的事说 3 遍，意思就是：哥们，我们要冲了，您可路指得准点，别让我端着枪跑出一里地了你又喊跑错啦，回来~回来~，我得回得来呀。

二. 妥协是一种坚守

你不得不面对一个问题，何时自己该妥协，何时对方该妥协。彼此应当总有自己要去坚守的东西，要么为了维护系统的统一或稳定性，要求对方做出妥协；要么对方坚持推出与竞争对手有差异的产品，你做出妥协。无论哪方做出妥协，风险总是明确的存在，可能推迟、可能未来维护困难、可能做完了也就完了毫无特点。

每个人都在大谈坚持，但事实上无论你是坚持还是放弃都是错的，前进是坑、后退也是坑，只是大部分人只知道后脚跟处有个坑，却不知道大雾弥漫的前方也是个大坑。进总是要进的，坑总是要填的，要看为了什么而舍弃了什么。

让他人妥协，是坚守自己的价值；对自己妥协，是坚守自己的利益和群体的目标。

三. 如何让对方妥协

有人觉得，我就一底层写代码的，要占据主动，推动别人走，怎么可能？

作为一名智商不高情商也 Low 的笨码农告诉你，你行的。如果你情商够高可直接跳过此节，因为对您实在没神马有价值的建议。对一名搞不来人情世故，不会玩、不会来事的宅男来说，有效的让对方做出让步的方法只有一个：让对方感受到风险，而非藏于内心深处。

看过《三体》的朋友应该知道，第二部《黑暗森林》中 4 位“面壁者”中的 3 位相继被“破壁”，只有大宅男罗辑成功的阻止了三体的入侵，而其方法居然是“威胁”：告诉你三体人，你要灭我，我就在你灭我之前广播坐标，咱们全完蛋。

当然不是要对自己的上司、同事用如此歹毒的招数，当量要缩小些，对相关人做不到动之以情就要做到晓之以理：我可以按你说的做，但这会带来不确定的安全性，原因在于……同时破坏了系统的统一性，本来此类问题可以复用某某模块，现在因为增加的特殊需求，而某某模块由于过去并未考虑到这种可能无法细分……因为这些额外的需求导致部分东西必须重新开发，时间上需要延期……总之，如果您坚持这么干咱们就这么干了……

你必须把你的担忧说出来，你的同事、上司是个明白人的话会仔细考虑清楚的，如果他能承担那你也可安心去做，且可能因部分不确定性争取到合理的时间，他也好做出充分的防风险准备。

透明可能是三体的弱点，换个角度可能就变成优点。

四. 可以没用的私货

我不知道为什么，我从小就喜欢这 4 个字，“可以没用”，我在我的书本上到处画满这 4 个字。有用没用不重要，重要的是你在思考。

a. 开发原则

人多、时间紧，代码写不好？我有招：

1. 独立原则：设立公共库，项目突击期不得往里面随便加东西，各自的工具各自维护，待重构期再总结重用；

2. 特例原则：同1，不是对整个项目细节特别熟悉，对实现手段了如指掌，不要轻易做大规模封装，封装尽可能是数据流经路径可拆解的（反转控制），避免遇到某个特殊问题而无法特殊处理；

3. 就近原则：同1，相关的代码应该尽量的靠在一起，或命名规范一致，如页面 A 要用到一段独立的脚本 B，不太长就放在页面内，太大放到同一目录下或指定目录下同名文件中，看到 A 就能快速的找到 B。

b. 产品对策

实际工作里并没参与多少产品设计，以旁观者的角度也提几点：

1. 夯实基础：设计稿应当是思维发散的，先把主干想清楚定牢固，枝叶就不容易被大风刮得东倒西歪；

2. 各个击破：主干确定下来后如果时间仓促一定要逐个枝条充实完善，不要一层层的完善，因为理解总是有偏差，没有细节开发很难保障与设计一致；

3. 最小文档：类似就近原则，给开发的文档要足够小和集中，如果资源多必须分散，请确定主文档，并加好“链接”。

五. 写此文联想到的

《失控》 我的最爱 http://book.douban.com/subject/5989373/
《三体》 近年大热 http://book.douban.com/subject/3066477/

我发现上面的标题很整齐，我很欣慰，该睡觉了