最近一直在苦恼，为什么我们的程序存在这么多的问题。抛开用户提出的新需求，抛开用户觉得开始设计的不合理，就单说明确需求与设计的前提下，做出的产品，为什么会有这么多的bug，并且感觉像个无底洞一样，已经上线许久了，还时不时的还会出现一些bug，更让人头疼的是，这些bug，隐藏的很深，犯的错极其低级，而且在这种环境下，已经产生了一大批的数据，抓狂不！！！
（刚写到这里，也想等有时间再写一写，思考思考，产品的一些规则，如何能够被很好的记录下来。）
之前在网上看到了一档节目【程序员吐槽大会】，一名叫水彧的中间件程序员，他说了一段儿对我来说很励志的段子：你看我们代码，虽然近看密密麻麻一片，你站远了看，满屏幕只有两个字-自信！如果有人来质疑我们的代码，我们也有一句统一回复：请先看一下文档；再质疑就是：请仔细看一下文档；如果你还质疑，那就是：请熟读并背诵文档！！！
回过头来，看看我们自己写的代码，往往就是，测试：你这个有问题啊！开发：好的，我先看一下代码；完全没有自信的样子。而我们是如何一步一步写出这么让自己不自信的代码的呢？我想了想，原因其实有很多，下面就列出一些来，好让以后在工作的过程中不断的反思，不断的解决这些问题。
1，基本功差。从一种语言的变量开始、类型转换、运算符、条件语句、循环语句、面向对象特性、线程等等，没有一个良好的掌握，那么产生bug的可能性就极高；
用Java举个例子，比如：定义了Controller、Service，在Service实现类当中，因为调用一个方法时，产生了两个需要的返回值，其中一个return了，而另一个通过全局变量来实现临时存储，然后下一步读取来用，而忽略了Service实例的单一性，导致如果多个请求一起来的时候，这个值可能会取的是另一个值。这种隐患，当开发人员，在开发和做单元测试的时候，往往自己是测不出来的，如果测试人员也没有做出覆盖性测试，好吧，那么这个bug，就会在上线后产生一定的后果。
2，逻辑覆盖不全，比较复杂的业务逻辑下，条件可能会有很多种可能性，各个功能块之间关系也是特别强，互相调用，传参。如果没有采用良好的设计模式，或者清晰的模块划分时，很可能写的逻辑，只覆盖到了某些方面，而另一些方面就会在极端情况下产生bug。
再举个简单点的例子，之前遇到过一个项目，逻辑层次大致是：项目=》任务=》分组=》表单=》字段，那么这些数据在移动端展示的时候，如果配置时，有部分改动，对用户有影响时，需要给出提示，记录上的提示是标识一个红点，到详情页的时候，需要把改动的详细信息都列出来。那么从直观上讲，就需要一层一层的判断，是谁改变了，改变了什么，这些改变是否需要给出提示，改动语言的组织等等。真正写的时候，如果也是平铺直叙的写，会发现有一大堆的逻辑，很容易把自己搞晕，最后出一大堆的bug。可能在写代码之前还画了流程图，呵呵，那也无济于事，后期的维护也很费劲。
3，没有充足的日志。首先说，一个项目，如果没有日志，那肯定是不行的，而有日志，记录的不完整，也是不行的，那记得太多，日志空间占用太大，还要考虑考虑，所以合适程度，需要做好度量。日志，通常分为系统日志和操作日志。系统日志在编写的过程中，尽量采用底层抛出，上层捕捉的机制来实现，而往往有些代码，try{……}catch(){什么都没有}，有意无意的把异常给吃掉了；日志等级划分不明确，调试日志写到了错误日志里面；没有调试日志的开关，写的日志太多；日志写了，不好获取到，或者没有很好的组织，特别像多线程中的日志，看了之后，你都顺不下来是怎么走的流程。
其实有时候，在用户没有提及的情况下，主动写写操作日志也是很必要的，避免出现数据丢失的情况发生，用户找来了，百口难辩，不定哪个用户不小心删了，他说是系统出问题了，捉急不！！！
4，必要的验证放到客户端问题。
我们往往因为项目团队的配置不均衡，会出现一些功能开发转移的现象，比如，有好多个前端，而只有一两个后端，那么后端的工作量就特别大，这时，就会出现一些偷机动作，把一些功能放到前端来实现，比方说，获取数据时，用户信息，往往只有用户id，那用户名，就需要关联来取，而一些通过微服务架构搭建的系统，只能通过接口来获取，那么谁取不是谁呀，客户端来取吧。那么客户端就把数据取到后，又调一次服务，把用户名拼起来，组装好，再显示。当然这个例子，对实现来说，也不是什么问题，关键有些验证性的内容，理应由服务端来实现的，或者说是必须由服务端来实现的，如果放到前端，那就是隐藏的炸弹。比如：非空的检测，重名的检测，服务端如果不做好校验，将来库里面的数据异常了，继而会引起其它的关联性问题。
5，没有测试代码，单元测试太随意。测试代码这个倒不是一定的，因为我们经常会觉得写出这些代码，是需要消耗时间的，特别是需求变化比较大的项目，写好完整的测试，工作真的要翻倍。但如果有可能的话，还是觉得写上为好，有时候，也比较羡慕那种外包项目，把约束写的清清楚楚，明明白白，接口测试运行一下，通过即完成，也是极好的。而单元测试的必要性是相当大的，特别是白盒测。很多时候，我们开发完后，有个理想的输出，得到个理想的输出就算完事儿了，但边界值，覆盖率较低的逻辑分支，却得不到测试，这便是恶梦的星星之火。
5，时间紧任务重。这个问题，真的是不想说，又不能不说。中小型的企业一般都不会对项目管理进行量化分析，那怕有什么CMMI，ISO的认证，实际工作中，所谓的度量分析，往往就是用户要求的时间加权领导拍脑袋的时间，完事儿。没有人才库、没有需求数转换、没有合理的度量分析算法，开干！于是，开发人员先着急忙慌写一堆bug，还觉得美滋滋，一测试，一上线，傻眼了，bug修啊修，改啊改，工期延啊延，超啊超。
当然任务有时候也不能怪领导安排的紧，开发人员的问题在哪儿呢？如果不是着急的写bug，那么就是慢慢的写bug，这完全取决于自身的上进心。
所以我们应该极力做出良好的系统设计，致力写出高质量的逻辑代码，这样才能心安理得的【写一段代码，品一杯茶茗】
