接着上面说的，假如是和产品合作，需求是由别人提出的，一定要参与进去。很多情况下，导致坏的设计结构的出现，往往都是因为不合理的需求。尽量去理解需求提出的初衷，并对可能导致坏代码的需求，提出自己的修改意见（不要轻易否定别人的需求）。

找一个长期做的项目，对代码反复迭代，不停重构。不停用几个标准来 judge 自己的代码：
是否低耦合？
编码风格是否规范？
别人调用自己的接口是否觉得别扭？
是否足够灵活来应对产品需求变更？

标准未必是我提的这些，但一定要要自己的标准，然后在一次次迭代重构中不断往标准靠。

过程中还需要对不同标准的冲突做取舍，去思考，往那个方向靠更加合理。比如低耦合和修改的灵活性有时候会冲突，那可以考虑这个模块是否会有频繁变更的可能性，如果有，那更应该考虑后续维护的低成本上，那么高一些的耦合性是可以接受的。而如果这个模块是基础性的，不会轻易变更，但却会被很多人使用，那低耦合更重要一些。

形成自己的有效的编码标准，有了标准，愿意思考，去看别人的代码，编程结构的时候就能非常有目的性的去攫取自己需要的那一部分来完善自己的编码结构。

另：虽然有些奇怪，我觉得代码不应该最求完美的设计模式。所有的代码都是为需求而生的，所有的思考都应该以满足需求为前提，为了需求做编码风格的让步是很高贵的品质。要追求，应该追求的是最契合需求的代码结构和编码思路。

推荐个 App：且慢

不要自己给自己挖语言陷阱哈
24 寸 4k 显示效果比 27 寸 4k 好 -> 27 寸 4k 体验不好？？？？

当然是没有市场啦

因为我想对我眼睛好一些，macOS 的字体渲染好，高分屏处理的好，有一些界面精良又顺手的工具，比如 Omnifocus 之类的。
实际上 Windows 愿意折腾的话也能搞好上面的问题（除了高分屏的兼容）
但折腾本身就是一件很需要取舍的事情，尤其是对于我在已经习惯了 macOS 的生态，会想着又何必再费时间和金钱去折腾 Windows 上的开发环境呢。所以基本上虽然家里有台 PC，但基本就作为游戏启动器。
我感觉这类生态和工具，大多看个人取舍。习惯与否还是得看自己调整，慢慢调整着，总是能越来越舒适。

睡午觉前喝杯咖啡

白天会议太多

买

我也是，很失望，我预期是 1000 万，比预期少了九百九十多万

「老百姓管你那些概念么？」

老百姓什么时候任命了个代言人了，我也是老百姓，我怎么不知道

摸鱼进度条

STMP -> SMTP

目前只能自己填写 STMP 的信息，密码会用 AES 加密存再 Shared Prefrences 里，运行时解密，密钥是随机生成的
https://github.com/HatCloud/SMS2Mail/commit/d4a614b2e070f1820421073fa4c21c25b379225c

我自己写了个 Android 的短信转发到指定邮箱的简陋 App，自己用了一段时间还行，一直没时间做优化
有兴趣的同学可以自己下源码编译跑一个，目前代码还在 dev 分支上
https://github.com/HatCloud/SMS2Mail