从B公司的离职感想
在B公司我学到了什么?
在大公司里首先学到的就是它较为成熟和完善的制度管理体系，不光是工作上，甚至是生活、培训、事故等方面都有完善的制度应对。特别是在代码开发的一整套完整流程上（开发、审查、调测、受控或变更）将代码的出错的风险率大大降低，不过冗长的开发流程也使得在小的改动也需较长的开发周期。
在实业型大公司，它的技术往往都比较成熟且稳定（除了少数前沿，具有研究性的岗位，但这毕竟是很少数，遗憾我不是），如果你是追求技术做出一番成就的话，在大公司你失望的概率太大了。成熟稳定的代码几乎只需要你反复修修改改那几个参数，开发工作基本等于维护和适配性，某些岗位一年下来代码量少得可怜。如果你想象中程序员要每天都在不停的码代码，有很多编程难题让你焦头烂额的等着你解决，那恐怕是要让你失望了。我这里是针对实业型公司，目前互联网飞速发展，相对其他领域的软件来说它的代码量和难题数可能是最多的。
谈谈B公司的待遇
在我看来B公司属于同工同薪，为什么说是看来而不是直接说是呢？首先它的制度并没有规定薪资是按工作年限，但是事实就是和工作年限紧密相关，年限差不多的只要是一个部门（公司太大，不同的大部门就像不同公司，会存在大差异）差异很小。这存在什么问题呢？薪资不按能力强弱分，会打击能力强者的积极性。另外两年基本未涨薪，17、18、19届同拿应届生工资导致新人纷纷离职。不过好在老员工的薪资在以前都已经涨上来了，虽然算不上高薪但是很稳定工作也轻松，所以老员工都稳定。所以B公司我坐在的部门三年以下的大批离职，工龄在这个段出现断层。不过领导都以吹嘘公司有多少8年以上的老员工而自豪，要知道实际拼命加班干活，制造产出的主力都是三年左右的年轻人，少了这个段的年轻人，在创新性上也几乎失去活力。
谈谈B公司的研究技术氛围
老员工都求安稳和自保，为了防止出售后事故巴不得代码不要做任何修改，即使代码写得低效又重复。我在职期间多次提出想要改善老旧的软件架构，增加一些安全检测也异常处理，但都以求稳定为由拒绝了代码大的修改，后来我也认同了这种观点，产品稳定的实业公司确实应该注重稳定性，技术的先进性则显得非常次要。在实业公司做技术，你的研究重点是在产品上，而不是技术上！（解释下，就是领导更希望你对产品包括细节特性都有所了解，但是却不需要你有多高的编程技术）
谈谈B公司的人际关系
总的来说B公司工作压力非常小，竞争文化很弱。你的升职加薪有完整的规章来定，而不需要拍领导马屁等领导一句话。因此同事领导间的关系较为简单易处，但基本上也限定在和你有业务往来的项目组里的同事（这个基本上哪个公司都一样，除了一些活动较多的公司，你可以在公司搞的文化活动或聚会中认识更多的人，遗憾B公司我所在的部门不是这样的）。
最先吐槽的几点
- 繁琐又死板的流程。
这可能是大公司的通病，无论你的修改量大还是小（小到仅修改版本号也不例外），都必须完整的走一遍步骤繁多的流程。我有时候在想是否可以大项目用大流程，小用小流程，而不是统一搞一套，但这也会使流程种类过多，由谁去评判修改量算大还是小呢。所以流程使开发过程得到详细监管和记录，大大降低了事故率，但也使得开发周期短不了。不过走平台的流程比起走纸单的流程要快不少，至少你不用到处去找不知道在哪里的领导签字了，B公司目前正在这样转变。
还有一个流程很死板的例子，我从来没想过一个项目废止会和流程相关。客户要求从一版老程序升级出多版子程序，等到我代码编写、审阅、调试、出报告到最后一步受控时，被告知平台流程不支持一版程序一次性升级出多版本新程序，只能一版程序升级出一版。客户的需求确实是需要升级出多版，仔细一想需求是合理的，你会说那改流程呀！然后流程不是下面的人想改就能改的，而且改流程周期相当长且影响大。最后只选择了其中一版给客户升级，其他升级项目都废止。此前很难想象一个反复催受控的急任务会因为流程原因废止了。
先写到这里，有空在继续更新，要干活了。。。