路由器Web页面(图示),主要负责路由器的配置管理,对于Web的学习算是从此起步。最近看着行业内日新月异的前端技术,谨纪录一下由此开始的前端之路。

    一、路由器上的Web

    路由器中Web场景的一些特征(合并了从产品/用研/工程角度的个人观点)

    • 硬件设备性能/存储空间受限;WebServer需轻量(RAM有限)、页面资源要小(Flash有限)
    • 用户端和服务器IP直连,链路上仅一跳;不用考虑Web资源部署、增量加载、流量优化等问题
    • 单IP访问限制,同一时间仅一个登录态会话;不会有并发读写,Server端不用考虑识别用户(仅Admin账号,登录逻辑独立)
    • 前后端数据交互简单,接口明确(很早就实践了API-First的策略:D)
    • 页面跟随固件发布/更新,更新频率低(用户较少升级)
    • 页面结构扁平(各模块的入口平级排列);且各模块相互独立(依赖清晰)
    • UE/UX需求较弱;页面访问路径简单且集中
      • 首次启用路由器,跟随引导页完成配置「☆☆☆☆☆」
      • DHCP Clients查看,WAN接入配置更改「☆☆」
      • QoS、防火墙等高级需求,网络故障排查「☆」
    • 产品原型可以在立项初期明确、需求固化后很少变动
      • 严格的瀑布开发工作流,不用考虑需求迭代
      • 强调文档,且文档被较好维护(因此很多刚毕业的工程师可以很快投入项目)

    同当今海量互联网服务所处的凶险环境相比,工程角度看、路由器Web开发活动只是”Hello World”级别的——本地随便起一个httpd托管webpages,”It works!”.

    因此作为一个边缘的开发领域,早前的Web代码都是由嵌入式背景的工程师摸索完成的。(当时还是有不少创新的,比如为了解决ODM形态产品「快速替换页面文案」的需求而自研的i18n方案)

    然而现在来看,早期的Web开发还是有不少反模式:

    • 没有严格的前端代码规范:有驼峰命名也有下划线命名,很多inline JavaScript
    • 没有模块划分概念;且一些跟随产品的差异需求,被hardCoded到前端逻辑里
    • 各产品页面共用一套Codebase,没有版本发布管理的实践:巨大的一个 ***.js 文件塞满公共函数,服务着很多内外销产品及衍生产品,包括一些已经退市的产品
    • 调试活动只能在板子上进行,很多页面是CGI吐出来的,小的修改往往也要对固件全量编译并烧机
    • Web安全漏洞(http://www.routerpwn.com/)、一些预留的调试接口被打包发布

    其实这些也不是什么重要的问题——

    产品的竞争力不是体现于此、而是更多强调性价比上对竞品的绝对碾压——Web UI再友好易用、也只是个Shell而已;路由器的定位应该是像客厅的插排一样,配置完就躺在角落里了。

    某种程度上,这也是正确且符合国情的——

    就像对手机制造业的理解,”产品比iPhone有更好的信号、更大的电池”,999的期货价,自然能收割很大一部分市场。

    正因为对于上游芯片厂商、下游分销渠道都有着的强大掌控力,对待创新时可以静观其变、利用资本和竞争壁垒的优势后发赶超。制造业寒冬到来前,一切看起来都还很不错。

    二、重构之路

    2013年,新的产品形态崛起(MiFi),即支持插SIM卡进行3G拨号、并提供Wi-Fi热点供附近的移动设备访问的便携路由器。一些其他的产品功能:

    • 作为大容量移动电源
    • 挂载SD卡作为移动存储设备
    • 收发短信,如查询剩余流量

    虽然有OLED显示屏分担了一些展示需求,但是毫无疑问Web的需求要多起来了、而且要更好支持移动设备的访问。产品质量压力开始凸显(各种移动端Bug和不友好体验),同时原页面架构和开发模式对于生产力的阻塞效应开始体现。

    在一款TD方案的开发时,SoC厂商 *** 提供的SDK中,我们见识到了Ajax(13年,不要笑)、以及它是怎么做到前后端解耦的;随后开始对其他平台的Web方案进行类似的重构。同期在评估一款RTOS下的嵌入式WebServer时,从开源的Mongoose了解到了WebSockets及WebDAV,也通过WebDAV协议做了一个简单文件系统管理的方案。

    这个过程中,因为原框架缺乏手脚架,导致新增模块的尝试步履维艰

    三、新WebUI

    时间来到2014,智能路由的元年。

    最早引起关注的是一款叫极路由的产品,漂亮的工艺、友好的使用体验、加上”极客”的自我标榜,迅速引爆了话题。虽然对于传统家用路由市场的冲击有限(当时智能路由在传统家用路由的市占率大概2%,媒体数据),提颠覆为时尚早、但确实带来不小压力。

    对于开源的OpenWRT的研究以及LuCI WebUI的研究都正式立项,Web体验的强化和页面改版也提上日程,当时的直线Leader和Manager给予了很多支持。

    注意到这个时候,已经不是再归咎Costdown思路的时候了,市场都看清了路由器作为流量入口和中枢这么一个巨大战略优势,传统厂商也投入了巨大资源进行研发。

    既然新项目启动,是时候首先解决此前的技术债务和开发模式上的问题了。

    1. 制定代码规范,并通过JSHint进行静态代码扫描
    2. 代码分库,将webpages代码独立版本管理,配合Git钩子(hooks)和既有Gerrit CR工作流,强化提交质量和协同开发效率
    3. 通过Grunt来实现前端代码的模版替换、压缩合并、构建打包等,引入工具链代替此前的粗放模式
    4. 内网一台Linux服务器上部署了一台Web模拟器,模拟真机调试
    5. 实现了一套模块化加载的框架
    6. Wiki上持续汇报工作情况

    所谓模拟器只是个Apache(非路由器上WebServer x86编译,彼时团队已经聚焦在前端了),主要是仿真所有的Web请求,包含一个Python WSGI后端(以Mock动态请求响应),一个MongoDB来模拟配置参数持久化。 服务器定义一个cron job,定期同步webpages库上相关分支的代码,同时还原DB中的数据(以重置模拟器上被修改的配置参数)。

    当时只是为了解决webpages调试问题,现在回想应该可以作为一个工程创新:

    • 同版本管理联动,自动部署最新代码(朴素的持续集成实现)
    • 因为服务器内网全员可见,可以请同事定期访问体验(预发布的效果)
    • 开发活动依赖兄弟部门的配合(UI设计、文案撰写、多语言文档翻译、测试用例设计),以往的工作流是要移交真机或开发板;现在完全可以直接通过浏览器访问模拟器进行
    • 测试活动彻底解耦;通过修改UA来测移动版页面
    遗憾当时年少单纯,没有强调其工程化价值,原本是一个提升团队技术口碑的好机会。

    整个过程都是摸着石头过河,比如想做模拟器时只知道CGI、不清楚可用一些Web框架来提高生产力;DB化的尝试用了MongoDB这么个有门槛的方案;了解到Grunt时对NodeJS和它的包管理系统懵懵懂懂、只是忠实地在文档中记录了要npm install,等等。

    四、Web技术小组

    现在回想,如果当时有高手能指点一下方向或给一些总结,不仅能减少很多试错成本,还能让大家对于「所用之术」有了深刻「理解」、并转化为「知识」。就像武林之人只习得练武口诀、不懂心法,则技艺不精一样。

    「尝试」=>「理解」=>「知识」=>「习惯」

    这是一条连贯的学习链条,虽然很多时候「尝试」后就能贡献生产力了(换句话说,能技术变现了——做项目、就业,等等),但是在极度膨胀的领域知识下,技能也在飞速贬值;参考CPI和积蓄之间的关系,如何沉淀技术也是一个问题。

    14年成立了技术小组,开始担任Web小组的Tech Lead.

    最早是为了解决各个项目下技术方向发散的困境,也就是怎么沉淀技术。后面通过技术专题学习,组织现场代码走读等,有了一点收获;职业生涯中的第一次技术管理实践。

    先写到这儿吧,发现全文更合适的标题是:《Web开发狗的产品经理心》