这是我参与「第四届青训营 」笔记创作活动的第25天

文中截图多来源于字节跳动夏令营讲座课件与学习资料，若有侵权请联系删除，感激不尽

就挑着自己觉得重要的部分记笔记了。

架构篇：

1.有关Flutter
Flutter是一个跨端开发的框架，可以同时运行在Android，IOS，设置是Windows上。它的分层模型图是这样的：

2.MVC,MVP,与MVVM
首先从MVC说起

但是这图什么意思呢？
我们把View看成xml文件，用户会直接在你绘制的界面上指指点点，对吧？我们都是点按钮，没人是点代码。
然后这个View它自己又做不了什么，它只能回头调用Activity，Activity把用户指指点点的结果更新到相关的某个类（Model）里，最后这个Model就直接setText之类了。这样Model便直接对View进行更新了。这样是不是就明白了。
但当业务变得很庞大的时候，MVC就不好控制了，这个时候就进化出了MVP。
ok，V和M我都懂，这个P是什么呢。
这个P就是从Activity中分出来的一个类，这个时候Activity就不会说去处理具体的业务了，而是交给Presenter类去完成。
比如哎呀我按这个按钮，他就会计算4918 * 4564+9484-988，但（我们假设）这是一个很复杂的运算，Activity全去算这玩意了，我点别的按钮就没反应了。MVP中Activity就把这个运算丢给Presenter去算，Presenter算完告诉Model“该更新数据啦”。Model更新完数据就告诉Presenter，“OK！”，Presenter就setText去更新View了。
不一定很准确，但可以这么大概理解。
但这样你肯定也会觉得，那Presenter是不是也容易变得很大啊？

’

CSDN @春风化作秋雨

MVVM中把Presenter改为了ViewModel。除此之外，View的定义也不再一样，xml的布局文件设置与ViewModel绑定。这样就不劳某个部分费心去更新View了，而是通过某种约定将View和数据绑定起来，从而实现View的自动更新。
有关三种架构模式就到这了，如有不对敬请指出。Po一张字节的三种模式的优劣对比。

3.IoC
控制反转。ServiceManager就是一个典型IoC实例。

4.一个程序的架构生命周期。
具体来讲会比较复杂，简单了解下图就行。

素养篇：

优秀的代码应该有明确的语意，命名清晰便于调试。
优秀代码vs不优秀代码

圈复杂度：也称条件复杂度，圈复杂度=边的数量-节点数量+2。也有圈复杂度=判定条件数+1.

代码评审：介于代码编写与代码提交之间，CR的目的在于提升代码质量与学习交流，并提前发现一些编码上的问题，而不是发现所有bug。
基本是CR的内容就是可以想到的，规范命名，拆解语句等。注意到CR的规模不应该过大。
技术债：由于各种原因，本应采用最佳方案，但妥协了从而给未来带来负担。
重构：重构是解决技术债的其中一个选择，通过封装成员变量，方法提取这样的手段简单修改代码，提高可理解性，降低修改成本。同样的，重构其实就是不断对抗Code Smell。
各类重构方法略。