上一篇文章写了微观规范，很多人提出了意见，谢谢大家的回复。
这里回复一下一些疑问：
疑问一：为了速度，进度，很多细节的东西，我们往往都忽略，除非他经常发生，能引起我们的注意
其实，有时候，为了速度，进度，忽略了很多东西，到时是要几倍补偿回来的。
疑问二：扯淡
这个问题不清楚为什么这样说，作者有更好的解决方案吗？
疑问三：就这些内容觉得还谈不上规范，等着看接下来的内容
这也是规范，只不过是比较细方面的。
疑问四：这样重复判断会不会影响执行效率呢？
一般的判断不会给程序造成多大的效率问题，比如判断一个整数a是不是等于3,这完全是不花时间的。又不是循环。
疑问五：这个环境看不到团队工作（team work），只看到一堆疑心病很重的曹操们
这个有可能，但主要看你怎么看问题。我们只是想把错误解决在最小范围内。如果你觉得比较累，不用便是了。
疑问六：我猜lz在日资企业吧
在纯正的中国企业里面。
疑问七：有人说到，如果那个参数不对，又可以不要，那么这个参数一定不重要：
不是这样的。有些参数是很重要的，但传入的参数可能是乱来的，这个时候需要Debug出来，知道是上一个环节出了问题，或者是哪个地方出了问题。
至于Release中，就是把它给处理了，然后返回一个不正常的值，外部就可以知道错误了。
简单来说，断言是为了Debug时用的，Release时要处理掉的。我们没有理由因为一个参数重要就不要Debug它。
说实在的，我个人也不喜欢在微观上面做太多限制，这实在有点限制个人的表达能力和创造性。不过，这是公司的规范，我就拿出来讲一下，不喜欢的否定就是了。我个人喜欢在宏观上，比如层次架构上进行讨论。