一个程序员的总结——开发注意事项

    一年到头了，作为本命年的我，今年发生了太多的事情，但是不幸的是，都是好事儿，有点太过得意洋洋了，不过，不管一年顺抑或不顺，都是需要总结的，毕竟，总结，才能让人成长，首先，想注意的事情就是开发注意事项。

    特别想说一件事情，公司每个功能上线之前都要测试，在测试环境测试，并且也会在正式环境测试（非公开版），把上线的问题降到最低，发生过这么几件事情，有好几次，我开发的时候没有看到问题，测试测试的时候也没有问题，但是在正式环境测试的时候，我们的头儿一眼就看到问题，很神奇的一件事情，感觉他好像就长了一双挑bug的眼，的确，我们的头儿是一个有十几年工作经验的人，不得不佩服他的眼力劲儿，但是，的确眼力劲儿是常年积累下来的，也许也是一次次的出的问题才会意识到这个地方需要格外注意，但是，既然是特别需要注意的地方，那么在他们心里，肯定有一个总结，就是每次上线前要注意什么，只是岁月积累变成了一种潜意识，那么，如果是对于我们这群“涉世未深”的菜鸟，该怎么注意呢？只能是学习经验并总结，把它们岁月沉淀的潜意识，总结出来，强制变成自己的意识。

    好了，废话少说，书归正传：

    第一：查询的时候注意上下界，这是个经常犯的错误，但是屡犯不爽，经常出现这种在哪里跌倒就还在那里继续跌倒的情况，这是第一条，已经拒绝在犯。

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

    第三：插入数据库字段为空情况，一般情况下数据库字段是不能为空的，既然数据库这样设计，那么插入是字段就不能为空，因为这个问题，已经让我在线上出国问题，感觉很惨是不是，所以，每个对象都要记得设置默认字段。否则，这很有可能因为你这里的改动，影响到其他功能。

    第四：字体样式问题，很多时候，开发的人比较注意功能的完整性反而很容易忽视的就是样式问题，所以反而更容易在这个上面栽跟头，虽然一般情况下会有前端来把关，但是我们也会经常遇到一些需求对前端要求比较低，不需要前端介入，所以这个时候，就需要注意一些样式问题了，尤其是字体样式更容易被忽略。

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

    第六：写代码的风格，平时写代码没有加空格的习惯，每次头儿给review代码的时候都会因为这个问题提醒我一下，或者他在看我代码的时候就会顺手把看的部分加上空格，当然，我们不会因为少加空格就出bug，但是会因为不好的代码而影响发现bug。

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

    首先，说一件事情，写代码复制粘贴是一种很常见的事情，但是我们究竟应该怎么复制粘贴呢？以前，总是以功能能够运行为主，其实，除了能够运行，还要注意代码中有没有多余的代码，这些代码能不能够影响性能。我是一个比较懒的人，但是也因为这样的懒，犯了不少错误，举个例子，又一次我只需要查询一个金额，但是查询的语句跟之前查询一个对象的完全一样，只是这次我只取里面 的金额，于是我想都没想，直接拷过来代码用，然后判断一下查处的对象是不是为空，之后直接从对象里去金额，这个问题测试的时候是没有问题的，但是上线之后出问题了，问题的原因是金额为null，因为我只判断了对象不能为null，忘记判断对象里的金额，之后头儿看了下我的代码，说了句“从你代码里看出你思路不太清楚啊”，当时听了很难受，首先是因为上线之后出的问题，一般这样的问题会对公司有影响，还有一个原因：这个问题是我犯懒了，如果我当时改动一下之前的代码，只获取金额，以后的问题就没有这么多了，当我把代码拷过来改动时，就意味着，我很有可能因为少改一些地方而报错，或者是因为依照代码的思路走下去，去修补之前的代码符合现在的需求，而不是从现在的需求出发，去构造一种真正的符合现状的代码。所以，粘贴复制没有问题，但是绝对不能通过修修补补来应付现在的需求。

    其次，眼界，眼界这个东西很难说清楚，但是总是隐隐感觉这是一个可以培养的东西，在做这个功能的时候，你的目光能看到多远，举个例子，产品有这样一个需求，一个数据，要么是一天，要么是若干个月，这就要求一个字段里面要么存一天，要么存几个月，当时我只是反复跟产品确认：天数只会出现一天情况，其他的都是以月为单位的吗？十分确定之后，字段设置的是0代表一天，其他的比如1代表一个月，2代表两个月，后来跟头儿说这件事儿，他的解决方案是这样的：1~100表示天，100以上，比如101，表示1个月，102表示两个月，这样即使以后出现15天的情况，也很好扩展。的确，我在做的时候虽然感觉这样的需求有点怪异（最后这个需求统一改成以天为单位，后话不说），但是我做的只是反复确认需求不会变动，但是，万一呢，虽然我们的需求一直跟着产品经理的要求做，但是没有人保证这个事是一定的，所以，我们何不往前做一步呢，这步并不难，难的是想不到。很多时候我都太着急，太过急于求成，忘记了，最省事儿的方法，是省将来的事儿，而不是立刻完成当下的事儿，做事儿之前先动的是脑，而不是手。

   还有，完成功能的前提下，多关注一下代码的效率，包括运行的效率和别人阅读的效率，边上有一个大牛，总爱听他说到“这个功能的设计的特别优雅”，不知道该怎么定义优雅，至少我从没有觉得我写的代码优雅，甚至连看都不想看，包括有时候事儿少的时候也会说看看自己的代码，哪里需要优化，但是，哎，渐渐的做多了，发现，不是因为不想重构，不想改进，而是自己跟写代码时的自己是出于一个level的，解决这个的办法不是看自己的代码，而是看别人的代码，当然看别人的代码不容易，找一个自己比较熟的功能，并且是一个比较厉害的人写的代码去看（功能熟容易看懂），你会发现你们写的差距，然后只有这个时候，才能激发你去优化你的代码的潜力，你也才会自惭形秽的去偷偷修改代码（因为是在不好意思让别人发现这块代码是你写的%>_<%，只能偷偷修改）。

   最后还想说，让自己进步最快的办法是虚心，程序员有一个通病，就是高傲，不愿意承认自己有问题，当然这不是只有程序员才有的问题，各行各业的都有，只是因为程序员的工作性质，别人总要提出各种各样的bug，所以不得不高傲，但是我认为进步，还是需要虚心，虚心接受别人的意见，时刻反省一下自己，才会去从不同角度考虑问题，比你厉害的人不必说，有太多的发光点需要你去学习，但是其他人，包括产品包括测试，他们的意见与想法，都是需要思考的，只有把不同意见听进去的人，才会去思考去判断，才会成长。

   这篇总结从年前写到年后，就先到这儿吧，再继续下去就变成裹脚布了，未完待续、、、、、。。。。