原文出处： 叶小钗   

前言

昨日，我请了一天假去考科目三，结果第一把挂在了没完全关闭灯光上，第二把挂在转弯时没有观察后方车辆，当听到师傅一句“下去”的时候，我那是悲痛的面红耳赤，这让我很郁闷，晚上也就不想回去上班了，回家后仍然有点低沉，在这种情况下，不写点毒鸡汤，好像已经不能好好的调节心情了，看看时间年底了，便写写今年的总结吧。

回想自己学车的点点滴滴，其实是很认真的，一旦有时间就去学习，练习时候也表现比较正常，晚上还会冥想整个考试流程，但最后临门一脚仍旧出错了，这个时候可以说我问心无愧了，也可以说我努力过了，虽然失败了，但我应该得到尊重。

现在看来说这种话的小伙伴不过在自我安慰罢了，做的过程中我确实很努力，也真的很认真，但是最后产生不了成果，做的事情不能落地，那么这一切的努力可以说毫无意义。将这一次的驾照考试映射到一次重要项目开发的话：

产品努力出需求 ->研发努力加班干 -> 测试努力加班测试 -> 上线 -> 大流量挂啦……

开发的过程中，研发天天加班，测试也天天加班，但是最后项目上线后就是挂了，那么之前的努力并不会换来丰收的果实，即将来临的可能是老板的怒号，团队的动荡，而不论是考试挂了，还是项目挂了，都有幸被我经历了。回头想想，人生嘛，什么都应该经历一发嘛，深深的体会一下挂了的那种无力感，也是不错的嘛，想到这里，我竟然有些释怀的感觉，只不过是重头再来（自我安慰而已啦）……

再回想16年初回到了成都，开始了愉快的“慢节奏”生活。不曾想，现在的公司给予自己的平台居然是其它地方所没有的，不论从工作强度还是业务复杂度来说，都是很对胃口的，偶尔的工作强度甚至超过了上海，嗯，这个很“成都”。

文中为个人观点，不喜勿喷

大公司or小公司

之前经常有人发文说到底要去小公司还是大公司，思考几年的经历，其实大公司小公司不重要，好的团队才重要！

大公司一般是什么都有，只需要你有一颗学习的心，多折腾多问，便能吸取大量的养分；而小公司也有一个巨大的优势，便是什么都没有，只要你有心，就能把大公司的东西通通实现一篇，这种实践来的知识技能可比学习要来的珍贵的多！

初到公司时发现了一种现象：

① 身边很多小伙伴没有买房但是都有自己的车子

② 多数小伙伴下班就回家了

可以很清晰的感受到这里的一种慢节奏，这个没什么不对，生活与工作要分开嘛，但这却让我感觉到了危机与忧虑，最大的忧虑是多数小伙伴可能不会在意到公司的财富了，天地不仁以万物为刍狗，其实生活是非常公平的，每个人的机遇其实都差不多，很多财富摆在那里，就看你是不是要去拿。

之前面试的时候，有人会问我知识获取的途径，也许是我比较low的缘故，我一直信奉一个原则：

听过 < demo过 < 实际工作用过 < 实际工作中被坑过 < 实际工作中被多次坑过或者深入研究总结过

风之积也不厚，其负大翼也无力也。网上有很多深度好文，如果没有一定基础，其实看了没有什么意义，只会在心里感叹，我尼玛这人好牛逼。

我学习的多数知识是直接从项目中来的，这个时候就需要你有一个好的团队了，我十分庆幸自己曾在携程无线待过，携程无线在前端工程化&hybrid&公共服务化一块走的比较远，而我当时又很好学，平时没事就在这之上挖掘，吸收学习，当时一些半懂不懂的知识，在后续的实践中也逐步融会贯通了，其带来的财富令我受益至今。

而，人的知识除了受限于自己的学习主动性以外，也受限至他的视野，当时我的视野就在前端方面打不开，没有去研究携程的日志统计系统与发布系统，到现在需要用到这部分知识时才感到苦不堪言而后悔莫及。

如果各位有机会到大公司去，一定要认认真真搞清楚，你自己所在领域里面，该公司的财富积累是什么，然后狠狠去挖掘他，了解他的历史故事，各种处理细节，更多的不是关注他怎么做，而是要关注他们为什么这么做，然后多问多demo，假以时日落地到实践中，这块财富就装入你的口袋了。回想自己的择业，我事实上是比较后悔自己当时为了一点小钱而放弃了阿里（成体系的前端团队）去了百度（新团队，不成体系，甚至前端框架都不统一），如果带着谦卑的态度去阿里吸取一番技术的给养想必会受用无穷吧。

技术的学习，这个需要一个学习的态度，一个学习的恒心，其实只要是持续的投入，便一定会有收获的。

技术体系化

在小公司，因为很多基础设施都不成熟，这个会让我们有将技术业务体系化&服务化的机会，而体系化后的技术便是公司的财富也是研发团队的技术壁垒，他能大幅度的提高效率，这个是一个生态体系，一旦生态体系成熟后，牵一发而动全一身，就不是任何人能轻易接手的了。

初到公司的时候，我们的系统是这么个状态：

每个H5项目有一个自己独立的登录注册，native又有自己的native的登录注册，甚至server端的服务都彼此独立，这样用户之间变形成了信息孤岛，这会引发很多问题：

① 每次做一个H5项目都必须做一个登录注册，徒增工作量

② 我们多出一个APP后，APP又产生了自己的登录注册

③ 我们H5项目内嵌至native后，账号没法打通

④ 当我们用户越来越多，子系统越来越杂的时候，我们的用户会越来越乱

这个时候，我们需要做的一件事情，就是整理所有的子系统，将我们的账号系统体系化。

数据库改造

这里我们做的体系化第一步是对数据库进行改造，将子系统做到一张公共的表，有过相关经验的朋友都会知道，子系统较多的公司，应该将基础用户表设计得足够抽象，只需要包含核心数据：

① 用户id

② 用户昵称

③ 用户手机

④ 用户密码

⑤ 头像&性别&出生年月&身份证&头像……

当然每个子系统的用户角色不尽相同，所以需要每个子系统自己维护一个用户角色表：

JavaScript //用户总表//公司用户不一定都是子系统的用户,但子系统用户一定存在与公司用户总表中var users = [ { id: '1', phone: '13579246810', name: '昵称1', infos: '其它公共信息' }, { id: '2', phone: '13579246811', name: '昵称2', infos: '其它公共信息' }, { id: '3', phone: '13579246812', name: '昵称3', infos: '其它公共信息' }];//子系统A中的用户表var a_users = [ { id: '1', roleId: '1'//游客 }, { id: '3', roleId: '2'//超级管理员 }];//子系统B中的用户表var b_users = [ { id: '1', title: '教授'//游客 }, { id: '2', roleId: '副教授'//超级管理员 }];//子系统C中的用户表var c_users = [ { id: '2', address: 'xxxx', title: '三甲'//游客 }, { id: '3', address: 'xxxx', roleId: '二甲'//超级管理员 }];

我们在处理用户表的时候，除了抽象基础用户信息时，有可能还需要一层业务公共层，以我们公司为例，多数用户是医生，所以像职称、所属医院这种信息会经常被用到，这个时候就会出现直接使用这种业务公共表的情况：

子系统A与子系统B都是使用的与子系统C一样的用户id，但是他们直接依赖了公共业务关联，他们在公共业务中获取了类似科室、职称等信息，如果这个体系再扩展的话，会是这样的：

公共H5服务

体系化的第二步是H5整合Server服务，当公共的服务出现后，这里便需要提供公共的H5页面，这里会遇到一个难题需要突破：

① 各个业务有自己的定制，比如注册时候要求的字段都不一样