到新公司接近 2 个月了(4.29-7.07),这两个月里也许是我毕业一年思考最多的两个月,的确是有必要进行总结。当然,纯属个人看法。

组织结构

背景

我所在的事业部成立于去年八月,属于前台事业部,也就是所谓的“创业部门”,极少同事抽调于其他团队,大部分为新人,最长任职时间不到一年(此处只谈技术相关),以下“业务团队”字样指代我所在的部门,因为我并不了解其他部门。

部门老大也就是技术老大,下面有若干前端与后端划分在不同的项目,但没有名义上的前端负责人与后端负责人,即使职称不一样,都是一线开发。

公司内部是有前端架构团队的,提供一些基础类库以及相关服务,譬如 jssdk、埋点、脚手架以及发布工具。

问题

这样的组织架构不少见,上家公司也是基本如此,但存在 2 点差异:

  1. 得益于老东家规模以及业务类型,架构组能够较为容易的推行内部工具;
  2. 业务线前后端是有负责人在的,可以理解为小组长,有一定的话语权。

这 2 点差异导致了 3 点问题:

  1. 选型不统一,已有项目经验难复用。公司规模大,架构组对业务团队基本没有约束力,导致业务团队除了一些公共基础服务必须使用内部工具,其他技术选型取决于具体项目的第一个开发者(大部分时候一言难尽),换一个项目可能要花一点时间适应一下,backup 困难;
  2. 缺少规范,协作困难。项目内没有代码规范,eslint 存在感极低,缩进、空格混乱且没有precommit lint。说服所有人很难,而协作是可能与所有人发生的。(“每个人风格不一样,很难统一的”,我真的很讨厌这句话,那要团队做什么?规范就是让 1+1>2 的)。
  3. 一些好的实践难以推动。想推 typescript?看你有没有机会成为某一个新项目的第一个开发者吧,并且说服与你协作的同事(如果有的话)。

思考

可能组织结构间接导致了下面我要谈的很多问题吧。

当然,我资历尚浅,可能有更深的考量是我所不知晓的。可能我所在的部门就是不追求这些东西,抓紧时间完成需求就好了,这些并不重要,其他部门并不存在这些问题(感觉可能性不大),但是部门老大经常强调质量,我认为还是落地方面有些问题。

组件库

现状

没有统一组件库,具体问题表现在以下几点:

  1. 数量:可复用组件少,经常需要造轮子,并且造完没有抽出来以供其他项目复用;
  2. 文档:文档缺失,更换开发者大概率需要摸瞎看源码,而且很可能 A 项目已经存在了解决方案,B 项目的开发者并不知道(或者知道了却根本无从下手拷贝),重复造轮子;
  3. 维护:1 中的轮子复用依靠复制粘贴,可维护性差,出现问题多方同步修改。

可复用组件类型:

  • UI 组件:譬如弹层(Popup)、轻提示(Toast)以及输入框(Input)等组件(往往还存在一些兼容性问题);
  • 业务组件:相同业务类型可复用的组件,譬如抽奖转盘组件;
  • 逻辑组件:譬如传送门(Portal)、切换器(Toggler)以及校验器(Validator)等可以用来优化代码结构并减少重复代码等无形态组件。

思考

活动页固然千奇百怪,但总有相似之处,如何与业务结合,分离可变与不可变,提高开发效率,正是工程师存在的意义(当然也需要产品【业务抽象】以及设计【ui 规范】同学的共同参与)。

如果不同项目设计风格实在差异较大,也能够通过改改样式复用,而非重写一遍逻辑以及兼容性处理。

既要有造轮子的能力(个人),也要有不造轮子的觉悟(团队)。

画外音吐槽:为什么把一个组件文件夹在不同项目中拷来拷去?文档也没有,我怎么用,代码质量就不说了,没眼看,都是一个人用的一次性代码。

行动

写了个 dora-ui,目前有以下组件:

  • Countdown 倒计时
  • Popup 弹层
  • Portal 传送门
  • Toast 轻提示
  • Toggler 切换器

感觉可以直接使用开源的组件库,为什么要自己写呢?

  • 反正没啥人用......(扎心了老铁
  • 后续会以业务组件为主
  • 也存在一点私心吧,锻炼自己,反正也支持按需加载,想和啥一起用就和啥一起用
  • 我会用心写好文档和单元测试的

脚手架(模板)

现状

目前团队内新建项目都是用 CRA 或者 DVA(为啥不用 Umi)改一改,我还没有机会自己去新建一个项目,但我觉着这也太麻烦了吧。

为什么不用公司内部的脚手架(框架)?我也不想看着五花八门的项目结构呀。

  • 我觉得可以用,但是团队内部没啥人用,架构组不强推,也没有前端负责人(话语权)...很难推呀;
  • 旧版本的 Bug。接的一个旧项目是用内部脚手架旧版本搭的,太多坑了,只能说勉强能用,团队其他人吓怕了,不过现在都修好了;
  • 公司内部的框架基本上都集成了我上面所说的内容。但框架定位是同构渲染,我们团队基本是纯前端项目,引入的很多概念概念配置增加了心智负担。建议把文档分开,给一个纯前端项目的最小知识集就好;

用 DVA 搭建项目其实还好,本来就是最佳实践了,只需要自己配些环境变量控制下publicPath以及增加precommit lint就好,但是用CRA就很麻烦了,要自己改很多内容。

问题

看项目内部架子(基于 CRA),最想吐槽的有 3 点:

  • 代码风格。前面说过。
  • 数据 Mock。为啥要在 src 里面根据环境变量引入 mock 文件,这不是开发时依赖吗?
  • 接口转发 Proxy。其实这个不算架子的问题。基本所有的架子都内置 Proxy 的,但是一些接口需要授权访问,这就需要鉴权,我们后台服务并没有提供给我们开发鉴权的形式,现在的解决方案比较麻烦:比如测试环境域名为m.test.zzzzz.com,使用SwitchHosts将本地 ip 映射为m.dev.zzzzz.com,前面m.dev可以自定义,后面保证一致,然后去 test 环境登录,这样就给浏览器注入 cookie 了,然后我们 Proxy 转发就能带着 cookie 转发了。可是缺点也很明显,内网 ip 会变化,把电脑带回家再带到公司,就要重新改 host,不知道还有什么好方案解决,感觉后端支持才是王道,也提到过这个问题,但是推不动。

思考

我觉得团队内部初始化一个项目,模板必须集成以下功能:

  • eslint/editorconfig(必须)
  • precommit lint(必须)
  • mock(必须)
  • proxy(必须)
  • 自定义 webpack 配置(必须)
  • 集成 redux(可选)
  • commitlint(可选)
  • typescript(可选)

当然有很多同学可能会说选型很多时候要考虑团队成员的能力。

但是能力是有及格线的呀!能被工业化大规模使用的工具会很难吗?这个太重那个太复杂,又不是引入angular or rxjs,用某位大佬的话就是“你脑袋只有几 kb 吗?”。

为什么要选择redux-thunk,是dva不好看还是rematch不好听?

可能仅仅是因为第一个初始化项目的人只知道redux-thunk罢了(当然如果只是一个人开发,随便怎么玩),但如果是协作项目,建议由一个真正深入过思考的人去进行技术选型)。

所以说脚手架很重要,但是 emmm...架构组的脚手架可能不适合所有业务场景(以及约束力因素),团队内部 emmm...大概率推不动(我正在写),说起来都是泪。

行动

正在写一个适合团队内部使用的脚手架,会集成上述内容。

尤其是预置代码规范以及风格,但是被关掉或者修改就没办法了呀,有些同事就是不喜欢用插件格式化代码,自己写的又达不到代码标准,真的好难。

前后端分离

惊不惊喜,意不意外。

现状

前端项目如果初次发布,需要把index.html托管到后端那里,我们虽然把 html/js/css 都上传到了静态资源服务器,但 html 用的是后端托管的,打包出来的内容不能有 hash,如果资源地址变化,需要后端配合修改 html,每次上线要后端刷版本号(就是加个时间戳),避免请求到了缓存的 html。

更多分析可以看我另外一篇文章——关于前端项目部署发布的相关思考。

思考

Nginx 配置代理应当是最优的,不然更改打包策略还需要后端配合,着实无奈,可能的原因就是配置 Nginx 需要找人找人找人,但是后端上线难道就不找人了吗,这里不是很理解,听说有在解决这个问题,可能这种操作背后有什么历史原因吧,但放到今天,实在是很难接受。

昨天在新生技术培训上向前端老大提了这个问题,听说架构组是有规划解决这个问题的,后面再看吧。

其他

关于上线流程

目前是没有上线流程的,对,没有!

  • 开发完后一嗓子上线,有些需求少的、关联性不强的开发人员都不知道啥时候上线,上线的时候人不在结果没发;
  • 对线上发布没有敬畏之心,一天可以发几次。

上周开了个会想要解决这个问题,希望能落地。

无非就是固定上线日期以及发布次数,通过邮件以及文档等进行需求生命周期跟踪。

需求 => 视觉 => 开发 => 测试 => 预发 => 正式上线。

不过上线流程在我看来应该是公司统一的吧,不然新团队还要重新建立这些流程规范,一不小心就走偏了,捂脸哭。

还有一个点就是公司内部没有使用邮件的习惯,见仁见智吧,我觉得比较神奇。

关于测试环境

我从未见过如此不稳定的测试环境。

关于代码重构

随着项目迭代,没有意义的代码要及时删除或注释,否则几经转手,没有人知道这些代码到底有没有用,反而还要在这些结构上进行新需求迭代,只会越来越乱,开发人员要有及时掏粪坑的决心与勇气(堆成屎山就完了- -!!),接过来的项目如果可复用程度不大,不如重做,当前项目架构不满足新需求时,应考虑及时扩展。

关于产品节奏

产品节奏很迷,一个需求提测后会有接近两周的空档,所以很感谢现在的项目,既让我了解到了一个项目能有多坑,又给我了如此多的时间去发现问题,修复缺陷。

虽然我们公司基本不咋加班,但是这个节奏着实让我有点不太好意思。技术人员当然需要时间去复盘总结,学习新知识,但团队内部其他项目贼忙,对比起来好惭愧。

但是心里面还是有些许动摇,虽然说成长靠自己(现在有时间去学习成长),但我还是想有一个更为优秀的团队以及平台,能够去落地一些事情。而现在团队内部,有极个别成员即使有许多时间,但也不见有何产出,一言难尽,虽然我现在有热情,但是我害怕有一天也会这样,可能就是贱吧。

总结

以上就是一些思考以及吐槽,这两个月成长的太多太多,在上一家公司和一个人负责项目,来这边三个人一起负责一个项目(感觉有资源过剩),遇到了种种问题,有的问题解决了,有的问题人言微轻,影响不大。

也有了 3 点感悟,哈哈。

  1. 办法总比问题多;
  2. 是问题还是绩效取决于自己;
  3. 永远保持好奇心。

一片荒芜。

但大有可为。