关于代码的组件化，我一直认为都是有必要的。我所坚持该观点主要来自于以下几项。
- 结构最小化
- 维护性
- 扩展性
抽象代码是结构最小化必备的思想。为什么？从编码角度，代码可以分为系统代码和业务代码。首先，系统代码是维护系统逻辑和业务逻辑必要的基石。抽象代码的目的，就是将业务逻辑和系统逻辑拆分，两者不冲突。最简单的方式是，从现有各个语言框架看，抽象思维遍地都是，抽象的另一个目的就是简化逻辑。让逻辑调用更简单。在我看来，抽象代码是相对来说是比较复杂的，首先需要对业务有足够了解，其次是对语言框架的了解。
维护性是从组件内考虑的。组件内的方法逻辑有调整，不会对外部调用者造成影响。在这一部分常犯的错误就是冗余，很多情况下，会出现两个相似的使用场景，但是存在一定的差异，有些做法大多会采用兼容多个场景的方式。
扩展性也是从组件内部考虑的。要从结构最小化来思考，如果某个组件存在兼容两个组件的情况，维护的代码量和拆分组件的代码量哪个更优，如果某个功能点调整，是否需要调整兼容组件的逻辑。这里影响的就是扩展性。
举个简单的前端代码例子，
- 提示框
- 对话框
这两个组件的共性：弹出层，有按钮，有文字内容和标题，有点击事件。差异性：按钮数量不一样。
从抽象代码角度看，结构最小化拆分为两个组件，存在部分相同的代码。达不到完全的最小化
从维护性来看，减少了为了兼容性而编写的代码，比较简洁。
从扩展性来看，对话框展示的内容有可能调整为html节点，提示框不改变，只要调整对话框即可，调整时不需要考虑兼容性。不会有太多冗余。或者出现较多差异性，各自调整各自的，不会影响，也不会出现兼容性错误。多好
由于最近工作中，有编写前端代码的需求，把实际所得的体会简单记录下，脑容量毕竟有限，还是记录下来比较好。在查询资料时，有一篇关于redux的文档，还挺不错的，react的思想还是挺好的，界面和状态分开，各干各的。
