妥协

非墨

妥协

黄弘 作于 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/

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

阅读 1.7k

会出错的总会出错。知乎:https://www.zhihu.com/people/ihongs

2.1k 声望
34 粉丝
0 条评论
你知道吗?

会出错的总会出错。知乎:https://www.zhihu.com/people/ihongs

2.1k 声望
34 粉丝
宣传栏