你们抵制996，但工作量完不成，不加班怎么办？ 第1页

中国的相当一部分经济问题都来源于“两个人拿三个人的钱干四个人的活”。

这就导致了有另外两个人拿一个人的钱还没活干，经济危机就这么来了。

想解决很简单，两个人拿两个人的钱干两个人的活就行了。

你們一天要掙十萬塊錢，但掙不到，是不是該搶銀行？

搶銀行犯法，強制996就不叫犯法了？還是說知道搞996也不會有人把你當場擊斃對吧？說到底你強制搞996你沒有生命危險~~

工作一天幹不完就不用非得都安排在一天裡，活兒是永遠幹不完的，而且單純靠堆工作量的工作也沒有什麼競爭力可言，你跟大公司比堆人力，你堆得過大公司？腦力工作者玩的是創意，人都休息不好還哪來的創意？但要按照目前這個趨勢看，強制搞996的老闆走夜路被員工捅一刀的可能性也不是完全沒有，人要是休息不好就會不理智，不理智的情況下幹出啥事都正常~~

说的好像你加班加点就能完成更多工作一样。

我来告诉你某厂的加班究竟是怎么一回事。

当年，某厂还是家不起眼的民营企业的时候，他们的软硬件质量很烂。

烂到什么程度呢？

烂到设备怎么都卖不掉，好不容易卖掉一台——卖给了梁山县——结果前脚卖出去后脚设备就坏了。

后来实在没法子，只好卖一台设备搭配个工程师。设备坏了马上起来给人修。

后来公司年会之类场合，总有员工把它编成小品，演给大家看。

当年他们的二号人物，大学刚毕业，清华。自己在会上给我们讲“当年的自己，蹬着双高跟鞋，背着个小包，每天跑厂里。厂子里的工人都熟悉了，一见就在背后窃窃私语‘看，大学生！’”，羡慕的不得了。

然而给人家开发的软件质量不行。三天两头往厂子里跑，可总也解决不了问题。

终于有一天，一位老工人对她说“邓小平说科学技术是第一生产力，我看这话在你身上体现的不明显”。

那个难堪哟。

再往后，这才引进先进管理制度，狠抓软硬件质量；“卖一台设备搭配个工程师”这种丢人的事才成为过去。

那么，究竟是什么神奇的诀窍，把一个“卖设备搭配工程师”的、质量稀烂的企业，变成质量可靠效率恐怖的巨头了呢？

1、你做的事，是会被同行认真评审的

比如，通过制度性的code review，你代码写的粗枝大叶乃至粗制滥造的地方可逃不过同事的眼睛。

当然，code review的原则之一是匿名。这是因为它的目的并不是“当众羞辱”。因此并不希望别人知道某个人就是被评审代码的作者。

匿名，才容易让同事们畅所欲言。

当一段代码写的好、挑不出丝毫毛病时，你自然可以躲一边暗爽；但当一段代码写的……有点……不可描述时，哪怕匿名，你的感觉如何呢？

或者，当看到别人写的优美流畅的完美代码时，你会不会心向往之呢？

通过code review，治病救人，有则改之无则加勉，代码质量自然节节升高。

2、鼓励分享

你在工作中想出了很好的点子，自己发明了不错的算法，某个任务被你以更优雅的方案实现了，甚至你最近看了什么书、学懂了某个技术……所有这些，你都可以写成文档（有价值的话，还会给你机会，让你给其他同事讲授这些知识），公司都会给出一个评估，计入KPI。

此外就是其它一些配套制度，用以保证项目从立项到实施、验收等每个环节的质量——包括文档字体等细枝末节，全都有详尽科学的规定。

这些东西带来了什么呢？

1、代码产出量大幅降低

没错，你没看错，代码产出量大幅降低。

一般来说，国际通用标准，程序员每周代码量应该是40~50行左右，最高不高于200行。因为再高 ，代码质量就没了保障。

代码量减少的同时，是文档的规范化，是编码前花在设计上的时间大幅提升，是代码质量精益求精。

2、代码复用度大幅提高，代码质量大幅提高，开发效率直接起飞

用过ORM吗？

ORM是“对象关系映射（Object Relational Mapping）”的缩写。

具体表现是，当你做关系数据库相关项目时，你不再是“先设计一个个表，建表，然后写代码连接数据库、一条条写sql访问数据”；而是“直接设计一个个类，指定每个属性（字段）的数据类型，指定键以及对象之间通过哪些键关联”——然后，数据库连接、访问你都不用管了，ORM框架替你干。

甚至，你修改了类定义，ORM框架都能自动生成SQL语句、帮你修改表结构——不会像人工操作那样，一不小心就造成数据丢失。

你甚至还可以随时切换数据库：不管你是从MySQL切换到Oracle还是从sqlite迁移到MS SQL，只需更换config文件中的配置即可。

类似的，我曾经在另一家公司做过一个工程。里面有几百种报表，每个报表都要通过网络传输；或者说，都对应着一个网络数据报文。

这个开发工作量实在太庞大，代码也太难测了。

因此，当时的项目组选择使用XML，理由是文本报文，万一出错了人眼能直接看出问题在哪——嗯，你想象下，几百个表格，一个个都要从C struct转换成XML文本通过网络传输、然后网上传来的XML还要一个个解析出来然后重新填写到正确的C结构体里……

这个工程需要多高的代码量？这些代码得多少测试才能确保无误？尤其是C，这要一不小心，得搞多少野指针出来、得有多少溢出覆盖——然后又会有多少缓冲区漏洞？

没错。在我接手这个项目之前，这个公司完全是陷入了泥潭。他们旷日持久的开发、没日没夜的加班，二百多人的开发团队忙了一年多……你算算光程序员工资得付出多少。

而代码质量呢……这么说吧，有天一个问题单到我手里，说我的程序崩溃了；结果我跟进core里面一看，明明白白是另一位同事负责的XML内容……他写越界了，然后不知怎么一口气覆盖到了我的栈空间——我们各自负责的模块隔着十万八千里呢。要不是XML格式数据，这故障还真不好找到责任人。

这种故障实在太多了；为了避免崩溃，这个项目组甚至连debug版的assert都给强制define为空！

掩耳盗铃的结果，是这个项目完完全全的不可用。每加入一个最最简单的模块都得持续几个月的测试，这才能勉强“跑通流程”。

我做了什么呢？

和ORM的思路差不多，我用泛型和宏搞了个“C结构体与XML报文的转换库”。

现在，你可以用DECLARE_TABLE(table_name)/DECLARE_ITEM(item_name, type, len)/END_TABLE(table_name)这一系列宏来声明一个报表——这个声明会自动“变”成一个C结构体和一个全局的、和表名联系的数据结构。

（大概思路忘差不多了，应该是declare table/declare 其实是在声明和初始化一个名叫tableNameDetails的数据结构，同时把struct声明当字符串拼接在一个宏变量里面，直到end table才真正声明这个struct。这样知道一个struct的typename，就可以顺藤摸瓜，读取相应的typename##details数据结构，根据指示自动打包/解包了。）

然后，我写了两个泛型接口: struct2xml和xml2struct。

只要你的报表是用这套宏声明的，那么你就可以用struct2xml(struct_ptr, xml_buf, buf_len)把任意结构体打包到xml；然后呢，当你从网络上得到一个xml之后，你同样可以用xml2struct(struct_ptr, xml_buf, buf_len)把它转换回来（struct类型标在人家的报文头部，很容易得到）。

这个东西我记得一共是800来行代码。写完后一次通过。

当然，限于个人水平，这个封装我很不满意。不易读（宏毕竟看起来太过杂乱），不直观，难维护（必须懂泛型），僵硬死板（可以支持数组，可以内嵌已经定义的结构体甚至结构体数组；但声明数组的语法较为怪异，不支持直接定义嵌套结构体，也不支持指针）——主要是当时还没见过ORM的优雅抽象，搞的MFC一样诘屈聱牙。

如果现在再做，我一定能实现的更漂亮，毕竟有成熟的ORM设计可以抄了嘛（另外，google也有个开源的Protobuf，是一个更优雅的解决方案）。

在此之前，他们每打包一个报表都需要至少一两千行代码（管理水平太差，用代码量当KPI，使得肯留下的，多半水平很那啥。因此哪怕二维字符串数组复制，他们中的某些人都不用循环，而是手工一行行码代码；再加上大量没有实际作用的废代码，因此一个报表一两千行代码都是少的）；按200个报表算就是二三十万行代码——再加上其它逻辑，结果就是二百人写一年，除了蜗牛般缓慢且bug层出不穷的破烂demo，他们一无所有。

而我这800行代码，可以把他们质量可疑的、打包/解包相关的几十万行代码统统替换掉。只需用DECLARE_TABLE代替直接的C风格struct声明即可。

嗯，知乎南郭先生们大概又该跳出来了：别人二三十万行代码，你给精简成800行？呵呵，吹吧！可劲儿吹！

见太多了。我说优化算法，他们说吹；我说代码质量，他们说吹。

只因为他们从来就没学会过编程。

这种人我一贯立即拉黑。毕竟夏虫不可语冰。

总之，代码复用率是一个极其重要的参量。计算机设计出来就是为了代替人工作的；这个“代替”的范围自然也涵盖程序员的工作：可以用循环做的，就不要出苦力一行行码代码；解决过一次的问题，就不要再次去解决它。

就好像这个报表从struct到xml来回转换一样。最差的码农能写二三十万行，bug层出不穷，以至于不得不把assert去掉，免得它老出来叫；初级程序员得写差不多十来万行（利用了循环，但必须一个个打包解包），稍不留意就出错；到我这里呢，抓共性，每个数据类型写一段代码、然后按需复用就足够了。所以800行代码解决一切打包解包问题——只要把这800行写好了、确保无bug，那么以后打包解包这块的质量就有了保证。

然后呢，这800行还可以继续优化，优化的像ORM那样优雅，那样易用好用；甚至高屋建瓴，做成protobuf。

那么，现在，请加班高手出来：你们007连轴转，转200周——也就是大约4年——比得上我这两三周的955吗？

这样写出来的代码得付出多少人日测试，才能达到我这800行的质量？

四年共1460天，208周；出苦力写三十万行代码封装这所有200个表格的话，每周需要1400多行代码，还会有无穷无尽的bug——可真苦了他们。

可惜，苦工的这种努力不值钱。一百个捆起来都不行。

我写这个代码，产出率大约是每周300行左右。

那么，如果公司技术氛围更好、像google那样，每周40行，给高级程序员更多时间查资料、思考和讨论更好更优雅的抽象方案、给出专门时间持续优化，有没有可能在他们之前搞出protobuf呢？

这个东西，和protobuf之间，还有什么实质性的鸿沟吗？

一旦做出protobuf，将来公司任何数据结构的串行化，包括网络数据报文的打包和解析、包括文本数据的存取，就再也不需要码代码了。

想想光这一项，提升幅度能有多大。

完全是工作效率和代码质量的双重升华。

当然，这是个较为特殊的案例。

实践中，几乎每个任务都有办法“取巧”，可以动脑子实现的更精炼同时更易懂；但像这个东西提升这么大的，的确不算多见。

但，类似情况也并不罕见。起码我亲手做过的就有不下于十几个；见过的更是不计其数。

没错。几乎所有的重复工作都是有办法自动化的。这本就是程序员存在的意义。

找出用计算机算法完成任何重复工作的路子，也是任何有志于在这个行业发展的人的基本追求。

之前，这个厂子和当年其他软件厂商一样，玩“封闭式开发”（其实应该叫“囚禁式开发”），几乎人人备个铺盖卷，007连轴转，转累了就地一铺，睡觉。睡醒接着干。

但这样蛮干已经被证明是行不通的——如你所见，一个个报文全手工打包解包，大概熬个夜也没什么。反正做多了都是熟练工，不用动脑子。

但是，想要抽取共性，硬生生从不可能中找出条路，用一个月时间碾压别人四年的工作，你的头脑就必须保持清醒。

别说996了，955我都不敢连续编码太久。一旦沉浸进去，至多连续工作四小时，不然吃不消（这事我说过很多次，当时2000行做了个一举解决所有接口测试问题的框架，思考一周，然后花了6小时敲2000行代码，一次过，0bug。累的起不来，在桌子上趴着睡了一个多小时才站起来。之后一个多月脑子嗡嗡响，一行代码都没写出来）。

必须有最好的状态，才可能挑战这种创造性的任务——才能用一个月不到的、寥寥没多少行的“简单”代码，碾压苦工们的四年007。

代码复用度越高，它就越好测试，质量也就越高——同时开发效率也越是提升巨大。

然而哪里都有庸人；很多东西，在高级程序员能够把有限的精力投入过来之前，的确也只能靠普通程序员先撑着——撑到高级程序员有时间关注这块、搞出更好用更高效的抽象和对应的支撑库之前。

——你当然应该尽量把自己训练成高级程序员；但并不能期望每个人都能随时随地完成创造与改良。尤其是那些只会996007出苦力的“苦力帕”们。

面对高级程序员一个月碾压自己四年的“恐怖现状”，面对高级程序员少量代码实现大量功能同时却又保持0bug的“恐怖现实”，很多人选择用“加班”来“自保”——我是砖我是瓦，我是兢兢业业的螺丝钉。看在我努力到这个程度的份上，效率不高能不能多担待？写出bug捅了篓子能不能别打？

我之前在知乎写过回答，剖析过这种人的心态：做一个优秀的程序员到底难在哪里？

这种人的存在，的确对公司工作氛围存在某种正向作用——看看XX，都努力到996/007了，我们还是有差距啊。

尤其是，中国一贯的有法不依；加上这种人干的也的确不能算是什么正经的脑力活，多干一分钟有一分钟的好处。因此管理层自然乐于诱导：“我司不提倡加班。但加班到9点有免费夜宵”。

但是，只要你能按时完成任务，只要你对自己有信心，也完全可以955。

如你所见，如果你是码农，那么加班的确能帮你尽快达成工作目标；但如果你是高级程序员，那么加班甚至仅仅是急于达成任务，都可能让protobuf胎死腹中。这个损失可比加一两年班要惨重多了。

换句话说，人家其实是双轨制：不需要加班的955，不得不加班的就让他996。

只是慢慢的，慢慢的，这个双轨制变了味……

我想，总不会是教育质量大幅下滑导致这届程序员不行，真正学成了高级程序员的基本没有，所以另一轨就萎缩了吧？

人手不够那就多招些人呗，搬砖的包工头都懂的道理你还不懂？

大家不是不愿意加班，而是不愿意白白加班。

这就是无能的领导在抬杠了。

别的行业不了解，互联网和IT业的996有九成工作是应付领导拍脑袋的瞎改和不负责任的计划。先随便定个需求，不管符不符合业务（可能根本是空想出来的场景）；搞个流程草图就急急忙忙上马开发，开发到一半忽然有新的idea，工作量增加两倍，deadline不变，只好996；没时间测试，线上直接修bug，出问题后全体继续加班熬夜；最后折腾两个月不休息搞出来一个破破烂烂全是毛病的半成品，要是管事的人能提前多用用脑子，可能一个半月不加班就弄完，还没那么多bug。

小公司和大公司相比，人员与资金虽然处于劣势，但架构简单，没那么多内部流程；层级扁平，老板能更好地管理到各人的工作；甚至拉合伙人、给骨干分配股权都容易许多。

这些因素结合起来，有头脑的领导能节约下大公司在冗长的审批手续和复杂的部门扯皮中浪费的时间，抢先完成产品、搞定客户，最大限度发挥自己的优势。

没头脑的领导呢？就只能靠压榨员工加班，人人疲惫不堪心生怨气，结果他怨气比员工还大，还反问别人，难道我小就活该倒闭吗？

对啊，不然呢？