比如机动车在斑马线上让行人。我们先不考虑效率等因素，先假定这是好的行为。那么，不论让行人的动机，是司机主动礼让，还是不想被拍照扣分，都应该大力称赞这种行为。

核心的一点是，不能因为动机是怕被拍照扣分，就认为这么行为不值得表扬，更不能觉得「本该如此」人们本该善良、本该助人这样的人设，并不出现在现实中，可能童话或动画片里会有。

如果愿意用一分来唾弃不好的，就要用十分来称赞好的；别因动机而吝啬你的表扬。

比如，开发自己的产品，可以给无数人用，相当于把自己的时间复制了无数份。

比如，做外包开发给别人开发产品，只能取得一次性的报酬；自己的时间并不能复制，只是简单的出卖。

不能复制时间的事，少做，这不利于自己价值的最大化。

不过，凡事无绝对。比如外包，如果钱实在多的诱人，或者正好自己感兴趣，或者可以锻炼自己正在学的技术，等等；对于这些情况，自然是可以做的。

关键词项目前端的功能差不多了，今天挑前端框架优化之，真的挑花眼了…

前后了解了 Bootstrap、Bulma、Ant Design、Element、iView 等，最后选择了 Element；其中，一个重要的原因是，鉴于我的 Vue 基础还不牢，而 Element 文档里包含了大量 Vue 实例代码，简直可以拿来就用，抵挡不了诱惑。

另外，对 Ant Design 也挺有好感的。一方面它的「面向中后端」的定位，其实挺符合我的需求；另一方面，它的生态相对更丰富，比如对设计原则的介绍、设计资源、文档等等。不过，未选择它的原因是，Ant Design 是 React 基因，Vue 版本貌似去年下半年才推出来，且未应用到 Ant Design Pro 中，是明显的二等公民。且文档中没有 Vue 示例源码 😂

挑完后，看了一遍 Element 官方文档，大概了解了它怎么用、包含哪些组件，也写了测试代码进行可行性研究，基本心里有数。原本计划 3 天的后端 UI 改进，看来可以加快到 2 天了。

今天给关键词项目上了并发系统。

先是用测试项目，实现了代理池自动更新；然后将其应用到爬虫系统中。由于要支持并发，代码系统变得复杂很多，且增加了一些冗余逻辑来保证一致性和可靠性。比较不爽的是，由于代理池性能的问题，10 倍速并发并不能带来 10 倍的提速，有点得不偿失的感觉。

实际项目中，架构及实现的可靠性，甚至比较性能更重要。性能问题，可以简单粗暴地加强硬件解决。但可靠性问题就比较麻烦；尤其是项目进行维护期，自己对代码越来越不熟悉，一旦出基础的问题，修复的成本就很高了。

这周一直在写代码，在开发关键词排名监控的业务，每天都干到很晚，确实很忙。

注意：说太忙，这话并不是褒义，而是预示着有很大的问题。

如果忙到没有足够的时间思考，没有在业务之外的范畴中有学习和进步，那么 这种忙，是螺丝钉级别的，是值得羞耻的。

换个角度，之所以忙，很大原因还是能力不足，导致开发过程有各种问题，比如接口的反复修改而浪费了不少时间，比如一些基础的问题还得去 Google，等等。而这些导致忙的问题，恰恰不是忙能解决的。必须在不忙的情况下，潜心地学习进步，才能在之后的工作中提高效率，变得不忙。

下周一定调整这个问题，切记。