3. 软件架构设计

本文最初作为知乎专栏的README，当时的构思是这样的：:

前几天发现知乎可以写专栏了，抱着试试看看的心思申请了一下。现在专栏开通了，我的
感想是：又多一个累赘……

所以我就构思一下我可以在这里写什么。作为方向性的构思，我先想到如下几条：

1. 必须写我非常熟悉的，这样我可以少动点脑筋，随口就来。

2. 因为我是做这一行的，有的是人想探我的底线。所以，这里肯定不会碰我工作有关的方
   向。读者也请不要和我讨论和架构选择相关的问题。这好比打牌，我可以告诉你牌是怎
   么打的，但你不要跑过来看我的底牌

3. 目标读者。我考虑的目标读者是软件相关领域的从业人员和在校学生。特别是后者。笔
   者读书时的理想一直是当老师，这也算是过个干瘾。另外，自己写软件写了二十多年了
   ，从对软件一无所知到现在也叫有几个成功产品经验了，深感我们国家软件教育之落后
   。这句话不是说要崇洋媚外。笔者职业生涯中，团队中一直不乏来自不同国家的工程师
   ，我们的软件学生确实在基础训练上不如别人。笔者这样说，不是说自己就可以改变什
   么，而是说明，这个Gap是存在的，既然如此，这个事情就可以做。至于做的意义——意
   义这种东西，那是哲学家的问题，我不讨论。

然后就是写作思路，我的想法是先定软件构架的概念——不是学术的那种概念，而是和读者
对齐软件构架是什么这个问题。是为了理解上的对齐，而不是严谨的范围区分，这两者的
区别是什么，读者很快可以看到。然后我会先介绍开发的一些基本的技能，比如怎么做单
元测试，怎么做数据结构定义等。这些知识看来简单，实际上很多开发者都学错了，在这
种问题上有错误的理解，后面我们谈什么都没有用，之后我们才会看是谈构架设计上的各
种考量。

基本上我会想到哪里写到哪里，根据读者的讨论也会走到不同的方向，欢迎读者一起讨论
。

最后，笔者是过来讨论问题的，读者来讨论，无论表达什么观点我都非常感激，但不要指
望仅过来装逼：）。装逼是一件快乐的事，但失去了要做的事情本身，仅剩下装，这个装
起来实在很丑。所以，我们要虚心实腹地“顺便装”，不要为装而装，那是很丑的。

对于软件工程师来说，什么意见会造成Patch的生成，什么意见完全是无效代码，这个其实
是很清楚的。对于无效代码，如果是无关紧要的tag我不管，但对那些我看不顺眼，解释又
会浪费逻辑空间的，我不会跟你废话，我会直接删除，所以，Please，装逼可以，请用干
货装。也许你会说，“难道你就可以肯定你是对的吗？难道你不应该谦虚一点吗？ ”，你说
得对，我在这个问题上，我就是武断的。这正是软件和自然语言的讨论不同的地方。软件
每个表述，某种程度上，都是单一结果的，每行代码改进去，我们都预期唯一的结果（唯
一的含义可以斟酌，但方向是这个方向）。软件工程师是最在乎“断”的人之一了。对的判
断，和错的判断，对软件工程师来说都是“有效的”，无用的判断，才是无效的。因为软件
的成本都来自逻辑量（代码量），if(a&b&c&(d|e|f))这个判断如果写反了，前面加一个！
就解决问题了，但如果这个判断整个写乱了，这个代码就彻底没有用了。


我说的这个“有效（对/错）/无效”的名称空间就好像老子写《道德经》前面的道可道非常
道，名可名非常名一样，是全文的根本。后面读者们应该可以看到，我的所有表述，其实
都是对这个空间定义的证明。

Contents: