少走弯路从总结起步

 一、开始和结束的循环

           2021和2022只是度量单位在递进吗？

          每天的86400秒，每年的12个月，总会发生太多的事情。

          不管是以天为单位计算，还是以其他方式度量，生活中少走弯路都是需要总结的，毕竟，总结，才能让人成长。

          在软件设计领域，首先，重重之重就是开发注意事项。不断总结开发经历。

           在项目实施中，公司每个功能上线之前都要测试，在测试环境测试，并且也会在正式环境测试（非公开版），把上线的问题降到最低，发生过这么几件事情，有好几次，我开发的时候没有看到问题，测试测试的时候也没有问题，但是在正式环境测试的时候，我们的头儿一眼就看到问题，很神奇的一件事情，感觉他好像就长了一双挑bug的眼，的确，我们的头儿是一个有十几年工作经验的人，不得不佩服他的眼力劲儿，但是，的确眼力劲儿是常年积累下来的，也许也是一次次的出的问题才会意识到这个地方需要格外注意，但是，既然是特别需要注意的地方，那么在他们心里，肯定有一个总结，就是每次上线前要注意什么，只是岁月积累变成了一种潜意识。

        回顾项目实施历程，记录经验并总结，把它们岁月沉淀的潜意识，总结出来，强制变成自己的意识。让开始与结束形成一个良好的闭合。

 二、逐一检查

    第一：查询的时候注意上下界，这是个经常犯的错误。

    第二：字段为空情况，很多时候我们以为这个字段不可能为空，或者正常数据不会为空，但是要知道，所以的bug都是处在非正常的数据中，把系统搞出问题的数据也肯定不是正常数据。

    第三：插入数据库字段为空情况，一般情况下数据库字段是不能为空的，既然数据库这样设计，那么插入是字段就不能为空。每个对象都要记得设置默认字段。

    第四：字体样式问题，很多时候，开发的人比较注意功能的完整性反而很容易忽视的就是样式问题，所以反而更容易在这个上面栽跟头，虽然一般情况下会有前端来把关。

    第五：多打日志，这个习惯好像到目前还没有很好的适应，但是这也是我下一阶段要十分注意的地方，无论是对异常日志的处理，还是console的日志输出，每次开发都急于完成，日志就编程一个可有可无的东西，而每次都是出了问题才想起来日志的重要性，但是这个时候在写日志就已经晚了，因为无法把出的问题记录下来。这是一个加星的注意事项。

    第六：写代码的风格，平时写代码没有加空格的习惯，每次review代码的时候都会因为这个问题，我们不会因为少加空格就出bug，但是会因为不好的代码而影响发现bug。

    这是一般情况下，不论什么项目都要注意的问题，当然还有一种问题，发生在特定的场合，这种问题，跟编程习惯、思维习惯就有很大的关系了，当然，还跟编程素质有很大的关系。

三、拷贝有问题----对象和对象内容的注意事项

         例如：只需要查询一个分数，但是查询的语句跟之前查询一个对象的完全一样，只是这次我只取里面 的分数，于是我想都没想，直接拷过来代码用，然后判断一下查处的对象是不是为空，之后直接从对象里去分数，这个问题测试的时候是没有问题的，但是上线之后出问题了，问题的原因是分数为null，因为我只判断了对象不能为null，忘记判断对象里的分数，之后头儿看了下我的代码，说了句“从你代码里看出你思路不太清楚啊”，当时听了很难受，首先是因为上线之后出的问题，一般这样的问题会对公司有影响。

       当把代码拷过来改动时，就意味着，很有可能因为少改一些地方而报错，或者是因为依照代码的思路走下去，去修补之前的代码符合现在的需求，而不是从现在的需求出发，去构造一种真正的符合现状的代码。所以，粘贴复制没有问题，但是绝对不能通过修修补补来应付现在的需求。

四、问题，你总没问

         举个例子，产品有这样一个需求，一个数据，要么是一天，要么是若干个月，这就要求一个字段里面要么存一天，要么存几个月，当时我只是反复跟产品确认：天数只会出现一天情况，其他的都是以月为单位的吗？十分确定之后，字段设置的是0代表一天，其他的比如1代表一个月，2代表两个月，后来跟头儿说这件事儿，他的解决方案是这样的：1~100表示天，100以上，比如101，表示1个月，102表示两个月，这样即使以后出现15天的情况，也很好扩展。的确，我在做的时候虽然感觉这样的需求有点怪异（最后这个需求统一改成以天为单位，后话不说），但是我做的只是反复确认需求不会变动，但是，万一呢，虽然我们的需求一直跟着产品经理的要求做，但是没有人保证这个事是一定的，所以，我们何不往前做一步呢，这步并不难，难的是想不到。 

       做事，先动脑，而不是手。先反问，探究清楚，目光才能长远，并深刻理解面向对象的可维护、可复用、可扩展和灵活性好的好处。

五、定义优雅于思维中，设计就有核心

         功能的意义有大有小，优雅的定义功能，优雅的思考拥有优雅的功能。

         认识完成功能的前提，认识功能的意义。分析代码的关系，多关注代码的效率，关注阅读的效率。

         身边有大牛，总爱听他说到“这个功能的设计的特别优雅”，不知道该怎么定义优雅 。

          先将优雅定义于思维，设计没开始就思考：功能来自什么思想，哪里需要优化！！！

          晋级思维来自：哎，渐渐的做多了，发现，不是因为不想重构，不想改进，而是自己跟写代码时的自己是出于一个level的。

          晋级方案：解决这个的办法不是看自己的代码，而是看别人的代码，当然看别人的代码不容易，找一个自己比较熟的功能，并且是一个比较厉害的人写的代码去看（功能熟容易看懂），你会发现你们写的差距，然后只有这个时候，才能激发你去优化你的代码的潜力，你也才会自惭形秽的去修改代码（因为是在不好意思让别人发现这块代码实在无法表述——————）。

六、少走弯路从总结开始

        从总结开始，让自己进步。进步最快的办法是虚心，多反问，虚心请教。

        虚心接受别人的意见，时刻反省一下自己，才会去从不同角度考虑问题 。有太多的发光点需要我去学习， 包括产品、包括测试，他们的意见与想法，都是需要思考的，只有把不同意见听进去的人，才会去思考去判断，才会在成长中少走弯路。

         同样，少走弯路从总结开始。