前端工程师最佳实践

# 前端工程师进阶实践 (我在创新中心画界面)

本课程面向需要了解前端工程师实质的产品经理，打算提高自身专业能力的前端工程师，以及可能想转向软件工程师的非专业人员。

罗列一些理想的执行思路以及实际在创新中心做出相应调整后的实践方式。本课程通过讲述日常的前端工程师工作内容，注意事项，给出开发工作的指导方向，剖析开发工作难点以及解决思路。

[TOC]

# 为什么软件结果与初期预计偏差大？

pie
    title 软件偏差原因
    "需求描述不准确" : 10
    "UI设计没有准确表达需求" : 10
    "接口设计不规范" : 10
    "前端开发未严格按设计执行":10
    "测试用例没有覆盖后期变动的需求":10

1
2
3
4
5
6
7
8

整个过程就像 我画你猜

# 为什么开发出来的程序不够灵活？

0.1+0.2===0.3 false
0.1+0.1===0.2 true

1
2

在 javascript 中 0.1+0.2 不等于 0.3 ，但 0.1+0.1 等于 0.2 。这看起来不可思议。但在软件专业人士看来这却是软件基本规律。

原因：软件是基于规则的计算结果。浮点数运算的精度问题导致等式左右的结果并不是严格相等。

解决办法：

IMG20230609-094836724

新问题：

tofixerror

再来一个新办法：

float_compare

# 刻板的程序员需要给出解释

现象：

同样的网站在电脑和在小尺寸的笔记本显示有偏差。

在 chrome 和 360 浏览器效果不一样。

BUG：如果我们不明确声明要适配小尺寸显示器，他们它就会出现无法预料的结果。例如文字过小，文字截断错位。

规律：软件在不明确指定逻辑需求时，它就会表现出你无法理解的结果。

明确声明需求：需要支持 1336*768 分辨率的显示屏效果。当然，如果是大屏或 4K 屏，仍然要做出以上需求声明。

备注：作为非开发人员，他们会认为这是理所当然的，无需单独声明；但作为开发人员，有必要强调补充这部分非功能性的理所当然的需求。

# 如何更高效的完成前端软件研发

软件难于理解，开发过程复杂，如何完成客户满意的前端研发，从以下几个方面分享以下经验：

需求控制与补充
管理进度
进行复杂功能设计
提升沟通质量
提升自我的专业能力
获取非专业技巧

# 一 . 需求控制与补充

# 需求评审会我们需要做什么？

项目经理要求：给出工时评估

研发人员：功能设计是否合理？能否实现？

深入思考：这个功能有没有更好的解决办法？首先是满足用户需要，然后时减少开发量，再次是减轻开发复杂度。

目的不是纠正产品经理，而是给产品经理做产品设计提供额外的上技术方案选项。

补充需求：“优化功能，补充必要的非功能需求。

指出需要补充的技术功能点；文件过大，数据条目过多，执行时间过长等等情况需要附加的额外逻辑功能。

保护程序界面的适配性逻辑包括:动态显示区块宽度，控制区域大小，以及已知异常的处理。

[ ] 罗列非功能性需求清单
[ ] 模块数量，页面数量，功能点数量
[ ] 复杂功能清单
[ ] 浏览器分辨率最大支持和最小支持
[ ] 要求适配的浏览器类型和版本
[ ] 是否做移动端支持
[ ] 明确业务主流程和关键技术瓶颈

# 如何进行技术类项目规模与工时评估？

通常项目截止时间是固定的，评估工时的主要目的是核对需要投入的人员数量。

以时间成本衡量需求复杂度。
计算模块数量，页面数量，关键性技术难点。时间受限的情况下可以先以最省时的方法完成功能，然后在后期重构优化。不要为了重构而重构，在提交测试或新功能开发的同时都可以执行老功能的局部重构。
相比于提供给项目经理的人月工时评估，研发人员可以在需求就绪研发开始前，做一个项目精细的自我人天工时评估。功能点约细，计划制定得越准确，这能够让你尽可能准确的控制自我的研发进展。
提前评估非功能需求

# 二. 研发进度中时间控制与调整

通过一些工作方式对比，综合分析实践方式，找出最适合自己的实践思路。

培养工程师思维，不要把思考重心局限在编程上。以项目规划负责人的立场执行开发，系统性整体协助软件开发。

理解你的项目特性和团队构成，以及项目流程。

# 分析项目的技术类型

# 开源技术选型

需要商业化，对外支撑类项目，尽量选成熟稳定的技术，起码 github 星数不能太低，查看 issue 列表，是否存在关键未关闭的不匹配需求的问题。前瞻类项目，创新试验性项目，可以使用浏览器实验性 API，但仍然要关注适用性，使用环境以及潜在风险。

# 了解你的项目流程

项目过程包括需求收集，原型设计，界面与交互设计，功能设计与实现，测试与 BUG 修复。部署与实施。

多数项目周期小，例如 1~2 月的项目的后台系统，界面设计往往很短，要求不高。需要实际投入界面精修的时间不多。
展示类项目，相对于功能严谨性，更要求界面展示效果。实际投入的界面精修时间会占整体研发周期的较高比例。
功能模块较多的系统，往往需要测试尽早介入，开发过程需要满足大量的测试用例。
数据流程较长，用户流程复杂，涉及多方对接的系统，往往开发时间占比最长的是接口对接，系统联通以及服务器环境，设备环境设置等。

对于以上不同场景的项目过程，需要有针对性的管理好时间投入比例。

# 了解你的团队

目的仍然是明确哪些工作内容可能成为你的研发瓶颈。

界面设计越精细，实际开发过程中消耗在沟通，查漏补缺的时间就越少。

相反，如果界面设计没有考虑到低分辨率可能带来的界面变形，没有准确的标记间距，区块大小，甚至遗失页面或图块，那么开发工程将消耗额外时间开发。

包括产品原型设计文档，UI 设计稿，后台接口文档，测试用例文档都是如此。

了解这些产出物作者的做事风格是否马虎，了解他们当前是否投入足够时间在生产作品，可以提前预估可能的时间风险。

# 尊重你的同事，从而获得尊重

不要抱怨别的同事产出物质量有问题，以身作则，尽量贡献相对高质量的产出物，从而反向推进其他同事给与更多支持。

给别人腾出时间不一定能帮到自己，但能提升自己的专业素养。

最好的方式仍然是建立起相对合理的产出物评审机制，提高产出物质量。

但实际情况往往是各同事疲于应付各类项目导致的投入不足。

# 在立项之初介入项目评估，充分规划需求

不要让别人帮你做项目工时评估，起码，他不会那么细节的考虑每一个实现细节。

# 如何保证按时保质完成软件研发？

定期关注自身的研发进度，调整。

# 三. 功能设计

（系统分析与设计思维，技术选型，梳理用例图，类图，模块划分，数据流程，用户流程）

# 为什么我们需要功能设计？

1.复杂功能：防止进入研发后期才发现设计缺陷需要重新开始。

2.提高系统扩展性：追加的功能如果破坏性强或者扩展性弱，会导致上线后系统不稳定，后期难以追加新功能。

3.防止系统被破坏：一个字段的修改或追加都可能对当前已经存在数据库中的几十万条数据造成影响，甚至导致已有用户无法使用相关功能。

对于现有功能的升级维护，即要保持对旧功能的支持，同时要保证新功能运行有效不破坏旧数据。

# 哪些场景我们不需要功能设计？

1.当前系统不复杂。

2.当前系统不需要增加功能。

3.当前系统上线后不做维护更新。

功能设计的一个好处是防止自己被自己写的代码绊倒。

# 使用 UML 进行功能设计

对于复杂的功能，可以使用时序图，数据流程图，实体关系图，类图，用例图等等进行多剖面的拆分。

以下罗列一些常见 UML 图。

我们不用刻意去绘制这些图，首先，在功能开发之前，脑子里应该要勾勒实体之间的管理，多角色产生的交互，数据流转的过程。

如果是多人协作，绘图的重要性就凸显出来，他能保证开发过程中各个环节的研发能在同一个角度沟通衔接细节。

# 四 . 沟通

（需求沟通，UI 沟通，项目进度沟通，接口约定，BUG 反馈，部署运维沟通，文档记录）

阶段性向产品经理反馈需要的调整，以及实际的研发结果。提前暴露可能出现的功能偏差。

通常，以对方的思维方式给出结论。

# UI 与交互管理

沟通阶段：

1.设计评审：确认是否有遗漏页面，复杂页面多状态下是否需要补充状态界面，。

2.研发中：核对设计稿，确认是否需要依据不同逻辑补充的设计细节。

3.研发结束：邀请 UI 进行页面复核，确认研发结果与设计初衷一致。

专注于 UI 开发有几年经验后，对 UI 间距，布局，区域分配会有一些基本的理解。如果发现设计稿有明显的不足，建议提出自己的理解建议。

# 后端接口协调沟通

1.接口设计：简要介绍接口设计约定。

2.研发中：核对接口文档，阅读接口文档内容参数细节，并要求补充参数说明等。

3.研发结束：单元测试，验证基础数据正常显示并写入，查看验证写入结果是否一致，验证关联数据被正常关联。

# 前端内部代码协调沟通

多人协同开发前端。

1.前端开发分工：设计好前端框架，约定好模块划分，以及公共组件。

2.研发中：建立独立功能进行开发，定时提交，在功能开发完成之前不要合并到公共分支。

3.研发完成：单元测试，核对数据正常写入并显示，确认功能完整性。拉取最新功能分支，合并到当前分支，解决冲突，然后合并到公共分支。对公共部分的修改应做到不影响他人的开发；更新的部分应当通知关联开发的同事。、

# 五. 专业能力

一开始就考虑了绝大多数问题以及应对的技术方案，考虑可能的变动以及可以追加的方案方向或者遇到一个问题引入一个技术方案，在遇到再引入方案，因为前期方案不能改，后面的方案只能补丁式最佳甚至发现无法追加方案需要推倒重来。那种方式更靠谱合理？系统设计与分析的是一种提前规划的思维习惯，在开始实际开发之前，要尽可能多想。考虑共性的部分，考虑变化的部分，考虑系统的扩展性和可维护性。

（UI 理解，代码健壮性，产物管理，兼容性和扩展性，熟练使用工具，定期重构，区分新建项目和维护历史性项目的做事方法）