【第824期】小公司的一年，一块儿看看小公司的前端能够怎么作

【第824期】小公司的一年，一块儿看看小公司的前端能够怎么作

前言

无论是大公司仍是小公司，公司提供的只是环境氛围，重要的仍是要靠我的的努力跟心态。今天的早读文章来自@叶小钗的受权分享。

正文从这开始～

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

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

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

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

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

再回想16年初回到了成都，开始了愉快的“慢节奏”生活。未曾想，如今的公司给予本身的平台竟然是其它地方所没有的，不论从工做强度仍是业务复杂度来讲，都是很对胃口的，偶尔的工做强度甚至超过了上海，嗯，这个很“成都”。

大公司or小公司

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

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

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

• 身边不少小伙伴没有买房可是都有本身的车子
  

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

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

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

听过 < demo过 < 实际工做用过 < 实际工做中被坑过 < 实际工做中被屡次坑过或者深刻研究总结过

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

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

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

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

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

技术体系化

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

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

每一个H5项目有一个本身独立的登陆注册，native又有本身的native的登陆注册，甚至server端的服务都彼此独立，这样用户之间变造成了信息孤岛，这会引起不少问题：

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

• 咱们多出一个APP后，APP又产生了本身的登陆注册
  

• 咱们H5项目内嵌至native后，帐号无法打通
  

• 当咱们用户愈来愈多，子系统愈来愈杂的时候，咱们的用户会愈来愈乱
  

这个时候，咱们须要作的一件事情，就是整理全部的子系统，将咱们的帐号系统体系化。

数据库改造

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

• 用户id
  

• 用户昵称
  

• 用户手机
  

• 用户密码
  

• 头像&性别&出生年月&身份证&头像......
  

固然每一个子系统的用户角色不尽相同，因此须要每一个子系统本身维护一个用户角色表：

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

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

公共H5服务

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

• 各个业务有本身的定制，好比注册时候要求的字段都不同
  

• UI会成为第一个拦路虎须要你去说服
  

既然是公共页面，就须要知足一些业务的定制需求，当底层框架完善而且统一后，即可以以规范的力量给予业务开发以指导与限制了，只有将公共业务作好后，才能真正提升咱们总体的开发效率

第一个问题是业务受限，那就说明公共服务作的不行，不具备通用性，那就改设计，改到知足就好了

第二个问题，确定是在咱们已经有公共服务的状况下，告诉UI，咱们这个是公共服务，是不能乱改的，设计要中性化

要整个公司的人都造成公共服务，以及重用，效率的思惟后，你们才会承认这个，在人家不知道或者不承认的状况下，说那么多也没用，知行合一才是王道。

一个较为合理的公共页面多是这个样子的：

因此，后期咱们的系统就变成了这个样子了：

当咱们这套体系走的足够远后，咱们整个系统可能就是这样的了：

打通H5与Native

体系化第三步是整合H5与Native资源，这里也是所谓的Hybrid体系，只有在前两步完成后，才能很好的完成这一步，不然就只能称为内嵌页，不能叫Hybrid，更不能说是什么移动体系化。

整合Native与H5的第一步仍旧是帐号打通，通常来讲，咱们强制要求native中H5只能使用native提供的统一页面进行登陆，无论这个页面是native的仍是H5的。

事实上，咱们H5端就登陆一块作了三套页面一个弹窗，一套帐号登陆（废弃）、一套手机号登陆、一套手机号登陆而且带第三方登陆，还有在页面里面直接弹出的登陆框，一个个APP中是不该该容许存在两个退出帐号或者有我的信息的地方。

设想，若是H5具备本身的登陆，那么整个状况会变得极其复杂，首先APP具备一套本身的登陆，而H5若是与APP登陆了不一样的帐号，那么就会存在用户串了的状况，固然，APP能够监控H5的登陆态变化，但这个东西技术实现成本比较高，而且容易出错，因此咱们这边要求全部H5的登陆所有走Native的一套体系，每次Native打开webview时，若是有cookie就注入webview，这样前端就本身有登陆态了 一旦当app注销帐户，以前全部的页面也将所有弹出掉，新开一局，如此一来帐号体系已经打通。

Hybrid化

当作到H5与Native帐号打通后，咱们即可以实行咱们的Hybrid化进程了，这里简单以Header为例。

主流Hybrid都是使用的Native的Header，缘由有不少：

①稳定，防假死

咱们料不到前端会出什么错，特别是第三方网站，一旦前端出错若是iOS连个退出的按钮都没有，那么就app假死了，这个比crash还讨厌

② 体验

咱们在刚打开一个H5页面时，可能会有白屏，若是header也不在的话，体验会比较差

而咱们在设计Header交互时候，须要考虑到前端的使用习惯，最好能保持业务代码一致，处于不一样宿主容器表现不一样，这里的设计是左中右的设计，图中就是咱们能提供的全部header样式了，不够也没办法咯。

完了咱们须要对tagname定制化，header中的全部按钮的惟一标识为tagname，因此tagname不得重复，其次经常使用tagname会有一个默认图标，须要定制化的话，就读取线上资源。

这里back比较特殊，在webview中会检查history的记录，若是大于1则后退，不然会退回上一步操做。 咱们能够看出，back的功能是很单一的，每每不能知足咱们的需求，因此经常使用forward+pop动画当作back使用，而这一作法将引发使人头疼的history错乱问题，针对这种状况咱们有一些特殊API，可是由于这个API须要Native支持，因此使用须要慎重，最好是新增一个native接口，用于跳转后，清除全部的history webview。

Header约定是Hybrid的重要一环，也是移动体系化，技术体系化中重要的一小环，与之对应的会有：

• 分享约定
  

• 登陆唤醒约定
  

• 离线包机制
  

• 跳起色制

.....

这里体系化作的足够好的话就会出现相似微信SDK通常的东西，可是这个要看大家是否是有足够多的第三方接入方须要大家费这个神了，可是只要作到这一些，你的移动端便已经体系化了，全部的H5项目的帐号系统与基本native打通是完成了。

这种体系化的东西造成后须要作到通用，好比两个app能同时运行同一个H5站点，甚至离线包机制都是一致的，header交互也是一致的

数据可视化

上述工做作完，表现层的东西就作了一大部分了，站在前端的角度的话，能够作的东西好像很少了，其实细细一想，有这种想法真的是图样图森破，就算要把上面的事情作完都要费老大的劲，何况真正的难点可能才真正的开始，如咱们第一张图，咱们有一个项目外包了，那个外包的用户是游离于咱们帐户体系外的，咱们应该如何处理？而更让咱们头疼的多是数据收集与分析，猛的回头，你会发现，对于前端，还有数据可视化这么一大坨的东西须要你去挖掘！

随着技术的沉淀，公司的发展，公司的业务虽然愈来愈复杂，可是在咱们的体系下，都还能很好的运转，可是业务才是技术的祖宗，咱们可能会收到相似这种需求：

• 请给我一下上次迎新活动3个月后的用户留存率
  

• 请给我XX推广人员的订单推广率
  

• 请给我APP由XX二维码推广活动的数据
  

• 请告诉我为何咱们转化率低

......

用户&订单渠道

能够相信，全部这一切一定会将你问懵，通常来讲，不是全部前端一开始设计便能考虑到这些问题，也不是考虑到这些问题就能设计得好，这里简单以用户业务渠道作一个说明。

为了解决以上问题，咱们在设计用户表的时候就得新增一些字段了（比较痛苦的是最开始没有这些东西，后面加就恼火了）：

• 项目来源，标志该用户（订单）来源于哪一个子系统
  

• 业务来源，标志该用户（订单）来源于什么渠道
  

这个渠道就比较复杂了，能够是推广人的拼音，能够是一个活动的标志......

这个设计其实比较简单，就是新增几个数据表字段嘛，真正的难点在于前端&native调用，通常来讲，咱们但愿业务开发无感的便存入进去了，因此咱们能够这样设计：

① 在url（cookie也行，就是麻烦）上加入一个channel的参

这里若是不使用cookie须要前端框架作处理，保证每次跳转将这个channel参数一直带下去

② 每次ajax请求的时候将这种新增一个入common的字段，让server端自动处理

因此，业务开发只须要在url作处理（生成二维码的时候带上参数），前端框架统一处理后，每次请求就自动带上了，好比：

http://medlinker.com/h5/interlocution/index.html?med_channel=qq

native处理方案相似，这里处理完了，咱们即可以收集到用户（订单）来源于哪一个渠道了，有了这个数据收集便能很好的作后续的分析。

补足体系

上述是业务方的数据收集，这个属于精准定制结果，直接接口存储，除此以外，咱们还须要对整个子系统进行数据打点采集，好比页面pv+uv+按钮点击，这个是比较简单的需求，若是一个H5站点用于了多个容器（微信、qq），而每一个容器（渠道）产生的pv信息须要记录起来的话，便会有些麻烦。

数据采集这块是我最近准备作的东西，事实上这块我也颇有一点束手无策的感受，首先碰到第一个问题就比较使人头疼？

咱们究竟是应该本身从无到有作一套采集打点系统仍是应该直接使用友盟或者百度统计这种第三方的东西？

这里由于我也尚未想清楚，便不作展开，当这块造成后咱们整个体系就变成了这个样子了：

通过将近一年的努力，咱们逐步构建了这个移动体系化，而且正在向各部分添砖加瓦，如今在如下模块仍然有所缺失：

• 数据可视化缺失，如上所言，这块是咱们接下来须要补足的，这里又包括了数据采集，存储，分析，展现多个方面，总之能够作的不少。
  

• 通用IM消息系统缺失
  

咱们如今Native使用的自身的IM，H5与Native因为原来北京成都两个团队而选择了融云体系，如今整个消息系统没有打通，这里是须要打通的，之后就算你们选用第三方的服务，都必定记得让本身server端作一次收口工做，作一次proxy，这个若是后期须要改造更换消息系统会轻易的多！

• 日志监控

咱们的日志监控与预警一块作的也不够完善，这里包括前端预警与server端预警，这块接下来要增强

• 全站https化
  

......

其实除了上面的一些，应该还有不少其余体系模块没有被提出，好比：

① 开发环境

通常环境分为开发、QA、预览（生产某一个机器）、生产四个环境，环境是比较好作区分的，可是难点在于通用的发布系统与各环境的数据处理问题，好比QA环境就是须要一些生产环境的数据，这个时候该怎么作？？？

② 小流量发布

有些时候，咱们为了测试，可能须要小流量发布，一方面为了关注流量变化，一方面为了确认没有错误，咱们须要这种系统，同时也须要咱们的可视化系统记录各类状况的转化率等数据

这里也仅仅是我（前端角度）所了解的移动体系，也许换我的来，又会大有不一样，无论是什么样的体系，都必定要保证，本身的公司是有一套开发所依赖的体系的，这个东西会极大的提高开发效率与稳定性！

体系设计

在我看来，体系的设计与出现不是一朝一夕的事情，也不是凭空设计，脱离业务，每当咱们须要在咱们的技术体系中添加模块的时候都须要思考一些问题：

咱们提出的这个东西是要真实解决咱们开发中的什么痛点？

这个会须要咱们具备必定的特质：

① 有强烈的意识，能了解性能的缺陷，开发效率低下的缘由，并能提供有效的处理办法，再此之上进行抽象

② 对于团队中搁置的老大难问题，要想办法进行有效的推进、处理

而，咱们体系化的东西也不是过家家产生的，这种比较通用的设计必需要出文档，必须与人商量，技术方案里必须的流程图、时序图都要规范，还要把设计要完成的关键参数标注好，最后做为验收标准。方案出来以后要确认方案如何落地，操做路线是什么，执行计划是什么，怎么处理团队间的阻力。

好比咱们上面作的通用的登陆注册页面，就须要相关的文档，要描述清楚，咱们这个东西的边界是什么，能解决什么问题，有什么限制，体系设计推进任重道远，你我共勉。

工做态度

我在上海工做期间学习到的另外一个受用无穷的知识即是“正能量”了，其实正能量并不能让你多写几行代码，可是他会令你的工做状态持续上升，与之对应的是负能量，若是你身边有小伙伴产生负能量的话，就必定要当心了，负能量就确确实实能让你少写几行代码了。

当时携程无线解散的时候，须要咱们并入其余团队，不知不觉间就生出了一些负面情绪，咱们是后爹后妈养的，过去确定没好日子过了，因而那段时间各类消沉，也有换工做的准备了；而团队两个老大哥的表现却截然相反，一个老大哥仍旧是勤勤恳恳的工做，帮助团队乃至整个公司渡过了当时比较困难的技术交接时期，另外一个老大哥积极的协助新团队推进新框架，甚至那个框架都不是咱们写的。

后来，我常常与两个老大哥交流，一个老大哥（来自华为）传给了我“忍、滚、狠”的绝技，另外一个老大哥带着我领会了皮实的意义，其实这些道理真的很简单，咱们处于顺境的时候，天然意气风发，那么当咱们处于逆境中的时候，咱们就应该自暴自弃、消沉不已吗？

时至今日，我有点什么疑惑的地方都常常喜欢请教两位老大哥，我也从他们身上学到了，其实在抓技术的同时，协调推进能力也是相当重要的，由于如今不少业务都是几个部门在作，若是没有良好的推进能力的话，极有可能iOS一套东西，Android一套，前端自成一套，这种对整个公司来讲是一种浪费，须要有人站出来整理整合。

团队战斗

我十分喜欢武侠，近期特别喜欢剑雨中的一段戏份：

当时是转轮王手下三大高手，雷彬、彩戏师、细雨等五人戏份（大S可忽略），彩戏师提出你我三人联手格杀转轮王如何，并开出了条件等待交易：

我（彩戏师）只要罗摩遗体

所有财产给雷彬

细雨回去和爱人太小日子

显然，彩戏师的价码是足够让人动心的，他也提出了至关的诚意，主攻转轮王去了，这个时候雷彬开始了观望，然而细雨一声“大家玩，我回家和相公吃饭去了”，直接把整个交易堵死了。

这部戏其实真的很是精彩，若是他们三忽然达成一致跑去围杀转轮王，我才会感到奇怪。考虑到电影才过3/4，观众可能会说那么这一切岂不是过轻易了？可是从真实社会阅从来说，这桩交易达成的几率很低，一个核心缘由是：

这笔买卖涉及了大多数人的利益，乃至生命，一旦一件事情涉及了多我的的利益，那么这个事情势必会很慢、很难达成一致

咱们作一件事情时，但烦须要他人合做共事，就必定比一我的难多了，人和人之间想法差别是及其巨大的，就看剑雨几个主要人物的需求：

• 转轮王，须要罗摩遗体长jj，好xxoo

• 彩戏师，须要罗摩遗体治病

• 雷彬，须要钱与不受控制

• 细雨，须要爱，须要家人不受伤害

• 大S，也许是须要关注吧

能够看到，里面最核心的利益冲突是来源于转轮王与彩戏师的，这也是为何处于弱者的彩戏师要先出手，表达诚意，其余人能够观望，能够退出。

一样，团队之中，人和人的差别是巨大的，这种差别甚至是难以调和的，在这之中就必定会有一个智障或者特别有私心、或者懒惰、或者喜欢单独和上级沟通的，只要一个队友有一项或者几项毛病，整个团队就会扯皮，而处理扯皮是内耗的事情，但这种内耗又每每比正经作事要花费更多的精力。

在团队内，各个小伙伴性格各异，彼此较劲；而后团队之间又有分别，产品与研发彼此对立，就算一个公司，内部也有派系之分，小至一个家族也会兄弟拆墙，讲到底，分的是彼此，争的是权利，除了本身人就不是本身人，不是本身人就算别人，这个分别不知什么时候才能中止。

由于是人都会有分别，产品变动了需求，就比开发改了我代码更可恶；上海分公司的产品欺负了深圳分公司的研发，又比身边的死UI更加可恶，大大小小的分别，职位的分别，地域的分别，亲疏的分别，人很容易就能够找到和本身不一样的族群做为敌人，因此纷争很难中止，解决分别心这种佛学的话题显然咱们无能为力，因此选人就变得尤其关键。

综上，要让团队有战斗力：

• 首先就要有好的计划

• 其次要有好的leader

• 而后找合适的人

• 最后打到共同的敌人（项目）

好的方向才可能出好的结果，任何没有计划的事情都收效甚微，好的leader才能团结团队，技术要过硬，视野要够远，抢业务要凶猛，而慈不掌兵，若是有和团队气质不符，甚至起到副作用的，必定要提早剔除（劝退是最后的手段，更多的应该是影响），不然吃亏的是整个团队。

这里再强调下leader的做用，团队的战斗力须要leader去激发，leader做为公司的执行意志与核心驱动力，须要起到正确的带头做用，要有足够的责任感与危机感，要善于汇报工做，争抢业务，若是你的leader老是把业务往外面推，那么这个leader是不合格的。

由于，咱们是来工做，是来赚钱的，我首先是来赚钱的，其次才有团队小伙伴的战斗情谊，若是没有业务就是没有KPI，没有KPI就是没有钱，连最基本的发展都没有的话，再好的私交在公司面前也不可持续，咱们是由于这份事业才在一块儿的，梦想&激情这种属于稀缺的消耗品，不是人人拥有的。

我的与团队的关系，矛盾而又统一，彻底追求我的能力成长最大化一定和团队利益冲突，若是能合理运用团队又能打破我的的局限，因此团队合做才是突破一切的关键，一我的的力量是有限的，遇到困难也更容易突破，若是发现一些事情，团队中只有你能作，就要当心了。

结束语

其实，小公司真的有不少独有的优点，不少坑等着你去作，去思考，只要能把这些坑一个个填平，那么必将会有长足的进步，也能尽快的突破自我瓶颈。