主要用于在日常的开发工作中，如何快速地编写代码，实现功能。

这里结合自己的经验，开发感受，进行整理输出。

帮助和期望能帮助大家高效高质完成工作任务，节约时间去做自己想做的事情。

1.文档阅读

开发人员自我检查程序流程 - 收集_william_n的博客-CSDN博客

PHP - 代码简写 - 收集/实践_william_n的博客-CSDN博客_php 简写

2.整理输出

前言

有时，我们在接到开发需求的时候，有点无从下手的感觉，但是我们知道，需求必须要做，那么如何开始呢？以及如何保证尽量高效高质地完成任务，减少不必要的时间浪费， 并且能享受高效编程带来的快感呢？

个人的经验如下，但是前提是你已经具有编程需要的基本技能，总不能什么都不会，就想能高效地编程，不过，即使做不到高效编程，也能提高工作效率，减少无用功。

供参考

2.1 首先，需求保证清楚明白

这一点就不用多说了，如果需求都没明白，编码实现都是后话。

所以，尽量非常清楚需求，免得做一些无用功。

当然这个视情况而定，有些情况下，需求也是一点一点加的。

2.2 编码实现环节「并非一直在编码」

1). 开始动手之前，先讨论技术方案，最后确定一种相对较优的，可行的技术方案。

这个过程有可能是跟你的同事，团队成员，技术leader， 甚至就是你自己

这个过程是不能少，要大体上保证技术是可行，至于技术实现细节，可以先跳过，

但是有些技术细节很重要，必须要确认是否可以实现，因为关乎整个技术方案能否实施。

我自己的做法：

在文本编辑器中，有时会在笔记本上用笔，写出来方案的思路，列出一二三四，要尽量很详细。

这个过程可能会迭代几次，具体看实际情况。这个过程对开发人员本身是一件好事，因为能让我们处于思考，实践，优化，验证当中，这是一个正向反馈。但是这个过程需要花费的时间，应该随着我们的经验，技能，知识贮备，而减少才是正确的。

2). 整理出1中的技术方案以及实现思路 

列出实现步骤一二三四

定义方法名，输入输出. 

可能还会定义一些方法内的全局变量，为了便于阅读，

另外，建议，一个方法内不要有太多代码，而且最好是一个功能点一个方法，基本原则：高内聚，低耦合。

可以看到上面的步骤就是拆解，将大的功能/需求拆分一个个小的功能/需求，

其实也是面向过程编程的思想，不要觉得有了面向对象的编程，就认为面向过程的编程思想可以丢弃了。

然后就是具体的每个步骤的实现，一个一个，一点一点实现，遇到问题就专门去查，去解决，

这期间也可以单独测试每个功能点，确保每个功能点，都是如预期的那样。

一直到实现最后一个步骤， 完成所有的步骤，

至此，就实现了整个需求，开始整个过程的自我测试，以及最后的程序检查

https://blog.csdn/william_n/article/details/121642611

3). 上面的过程，不仅仅是完成一个需求那么简单的事情，

最重要的点在于，培养解题思路，锻炼解决问题的能力，当然也会提高自己编码的质量和速度。

这是核心能力/竞争力。

4). 编码过程中，也有一些应该遵循的原则

具体根据不同语言的规范，以及项目规范而定。

但是个人还是想说几句，参见下面文章

开发人员自我检查程序流程 - 收集_william_n的博客-CSDN博客

插入：

切记，要及时提交，不然万一电脑出现问题，代码没有提交推送，又没有备份，就JJ了。

我几天前遇到了，写了一个星期的代码突然因为Mac的磁盘坏掉「这个概率其实很低的，但是还是有概率」无法开机，修复要两天。

最后还是重新写了，花了半天的时间，还好因为上面的步骤，写得比较快。

但还是建议，完成一个小功能，或者一个步骤，就commit一次，推送一次，如果嫌弃太频繁，至少在下班前，提交一次，推送到远程仓库。 

如果发现commit记录太多，可另外解决。

3. 思考

什么时候，都不要忘记思考。

不论干什么，都不要忘记思考，然后思考回顾，从中学习，总结，

从而做优化，争取达到最优解，或者近于当下最优解。

后续补充

...

1. 如果不熟悉业务逻辑以及没有项目文档可供阅读参考，那么熟悉代码就是只能从代码入手。

这里提供一点参考：

    想要快速掌握业务逻辑和代码阅读.
   

    直接找相应的接口，然后开始查看代码，关键从如下方面下手:
    1. 数据库实体表
    2. 数据库表的写入[入口]和读取[出口]

通常业务逻辑必然涉及到实体表的操作，逃不出CRUD，只要弄清楚数据的流转，通常，也弄明白了七七八八，即便有些业务逻辑还不是很清楚，但是功能实现，代码修改都是可以很快实现的。

另外，要灵活使用减枝策略，不符合条件的部分，不是目前关注的条件分支，可以直接忽略，跳过去【甚至直接先删除，世界都变得清净了】，

只关注最核心，密切相关的部分，只要能理出这部分代码大致逻辑即可，剪枝策略能很大程度上帮助我们快速找到问题本质和野心逻辑，然后快速完成需求，至于额外的需求，不是那么紧促的需求，可以另外找时间去研究。

参见文档阅读列表