在国企当程序员是什么体验

乐字节教育 是集线上教育与线下培训于一体的全栈式教育机构，致力于高端IT技术教育，培养高端IT人才，让人人都享有高品质教育是乐字节的教学理念。

2017年初，我通过一整天的笔试及面试加入一家（某一线城市国资委全资控股）某集团的研究机构（中央研究院），任职软件工程师！

在这边工作了整整一年，目前 已经跳槽到一家互联网公司 ，在回头看看这一整年，感受颇深，只好一吐为快，以便对想进入国企的程序员帮助及借鉴。

入职考试

国企面试与其他企业并没有太大区别。

首先是笔试，一般都是前面50道选择题，后面两道是开放性的大题，大题没有固定答案，只要符合社会主义核心价值观就可以拿到满分。

选择题是关键，全部都是技术题，需要答对40题以上，才有可能进入下一轮面试。

面试分三轮， 首轮是程序员面你（你未来的同事） 。

他们会问你一些技术相关问题，例如：选举算法，redis的应用场景，如何处理高并发，如何保证高可用，是否关心Nodejs新发布的版本，deno是什么；诸如此类的问题很多很杂。

第二轮面试是由副院长来面（也就是你未来的直属上司） 。

他会问你项目相关的问题，例如：做过哪些项目，解决了什么问题，你在项目中的角色，项目是如何管理的，又是如何进展的，使用了哪些技术栈，为什么挑选这样的技术栈，遇到哪些问题，如何解决的这些问题。

第三轮面试是由HR来面 。

这个面试就很简单了，简单说一下你的情况，聊聊家常，然后他会向你说明组织结构，与一些待遇问题。

PS：进国企最重要的素质是文凭，我们研究院硕士以上学历人数比本科要多，而且大部分毕业于国内一流院校（交大生是整个研究院的主体）。

入职国企工作

1、工作压力

工作压力还是蛮大的，产品并不像私企由市场导向，而是政策导向；国家说人工智能热，那我们就去做人工智能的项目，说区块链热，我们就去搞区块链的项目，反正我在研究院一年以来，搞过云计算，人工智能，大数据，区块链。

好处就是你能学到很多东西，而且紧跟市场热度。坏处就是什么都会，但是什么都不精。

举个两个例子，我们也开发OCR AI识别系统，在市场上已经有很完善的产品，而且很廉价，我们依然花钱去开发这种产品，市场价值基本没有，因为直到目前为止，我们产品的识别率依然不如市场上的几个主流产品（阿里，百度）。

第二个例子，便是私有云，这个我们做得真的还不错，但是市面上最强的是华为，他们是卖服务器送私有云，也就是传统的卖硬件送软件，与他们相比，我们的产品就不具竞争力了。

工作强度真的还好， 一般都不需要加班 ，至少我是不加班的。

这就意味着可以放羊了吗？当然不是！

我加入的项目组，大多都是以2个星期为周期进行开发的，每两个星期要举行一次组内讨论会，如果完不成任务或者bug太多是需要加班处理的，因为国企是不可以出错的，一次出错可能直接招致点名批评（包括这个项目的所有相关人员）， 一次KPI黑记录，会直接影响你以后的升迁前途 。

组内都是协同工作，可能因为你的原因导致项目没法按时上线，发生一两次你就会被边缘化，最终要么离职，要么下放到子公司。 就算是副院长级别，如果完成不了集团的KPI，也是会被下放的。

但是相比互联网公司，国企的压力相对小一些，互联网公司实行的是不能胜任就走人的策略，所以每个人几乎都没有什么安全感，只有拼命的工作来争取自己有安全感。

国企，特别是大国企，公司的人事权一般都在公司总部手里。

国企办公环境一般都是比较好的，我们有自己的园区，自己的办公楼，空间很大，硬件配置都是很不错的，有健身器材，有空气净化器，有自己的食堂，有自动售货机。

有自己的产品展厅，有自己的公司纪念馆。

这部分只剩下吐槽了， 一个萝卜一个坑，萝卜不走，也不会让出这个坑 。在国企表现是没有意义的，除了口头表扬，你获得不了任何实际好处。

好的人脉要比努力重要，如果上面没人认识你，就算你的领导大力推荐你，你也不会得到提拔，空降长官在国企是一件司空见惯的事。

PS：组织人员要比群众晋升快（群众进不了总部）。

如果说国企15年前的待遇是一流的，那么 如今的国企待遇最多只能算是二流的，特别是对于IT行业来说。

以我所在公司为例，待遇采用工资+福利（洗漱产品，**票，接近1500元人民币的补助等）的方式，工资增长比较慢，相对于互联网公司来说，待遇至少是被腰斩的，鄙人也是迫于生活压力，为了生计而离开国企，跳槽去了互联网公司。

吐槽：国企没有奖金，国企没有奖金，国企没有奖金 ，重要的事情说三遍。

国企的稳定性应该是最被人人称道的，特别是中字头企业。

一方面是国企的社会责任感几乎不太可能会裁员；另一方面公司的人事权几乎都是在公司总部手中，下面的分部门是没有权利做出裁员决定的。

以研发为例，如果有人不能胜任工作或者和其他人工作合不来，部门领导会想总部申请调岗，调到行政人力或其他部门，不会出现领导向总部申请把你开除的事，所以国企给了员工很大的安全感。

互联网公司则不同，裁员是家常便饭，领导一高兴或一生气甚至一拍脑袋就裁员，经常一年就会裁员几次，员工几乎是没有安全感的。

互联网公司很多都是靠融资生存，一旦融资间隔比较大或融不到资就会裁员，生存的压力巨大，让它们没有能力或者没有职业道德感或无耻去考虑员工的感受。

国企则不同，国企的业务本来波动就很少，国企营收相对稳定，再说也不差钱，没有生存的压力。

实际大部分国企使用的技术一般都是商用的，比如Oracle，SQL server等，极少使用网上的开源框架。

一方面是因为商业软件系统稳定，有大公司做技术支持；另一方便开源软件稳定性有待加强，到了线上因为开源框架的bug导致的系统故障可以说是得不偿失，毕竟对于国企来说不差这些钱。

但是我们不同，我们毕竟是研究院，以研发为主，所以更多地使用开源技术。

PS：国企软件开发版本迭代比较慢，系统测试时间比较长，毕竟对于国企来说，不怕慢，就怕系统出现问题，系统出了问题比系统开发不出来更严重。

程序员开始脱离大厂投身制造业

程序员开始脱离大厂投身制造业，曾经被年轻人、高学历人群忽视的工厂，最近又迸发出“吸引力”。一大批研究生、博士生、程序员走出大厂“囚笼”。程序员开始脱离大厂投身制造业。

程序员开始脱离大厂投身制造业1

程序员应该是一帮专业型人才，虽然，现在人工智能普及程度越来越高，但底层代码并不为人所了解。面对繁复的代码，很多人如同看天书，望而却步，更不要说从事这项工作了。

程序员是高收入群体，在人们的印象中，他们也是加班最多的一类群体，经常有报道，程序员猝死在工作岗位上。透过光鲜亮丽的外表，程序员的“底层逻辑”看起来有些“寒酸”，如果将加班时长和较短的职业生涯联系在一起，程序员那点高工资恐怕无法弥补。

35岁是一道坎，社会上存在年龄焦虑，对程序员尤其如此。最近，大厂（大型互联网公司）刮起“裁员风”，爱奇艺、字节跳动、腾讯等都传出了裁员消息。特别是年龄大的程序员，首当其冲成了裁员“牺牲品”。在某大厂工作十多年的A先生告诉本网记者，他最近被公司材料了。

对于37岁的A先生，无论是生活现实，还是职业打算，他都决定牺牲一点薪酬福利，再找一家公司去从事程序员的职业。不过残酷的现实让A先生不得不妥协。

A先生被裁员后，他开始把简历投到大厂，结果因为自己年纪大（37岁）被拒绝掉，找了3个多月工作，没有一家公司肯给A先生面试机会。眼看“d尽粮绝”，房子要还月供、孩子奶粉钱、一大堆账单，A先生有点喘不过气了。他开始妥协，准备牺牲一部分薪酬，只要有小公司肯招他，他愿意“屈尊降贵”到小厂（小型互联网公司）上班。

让A先生万万没想到的是，小厂的人力竟然嫌弃自己的工作能力，这完全接受不了。现在，职场中的“大龄”人员往往被贴上“好好先生”“缺乏上进心”“工作态度懈怠”等标签，特别是程序员，35岁如果还未到管理层，程序员的职业生涯基本就结束了。互联网公司更喜欢“年轻血液”，刚毕业的年轻人，一张白纸，好调教，能胜任“5+2”“白加黑”，更重要的是工资给得低。

A先生离开大厂，生计何在？35岁真的是一道坎吗？

最近，本网记者注意到一个新的现象，曾经被年轻人、高学历人群忽视的工厂，最近又迸发出“吸引力”。一大批研究生、博士生、程序员走出大厂“囚笼”。前几天，新能源巨头宁德时代全资子公司在四川宜宾举行招聘会，吸引大批求职者。

高学历、程序员重返工厂，反映出我国新兴产业崛起的旺盛势头。工厂不再是人们眼中技术含量低、工作内容枯燥、待遇差的“工棚”，数字化、物联网、人工智能大量进入工厂，生产线需要工人的智慧和专业知识。这样科技含量高的工厂将给新就业创造巨大空间。

程序员开始脱离大厂投身制造业2

近年来，工厂似乎被年轻人抛弃，平均每年有150万人离开制造业，转身成为快递小哥、外卖小哥。

不过如今潮流再次改向：研究生、博士生开始青睐工厂，程序员离开大厂走进工厂。

12月3日，新能源巨头宁德时代全资子公司四川时代在宜宾开展招聘，吸引了大批求职者，现场人山人海，热闹程度堪比春运。

有网友表示，目前来说，宁德（四川）时代在宜宾待遇仅次于五粮液，工资反正高，也是让很多人不用外出务工了，家门口的`工资就能媲美沿海城市了。

最近一段时间时间，国内互联网公司遭遇“寒冬”，无论是在线教育、在线支付、网约车、游戏等行业都遭受到一定的影响。

与此同时，新能源汽车成为新的风口，新兴产业的崛起，高科技制造业的发展，也正在吸引越来越多高学历人才加入。

作为国内动力电池龙头企业，宁德时代以1145GWh的装机量，继续排名国内企业第一，市场占比55%，一己之力扛起国内动力电池的半边天。

最近，宁德时代市值也是节节高升，目前接近15万亿，总市值在A股排名第三，仅次于茅台和工商银行。

程序员开始脱离大厂投身制造业3

今天上午的热搜除了清一色的公祭日之外，还有一个很诡异的词条：越来越多高学历人才加入制造业！一边是某大厂程序员跳楼,大家都在为年轻的生命逝去痛心疾首，另外一边就是宁德时代四川宜宾分公司招聘现场火热,堪比春运。记者是这么形容的：33岁高龄程序员离开大厂，进厂。

诡异吗？很诡异！奇怪吗？不奇怪！

现在的年轻人多聪明，你以为年轻人那么好忽悠的吗？体制内我倡导进厂年轻人就要积极响应吗？就要去？如果对人生对理想还有追求，就不要加入制造业。别拿新闻来举例，那可是宁德时代，咱们有几个宁德时代？也不要拿制造业比互联网好来欺骗自己，没得选的时候可以进制造业，可以进郊区。

但要知道自己是没得选才去的，不就是因为本科和硕士专业差，又没有互联网实习经验，想考功没岗位才去的工厂吗？真有得选谁愿意去郊区？真话往往不好听，别看别人说了什么，要看他们做了什么。看他们愿意让亲戚朋友的孩子去互联网还是去宁德时代这样的工厂，就知道答案了。

综合起来就五个点：

1、说明工厂是真的缺人了

2、说明高学历人才越来越不好忽悠了

3、说明他们真的急了

4、说明新媒体我的kpi越来越高了

5、正经来说,程序员可以完美向下兼容,在经济下行时期,确实可以考虑去一些环境比较好的高新技术企业,进行降维打击。你进厂汗流浃背007 ,人家进工厂冬暖夏凉965 ,更说明计算机是唯一真神。

作为一个程序员，最重要的职责就是： 按时保质保量地完成需求开发。

像开发新业务这样的复杂需求， PM （Product Manager，产品经理） 一般会写出详细的 PRD （Product Requirement Document，产品需求文档） ，甚至可能会制作高保真原型。

而像调换两个按钮顺序这样的简单需求，PM有可能只会口头通知一下，最多在JIRA之类的项目管理平台上创建一条只有标题的ISSUE。

如果是有和用户交互的需求，负责设计的部门或人员一般会提供设计图。专业一点的话还会帮你把图都裁好，并准备不同屏幕分辨率下使用的多个尺寸版本。

当然，如果你在一个刚刚成立的创业公司，很有可能是创始人在白板前（或者是饭桌上）讲了半个小时，然后就问你：“需要多长时间把它做出来？”

不管提出需求的是PM还是创始人，他们的脑海中一定为这个需求设想好了一个自洽的逻辑和形态。PRD也好，口头宣讲也罢，都是在描述这个逻辑和形态。他们提出需求，就是希望程序员能够最大程度地还原他们的设想。

说起来简单，做起来难。 我们可以通过一个小实验来揭示这一点。

首先，你需要找一张长方形的纸。如果你在办公室，那就找一张A4纸；如果你在家，那就找一张纸巾。然后按照下面的步骤进行 *** 作：

你的作品是什么样子？中间开洞了吗？边上呢？角上呢？如果再做一次，你能完成同样的作品吗？

你可以拿着同样的纸去找你的家人、同事或朋友，请他们来完成同样的 *** 作。在你不施加影响的前提下，他们完成的作品极有可能和你截然不同。

为什么会这样呢？

如果你仔细观察他们 *** 作的过程，就会发现：

由于每次对折都会可能产生两种不同结果，在撕第一个角时纸的朝向有四种可能性，旋转180度时有两种可能。所以仅仅两个撕角的位置，就至少有 2 x 2 x 4 x 2 = 32 种不同的可能性。

就这样，我们还没有考虑撕角的大小、角度的区别，还有极少数人是会沿对角线对折的……

上面撕纸的需求，其实是我自己拿了张纸随意摆弄，然后记录下来的 *** 作流程。我照着这个流程，可以十分轻松地做出完全相同的作品。但是如果让别人来做，结果就完全不一样。其原因就是，我在完成作品的过程中，不光是按照流程进行 *** 作，还隐含了自己的一些小习惯，却并没有把这些细节记录下来。

如果把所有细节都完整地记录下来的话，需求应该是这样的：

同样，PM在写PRD时，很有可能会漏掉一些自己认为应该是「常识」，无需再进一步说明的内容。比如「把一张纸对折」，我们很容易想当然地认为，应该是沿着长边对折，但事实上并非所有人都是这么理解「对折」的。

由于每个人的成长经历不同，其认知结构之间必然存在差异，因此对同一概念未必持有相同的理解。 你所认为的「常识」，我可能并不知道，或者拥有和你截然不同的理解。所以程序员在看PRD时，一定要把自己对需求的理解复述出来，跟PM确定是不是这么回事。否则就容易出现开发中、提测甚至上线后发现逻辑性错误，需要紧急修复甚至返工的情况。

此外， 很多问题在设想阶段是发现不了的，只有到了具体实施时才会暴露出来。 PRD不可能真正做到完备，也不能保证没有错误和遗漏。比如一个表单需求，很可能在做的过程中发现某个非法数据case是PRD里没考虑到的，这时的用户交互怎么做？文案怎么定？这都要和PM沟通来解决，而不能自己拍脑门决定。

PRD只是需求的一个快照性描述文档，并不是需求本身。 程序员应该对需求负责，而不是对文档负责。 只有和PM保持沟通，不断地细化需求，才能让需求真正落地。当发现PRD里有不合理或者有疑问的地方时，一定要提出来让PM进行解释。千万别视若无睹，甚至干脆将错就错，等着看PM笑话。

如果我们拿到了一份图文并茂、十分详尽的PRD，是不是应该马上照着文档开工呢？那可不一定。

一位优秀的程序员，应该在开工之前把下面这些问题想清楚：

程序员有责任对需求方案进行review，并协助PM改进设计。 要知道，PM一般不会从技术角度对需求进行考虑，所以往往提出的并非最优方案。有时只要做一点点调整，技术实现的难度就会大大降低，却不影响目标的达成效果。

比如某个业务需要用到日期选择器组件，PM为此专门设计了一个，而你知道系统中某个功能页面里有现成可用的同类组件。这时就应该和PM沟通是否可以直接复用，或者在原有组件的基础上进行功能扩展。这样既节省了开发资源，又保持了用户体验的一致。

程序员要对整个产品的可用性负责，全面评估需求可能导致的不良影响，谨慎对待有破坏性的需求。 PM由于不了解系统的底层实现和实际数据的组织方式，所以很可能无法全面地评估需求的影响面。如果程序员忽视在这方面的思考，只是机械地按部就班地执行方案，就很可能导致严重的线上事故。

比如要对某数据进行批量修改，在做的过程中时发现该数据有多个业务正在使用。这时就应该必须停下来和PM沟通，因为PM可能只了解自己负责的那一块业务，不知道修改可能会对其他业务产生影响。此类需求要和相关各方沟通协商，确认修改没有不良影响后才能继续。

程序员要有魄力去拒绝那些明显不靠谱的需求。 有的时候，PM提出需求的动机不是为用户创造更多的价值或提升用户体验，而是为了冲绩效完成自己的KPI。为此拆东墙补西墙，从兄弟业务手里抢流量入口；甚至杀鸡取卵，以严重破坏用户体验的方式拉量。遇到这种事，程序员一定要坚持自己的原则，守住自己的底线。

程序员日常开发工作，基本是上离不开阅读文档，这也是很多程序员喜欢两个显示器的原因。

项目方面

技术方面

是不是很多人都认为，如果在开发过程中，还要不断地翻技术文档，说明他的开发能力不扎实。其实不是这样的。

首先IT行业技术升级换代的速度太快，当我们大多数公司还在用Java8的时候，Java11都已经出来了。如果非得要程序员熟知每一个类、每一个方法，是很不现实的。

很多时候我们只需要了解有这么一个东西，作用是干什么的，具体的细节可以在用的时候再去翻文档，比如方法名字是什么？参数有几个，都是什么类型的？

所以我们都习惯至少两个电脑屏幕，一个屏幕写代码，一个屏幕看文档；如果豪一些的话，再加一个屏幕展示日志信息。

看文档的屏幕要买竖屏！

我们团队

我这几年也带过几个团队，对于每个团队成员，我对他们的要求是：实现需求的前提下，最好能对所用的技术有一定的了解，千万不要从网上抄过来一段代码就用，这样是很危险的行为。所以鼓励大家多找一些资料，最好是阅读框架的官方文档。

现在的团队，我已经这样要求了：代码写累了，或者觉得自己没有状态写代码，可以找点儿自己有兴趣的技术文档学习学习，这个技术甚至是可以跟现在的项目没有关系的。

首先，我不是程序员，我是一个设计工作者，不过我来说一下我的观点：很多人以为程序员像**里的一样，啪啪啪几下键盘，屏幕数据飕飕的变，其实真实情况是程序员写代码就像学生写作文，也会遇到不会的词语跟修辞手法，那这个时候就要停下来想一想，查一查，看看例子是怎样写的怎样用的，写错了还要划掉（删掉）再来，至于这个大量不大量看的情况，如果这个是个新手，那肯定是可以的，那如果是个老手，还需要大量时间查说明文档，那就说明这个项目肯定不会小，不是一两天能做完的，那一个用月做单位的项目，用一个天做单位的时间来查文档，不过分吧！程序员也是人，不是因为他的工作高端，就觉得这个人万能，他也会当机，要吃饭，要休息，也会忘记一些东西，所以请各位多多体谅，能一起工作实属不易，感恩2018，谢谢。

这个问题怎么说呢，开发过程中会遇到各种各样的问题，没有一个人是全能的，也没有人可以绝对的说自己在整个项目中不会遇到一点问题，不去查东西，自己大脑里的东西完全可以让我把这个项目测测底底的做完，并且没有任何bug。

上班的时间，也没有老板或者谁在后面一直看着你去做东西，大家都挺忙。文档是干嘛的，文档本身就是用来看的，甚至很多项目开始之前，总监都会让你去搜集一些这个项目可能会遇到的bug，可能会用到的效果，尽量在之前找到比较好用的插件，这样会节省很多时间，自己如果写代码的话不可能百分百的确定没有人和bug，但插件不一样很多插件都是前辈通过很长时间慢慢完善出来的插件，所以很多人才会用。所以你提问的可以肯定的回答你允许。

说个我遇到的2个真事吧，

第一个，公司找的外包公司写项目程序，已经要交付了，发现有几个功能没做，产品经理和开发那边都找我，我一个搞运维的又不懂，只能让他们去对开发文档，我也就顺便看了看，开发文档中明确的写明怎么做，然后就让他们就重新按开发文档继续写，

另一个，由于 历史 原因业务系统处于托管状态，只有部分参考文档可用，开发那边只能按当前已有文档进行开发参考，开发那边也一直在根据现有相关文档进行开发，杯具的是这帮子不仔细看，有问题总想着我能直接给他们答案，我也只是会用而已，开发我还真搞不来，然后和他们一起看开发文档，加密算法部分给她们指出后，问题解决了。

所以我觉得，开发团队在开发中很有必要阅读开发文档，这可以避免绕圈子，也会清楚开发文档中提供的内容。

程序员上班的主要工作就是看说明文档，根据说明文档编码。如果实在没有说明文档，有时还得亲自披挂上阵写说明文档。

写接口的有API文档，写通讯协议的有协议字段说明文档，写数据库的有数据库规范文档，

总之任何一个大公司文档扮演的一个至关重要的问题，因为形不成文档，公司管理就会陷入混乱不堪的局面，当某个核心员工离职后，下一个接盘的程序员会丈二和尚摸不着头脑，一头雾水，边填坑边骂娘，有了文档就可以看文档结合代码，了解其中模块逻辑以及结构，包括哪些坑不能踩等等好处。有些公司会专门有文档工程师这个职位来专门负责整理各种文档，并且保存在服务器上。

好的文档都是程序员等人智慧的结晶，是一盏指路明灯，是一条通往光明的道路。程序员不能看说明文档等于在黑暗里摸爬滚打，有了说明文档才迎来了黎明的曙光。

先说观点，我认为看文档没什么问题，但是“大量”这个程度很难衡量，按照需要看文档是个非常重要的事情。

需要花费时间的情况 不需要花费大量时间的情况 小结

在工作中阅读文档其实也是工作内容的一部分，而且现在大多数互联网公司都靠KPI进行考核，平时就算你把时间都用来看文档没关系，最后KPI没完成一样会被公司淘汰。所以公司不会阻拦你花费时间看文档，最多你老板会提醒你浪费这么多时间看文档而没有实际的产出会对你年终考核造成影响罢了。

题主对文档的定义不是很明确

第一个是需求说明文档

这个是在开发过程中必不可少的文档，只有清楚了开发需求，程序员高效率的开发，程序员一天的工作时间并不是都是在写代码，而是在看文档，了解需求，理清思路，只有什么都清楚了，写代码或许只要十几分钟。

再者对于一个项目新人来说不看文档了解需求，没人给你从头到尾的在讲一遍需求，你不看文档自己发挥？进入项目是和别人共同开发，你不肯能不顾及之前的代码规范。

第二个是开发文档

就拿微信开发来说，微信开发不是每个程序员必须会的东西，但是用到了怎么办，还不是去看他们的开发文档，只有将开发文档思路理清楚了，才可以进行下一步开发。

第三个是API文档

在前后端分离的开发模式中API文档是必不可少的文档。不看API不知道数据是什么样。也就是不可能顺利的和后端进行结合。

兄dei，假设你是程序员，你在写程序时，旁边会有人守着你吗？

假设你不是程序员，你在做本职工作时，旁边会有人守着你看你怎么做事吗？

答案肯定是没有的。谁会闲着招个人去监督你，看你用什么方式去完成给你的任务。

现在不管是大公司还是小公司，没有人会在意你怎么去完成你的工作，给你的任务，在很多时候，大家只关注结果。如果说有干预，最多只是实现的方式。像写程序，假设有个功能是即时通讯相关的，这种自己写需要的时间成本投入较高，那么很多公司就会选择采用市面上比较稳定的第三方平台。这算一种实现方式的干预。但是在接入的过程中，不会有人去管你是通过阅读第三方SDK文档，还是谷歌搜出来的，最后能达到预期效果就ok了

所以，其实你看不看大量文档，没有人会在乎，关键是你自己，建议自己写东西时，不要一味的复制粘贴，要有自己的想法。太依赖文档对于自己成长很不利

当然允许看文档。

要知道，随便哪个类库，都有无数的类和方法，每个方法又有若干参数，鬼知道它们都是什么意思，谁的脑子能记得那么多内容。别说是人家提供的类库，就是自己写的代码，过一段时间也不记得什么意思了。没有注释和文档，怎么看懂代码？

如果没有需求分析文档，程序员怎么理解正在开发的这个软件的基本业务流程？

如果没有架构设计文档，程序员怎么理解软件各个功能模块之间的功能与业务逻辑？

如果没有接口文档，那么多类和方法，都怎么调用，会返回什么值，难道靠猜？

……

在日常开发工作中，不仅允许看文档，还会强迫你写文档。如果你写的文档别人看不懂，别怪领导骂你不认真。文档对于软件开发的重要性是不言而喻的。

还有一个秘密告诉你，那些经常写文档的程序员，要比不写文档的程序员工资更高。

真的！！！

迎娶白富美，从会写文档开始！

毫无疑问是的。

对于程序员来说，在实际工作中进行代码编写和项目开发时，是离不开各种各样的文档的。文档包括：

不允许看说明文档，这基本上只会出现在面试或者考试中，为了考察程序员自身的编码能力，才要求脱离参考资料，利用自身的知识和技术来完成。

当然了，程序员工作中也不能只看文档，要是花费大量时间通读不必要的文档，工作可就做不完了。

通常我们进入公司以后，不会是重头开始一个项目，而是在已有代码的基础上进行维护或新功能的开发，所以必须“读代码”。

读有“泛读”，了解系统架构、功能模块，对系统有一个大致的认识，各个功能能找到相应代码实现的位置。

还有“精读”，通常就是调试了，在fix bug的时候使用。此外还包括审核：一些规范一点的公司，都会有code review，也是精读，但不用debug。

对于一个成熟的项目来说，读代码——而不是写代码——可能是最耗时间的工作了。

写注释文档

为了减少“读代码”的时间，我们不得不花时间“写注释”“写文档”——这个程序员最深恶痛绝的工作。所以现在“烂代码才需要注释”的声音变得越来越强，但无论如何，文档还是要写的。（注意：要能区分注释和文档）

了解需求

好了，终于到了“写代码”的时间了。

然而，在动手开始写代码之前，你必须花时间“了解需求”。和自己写个小程序玩玩不同，在公司，你是为别人写代码，所以你一定要了解别人究竟想实现什么功能。通常，这并没有你想像的那么简单，需要反复的沟通。

当然，也有一些团队和个人，不愿意在这上面“浪费时间”，通常他们的下场就是不断的写代码，然后不断的改代码，加班加点的做大量的无用功，整个公司怨气冲天一地鸡毛。

填影响绩效的指标。

程序员年终绩效考核表中要填一系列影响绩效评估的指标。

指标有季度工作量完成情况、技术贡献等，需要按照实际情况进行客观评估。

一、先列三个常见的开发场景：

1、拿到一个模块详细设计文档，大部分程序员的通常做法就是开始搭建界面代码，然后从第一个按钮点击事件或页面Load事件开始写第一行业务代码。写的差不多了，就运行一下，发现哪里不是自己想的那样，就改改，直到改到是自己预想的那样。

2、做完了一个功能模块或几块相关联的功能模块，输入111asd，发现新建正常、保存正常，就提交给测试人员。测试员用测试用数据、测试场景用例来测试，发现有问题，就登记bug。对于严重的影响下一步测试的BUG，测试员就用内部IM通知这个开发人员。对于不影响继续往下测试的BUG，测试员就登记下来，等程序员有空时处理。

3、程序员一般工作不希望大家打扰，所以开发起来就是开发。等手头开发告一段落，就看看BUG库。发现有与自己有关的BUG，就从第一个BUG开始看起。就开始通过IM和测试员掰扯起来（这不是个BUG啊、业务逻辑不是你想的那样啊、我这里不能重现啊、你给的信息描述不清晰啊），于是IM几来几往，甚至跑过去当面交流一番，甚至会拉扯上产品经理一起讨论，更甚者需要项目经理或产品经理发起一个会议来集体讨论一下

这是不是很熟悉呢？这就是大部分程序员开发的三个步骤：写代码、自测、修复BUG。

二、说好的代码设计、代码测试呢？

代码设计？那不是都有开发平台么，已经固化了啊。那不是维护旧功能做完善修改呢么，又不是写新代码，只能在现有代码基础上修改啊，你又不能大幅重构。

代码测试？你丫需求讨论期、产品设计期、设计评审期那么长，都把研发项目时间占光了，就留下2个星期让我们写代码，我们哪里有时间搞那么深的测试。还想让我们搞结对编程？还想让我们搞测试驱动开发？

而且你看测试，什么功能测试、集成测试、性能测试、安全测试、安装部署测试、升级测试、迁移测试、UAT测试，一大堆测试，测试也需要很多时间。

一个项目，需求讨论、产品范围规划与评审、产品设计与设计评审占了一个半月，开发+自测就一个月，测试占了一个半月，这就4个月了啊。

三、为啥程序员写代码总是写写测测？

刚才大家也都看到了，大部分程序员都是从界面代码开始写起，而且写一写，就运行一下看看。为什么会是这种开发方式？

那是因为大部分程序员缺乏在脑子中的整体建模能力。只能做出来一点，真实的感觉一下，然后再往下。

有些是产品经理的上游就有问题，没给出业务流程图（因为产品经理也没做过业务），也没画清楚产品功能 *** 作流程图。

为啥没给出业务流程图？因为产品经理不熟悉业务，另外，产品经理也没有流程建模能力啊。为啥没画清楚产品功能 *** 作流程图啊？因为不会清晰表达流程啊。

很多产品经理、程序员，都缺乏分类、分层、相关、先后能力，更别说总结、洞察能力。

这是基本训练，是一个做事头脑清醒的人必备的技能，这不是一个程序员或产品经理或测试员的特定技能要求。

我经常看书就梳理书的脉络，每看一本就写一篇总结。我过去闲扯淡还梳理过水浒传、红楼梦的人物关系图呢，其实就在事事上训练自己的关联性、层次性、洞察性。

我经常面试一个人时，我会问这样的问题：“你把我刚才说的话复述一遍，另外你再回答一下我为什么会这样？”，其实，我就在看一个人的细心记忆、完整梳理、重现能力，我也在看一个人的梳理、总结、洞察能力。

我个人写代码就喜欢先理解业务流，然后理解数据表关系，然后理解产品功能 *** 作流，大致对功能为何这样设计、功能这样 *** 作会取什么表、插入或更新哪些表，哪些表的状态字段是关键。

然后我写代码的时候，就根据我所理解的业务流、功能 *** 作流、数据输入输出流，定义函数，定义函数的输入与输出。

然后，我会给函数的输入值，赋上一些固定值，跑下来看看能否跑通这几个关联函数，看看还需要怎样的新增函数，或者看看函数的输入输出参数是否满足跑通。

剩下的事，就是我填肉写详细逻辑代码了。

当然，大部分人没我这样的逻辑建模能力。怎么阅读理解也想象不出来，也没法定义函数。毕竟有逻辑建模能力的程序员都很少，100个人里有10个，已经是求爷爷告奶奶好幸运了。

那怎么办呢？

我建议是分离分工配合，这就是现实中没办法的办法。让有逻辑建模能力的人来设计函数框架、来设计工具来设计代码模板，然后让没有逻辑建模能力的人来填肉写详细逻辑代码。

我们可以先从最紧要的模块开始这么做。不紧要的模块，还让它放任自流，让熟练手程序员继续涂抹。

我曾经还让有头脑的程序员做榜样，给大家分享他是怎么规划函数的，怎么做维护性代码的代码结构改善的。但是发现效果并不佳，其他人并没有因此能做代码设计。可能逻辑建模能力是个人的基本素质，是从小到大训练成型的，不是你一个大学已经几年的人能够短时间内可以训练的。

所以啊，还是让能走的人先走，让从最紧要的模块开始这么做。

不必担心这样做后，因为过去一件事被分工（一个做代码框架一个填肉）成两个人做了会降低工作效率。我们很多的工作效率低就是因为半瓶子醋搞出来的，来回反复修改。

真是应了刘德华在**里说的那句话：说你又不听，听又听不懂，听懂了又不做，做又做不好，做不好还不服气。

四、为什么大部分程序员不做代码测试或白盒测试或单元测试呢？

还是因为没有代码设计。因为没有函数啊。所以，一个按钮功能有多复杂，代码就有多长。我见过2000行的函数，我也见过1000多行的存储过程和视图SQL。怎么做白盒测试啊，这些代码都粘在一起呢，要测，就得从头到尾都得测。

所以啊，先学会设计函数，先写好函数，这就求爷爷告奶奶了。很多开发了5年的熟练手程序员，可能都未必会写函数。

函数的输入输出值就很有讲究。很多人都写死了，随着版本迭代，发现过去定义的函数参数不够用了，于是就新增了一个参数。然后，相关性异常就爆发了，其他关联的地方忘改了，到底哪些有关联，怎么查啊，本系统没有，没准其他系统就调用你了，你根本不知道哪个神经人曾经COPY过你的代码修吧修吧就改成了他的功能呢，而且里面的很多代码他看不懂也不敢删，只要他实现的功能正常了他也不管了。于是，你改了你这个函数，他的系统就莫名出错了。

所以，我一般会定义几个对象来做参数。另外，我也很注重函数的日志、函数的异常保护、异常抛出、异常返回。另外，我也很注重参数输入值的合法性校验。

所以啊，应该开发Leader们先制定函数编写规范最佳实践，输入输出参数怎么定义比较好，函数的返回值如何定义比较好，函数的日志记录应该怎么写比较好，函数的异常保护、异常抛出、异常返回如何写比较好。先教会一般程序员，先从会写函数开始啊。

当然，你光有一份规范，程序员们还是不理解、不实际应用啊。所以，还得Leader们做好典型的代码模板，里面是符合函数规范的代码框架，只有这样，一般程序员们才会照猫画虎适应了函数设计的编程习惯。

所以啊，我专门重新定义了leader的明确职责，其中第一个重要职责就是：负责工具/框架/模板/规范的制定，并且负责推广且普及应用落地。

你不明确定义Leader的这个重要职责，你不对这个职责做明确的KPI考核，谁尿你啊。你以为好的工具/框架/模板/规范是靠人们的热情、自发产生的么？我们还没有那么自觉高尚啊。

五、为什么大部分程序员不写注释啊？

我经常说一句话，千万别多写注释。为啥？

因为我们经常遇到的问题不是没有注释，而是更糟的是，注释和事实代码逻辑是不相符的。这就出现常见问题了：残存下来的设计文档是一个逻辑、注释是一个逻辑说明、真实代码逻辑又是一个，钟表多了，你也不知道正确时间了。

所以啊，产品文档、注释、真实代码，三者总是很难一致同步。我为了几百人研发团队能做到这个同步花了大量心血和办法，但我最终也没解决了这个问题，还把Leader们、总监们、我都搞的精疲力尽。

索性回归到一切一切的本源，代码，就是程序员的唯一产出，是最有效的产出。那么，让代码写的不用注释也能看懂，咱得奔着这个目的走啊。

为啥看不懂，不就是意大利面条式代码么，又长又互相交杂。

OK，我就规定了，每个函数不能超过50行。用这一个简单规定和静态代码检查插件，来逼迫大家尝试着写函数。有的函数属于流程函数，是串起其他函数的，有的函数就是详细实现函数，实现一个且唯一一个明确作用的。

有了流程函数和功能函数，而且每个函数不超过50行，这就比过去容易看懂了。

六、为什么大部分程序员不抽象公共函数啊？

我经常说一句话：千万别抽象公共函数啊。为啥？

因为大部分程序员缺乏抽象洞察能力。特别是有些积极热情有余、爱学习爱看书、半瓶子醋晃悠的二杆子，看了几本UML、重构、设计模式、整洁代码之道，就跃跃欲试了，还真敢给你抽象公共函数了。

一开始，他觉得80%相似，20%不相似，于是在公共函数里面简单写几个ifelse做个区隔就可以。没想到，越随着版本迭代，这些功能渐渐越变越不一样了，但是这个代码已经几经人手了，而且这是一个公共函数，谁也不知道牵扯多少，所以谁也不敢大改，发现问题了就加一个ifelse判断。

没想到啊没想到，这个本来当初公共的函数，现在变成了系统最大的毒瘤，最复杂的地方，谁也不敢动，除非实在万不得已，手起刀落。

所以，我平时告诫程序员，纯技术的、纯通用的，你们可以尝试搞搞抽象公共函数，对于业务的，你们还是简单粗暴的根据Leader们做的代码模板代码框架，乖乖的复制、修改、填肉吧。

你们啊，先从做模板做代码片段开始吧，咱们放到咱们内部代码片段开源库里，看谁的代码片段被别人复制的多，说明你的代码抽象设计能力越好了。那时候，我就大胆放心让你撒丫子跑了。在没有学会跑之前，给老子乖乖的复制、修改、填肉吧。

对于大多数运维程序员来说，时时刻刻都需要关注服务器和系统程序可能出现的问题并提前解决。今天我们就通过案例分析来了解一下，运维程序员如何快速处理线上问题。

任何一旦掉进坑里，明智的做法一定是：跳坑_>填坑_>避坑，线上故障处理的过程也一样，优先级从高到低，线上故障处理的目标如下：

跳坑

‘跳坑’——快速恢复线上服务，或者将对线上服务的影响降到低。

线上服务的可用性决定着服务者的客户利益，影响着公司的收益。一旦线上环境不可用，无法服务用户，给公司/团队带来经济利益损失的同时，更为严重的会给公司/团队带来恶劣的名声。所以一般公司都会对线上环境提出稳定性和可靠性的要求，这也是团队乃至部门的kpi。为此，遇到生产故障后的一要务是：恢复生产服务，即使不能完全恢复线上服务，也要想尽办法将对线上服务的影响降到低。

填坑

‘填坑’——找到问题原因，根本上解决问题。

在恢复线上服务，尽大限度减掉对用户/公司/团队带来的影响后，我们需要彻查问题，搞清楚故障发生的根本原因，从根本上解决问题。通常情况下，‘填坑’和‘跳坑’是同步在做的，完成‘填坑’也就意味中‘跳坑’成功，但是也有一些紧急情况下的特别‘跳坑’方法，比如重启服务，或者服务降级/熔断等等，实际并未在当时完成‘填坑’，而是先采取非常规手段‘跳坑’，之后再慢慢‘填坑’。

避坑

‘避坑’——举一反三，消灭隐患。

找到了根本原因，解决了问题之后，我们需要举一反三，以此及彼，想想在这个故障排查和处理过程中，那些环节存在弱点那些流程/规范/制度需要优化这类问题是否在其他系统或者团队中也存在通过这样的反思和自我批评，形成一份线上事故报告，不断完善流程，避免再次踩坑，也在团队中交流经验，共同提高。

线上故障处理的思路

依据线上故障处理的目标及目标的优先级，线上排障的一目标是恢复线上服务或者降低对线上服务的影响，关键点在于快速二字，在‘跳坑’-‘填坑’之后，再行回溯总结，以便‘避坑’。因此，可以将线上故障处理的步骤分为：

故障发现

故障定位

故障排除

故障回溯

其中前三步是‘跳坑’行为，后面一步包含了‘填坑’和‘避坑’。

上述步骤并不是说要从上到下顺序进行，建议在不乱阵脚的情况下，并行去做，因为通常线上故障后会紧急启动故障处理程序，运维、开发、测试、产品各个角色都会参与进来，这时候分工下去，并行去做，不断汇总消息，做出判断，以求快速排障，恢复服务。这个思路类似于 *** 作系统的fork/join设计思想，目的在于提高效率。

在无法快速找到故障原因的时候，需要果断跳过故障定位环节，直接进行故障排除，比如采用服务降级、服务器扩容等手段，确保对线上服务降到低且可控。昌平北大青鸟建议可以等到线上服务’撑’过去之后，我们再慢慢定位故障原因，根本上解决问题。

以上就是关于在国企当程序员是什么体验全部的内容，包括:在国企当程序员是什么体验、程序员开始脱离大厂投身制造业、作为一名程序员，你真的理解需求吗等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！