离职在即，在准备下一个工作环境的这段时间，忽然有一阵感慨，工作近五年，在这段时间中，体验了两种不同的工作环境：一个规模很大，各种开发体系完备的大公司，另一个（也是目前的）是一个规模 100 人左右的小公司。目前正在准备离职中，对于两种不同的环境，很想评论一些什么，但是由于目前工作年限较低，也没什么资格作什么评论，在这个时间，在这样一个心态下，就给自己留点什么，对于今后彷徨时，给自己一个参考（不说谁好谁坏）。
很多人在买车时担心，车子是好是坏，总是会参考各种论坛的各种评论，近来我也在逛论坛，也在参考其他人的评论，但是好坏参半，究竟如何选择仍然拿不定主意，但是，其中的一条吸引了我的目光：汽车就像是一段路，而大家的口碑就是地图，地图只是一个参考，路好不好走还是要自己走走才知道。在离职的时候彷徨过，走了之后要找一个怎样的工作，要去一个怎样的公司，要走一个怎样的方向，记得当时很流行的就是去一个小公司拼几年，没有那么多文档，没有那么多流程，你只要编码就好，而且钱多多。当时真的就觉得，小公司没有这些流程，效率一定会高很多，却不甘心由一个那么大的公司跳到一个只有一间小办公室这样的公司。拿不定主意的时候又想到了北漂，多么流行的一个就业方向，虽然向往，却没有向北京投出一个简历。后来有一个外企的机会，借着这个机会，也去一趟首都，总不至于在中国这么久却没去过首都，太说不过去了，但是，当我真正坐在会议室里，看着面试官很悠闲的听完我所做过的项目，就结束了面试后，开始感觉到现实的残酷和自身的不足了，北漂适合我么？当我在游北京看到每天的地铁二号线的人山人海时，我放弃了，这里不适合我。是啊，适不适合，不是别人一句话说的算的，还是要亲自体验才能知道是否合适。
流程控制，大公司讲流程，全程 QA 跟随，每一个环节都有很正式的「小仪式」。参与过的一定都很痛苦，QA 怎么那么烦啊，什么事都管，每天的例会，每周的早会，都会有 QA 唠唠叨叨……而小公司，流程上没那么复杂，开发人员结束开发后，直接用下 U 盘将程序拷过去安装和调试就 OK 了。没有那么多流程上的东西真的很轻松，换来的是我对自己开发的程序没有底。就像我原来的部门朋友在一次聊天时和我感慨道，原来的公司的体系真健全，我现在的公司都没有什么流程上的控制，我做出来的东西都不敢往外发。是啊，当自己做的软件人命关天时，都会有这种感觉，当然了，我也感觉到了，所以现在我认识到流程的重要性，也在公司没人在意的情况下坚持有流程上的记录，坚持按照以前公司的流程来进行开发（虽然只是有模有样的参考）。流程还是有必要的。客户源的不同，很随便的做事风格就会有很随便的客户。所以，大公司一般接到的项目都是一些成熟的企业的项目，小公司的客户一般就很随便了。最直接的体会就是，我的第一个项目，在给客户发布版本的时候，Release Note 中的发布程序的格式错误了，每一次发布都应该是单独的，而我将所有的程序版本累计加到了表格中，在连续三个版本后，客户那边就来确认这是怎么回事。而目前给我的感觉就是，我们和客户交流，随便说说，做做，没问题就 OK 了。以前和客户的沟通是邮件，而每一次的问题都会有邮件伴随确认，而目前呢，只需要 QQ 就 OK 了。一个电话打完也就 OK 了。你随便，客户也就随便了，什么事都没有很好的依据了，想修改什么，就修改什么了，也没办法，我们服务于客户了，我们就是在要饭吃，但是，如果我们太随便，那就真的是要饭的了，在项目上，如果单靠嘴来确定什么，将来是很吃亏的……你都随便了，客户当然更随便了。
开发习惯上的不同，来到小公司最开心的一件事是什么，我写代码不用去管编码规范了。什么控制代码行啊，什么格式啊，统统甩一边。说实在的，原来在大公司里，要完成一个功能很不容易了，更何况还要参照编码规范。但是究竟从什么时候开始关注编码规范的呢，应该是我在看到了一段又 700 多行一个函数的时候吧，没错，700~1000 行的一个函数，去掉注释应该有 700 行左右吧。当然这一定有他的道理的，开发时间短。当然每个人的开发习惯不同，导致开发习惯不同，能写出 700 行的一个函数应该算是高手了。但是对我可能不太习惯，在今后的开发，无论条件多么宽松，都应该严格要求，不是因为代码多好看，而是今后的维护成本。如果可以，别在新进入一个公司就承担这个公司的基于 base 的优化与重构。基于此，我比较赞同大公司的经验丰富的熟悉系统的人来带领较聪明或较勤恳地新人来做。而如果让新人赶鸭子上架的方式单独进行这方面的开发，就有点得不偿失了。如果是从 0 开始开发也许还不错，但是如果基于 base 的，熟悉原代码是一方面，另一方面修改与调试也是一项耗费成本的因素，修改的代码是否能够让老代码正常工作，不是一个小时的调试能检测出来的。当然，无论大公司还是小公司，研发工作都是一个费力不讨好的工作，你的成绩永远盖不过你的过失。在大公司，我可以用两周的时间去调试别人四周未出结果的研发工作，却在后来因为领导实在等不下去的时候以这么长时间没弄出来而告终，当然，科技这东西就是要短时间出成果的，没有实力就不要随便去担任研发工作。而基于 base 的小公司式优化与重构，在时间周期短的情况下最好不要去尝试，当然，如果你有足够的实力和足够聪明的脑子，还是要尝试的，出于时间的考虑，boss 一定会希望你在短期熟悉系统，并进行重构和优化，boss 永远是 boss，员工永远要去完成 boss 的命令，这是必然的，无论对错，在短时间的开发周期中，你要灵活……
总结我的这次重构上的失败，完全出于自大，开始有模有样的设计出了一套框架，对于熟悉的部分，当然是重构的有模有样，但是在项目的后期，由于时间的关系，没有时间去熟悉其他部分的功能，得到的命令是把原来的东西拿来用吧，但是你懂的，很随便的程序开发出来，有很多东西是可以通过全局变量来解决的，但是你设计的各种模块对于把老代码整合进来还是有挺大困难……也许是我太笨（就是太笨）。没办法将这样的系统整合在一起，但是我的想法中，如果真的整合在一起，这样似模块又毫无模块可言的东西……真的不如没有。其实无所谓好与不好，每个人根据自己的工作个性，来寻找适合自己的工作环境。就像在正常情况下，测试和开发是有点敌对的，但是作为体验了测试和开发的工作之后，在测试时我理解开发的固执，在做开发时我也能理解测试的找茬，这样就很好了。都是为了项目能做好，只是出发点不同。其实仅仅工作了五年就来谈大小公司的区别，只是个人的浅见，离职之际，给自己的五年工作经历作一个总结，没有贬低小公司赞美大公司的意思，也没有讽刺大公司歌颂小公司的意思。就像买车，试驾过多个车型之后，才知道自己到底喜欢什么车，而不是通过论坛的评论就决定的。
总结一下，无论下一次的工作是什么样的环境，都要将经历中的好的方面作参考，不好的方面作警示：
1.与客户要做到涉及项目要正规，凡是项目上的东西有理有据，一定要有确认。
2. 遵守流程，无论大小项目，有流程上的确认才会有底，流程上别含糊，你含糊的不是客户，含糊的其实是自己。
3. 程序员更要有文档，你根本不知道你留下的代码会被多少人骂，你也不一定会记得一年前你写的一个函数是什么意思（老掉牙的建议）
4. 不要轻易接受一个研发的项目或者重构的项目，尤其是单兵作战的时候，更何况没实力呢，不要认为自己在一个公司里有了一点实力就很强大了，也不要被领导的信任冲昏了头脑。
