让程序员去测自己项目的bug是不太靠谱的，毕竟这些bug就是他们写的，这些bug就相当于他们的盲区

根据书的结构思考模块的设计

之前看了阿里p8的指导p6如何晋升到p7。p6之前自己晋升失败了，觉得应该学习node，拓宽一下后端，几个p8的说：那你就更偏了。

p8的谈到了书需要标题，需要章节，章节又需要小章节。我认为这是核心，每一个内容都应该简化成一个简单的标题去概述。多个小标题也合成一个大章节。

我认为这也是在代码层面设计模块时的核心。一个模块需要完成什么功能，它将分为哪些子功能，每一个子功能又该如何拆分。

具体实现时，一个函数的命名如何诠释它的功能，如果这个函数写完后，发现无法为它取一个可以语义化的名字，那可能是这个函数什么功能都做，名字也不知道取啥了，就用个handle做前缀了。

就像一本书的一部分内容写完了，作者想取个标题，发现根本无法取，因为文章内东说一些，西说一些。

那如果作者在写书前，就认真思考过这本书的核心是什么，又基于此分成了几个目录，又思考每个目录的内容是要说明什么，基于此又分出了章节。之后为每个章节去写内容时，就更容易不跑题了。

如果设计模块时，按照这种方式来，可能就离可扩展，可维护，可读性更近了。
#每天一个知识点#