| | |
|---|
| | | |
|---|
| | | 尽管我们来自五湖四海，有着各自不同的编码习惯，但现在我们聚集在一起组成了一个团队。为了使团队合作更加流畅，减少沟通成本和内耗，我们需要在以下几个方面达成共识。 |
|---|
| | | |
|---|
| | | ## 1 代码首先是给人读的，其次才是给机器运行 |
|---|
| | | ## 1. 代码首先是给人读的，其次才是给机器运行 |
|---|
| | | |
|---|
| | | 团队开发与个人开发最大的区别在于：你身处一个团队中，大家需要相互配合。因此，**让代码容易阅读是你应尽的责任**。 |
|---|
| | | |
|---|
| | |
|---|
| | | 1. 做无关模块开发时可以快速跳过不相关代码 |
|---|
| | | 2. 做相关模块开发时一眼就能确定要查看的代码 |
|---|
| | | |
|---|
| | | 同时，让实体名词承担功能表述的作用，能让代码维护更依赖阅读而不是记忆，极大减轻记忆负担。 |
|---|
| | | 同时，让实体名词承担功能表述的作用，能让代码维护更依赖阅读而不是记忆，**极大减轻记忆负担** |
|---|
| | | |
|---|
| | | ### 1.2 设计良好的模块与分层结构 |
|---|
| | | |
|---|
| | |
|---|
| | | |
|---|
| | | 这不仅减少了代码冗余，还提高了开发效率和代码质量 |
|---|
| | | |
|---|
| | | ## 2 思考先行，开发随后 |
|---|
| | | ## 2. 思考先行，开发随后 |
|---|
| | | |
|---|
| | | ### 2.1 理解清楚需求再动手 |
|---|
| | | |
|---|
| | | 由于我们的需求文档通常由老板和总监编写，没有专职人员完善需求细节，因此某些需求描述可能比较模糊 |
|---|
| | | 这种情况下，如果对业务理解不深，很容易导致开发的功能与实际需求不一致，最终需要重做 |
|---|
| | | 这种情况下，如果对业务理解不深，很容易导致开发的功能与实际需求不一致，最终导致需要推倒重来 |
|---|
| | | |
|---|
| | | 因此，我们需要在开发过程中不断积累对业务的理解，至少要达到能发现需求歧义的程度 |
|---|
| | | |
|---|
| | | 有歧义是正常的——老板和总监对业务太熟悉了，往往会自然而然地认为某些理解是理所当然的； |
|---|
| | | 而对业务不熟悉的人，从需求文字字面出发，确实可能产生不同理解 |
|---|
| | | 有歧义是正常的，老板和总监对业务太熟悉了，往往会自然而然地认为某些理解是理所当然的 |
|---|
| | | 而对业务不熟悉的人，从需求文字字面出发，从而可能产生不同理解 |
|---|
| | | |
|---|
| | | 发现歧义时，请及时咨询我或旭诚，问清楚具体要求，一定要完全理解需求后再开始开发 |
|---|
| | | |
|---|
| | | ### 2.2 设计清晰方案再动手 |
|---|
| | | |
|---|
| | | 除了业务需求，在开发前我还应该梳理清楚技术形式、模块拆分和实现方式，以最简洁的方案实现需求，切忌盲目开工，为求速度而书写毫无章法的代码 |
|---|
| | | 除了业务需求，在开发前还应该梳理清楚技术形式、模块拆分和实现方式，以最简洁的方案实现需求 |
|---|
| | | 切忌盲目开工，为求速度而书写毫无章法的代码 |
|---|
| | | |
|---|
| | | 如果不重视工程质量，因为前端代码过于灵活，一段时间后代码混乱到无法维护了，就被迫需要重构，我们应该避免这样的事情发生 |
|---|
| | | 如果不重视工程质量，因为前端代码过于灵活，一段时间后代码混乱到无法维护了，就被迫需要重构，我们应该避免这种事情发生 |
|---|
| | | |
|---|
| | | 只关注结果产量而不重视工程质量，这种代码是会被要求返工重写的 |
|---|
| | | 只关注结果产量而不重视工程质量，这种代码在代码审查中一旦发现，就会被要求返工重写 |
|---|
| | | |
|---|
| | | ## 3 用户体验是工作的一部分 |
|---|
| | | ## 3. 用户体验是工作的一部分 |
|---|
| | | |
|---|
| | | 用户体验是我们前端开发者需要主动思考的问题，这是我们工作的重要组成部分 |
|---|
| | | |
|---|
