性能迷思与软件工程哲学
越来越感觉"性能"这两个字在学校的语境下很扯淡。
没有场景的性能讨论毫无意义
没有业务场景和具体的工作负载，乃至对比的代码进行的优化程度，单说一个"性能好"最无聊了——等效于没有任何信息。
当然是抽象层越少的性能上限越高，但上限高不等于我能写得高，更不等于我能在给定的时间和可能的拓展性要求下写得高——更不提大部分时候我们完全就是缺乏对性能的先验知识，你说A语言比B语言快，快多少，A的相关业务库又比B的快多少——说不定B语言慢但B框架/类库给力，反倒在这个领域完全干死了A语言，这个快的意义是什么？瓶颈在IO还是计算还是网络还是其他？
协程的启示
写一些学校作业的时候总有一些奇奇怪怪的优化要求（或者自己给自己加的某种约束），但就像协程的诞生一样，我总得先知道哪里才是bottleneck，才能做出有效的抽象。
举个例子：你说这部分的优化加速能让他支持某个场景，例如给单机MySQL加Redis能突破1w QPS的瓶颈，我虽然没有自己实践过，但大概知道了为什么要这么做，以及什么场景下需要这么做；但你就说例如C++写Socket比Node.js快100倍，那我除了"嗯嗯"之外也不知道说什么——感觉你说了一句废话。
代码美学才是第一生产力
诚然架构的迁移需要的精力是巨大的，但这不是过早优化的理由，我认为软件工程的意义上而言，代码的美学才是第一生产力。
我们有那么多"优雅"的成功案例：TypeScript、PyTorch、Spring……却从来只讲如何 Build A Toy From Scratch，不讲 How to Design a Real Project。
关于教学的思考
因为我们只学了/教过/传统是XXX语言，所以就是指定使用相关的东西进行教学和作业也是非常令人不爽的一个逻辑。就像system教学之中的某些东西一样，重要的不是结果，是过程——而在web课之类application性质课的上却完全忽略了这一点。
课程的课时数也完全不能成为某种借口或理由，将精力放在讲解"茴香豆的四种写法"上是极其无聊的——那么多的文档和视频呢，在入门阶段的学生更需要的是一项技术发展的脉络和思考。退一步说，为什么不能给点课外阅读材料？
对着每一个API讲是不屑于讲的"培 训班"模式，那扣各种奇怪的地方的API就不是"培训班"模式了？为什么会有这种越是low level越是高贵的感觉？
个人认为，low level是本事，能够把low level的东西包装成high level的东西——更进一步，make doing the right thing easy，写正确的东西容易，写错误的东西难——似乎更是重要。在这方面上，学校的培养似乎是完全缺失的。
ORM的启示
看Prisma文档花了超级大的篇幅在讲清楚ORM设计的脉络有感：上了一学期Web课，对ORM除了名词之外还是啥都不知道，也蛮搞笑的。
推荐阅读：