函数层面的堆积木，不过结果是函数功能越来越单一化

一年也没有几次需要跟 10086 打交道的，就直接屏蔽了 10086 ，有什么问题我主动找它就好了

好危险，感觉稍微再推动一下，就会得出另一个「父母皆祸害」的结论

观察你所说的「别人」
如果他是比你优秀的，克服的方法就是向他学习，你会变得更好
如果他是跟你差不多，那么也不必介怀。因为换作是他，他做的结果，大概也跟你差不多；但此时，你可以再想想如何做得更好，好到不用介意他的感受的程度
如果他是比你差的，那就不用理会了，因为他做的结果，肯定是比你还差的

可以先理一下思路：
如果函数执行正常，那就是意味着没有错误，那么 user 就应该有一个结果，而且它是可用的；
如果函数执行不正常，那就意味着有错误，那么 user 即使是有结果，那它也是一个错误的结果，是不可用的。

返回一个 Empty struct 的危险之处之处在于，当调用方忘记了检查 err ，而且 Empty Struct 从业务上也讲得通，后面的逻辑会根据这个错误的结果执行下去了，于是最后的结果也可能是错误了。

虽然说算法都有实现，但是知道有这个算法与不知道有这个算法，还是有区别的；而知道有这个算法而且还能有点印象的方法，好像也只能通过刷题？

从一开始，也许并没有 MVC ，只有一个文件，叫源文件，所有关于业务逻辑，UI 构建的代码都写在里面。

后来，发现业务多起来了，这样子发展下去不行，维护起来太麻烦了；不过我发现，逻辑大致可以分成两部分：一个是数据模型，一个是 UI 视图，那么怎么把两个关联起来呢？中间需要一个类作协调，叫它控制器吧；
好了，这个就叫做 MVC

后来，发现 MVC 还是应付不了业务庞大起来的情况，数据模型太纤瘦，UI 视图还行，关键在于很多很多逻辑堆在了控制器里面，还是得从控制器抽点代码出来，那我们就把数据处理、转换部分的代码也抽出来吧；咦？好像 UI 层需要的数据也可以搬到里面；那么，这一层好像跟数据模型有关，也跟 UI 视图有关，那就叫它 view model 吧

（我是写 iOS 的）咦？还有个 RxSwift 的东西，可以用这个东西把 view model 数据每一次变化通知到外面上。那我就可以在控制器中将 view model 与视图绑定起来，每一次数据发生变化，视图就可以更新了
好了，这个就叫做 MVVM

于是，从所有的代码写在一个文件中，演变成：viewModel 放乱七八糟的业务代码，只要把 UI 需要的数据发出去就可以了； View 就是 view ，不参杂任何业务处理的逻辑，就负责当花瓶；剩下的 controller ，原来乱七八糟的业务数据、处理都是写在里面，现在全外包出去了，重点就剩下绑定 viewModel 和 view ，说不定关于绑定的代码占了这个代码文件的一半以上

其实核心就是一个，通过分拆代码使得日后维护工作简单快捷，可以早点下班。

“不宜妄自菲薄”

有个疑问，楼上有些说的德亚，我看沃尔玛里面卖的保质期有一年之久
再结合一下随手查的资料（可能不全面），这些牛奶一般是经过超高温处理，营养已经没剩多少了
那岂不是买了个寂寞？

所以可以选的话，还是应该选本地产的鲜牛奶？

启动页不能动，只能在启动页过后再做一个假的启动页

防君子不防小人🥲

注释（这里不算方法签名上的那部分）应该是写某个模块的总体思路；或某个有惊喜的地方需要稍作注明，用于提示别人或以后的自己
而本来写在具体实现中的注释，应该通过好的变量名和方法名来体现；如果觉得其中的逻辑过于复杂，想写注释时，应该先思考一下逻辑是否可以进一步拆分

之前也出现过 op 的情况，后来我就默认英文了
但如果搜了一圈还没找到的话，就会开始怀疑是不是关键词拿捏不好，于是再转用中文

@Chad0000 养肥了再杀

有句老话作参考：养儿一百岁，长忧九十九

尼采式鸡汤：人生是没有意义的 ；硬要寻找意义的话，那就努力超越自己 💪

公司里有一个 App ，里面的代码几乎全都是我写的

我会把它装在手机里，虽然很少打开它，但它的存在会督促自己把代码写好一点，毕竟是自己写的代码，并不想意识到有一个代码写成屎的 App 存在手机上

当然，以后要是离职了就另说了