前言
就在半年前，我还是一个快乐的童鞋~~~然而一个错误的决定，让我彻底走上了一条不归路。在这条路上，首次踏上社会的我，心里怀揣梦想，希望改变世界，然而惨遭毒打。更重要的是，这不是结束，而是噩梦的开始，毒打生活还在继续~~~
前言
前面的这一段都是玩笑话，我在公司里确实经历了毒打，就像主管说的一样，这是我成长的必经之路。所幸没有造成严重的代价，也通过这些毒打，让我认识到工作与学习之间的差异，让我的思想进行了转变，这是我要吸取和总结的点，我也非常感谢主管、公司能够给我这个机会。下面我将从流程上、心理上、思想上、行动上分别阐述公司与学校的差异。
流程差异
我在学校里，我的导师很佛系，从研一丢给我一个课题，然后我就开始自己学习、钻研。其中导师给我提供了实验平台、我也会将我的成果与思考和导师交流。因为我是单传弟子，因此导师对我不是非常严格，也不像其他课题组一样，要求早上几点、晚上几点打卡。所以我平时也比较随意和自由，一般写代码的时间都由我自己支配。而且代码写完，意味着这个工作基本上快结束了，后面的就是整理数据，发论文。
在公司里，最大的差异是代码工作只占需求的三分之一，可能没有入职的小伙伴们觉得非常诧异，不写代码开发什么？其实从前端的数据采样、需求分析、需求规划、需求评审、再到UX设计、需求分解、零层、一层、二层设计、最后到测试、维护。每一个环节都非常重要。我说的三分之一还只是开发的三分之一。如果包括全流程，可能不到十分之一。
这里我就对三分之一谈一谈作为开发的看法，首先接需求，不能大意和轻敌，也不要过于激动，有需求来了。而是要准备好和SE(System Engineer)进行方案对齐，然后SE会对需求进行分解，给出零层和一层设计，零层是指架构层面的设计、比如应用层、框架层等，运用哪些技术、哪些框架、牵扯哪些应用等；一层是指模块层面的设计、比如涉及蓝牙、WIFI、手机、PC等模块，每个模块实现哪些接口，时序如何运转。然后我们要给出二层设计方案，二层设计就更加具体了，主要是每个模块内部的实现逻辑。还要和UX(User experience)进行体验对齐，我们最终呈现给用户的是哪些界面，如何显示、包括图片、图标、字体、动效、背景、阴影、模糊、旋转、缩放等等一系列体验相关的问题。然后和这些人对齐以后，我们要做的是拉通SE、UX和后端测试进行反串讲，和SE讲一讲我们的理解，和UX、测试讲一讲我们要做成什么样子。当这些都完成后，可以认为前三分之一的工作结束了。
中间三分之一没什么过多阐述的，就是开发代码，其中开发的时候，一定要注意DFX(Design For X)的设计，DFX是指可维可测，表示代码的可维护性、当出现问题，能否定位和维护？然后就是代码的设计模式，不要过于复杂，但是一定要高内聚、低耦合，这里不过多赘述，可以参数设计模式相关章节。还有一点是编程规范，因为团队合作，开发的代码一定也要能够其他同事轻松理解，其实也是为了自己几个月只后解bug能够看得明白。
当开发结束了，我们切记万事大吉、这是我的一度想法，我之前认为终于结束了，累死个人，好好休息休息。其实后面还有一堆的事情等待着你，最重要的是交付件的准备，交付件包括代码设计说明书，其实也就是二层设计，要在开发中进行完善和调整。然后准备详细的自测试用例，这一步也是非常重要的，有问题的功能，还不如不开发功能，这时公司存活的铁律。比如三星手机、自从故障之后、几乎退出了整个中国市场。还要准备稳定性报告，尤其是一些重要的底层模块，可能涉及上层的所有应用，因此一定要进行冒烟测试。其他的就是一些代码扫描结果、合入链接。当我们将这些都准备好以后，就可以正式转测了，这里要注意，没有十足的把握，不要转测，因为公司的宗旨是开发阶段完成稳定性和自测试，什么问题都留给测试是不可靠的，所以测试的任务就是千方百计发现你的问题，而发现问题之后的代价也是非常重的。这就迫使开发设计和验证要小心翼翼。
心理差异
我初入社会，周围也有很多其他公司小伙伴们说，主管天天开会，没啥实力，只会接需求，然后安排给我们做。其实并不是这样，主管也是开发一步一步做到这一步的。而且主管的工作并不是接需求、分配任务。比如我的主管，也承担着SE的工作。其实对代码和设计模式都非常熟悉，有时候在需求分解，在讲到如何设计模块交互时，往往用到回调方法，这个我也在前面的博客提到过，感兴趣的小伙伴可以看一看。对于复杂和多次嵌套的回调，我这样的新手把握不住。于是我经常和主管讨论，而他轻松能够写出回调的用法，有时候我要去理解半天。
所以在心理上的变化是，不是主管没实力才去做需求的分解。结果相反，开发代码是很简单的，等到SE将模块分解，接口对齐之后，我们的开发工作量会极大减少。这是一个学生所不能理解的点。
思想差异
在思想上，因为上学的时候，研究生有三年，做一到两个课题，发几篇论文还是比较容易的，所以写代码的时候也比较自由。但是工作上面从一开始的需求分析到最后的测试验收都非常紧急。
为什么这么说呢？这也是容易理解的，课题和论文这个事情，一般来说都是大型的项目，我在读研期间，这个课题是一个院士牵头去申请的，时间跨度为5年，因此在交付方面不急于几天的时间。论文就更不必说了，除非是顶会论文或者热门学科，很多人研究，要不然不至于紧急到必须今天或者明天写完。只要在做完实验的一到两个月写完，然后导师修改一下，三个月之内能够发出去即可。如果是一些冷门的学科范围，可能几年之内也没有很多人去研究相关的成果，所以一般不用担心论文被其他人提前发表的问题。
因此就会养成一种太过于散漫的交付态度。然而公司的交付时间是有严格的期限的，比如提前说好了，在XXX版本进行测试验收，到时间如果还没有将功能合入到主干代码中，测试就会直接提一个主干致命单，或者是到最后才完成，也没有进行完备的自测试，如果测试发现了重大问题，也可能会提一个主干严重单。还有一种更致命的情况，大家都知道的，主干代码只有一条，很多部门，很多同事都会在XXX版本交付需求，如果因为你的代码，导致其他人的功能不可用，或者整个系统产生了bug，举个例子，如果是手机产品，导致开不开机了，那么相机的功能在这个版本也没办法测试了；如果是应用app开发，假设是支付宝，导致支付宝打开就crash，崩溃了，那么蚂蚁森林开发的同事在这个版本也没办法测试了。这就相当于导致流水线停产了，这个问题就更加严重，要会对主管、主管的主管、主管的主管的主管进行晾晒、通报。基本上出了这次事情，你的绩效就很差了。
有的小伙伴觉得这个不可怕，版本不行，及时修改bug出一个版本不就可以了吗？当然是可以的，但是在漫长的开发过程中，不能你这边改一下，我给你出一个版本，他这边改一下，我给你出一个版本。随着公司的体制成熟，负责版本管理的同事会固定一个出版本的时间，所有人在该时间之前，就会把代码合入主干，这样相当于你的代码就带入进去了。当然如果出现了上面这种情况，肯定是重出版本，但是晾晒和通报肯定也少不了。
切记切记，一定要和PM(Project Manager)对清楚交付计划和节奏，有风险及时说出来，谁block你，或者因为什么情况导致风险，主管都会帮你协调和分配的。但是如果你到了交付的当天，说这个需求还没做完，或者没有自测试，那么谁也救不了你。
行动差异
详细说了上面几点和上学的区别，最后一点就是我们要合理规划时间。在公司里面，我们就是韭菜，肯定是希望我们干的活越多越好，因此当你干完活，或者这个活还在开发，下一个活可能已经在分解了，甚至我经历过三个需求同时开发的场景。
这个时候，我们要做的不是抱怨、而是有风险及时报备。剩下的就是安排好计划和节奏，将提前交付的需求优先级排高，然后将block你的模块和主管进行沟通。因为有的时候，我们作为新员工小白，那些大佬或者公司的老油条是不会响应你的号召的。所以我们能够做的就是将你推不动的人，交给主管推动。这样效率就会极大提高。
还有一点职场小技巧要交给大家，开会、或者订规格一定要有明确的结论。在会议之后要发出会议纪要，这样后面如果有人不认同，可以用纪要来防止扯皮。如果某个结论在会议上没有讨论出来，一定要记录责任人，这也是非常非常重要的，如果你不记录责任人，那么可能会后找不到应该找谁闭环这个问题。
小结
给小伙伴聊了这么多，不是想告诉大家公司、社会有多么可怕。其实在技术岗，同事、主管的关系都是非常融洽的。我们要区分工作和学习的差异，学会如何工作，如何避免问题，这样我们的职业生涯才能越走越好。