买股票有两种方式,一种叫自顶向下,一种叫自底向上。写code也有这两种方式。我们先讲买股票,再讲写code。

自顶向下,也就是从宏观到微观。从最大的到最小的。比如说我先考虑一下国际局势,俄罗斯到底要不要和乌克兰开打,如果开打了,对于哪些国家是有利的,对于哪些国家是无利的。反之亦然。

这里我假设对美国有利,对中国无利。那么显然我应该选择美国的股票买入,放弃买入A股的想法。

然后我再考虑一个国家内部的局势,新冠疫情造成的影响会怎么样,和中国的外交政策会怎么样,美国内部会不会出现种族问题加剧的情况,对总统的支持率会怎么样,联邦储备局会不会加息,加息对市场的影响几何。从而得出结论,现在美国的股票里面,哪些赛道会有利,哪些赛道会不利。

然后我就剔除那些不利的赛道,只选择那些有利的赛道。然后我再看每一个赛道里面的个股,分析比较哪些股票值得买,哪些不值得。只有到了这一步,才是微观层面的公司的基本面分析。

自底向上,也就是反过来,从微观到宏观,从最小的到最大的。

比如我先根据我的能力圈选择一些我认为可以买的股票。比如我只懂科技,那么我就先根据公司的基本面,选择一些科技股。然后我再分析我买的这些科技股的赛道怎么样,从而剔除一些个股,然后再分析剩下的科技股会不会受到上面描述的美国国内的各种因素的影响,然后再剔除一些个股,最后再分析国际局势,再剔除一些个股。

真正的价值投资,永远都是自底向上而不是自顶向下。同样的,真正的写code高手,也都是自底向上的写code而不是自顶向下的写code。

这是因为,我们的分析,大都是要预测未来,而分析大的问题,比分析小的问题要难的多,不确定性要大的多。越是宏观经济,分析的准确度和需要的专业水准就越是要高,很难分析对。而基本面的分析是相对比较确定性的。

分析的过程无非是剔除的过程,可以归纳为一棵决策树。那么,在决策树的开头几个分叉,你愿意用一个确定性不好的指标来做决策,还是愿意用一个确定性更好的指标来做决策呢。决策树的前面几个分叉意义重大,显然只有在一开始就用确定性最高的指标,才能在一开始就尽可能多的剔除掉不需要的分支。这样才能避免走错。

况且,有时候宏观的情况和微观的情况未必有什么必然的联系。美股历史上已经有过好几次,加息只暂时打压了股价一小会儿,然后股价就大幅上升的例子。所以回答加息对股价的影响很难,说(测)不准,但回答基本面有没有变化会相对容易。

因此自底向上有时候可能到第一个层次就足够了,分析下基本面就足够了,因为已经足够能区分出要买的股票了,再往上的分析,很难可以有一个确定的回答。

这样,自底向上就比自顶向下更加的快速,简洁,高效。

对于写code,自顶向下的写code就是我先把整个项目的框架建好,然后开始写一个service,然后再往service里面填肉进去,写一些业务逻辑,然后在业务逻辑里面再写访问数据库的代码和一些工具代码。

但是这样的写法马上就有一个问题,你写的东西都是虚的东西,不确定性很大。因为上面几层写的都是框架类的code,实际起作用的code得到很下面的层次才能写,所以上面几层写出来的code是没有办法确定以后就是会按这样的形态跑的,万一写到了很下面的层次,发现很上面的层次的写法或者想法错了,那么就只能从上到下全部推倒重来。

依赖需要反转。

要先写没有依赖的东西,如果A依赖B,那么先写B而不是先写A,会好得多。因为写A的时候不知道B会长啥样,如果B写错了那么A也得跟着推翻。但是如果先写B,那么写完了B就能用B的样子去定义A长啥样,如果B写错了,那么A还没写,也只是推翻B而已。

如果整个代码层次结构是一棵树,那么就是从树的叶子开始写。或者也可以用拓扑排序来比喻这个过程。

这就是敏捷开发的全部奥义。从叶子开始,层层往上,用下层的确定性去压缩上层的不确定性的范围,用已经写好的已经有具体形态的下层来影响上层的不确定的形态让其变的更为确定。

那么树的叶子都是些什么东西呢。非常简单,一些Util类。

就像造房子一样,房子的外形内部的结构可能千差万别,但是它的地基其实就那些东西,差别不会太大。造房子一般都从地基开始。

比如我判断这个项目需要数据库,这个项目需要日期处理,这个项目需要字符串处理,这个项目需要记log。那么这些Util马上就可以开始写了,我甚至都不需要知道这个项目的具体业务细节是什么。

等我有了这些util,那么接下来我就要想,我能把手上的模块去组合一下,加点新逻辑,能组合出什么样的上层模块呢,组合出的上层模块是不是能一步步逼近我们要的业务目标呢。

比如我有了数据库Util,那么我接下来就可以考虑怎么设计数据库的ORM,只有到了此时我才需要知道一些业务的细节,只有到了此时。注意这里的关键在于,我采用自下而上的方式,我只有到了必要的时候才会去探究对应的业务细节,因此我有效的将对于业务的需求defer到了真正需要它的时候。而如果是自上而下,那么我无时无刻都必须要将所有业务的所有细节全部装在脑子里,一开始就得全部盘算好,这显然超出了人类的脑力。

所以写code一定是优先选择归纳组合,而不是分析拆分。

注意这里说的写code,是指的真正开始写code。当然在写code之前,还需要有一个项目拆解估算进度的过程,所以在写code之前的分析拆分,其实也是少不了的。

上一篇 下一篇