沉淀高效编程的习惯

长久以来一直在思考这个事情：如何能够更快更好的写出优雅高效稳定的代码，一个优秀老练的程序员和新兵会有那些本质的不同，而新兵逐渐成长的路上所积累的东西是什么。
这里首先排除主观能动性部分，从群体角度看，同样基本素质的senior相对junior并不会在写出优秀代码的渴望有更大的优势。

到写这个文章的时候，我想到的答案之一是：洞察背后的道理，找到解决办法，沉淀成习惯。

TheCase
这个是促使我写这个文章的问题，最开始写一个很简单的类是类似这样的：
public Test
{
int a,b,c,d;
};
看起来非常的简洁，正常情况下使用没有问题，但是我已经设计和编程了超过12小时，时间也超过凌晨，尽管我还是杀气十足，不搞定不肯走，但是思维灵敏度和集中力在不知不觉中下降--犯错几率已经大很多。
这个类在10+各地方被使用，于是在一个不起眼的地方，有一个值没有初始化，结果是诡异的问题，进一步消耗了很多的时间来debug，找出问题。
这个问题有很多解决办法，其中比较合适的应该是这个：
struct Test{
public:
    Test(int aa,int bb,int cc, int dd):a(aa),b(bb),c(cc),d(dd){};
public:
    int GetA()const { return a; }
    ...
private:
    int a,b,c,d;
};
这样从设计上就完全避免了忘记赋值的情况，这样的做法可以这样解读：
额外的那些代码，可能有人眼里会认为是“臃肿”的代码部分，在实现者看来是非常值得的，是更好的选择
我们可以这样量化评价原先的代码：
高出错几率：实现上没有错误，但是保护不够的代码，就是有更高的几率出错，这就是一个客观的概率问题，在样本足够多的时候，就是会造成伤害
实现消耗高，效率低：使用这种代码，为了避免出错，写的时候就要更加小心，你的心理负担就重，你会更快的消耗你的精力，就像运行效率低一样，这种代码在使用的时候会消耗你的资源，轻则消耗更多精力，重则导致bug，让成本质变

而且有了我昨天的切肤之痛之后，后面类似的问题会毫不犹豫的耐心的把多余的代码敲完。

TheSum
从上面的一个例子可以看出，在我们正常学习的时候，编程语言和算法书并不会提及，出错几率的设计，实现消耗这样的事情，而类似<the pragmatic programmer><code complete>在提及这样的事情的时候，对于正常人的我们，缺乏足够实践的前提下，并不会深入理解那些隐藏较深的，在编程实践方面的背后的道理。
早起的我绝对会反对上面例子的安全臃肿版，只有在大型项目中，经过长期大量的编程，切肤之痛之后，才会真正意识到后面的做法是真正更加好的。
那么回答最开始的问题，答案之一就可以是：洞察背后的道理，找到解决办法，沉淀成习惯。