从一开始，也许并没有 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 存在手机上

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

所以这就是它价格与 iMac 相当的原因吗？🥲

对于墙的问题，有条件的是否还是应该备一套上网环境比较好？

现在只是 Notion 而已，那如果以后遇到新的，好用的产品呢？（当然，也可以等开源或竟品的出现）
况且但不绝对，像这种眼前一亮，相见恨晚的产品，一般是从国外诞生吧

我还时不时就申请在家办公

打一些比较套路化的代码时，就开着音乐摇摆一下；打一些逻辑比较复杂的代码，就安静下来；比较烦躁的时候还可以大叫几声抒发一下；在办公室就没有这种操作了 🥲

实际操作中，我个人都是先同意预弹窗，然后在系统级弹窗拒绝 🥲

当然会，不然读了十几年的书岂不是白读了？

重要的人做重要的事，然而，90 percent of everything is crap. The same is true of our own work.