Coup de Grace

如何在公司内讨论技术

如果想要舒心的在公司内讨论一些 experimental 性质的技术选型,方案,探索等等

那么牢记以下几点可以让你保持一个好心情.

ps: 我最近听了机核的这期电台很多次

对于重轻提起的社会化失败很有感触,希望大家都不要变成无聊的人,祝你老是失败.


ref 背书

如果想节省一些交流成本,那么很多 ref 是必要的.

你直接引用一下 Google 的,MDN 的,甚至是 IBM Developer, CSDN的都可以.

如果没有或者懒得这么做,想轻松的开始沟通那是不可能的.

发表出来成文章的东西是有神圣镀膜的.


名字很重要

你的方案必须具备一个名字和代号,最好是开天辟地型的.

中国神话用完可以使用希腊神话,希腊神话用完可以考虑一下北欧神话.

毕竟复仇者联盟和战神 4 都出过了嘛.

为难一下别人的舌头又不是什么冒犯的事.


必须单独成项目

扩展协议,扩展标准什么的就 low 逼了.

你的方案必须成为一个单独项目,别人有想法我们是不接受 pr 的

事成之后你可以走需求流程来提需求,我们考虑实现.

当然,我不想维护了就可以强制清退所有用户.

你骂我kpi项目是你不客观.


结果相同代表方案相同

有 Dash 珠玉在前,面向过程的实现功能不是犯错.

只要我们输出的结果是一样,那么方案就相等.

主张者是不需要举证的,只要理论上我土法炼钢炼的出,就没问题.

毕竟推翻重做和下期再做是万能解药.


统一与包装很重要

当你团结了另一个用户,那么你的方案已经得到了统一.

这时候游离在神话体系之外,名字上加上U已经没问题了.

不管你理解成 Unite 还是 Ultimate 抑或 Urocyst 都可以.

使用任何东西也切记要包装,最起码也得在每个组件上加个 U+ 神话的前缀.

不然被人发现了怎么办.


不直觉的想法很可耻

如果你的设计反直觉,甚至anti-pattern.

那么你要小心了,此时ref 背书原则都不一定起作用.

可耻的活下去吧.


done.

哦你瞧瞧我这脑子,刚写完就忘了加上 ref,抓紧补上.


ref

图片够不够大.