如果是想学习业务方向、传统后端思路的话，java or c#。
如果是互联网方向，喜欢短平快，可以选择楼上说的 go 、nodejs 甚至是 python 。

本身能力上跟年龄确实关系不大。

但年龄客观上会影响：
1 、学习与工作的态度、意愿。
2 、接受加班、出差的可能性。
3 、请假的频次。
4 、更大的风险。
5 、更高的人力成本。

@exmario #15

钻研技术是正确的，但钻研技术的核心目的是达到更合理的软件工程实现，而不是秀。

最近在栈溢出中看到的评论：“现在年轻的程序员都喜欢用逻辑非常复杂的、高耦合的、难以阅读的代码来解决简单问题以体现自己的能力，这让我感到非常悲哀。”

这里面你犯了一个基本错误。即：程序的重构应该是你们技术团队内部风险对冲的一种举措，为何会捅到上面去？作为一个商业视角的决策者，怎么可能会同意大成本的，仅有技术意义的重构？

当一个重构带来的是额外的成本，而不是收益的时候，重构真的是重构么？

首先，图 1 与图 2 之间是决策问题，不是对错问题。
你说滋水枪和核弹那个是对哪个是错？

如果脱离实际应用，只说狭义上的快速迭代、敏捷开发，必然是图 1 。
只不过现实上来讲图 2 相对较多。虽然图 2 的场景并不是原教旨主义的敏捷开发，但图二相对而言成本更低，成功率更高，项目也更可控。

其实上下这个功能的主要掣肘在于：效用不明显。

v 站其实是有一个不公开的帖排序系统的。（不能挖坟、你的新帖不一定在最上方等等）
这就导致你点了上、下，其实 v 站的排序顺序也未见得会遵从你的意愿。那么操作者就不会形成操作正反馈。（我点了都没有用，甚至是反作用，那我点它做什么？）

角度挺好的，但怎么让客户信任你真的代表的是客户的利益，这点我觉得挺重要的。

这就类似于保险行业的经理人。
又卖保险，又维护保险配置，那怎么证明你是按照我的需求最大化的保护了我的权益，而不是最大化了你的提成呢？

在可能的前提下，尽量选择味道单一的（香精少的），这样能降低高温导致香精分解带来的不可控有毒物质。

1 、技术上合理，不等于功能上合理。
2 、功能上合理，不等于业务上合理。
3 、业务上合理，不等于执行业务的人认为合理。
4 、执行任务的人认为合理，不等于他有能力用好。

不甘心很简单，解决现有流行框架的痛点就好。
但这有两个问题：
1 、你不用别人的，怎么能知道别人的有多好。
2 、你不用别人的，怎么能知道别人的哪里不好。

不解决好上面两个问题，你永远都是在闭门造车，连“重复造轮子”的边还没摸到。

btw，从描述来看（高度数、定做），应该是用了很高折射率的镜片，高折射率的镜片阿贝系数也会降低，也会导致“锐度不够”

“看近距离对焦困难”，应该是你新配的眼镜度数比之前度数深的结果（或者说是过深了）。

这和眼镜本身多少钱其实没任何关系，是验光水平的问题。

我每天都是“活动日”，但也觉得挺累的😂。

可能是因为封装 header 、footer 带来的复杂度和工作量，相比复制粘贴起来要更高一些。

技术选型和架构设计向来是最高性价比，而不是最优、最好。
要从软件工程角度来看待这个问题。

你已经说了，本地计算的优势主要在于：
1 、数据量大的。
2 、实时性要求高的。

而且前端机器学习、边缘计算未见得就一定是下放到底（用户端）。也有可能是边缘节点，只不是中心服务器。

而且目前直接下放到用户端的，多数都是导入既有模型的利用（比如使用 TensorFlow.js ）。

之前玩星际 1 的 AI 时，回顾了一下星际 1 的对战。
建造顺序和快捷键都还记得，操作流程也也一样，但就是慢了很多😂。