自动生成代码

——读MCD前言

    其实我想写关于宏的东西，毕竟宏也是自动生成你定制的代码，如果你对宏的理解足够深入的话，但是我却觉得这个东西没有必要，毕竟这是很基础的东西，你可能天天都在用他而不觉得有什么。
    但是，前言还是给了我唠叨这个东西的勇气。
    本书对软件设计师展示的C++，宛如一种新语言。
    记得有些时候，我们总以代码行数论英雄，随着时间的推逝和经验的增加，我们知道有的时候代码行数不能说明一切问题，一个好的设计师要比一个代码员强不少。但是这对我的影响只是比再跟人比代码行了，内心里却还是没有弄明白一个设计师如何展示自己的魅力。
    而在使用Andrei的思想编程的时候，我似乎对这一点理解有了实质的进步。
    定义一个宏远远不是写下一个#define就完事了的，你有没有考虑到对参数合法性验证和未来的复用以及复用的容易程度。你有没有考虑过参数检查的时候编译器给出的信息是否足够明确。
    对于类似代码而言，你是否仅仅是强制自己不使用ctrl-c加ctrl-v就以为就安全了，事实上，有可能不使用的情况下你劳累了自己还是埋下了bug的“祸根”。是的，用模板是一个不错的选择，但是你有没有编写模板前用心设计呢?你是否认为编写模板就是把不同的地方做成帽子然后给其他模块引入一个“带帽子的新朋友”呢？
    我的经验是用模板易，用好模板不易，写模板易，设计模板难。
    事情是发生在对一个项目的修改过程中，因为某种原因，要对30多个类似方法修改为异步模式（我承认，在这30多个方法的开发之初我们就犯下了错误，那个时候就该用模板），我直接就想到了模板，然后一个多小时，一切搞定，但是我马上发现面对未来可能的变更，我仍需要每次做或大或小的修改，于是我决定重新设计这部分。
    还是用了一个小时的编码时间，但是我却花了一个上午的时间分析这个结构，考虑对可能的修改方式的应对。
    我不是一个设计者，所以这个过程中花在设计上的时间完全可以解释为我没有经验对时间的浪费，但是我愿意跟你分享这两次编码是的感觉。
    第一次的时候我总借助编译器检查是否有语法错误，也就是说我关心细节。第二次我朝着自己的方向做，从为考虑过编译器的反应，因为我要实现的是一个预定的结构。
    在很干净的设计中仍然会发生像雪崩一样不相干的细节，又何况没有良好设计的东西呢。我的重视我的设计了。