离职在即，在准备下一个工作环境的这段时间，忽然有一阵感慨，工作近五年，在这段时间中，体验了两种不同的工作环境：一个规模很大，各种开发体系完备的大公司，另一个（也是目前的）是一个规模 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 的命令，这是必然的，无论对错，在短时间的开发周期中，你要灵活……
总结我的这次重构上的失败，完全出于自大，