前端开发胡扯

前端开发胡扯

js嘛入门确实容易。一个记事本编辑、浏览器查看就OK。

不定期更新。完全想到啥说啥！欢迎指教！

流程

只是项目开发流程！！！毕竟眼界和格局限制了自我的想象力。

产品方案 > 需求&设计 > 需求讨论（开发、测试 跟进和评估 可行性、时间周期、成本等）> 相关开发组开发 & 测试用例（包括部分测试脚本等）> 测试（开发自测、单元测试、SIT 集成测试、UAT 产品&设计等验收测试）> 一键部署 > 后续迭代。

产品方案怎么落地不太懂。

产品

一个想法、服务、功能点

• 比如 营销活动、会员服务等内部产品一般 涉及的 利益方比较少；沟通和实施起来比较容易！
• 全网积分兑换、乘车码 等涉及到跨组织的就比较难协调各方利益。

产品可行性。

• 是否合规、当前技术是否可行（比如目前大热的AI智能都难以达到我们的期望）等。
• 根据可行性考虑是否需要 调整 和 分拆 可实施的阶段性产品。

产品方案。

• 不同可行性方案间成本和收益的评估和选择；当然想大厂也可以多团队、多方案内部竞争。

注：产品方案一般还只是一个大概的、各方负责人确认的可执行的实施方案。后续还需要各方就达成的方案协调推进、各司其职。（后面只谈开发方相关的一些个人想法；毕竟财务、市场等其他方的工作流程不懂）

需求

需求 就是以书面的形式 尽量具体的把可执行的产品方案 告诉团队内 各成员。以便一线员工可以有效的沟通和协调去推进方案的实施和落地。所以没有需求是肯定没法动工的。就算是简单的产品方案，非 小创团队（注：小创团队，非公司！！！）最好还是要需求文档；避免频繁的更改、推诿。徒增内部的沟通成本和返工成本！

• 版本迭代：大版本、长周期的需求 可以分拆；通过快速迭代，可以减少风险、根据反馈调整后续需求，提升用户体验。
• 需求尽量具体、考虑边界情况。比如用户系统：用户忘记密码、忘记账号的业务流程；各种提示语等。

需求预沟通

• 需求 发送 设计、开发、测试、运营等项目开发相关方负责人（群发也行；提前了解一下，做个心理准备）
• 原型设计、定稿（具体的高保真设计图可以晚一些）。开发方案、测试用例等。
• 充分沟通、调整之后 出需求稿、定排期。

需求沟通：

• 产品、开发、测试、运营 相关方通过短会最终确认一下 排期、版本功能点。

准备下一个 产品方案的需求文档！

设计

需求排期后根据设计终稿 尽快出 高保真图。避免影响前端UI开发。

终稿交付就可以投入到下一个需求的设计中去了！

开发层面

• 可扩展和配置化、多技术栈支持！
• 单开项目维护UI的开发。各项目间通过版本控制。基础组件尽量维持稳定。
• 可采用 配置文件（vari）、基础样式（base 无类、纯dom标准化浏览器 样式和common 项目基础样式）、组件文件（component、page）等 样式文件维护。这样方便 zepto、vue、react等技术栈共用样式。具体样式脚本 less、sass、stylus等都可以！
• 组件内的变量 尽量继承（默认取）配置值。方便在各组件中修改默认值，而不是直接联动。

UI 组件化

• ui分基础控件和业务组件。

基础控件 应该是无关业务的。任何公司团队都可以使用，比如boostrap。这一类的通用UI控件在PC、特别是CMS后台管理平台是非常好用的（核心关注点在功能实现上）。而移动端很少有通用型的UI控件流行，公司层面不希望千篇一律、同时移动布局相对简洁。所以基础的通用UI控件目前主要针对公司内各团队使用，避免一个APP（公司）不同业务团队的产品五颜六色、重复开发等。

特殊 定制的 UI 控件可以 在项目中新增配置 文件覆盖（较多时、当然也可以更新到基础控件中去）或者项目代码中覆盖（较少时）

业务组件 和产品需求相关。随着产品迭代周期变化；抽离出来是方便各页面共用时避免重复开发。

具体可以 参考element ui 等实现方案！

字和颜色

• 字体问题不谈（需要单独引入字体文件，用户手机定制主题字体问题在安卓机比较多）
• 子高 问题不谈 （不同字体的子高不一样）

只谈 行高、行间距、字号（字体大小）

所以设计稿中尽量 行高、行间距、字号。

• 字号越少越好维护和管理。方便配置管理！ 切换夜间模式或者不同主题色方面比较方便。
• 颜色 同上

备注

以上字号和颜色 尽量少的建议 主要是针对 基础UI和业务组件UI。特殊活动页或者定制（节日）啥的想怎么炫酷和脑洞都行。只要你们开心就行。

图标

• 图标 按业务或者尺寸 分类都行。
• 通过工具生成雪碧图。
• 大量使用也可以 维护一份iconfont 图标库（设计维护）
• 基础公用的icon 尽量单色。

边界

• 设计图多考虑一下边界情况的展示。

没有结果展示、多（少）于设计个数、超出（少于）设计行数 等！

开发

都说IT码农、搬砖工。说明日常的业务开发确实不难。毕竟产品逻辑 需求都已经帮忙写的很清楚了;开发只是通过代码去实现产品逻辑而已。难在架构，但没有大的业务量 往往谈不上架构。所以大多数开发更多的问题在于规范和开发环境。

开发规范

• 千人千面。GitHub上也有很多大公司开源的推荐规范
• 建议：借鉴他人好的规范，慢慢形成自己团队的开发规范。
• 规范维护：采用 eslint。

支持通用的规范配置。

个性化的内部规范可以在GitHub上新建一个项目；去维护自己的规范插件。

通过打包脚本控制规范的执行。不符合规范的代码不容许打包编译！

小部分没法插件自定义的规范可以在代码走查或者AB角中审核！

开发文档

• 最好通过测试脚本和规范的代码维护。核心代码还是维护一下文档比较好。或者通过工具生成；避免更新不及时造成的沟通问题！
• 业务代码 文档还是算了吧。可能业务更新的，文档或者注释没更新啥的 反而造成不必要的麻烦！（只能第一次开发时有空多写点注释！）或者业务代码要求一般代码一半注释吧！反正业务文档是有点难以维护。所以开发交接他人的业务代码一般更愿意重写！

代码结构

• 通过抽离一些基础服务、共用层 简化日常开发；更好的聚焦在业务代码实现上！
• 总的来说就是 确保项目搭建好之后，日常开发只需要关心自己的业务逻辑，其他的功能 都通过标准化的 API 输出给 各页面调用。 无需关心内部封装实现、依赖、配置等；只关心入参出参 的黑盒子！
• 前端来说可以 抽离 客户端交互、通用的ajax封装、和其他业务基础服务。

核心的共用层代码最好 有自动化测试 代码。保证核心代码质量，同时也方便升级和维护。对外输出或者多团队共用的最好提供开发文档（建议通过工具直接输出）。

部署一个测试页面也是 有必要的。毕竟前端浏览器、手机、系统平台兼容性问题还是挺多的。而不是等到具体业务使用时发现 核心代码的兼容性问题。

• 后端 基础的路由层、业务层、数据层。具体开发同样只需要 关心 具体接口的 业务实现。

路由层标准化 接口的入参、出参和基本的校验。

后台 相对来说 没有复杂的兼容性环境。核心代码的自动化脚本更好维护。

• 统一参数格式。

参数传递方面我个人偏爱对象单一参数。node 的(err,data)也不错。共用层面的代码 固定形式的参数 最好形成统一。具体什么格式都可以吧；只要避免像业务代码那样千人千面的传参格式就好！

• 统一状态码。

统一 成功回调 （100）;参数层面错误（1xx）;数据库层面错误（3xx）、业务层面错误（4xx）等状态码的配置。最好通过状态类的方法调用，避免人为设置错误的维护问题！

联调

• 开发中分 客户端、后台、前端等 是为了大家专注在最擅长的地方协调分工高效的完成项目！本质上联调就是调用一个API；和调用自己的基础服务没啥区别，只是跨平台导致的环境问题更多一些！
• mook阶段各平台 同步开发，可以通过mook 数据确保基本逻辑。联调阶段最好还是有 和测试、生产相近的 开发环境。
• 通过 统一开发平台 客户端可以随时更新 开发调试包；前端、后台可以随时 打包部署 到开发环境。尽量把更多的问题在开发环境中发现和解决！

代码管理

• git版本管理这没啥说的，看看第一大同志社区github就足够说明了。
• 开发联调完，提测到测试环境 就要准备 下一个迭代版本的需求开发中去了。所以这时候打版本分支并行开发。等发布生产之后 再合并到主干中来。至于生产之后的bug可以通过生产的tag代码紧急修复，不急的小bug可以在下个版本中更新上去！

测试

测试、开发的合理比例是多少不是很清楚。但测试是确保代码没bug的最后一关。开发容易顺着产品逻辑去实现；忽略了用户的各种逆操作导致的bug。对于生产上的日常bug，我个人认为测试应该负主要责任。

测试的工作同样也是在需求沟通会之后就开始针对每个版本功能点写测试用例。 尽可能的覆盖不同的操作流程。

版本问题

• 测试包的部署 和开发环境一样；通过一个统一的开发平台打包部署。只是权限在测试，同时对每个测试包 生成一个tag。
• 测试环境非严重影响系统运行的bug尽量不要频繁的发包，有bug先通过开发平台 提给对应的开发 在开发环境中解决。一般附上 复现流程、场景。等bug集中解决或者确认 修复之后再 通过 打包部署复测一下！
• sit测试之后，可以让产品方进行uat测试。都测试验收 之后就可以通过最新的测试tag包 生成一个生产包。
• 规范版本流程 和开发的规范 一样；都是为了日常核心的工作只需 专注在版本的功能点上。 而不是浪费在频繁变更、环境不可控等人为导致的故障排查上。保证测试环境 准生产环境的稳定性都不为过。

运营

• 产品数据、生态的维护。生产稳定的保证。

cms

• 作为平台的数据来源，维度越丰富越好，校验越严越好。
• 再保留原始录入的情况下，有些可以预处理的数据尽量也在cms中解决。避免在用户使用的 实时处理；提升用户体验！
• cms相对于外部用户系统来说性能上要求没那么高。建议采用node；

一方面可以直接让前端开发，这样可以缓解大部分公司前端人员配置紧缺的问题（虽然客户端一般也少，不过对于大多数的混合开发的APP来说，客户端只是一个可以定制功能的纯容器；相对来说工作量没那多大）；

另一方面在内部积累一定开发经验的情况下，后续可以把node投入到营销活动、页面直出、中间服务等开发中！

发布

• 日常的版本发布，我认为只需要提交一下系统平台；都运营那边就可以自动化部署。
• 非常规的可能需要提供一下其他的配置、依赖等。
• 同 开发、测试一样。尽量自动化、规范化，毕竟脚本比人更稳定、可靠！更多的去完善脚本、数据收集、统计、系统预警等。

参考