这次谈谈纯技术，谈一些编程习惯的事情。

标题是「编程慢习惯」，为什么是「慢习惯」呢？

因为我今天分享的这些习惯在短期之内会增加时间开销，不能立即获得什么收获。但时间久了，至少对我自己是非常有帮助的，为我节省了不少的时间同时在编程能力上也获得了成长。

另外在啰嗦一下，本文并非针对高手的，如果您是高手，可以跳过后面的内容了，接着看下去会耽误到您宝贵的时间。

一、做自己的需求文档

我们在编程时，是否充分的了解了需求，关系到我们后续所开销在项目上的时间。做一个新功能通常不会让我厌倦，但是一次次的修改却会让我身心疲惫。特别是一些本身就时间紧任务重的项目，就意味着需要一整晚又一整晚的加班赶工了。

具体比如说，以下3点会大量增加我们的时间精力投入：

1.需求本身就存在问题，逻辑无法走通，但是这个时候已经写了不少或者和之前的代码冲突到了。

2.部分需求没有表达清楚，沟通后发现对时间的需求误判了，规定时间内完成变得困难

3.写到一半，发现自己思路不对不得不重头开始整理

解决这些的方法每个人都有每个人的选择，我的选择是做一份自己的需求文档。这份文档内容并非是产品经理或者技术主管、需求方所表述的，而是基于我的理解进行的二次整理。

需求文档当中大概有这么几部分的内容：

1.项目的基本概述

项目的简述，这个项目到底在做什么

完成的目标，最终使用人对于使用这个系统的实际需求

预计交期，DEMO演示的日期，交付测试的日期，上线的日期

2.项目的资料

服务器账号和环境

需求文档

开发、生产环境需求

参考的项目或代码

沟通会议记录

3.业务相关

业务核心逻辑，通常还会转换为初步的实现逻辑

执行流程

4.实现

需要做的功能拆解

数据规模

实现方式

对现有系统影响的改动点，如果是全新系统可以忽略

5.其他

测试单元规划

记录完这些内容会花掉不少时间，中间可能还要跟需求方、产品经理进行多次沟通。至于细节到底多细，没有一定的标准，视项目和个人情况而定。

最重要的是做到心中有数，对开发周期的心中有数、对模块大致划分的心中有数，对内部流程的心中有数。

花力气为自己做的需求文档。在完成后，不仅核心要点印象深刻，后期检索也会非常方便，最大限度在已知条件下降低走弯路的概率。从过往经验来说，等到开始开发以后再去查聊天记录，或者是找相关人员询问，就慢的多了。

二、用最笨的方法先去实现

需求文档做好了之后，我就会开始动手写代码，会把需求文档中最核心需要实现的业务逻辑独立分解出来，做一个Demo。按照输入、处理、输出，三个部分进行编写。

基本上不会去写太多的注释。也不会去想模组如何构建以及语法是否美观可读、效率是否是最优。能够得到正确的输出结果为第一位有优先。这样做可以随意修改，而且代码量少，如果实现过程出现问题，很容易就可以定位到原因。

把功能实现以后，先做压力业务逻辑测试，没有问题，再移植到项目中。移植的过程时，本身也是对代码逻辑的Review，思考实现的合理性与是否需要进行一些调整。

这里还有一个重点，通常稍大的项目是无论时间有多紧张，也不能不经思考直接的去把代码直接复制进去。给自己挖坑的事情越少做越好。

三、做压力测试调整结构设计

很多程序员习惯把代码先写完，交付前最后在做性能测试，如果前面的设计就没有考虑到性能问题，就很头大了，代码也没有时间可以重写，就这么将就着先用了。最后一直被性能问题所困扰着。

业务的需求和压力在哪里，产生瓶颈的核心点在哪里。如果你做为程序员也能懂这些，不仅有效避免后续的修改次数，自身价值也会更高。

所以我在DEMO实现后，就会习惯性考虑性能问题。模拟预想中会出现的高并发高流量，自己写一个压力测试模块。如果发现有问题，先修改DEMO中的核心代码及实现方式，调整到自我认为平衡为止。

四、尽可能的砍掉代码冗余

同样的实现，通常有多个方案可以去实现，我在一开始做的时候，用的可能是当时想到的快速实现方案。

当想到更好替代方案时，不太会犹豫，保证安全和性能的前提之下会砍掉原有的代码。用更简单的逻辑的写法替换到冗余的代码。

五、多留日志

就算测试的再完美，上线之后也难免会出问题。这之中，既有可能是本身服务器运维方面的问题，也有可能是BUG。如果能再现的故障还算好查，最怕一些偶然发生，但又无法复现的问题。负责运维和开发的工程师两边都会非常头疼，难以快速解决，还会相互扯皮。

所以我会在代码里尽可能的多留一些日志，并且把这些日志自动进行一些采集。这样，如果有发生问题，第一时间就会有大量的数据可以去查询，对定位问题非常有帮助，不必再一点点的去调试，一个个模块去排除。

同时如果对业务数据的准确性非常敏感的系统，除了一些常规的日志外，我还专门针做一些对业务逻辑校验的日志，定时通过一些自动化的程序去检核这些数字。通过结果反推是否存在一些没有预料到的问题。

六、忘记编代码的过程，以其他人阅读角度进行修改

虽然程序是给计算机去执行，但是无论是业务的扩展还是BUG的修复、性能提升、算法优化，都需要通过人来进行。写好一组代码之后，并不100%保证自己或其他工程师以后完全不会去做维护。

基于这个考虑，在完成基本的程序编写之后，我还会习惯先强迫自己忘记之前写的代码，以第三者的视角再来审视一遍程序：

1、程序逻辑是否清晰易懂

2、代码命名是否规范

3、有没有留下足够的注释线索

4、一个模块中是否过于复杂

5、是否留有进一步改进的余地

是选择前人挖坑后人埋，或是选择前人种树后人乘凉，都看写的人自己的一念之差。但本着负责任的态度，任何情况下都少挖坑为妙。挖了坑，是出来混的，最后总是要还的。

七、记录错误

这一点和项目没有关系，但是和个人成长会有直接关系。就像我们中学时做的错题本一样，从错误中学习是最快的方法。通过错误的记录，发现我们究竟是哪一部分有待提高，是语法不熟悉，是思考不够全面，还是一开始就用错了。有了记录我们就会有可以去发现问题的线索。

依靠这些线索进行思考，主动意识到我们经常出错的部分之后。总可以有针对性的去解决。解决后接下来不定期的去反思，通过反思，将学到的能力内化形成战斗力。

最后总结一下，我今天分享的七个慢习惯：

1、做自己的需求文档，让自己对将要做的内容心中有数，尽量避免理解不到位所付出的成本。

2、用最笨的方法先去实现输入、处理和输出。核心逻辑优先。不去过多考虑其他问题。

3、整合项目前，做压力测试达到一开始的性能需求。而不是全部做完之后再去做性能优化。

4、如果觉得代码不合理，尽量多砍掉不合理的代码进行重构。

5、多留日志让不可预期的问题容易定位、分析、解决。

6、让代码具有可读性，别给自己与别人挖坑。

7、记录经常犯的错误，及时反思总结。

以上是我的心得，欢迎各位同学与我交流。