突然想起以前一个很轴的同事的代码风格，他主要写存储过程，而且他是有意的与代码分开，因为他不太关注代码。他写一个存储过程会在前面加下一大堆验证，验证输入是否正常，验证查询的表里面是否有数据，验证关联的表里面是否有数据，等等，不夸张的所，大部分都是验证代码。而且还拿“任何数据都是不可信的”这句话来做为他的标准（我也不知道这句话的出处，或者是他没有多思考使用场情）。
然后我又回到存储过程的问题，工作3年内我一直接受一个思想“多用存储过程，性能好，方便修改”。工作3年以上我又接受一个思想“少有存储过程，因为维护杂复，不便用修改”。为什么会两个如此大的差别，不仅仅是这个思想上的问题，我发现很多思想可能最近最平常的同事之间会有完全想反的思想，工作3年以内，写大最的sql语句（也是过程里面的），很多人是觉得越写得长，越漂亮。if-else加begin,end，分行非常频繁。而3年以后我不这么认为了，可能还是有很多人不会改变。（还记得以前有个面试官知道我平时写sql较多后，居然问我写得最长的存储过程有多长？我说越短越好，他的意思是越长越牛逼），我认为当然是越精练越好，一个是语句的精练，一个是风格。我就不明白一个if return为什么非要 if begin return end.加上这两多了两行代码，而且也不比if return 更清析啊。很多时间c#代码里我也写得简练，一些简单的判断我甚至放大一行里面，完全不影响阅读，反而是在很长的代码中一层层加上括号让我更费时间（这里会有人反对了，我不是绝对的啊，我只是很少部分超简短代码才这样写）。再比如“建外键-与不建外键”（当然这个是要看具体的项目情况，所以不能轴。），比如“炫耀-可怜”，“长线-短线（股市）”，“吵架打架的输-赢”，“争论的输-赢”等等，怎么有一种见山是山，见山不是山，见山还是山的感觉呢？就像以前一个论坛中对摄影技术的一段回复。有一爱好者问：怎么才能拍出好的照片? 一大牛回答：到风景美的地方拍照。（当然这个是风景论坛版块，所以说的风景，当然如果是人像版块是不是就是去拍美女）。这人就是最朴实的方式，的确当时间长了，对一些东西有了更多的思起可能答案就完全不是之前的一些认识了。可能好多人认为要好的器材，要好的后期等等。其实到最好发现还是最本质的东西，当然拍照就是拍的主体牛逼。后期也是一样的道理，看照片多了可能就不喜欢ps这些东西了，如果你天天看到美图后的照片，最后发现还是直接拍下来的好看。大学时我几乎迷恋上ps，花了很多时间在这个上面，现在我基本上不用ps。而且我平时保存照片也留原始照片，因为我感觉我以后慢慢回看自己和家人的过去时，还是这种原片有感觉，当然也不用花时间去处理。
像代码验证这种，应该分好层，哪里用哪些验证，或者哪些验证不要。比如过程里面加这么多记录是否存在。这种我宁愿报一次错也不愿这样。而且过程与代码是完全耦合的，存储过程不属于一个完整的层面，代码里面传哪些参数，过程收哪些参数，而且过程处理的任务是什么，这些是一对一的（当然有些可以复用的，但是也不完全属于接口形式，也认为是耦合的）。当代码调用这个过程时，必定是要处理这些数据或者查询，为什么会存在没有的情况？有人答曰：任何数据是不可信的，有人答曰：管理人员在后台修改，删掉了。那么我请问：管理人员多吗？他们改的时间多吗？他们在什么时间修改？，有人答曰：存在，有我们就必须做。对这句语是对的，比如一个问题很少发生，但是要发生，那么我们就得做好发生后的处理。但是这个管理人员这种发现是我们能通过管理方式处理的啊。角色的管理，操作时间的管理，以后报错方式的处理都可以把这种黑天鹅事件处理掉了(当然这里有些是可以预料到的情况，也有不可预料的情况。本来黑天鹅事件表示不可预料的小概率，影响较大的事件，最近出现一个灰犀牛事件表示可以预料大概率，影响较大的事件)，为什么我们要编一大堆代码，一大堆分支，增加了设计的复杂度，增加了代码量，增加了测试的用例数（这里要说明一下，分支的增加可能用例是成倍成几何级的增加），而且会有无数次的空验证（可能验证1万次才出现1次，不夸张的说，不只1万次，可能几年才会出现一次刚才说的情况），在性能上也是一种损失。
其实上面一段又说回去了，我本不想讨论代码的问题。我通过对代码的理解，一些规则的理解回到生活上面，生活才是我们的主旋律。生活中我们也应该多看看反面，说不定反面就是真理。经常赢的人不防输一输，左右脚穿鞋不防换过来穿一穿，一直向前走的不防回头看看......
配图来原网络，如有侵权请联系我处理
后记，根据前面我说的东西，可能说明我今天的思想也可能完全有问题，明天我的想法有可能又和今天完全相反了。