程序员素养：高效编码秘籍

程序员素养：高效编码秘籍

前言

你还在为任务延期而苦恼吗？还在写一堆自己都看不懂的垃圾代码吗？还在被bug缠身吗？这样的你一看就让人感觉很菜，一起来学习如何高效编码吧，这是进阶成高手的第一步。

高效编码不仅能提升个人的工作效率，还能提高团队的协作效率，最终带来项目的成功。通过掌握一些实用的方法和技巧，我们可以在日常工作中实现高效编码。

1.软件开发流程

软件开发可以细分为多个步骤，作为开发人员，我们需要关注的不仅仅是代码实现这个步骤，需求评审、系统设计、代码实现、维护和支持，这些步骤都需要开发人员深度参与。

本次主要介绍如何高效编码，我们对流程图上的需求分析、系统设计、代码实现进行拆解。

1.1.需求分析

需求分析是指，产品经理从用户/业务的需求出发，通过分析，确定用户/业务的目的和目标，明确需求或问题的最底层逻辑，将用户/业务需求转化为产品需求，输出解决方案。

目标：

• 确定和理解用户的需求和期望。
• 编写需求文档。

关键活动：

1. 需求收集
   • 与客户和利益相关者进行讨论和会议。
   • 使用问卷调查、头脑风暴等方法收集需求。
2. 需求整理和分析
   • 将收集到的需求进行分类和整理。
   • 识别核心需求和优先级。
3. 需求文档编写
   • 撰写需求文档，详细描述功能需求和非功能需求。
   • 包含用户故事、用例和功能描述。
4. 需求评审和确认
   • 组织需求评审会议，与团队成员和利益相关者确认需求。
   • 确保所有人对需求有统一的理解。

高效编码实践：

• 熟悉文档：在需求评审之前提前浏览需求文档，了解需求大致内容。
• 术语统一：确保团队内每个人对一些术语保持相同的理解，这将大大降低沟通成本。
• 明确需求：在编码前确保完全理解需求，避免在开发过程中频繁更改代码。
• 沟通和协作：与需求分析师和客户保持良好的沟通，及时解决疑问。
• 文档化：编写详细的需求文档，为后续开发提供清晰的指导。

1.2.系统设计

系统设计是软件开发过程中的一个关键阶段，其主要目的是定义系统的架构、组件和模块间的交互，确保系统能够满足需求规格说明书（SRS）中定义的所有功能和非功能需求。系统设计阶段为后续的代码实现提供了明确的蓝图和指导。

目标：

• 定义系统的架构和组件。
• 设计系统的整体结构和模块之间的交互。

关键活动：

1. 架构设计
   • 确定系统的整体架构（如微服务、单体应用等）。
   • 选择技术栈和工具（如数据库、缓存、消息队列等）。
2. 模块设计
   • 将系统拆分为独立的模块或服务。
   • 定义模块之间的接口和数据交换方式。
3. 数据库设计
   • 设计数据库模式和表结构。
   • 考虑数据的存储、检索和索引优化。
4. 详细设计
   • 为每个模块编写详细的设计文档，包含数据结构、算法和接口设计。
   • 考虑安全性、扩展性和性能等非功能需求。

高效编码实践：

• **画图：**流程图、模型图、时序图等，通过这些形式能更容易理解和设计系统
• 模块化设计：将系统拆分为独立的模块，提高代码的可维护性和可重用性。
• 接口设计：设计清晰的模块接口，确保模块之间的低耦合。
• 技术选型：选择合适的技术栈，利用成熟的工具和框架提高开发效率。

1.3.代码实现

目标：

• 将设计转换为可执行的代码。

关键活动：

1. 编码
   • 编写代码实现设计文档中定义的功能。
   • 遵循代码规范和最佳实践，确保代码质量。
2. 代码审查（Code Review）
   • 进行代码审查，发现和解决潜在问题。
   • 确保代码的一致性和可维护性。
3. 自测
   • 编写单元测试，确保每个模块的基本功能。
   • 使用测试框架和工具（如JUnit、Mockito等）。
4. 持续集成
   • 使用CI工具（如Jenkins、GitHub Actions等）自动化构建和测试。
   • 集成静态代码分析工具，提前发现代码问题。

高效编码实践：

• 代码规范：遵循团队的代码规范和风格指南，保持代码一致性。
• 重构：定期重构代码，保持代码简洁和可维护。
• 自动化工具：利用CI/CD工具自动化构建、测试和部署流程，提高开发效率。

2.如何写好技术文档

技术文档有助于后续进行高效高质量的代码实现，还能确保开发人员对需求的理解和设计与需求文档保持一致。对于后续其他同事了解需求的实现也有很大帮助。

技术文档的质量能直观地体现出开发人员的职业素养和水平。一份好的技术文档，可以让代码实现变得非常轻松，多花些时间在系统设计上，你的bug率将大幅度降低，编码速度会大幅度提升。

很多程序员都不喜欢写技术文档，但是它又是如此重要，所以我们需要有一些方法和技巧，高效完成一篇高质量的技术文档。

2.1.理解需求

在开始写技术文档之前，我们首先要通过需求评审清楚了解需求的具体内容。尽可能细致地了解需求，有疑问第一时间提出，尽量减少评审结束之后又产生问题。有歧义的地方一定要说清楚，让测试、产品、开发保持一致理解。

在评审时需要先思考一个初步的设计，例如表结构设计、关键接口有哪些、需不需要缓存、整体交互流程等。在评审结束后可以先简单说一下自己实现的思路，和大家做一个一两分钟简短的讨论，以确保后续技术方案的可行性和合理性。

看需求文档主要看一些重点部分，例如需求范围、交互原型图。需求范围会概括出主要的功能点，交互原型图可以看到最终大概想要的效果，从原型图上基本可以看出需要哪些接口。功能详细说明可以在开发时再仔细对照开发，大多是一些校验，也包括一些复杂的逻辑规则。

2.2.定义模板

很多时候打败你的并不是复杂的设计，而是如何开始写。

当你新建一个文档，面对一片空白，不知从何下手的你一定很痛苦。

所以我们需要自己定义一个文档模板，这样不仅能让你的思路更清晰，还能让你写的文档风格统一。

模板定义大同小异，分享下我平常使用的模板：

• 背景
• 目标
• 整体设计（流程图、模型设计等）
• 详细设计（代码实现等）
• 接口设计（列出接口）
• 问题
• 优化方向

整体设计和详细设计一般是篇幅比较重的部分，可以将不同的功能分点描述，让人更容易理解。

2.3.画图

我们在进行系统设计的时候，为了更加具象地呈现系统的轮廓以及各个组件或者系统之间的关系和边界以及工作流程。我们就会画逻辑架构图，模块图、流程图、时序图等等。

在日常开发中，软件设计图是一种非常好的表达方式，尤其在技术评审的时候，一副好的设计图可能比干巴巴的文字更能说明问题。正所谓“一图胜千言”。

4+1模型

4+1模型是一种用于描述和设计软件系统的架构模型，由Philippe Kruchten在1995年提出。该模型通过五种视角（视图）来描述系统的不同方面，帮助架构师、开发人员和其他利益相关者理解和沟通系统的结构和行为。五种视角中的四种是实际的模型视图，第五种视角（+1）是场景视图（用例视图），用于展示系统的行为。

1. **场景视图/用例视图（Use Case View）**展示系统的功能需求和用户如何与系统交互。
2. **逻辑视图（Logical View）**展示系统的主要功能模块和它们之间的关系。
3. **开发视图（Development View）**展示系统的代码结构和模块划分。
4. **进程视图（Process View）**展示系统的动态行为和运行时特性。模型图： 流程图： 时序图：
5. **物理视图（Physical View）**展示系统在物理硬件上的部署情况。部署图。

画图实践

通常来说，我们写的技术文档中不需要包含所有类型的图，不要为了画图而画图，我们画图的初衷是更清晰的整理自己的思路，让他人更容易理解整体的设计。

所以我们的技术文档一般会选择几种关键的图示，基本集中在进程视图中。例如模型图、流程图、时序图。大多数需求通过这三种图就可以描绘出完整的设计思路，如果涉及到多个系统间的调用，还可加入泳道图。

UML图的图形和连线都有各自的含义，我们平常使用时需要注意一些基本的图形表达，例如判断用菱形、流程用方形。但是个人认为遵循一些大家都熟知的规范即可，不要过于纠结一些其他相对冷门的规范。如果是需要发布公开，那么对图的规范质量可能有更加严格的要求，但是我们的文档最主要的目的是更高效的工作配合，只要画出来的图大家都能理解就好。

画图工具

ProcessOn:https://www.processon.com/

Pixso:https://pixso.cn/prototype-design/

2.4.设计

后端文档一般会包括整体设计、详细设计、接口设计等，我们通过从整体到局部的理念来进行设计。

整体设计

首先进行需求流程的梳理，可能包括数据的流转、多系统间的调用等，可以通过画流程图、时序图等方式进行。

详细设计

重点功能设计可以先理清功能点的逻辑，再根据实际情况列出技术选型、代码实现、调用时机等。主要是让人能清楚了解功能点的处理逻辑和实现方式。

接口设计

文档中只需要列出接口名称即可，复杂的接口可特别说明。其他的接口详细信息通过swagger获取，可列出swagger链接。所以后端在开发时应该先定义接口，如果前端有需要同步进行开发，需要先把接口发到测试环境。

3.如何写好代码

当你完成了一份足够详细完整的技术文档之后，写代码就是一种享受。只要技术文档的设计没问题，那么代码实现基本也不会出现什么大问题。

3.1.规范

代码规范

代码规范在软件开发中具有重要作用，可以提高代码的可读性、可靠性、维护性和团队协作效率，是保证高质量软件的基础之一。

我们可以遵循阿里巴巴开发规范，可以在编辑器安装插件，以便更好的遵守代码规范。

分支规范

主要是GIT操作规范，分支命名规范。

feature/xx_gongengn：个人分支

dev：开发分支

alpha：测试分支

hotfix：线上bug处理分支

beta/release：稳定分支/uat环境

master：生产分支/部署分支

代码风格

个人的代码风格保持统一，对自己的要求高一些，至少一眼看去比较整齐，该换行就换行，不要都挤在一起，确保可读性。

3.2.性能

• 禁止在循环内部查库（大批量操作除外）
• 查库时考虑是否命中索引。
• C端接口一定要评估是否需要缓存，流量大的接口尽量不查库。
• 选择合适的数据结构存储数据。

以上是最基本的一些性能要求。除了这些，写代码时我们应该有更多思考，大多数情况下多几次循环或者多创建一些对象并不会影响服务的运行，但是服务器忍了，你自己能忍吗？我们应该追求更高效优雅的代码，在不影响整体开发进度的情况下，我们应该用更合理高效的代码实现功能，不要随意的创建对象和循环，不要让代码做额外的无用功。

3.3.思考

写代码时应该边写边思考，写完一小部分内容时，可以回看一下写的逻辑是否有问题，再看是否有更优写法。将完整的一大块逻辑分成多个小步骤处理，每个小步骤思考后再写，写完再回看，这会大大降低bug率。

3.4.工具

AI

目前市面上各种AI问答软件，都是我们写代码的好帮手。前提是你要描述清楚你的逻辑，你也可以让它给你提供思路。

要注意的是AI提供的回答不一定正确，我们必须加以验证，反复确认逻辑是否正确，代码实现是否合理。

选择一个靠谱的AI问答软件也非常重要，目前我只推荐chatGPT。

编辑器

无论是idea还是vs code，这些代码编辑器其实集成了非常多功能。

• idea安装了代码规范插件后，会给不规范或者不合理的代码画黄色波浪线，通过鼠标悬停即可看到idea给出的提示，甚至可以直接点击idea给出的修改建议，让idea自动帮你修正代码。
• idea还可以连接数据库，一键生成实体类、DAO等。
• 编辑器的快捷键也能大大提升效率，例如idea的封装方法快捷键，只需选中代码块，ctrl+alt+m 即可直接生成方法，并且还可将其他地方相同的代码一起替换。

4.技术之外

扎实的技术能力只是优秀程序员的其中一个特质，除了技术，沟通能力、责任心、团队合作等各方面都需要关注。

4.1.沟通

你讲的话别人听得懂吗？别人讲的话你听懂了吗？

表达能力和理解能力非常重要，在内部沟通时，尽可能用简单直接的方式表达你的观点，如果要描述的事比较复杂，尽量举例说明，或者画图说明，确保你表达的观点清晰，让其他人能清楚理解。复杂的事能当面聊就当面聊，提升沟通效率。

理解别人的观点时，认真听完他人表达的观点，自己可以举例说明，和对方确认是否理解一致。

良好的沟通可以极大提升效率，失败的沟通轻则任务延期，重则代码逻辑错误，甚至可能导致对方生气。

大家沟通时保持心平气和，尽量冷静一些，不要百分百确定自己是对的，也分析一下别人是不是错的。

4.2.责任

需求评审时

需求有不合理的地方，你开口说了吗？

不要只是专注于代码实现，多思考需求的合理性，如果你有自认为更好的见解，一定要提出来。不合理的功能点上线了之后，使用者反馈不好用，然而你只留下了一句，产品说这么做的。

开发完成后

自测了吗？

前端一调接口，500。测试一点页面，500。bug+1，对方心里印象分-1。

需求上线后

有人反馈问题了，你及时响应了吗？

不要害怕问题，要勇于面对问题，评估问题严重性，想办法解决问题。解决后及时反馈。

5.总结

高效编码绝不只是写代码，它体现的是程序员的综合能力。

文档列出的几点都是成为一个高手必备的特质，达成这些之后，你就算不是个高手，看着也像个高手了。