选框架的时候，大家比的都是文档全不全、社区活不活跃、性能跑分多少。

很少有人把「三年后谁来维护」放到权重里。但那才是真正的大头 —— 一个当下省你两周的库，如果两年后停止维护、升级引擎时卡住你，它吃掉的是一个月。

我的经验是：依赖越少、越底层、越无聊的方案，活得越久。 惊艳的东西通常也短命。

#技术选型#

零事故、两万多行代码，抵不过一次很快就修掉的小失误。

有段时间我在公司写了个提效工具，替掉一批重复度很高的活，上线那阵子没出过一次事故，原来的流程照旧跑，只是速度变了。同一个时期我漏过一个边界条件，被下游测出来，临时修了一版。

两件事的分量根本不在一个量级，但被提起的次数是反的，反得很明显。

我一开始有点不平，后来把这份不平收了——不是别人看错了，是我做的那件事从头到尾没长出一个"能被看见的形状"：没有时间点，没有当事人，没有需要处理的动作。人记的是事件，不是状态。

一件安安静静做完的事，在别人的账上留不下痕。

想通这一层之后，我给"做完"换了个定义：每件事收尾时留一分思考，问三句——还能不能更好、有什么能沉淀、怎么让人看见。这三句花不到一小时，但它管的是下一件活。

你上一次"活干完了，但没人知道"，是什么时候的事？

#新人报道# 新手报道，主攻python大家多多指教