单指对于过程式的逻辑实现, 没有本质区别. 区别主要在于 static 方法的物理性质, 决定了 static 方法无法很好进行 unit 测试以及模块之间的 integration test. 所有 static 方法改成用 instance 方法来实现并不需要多大的工作量, 带来的好处是可预见的.

本质上和实现上没有区别, 只是 API 的表现方式不一样: 是把路由规则放到 http 规范层面还是放到业务层面. 做的好的, 切换两种方式可能就是一两行代码的事情.

语法错误和代码规范都可以通过工具自动拦住; 还有更多的比如是否方法过长, 嵌套层次太多这样 common pratice 也可以通过工具实现; 真正到了业务逻辑层面, 如果不是有配套的 pair programming 实践, code review 一个标准基本不太现实;

是否使用严格的 code review, 取决于代码改动的频率和次数: 业务变化快速频繁的领域或者代码价值不太高但是又不可或缺的领域, code review 可以适当放松限制; 对于成熟的业务价值大的领域, 可以采用严格的 code review, 这样才能带来更高的收益.

这个界限确实比较模糊, 因为不同的系统 part 之间, 对于异常是有不同的理解的: 比如要实现一个 Map 的 API, 如果 get 一个不存在的 key 是返回空值还是 throw exception 呢? 站在 API 实现方, 他可能倾向于把这个当做异常; 而站在 API 调用方则倾向于返回空值, 因为这样可以用比较轻量的方式处理这样的"异常"逻辑分支.

总结一个不太实用的定义: "不要用异常来控制主业务逻辑分支". 说不太实用是因为, 不同人对什么是"主业务逻辑"的理解是不同的.

LZ 举得例子就比较典型, 因为既可以把 UserNotFound 当做业务逻辑的一部分(和其他类型的异常, 比如网络错误,服务器错误等还是有些概念上的区别的), 也可以当做异常. 我个人觉得, 如果对 500/404/400 等前端处理逻辑都是一样的话(比如在某个地方显示 warning message),那么返回异常比较好; 如果对 404 有额外的逻辑业务处理, 则返回空值更好.

DK 的那本 How to be a Coder 感觉还可以.

看书, 看框架文档, 加看脚手架的源码基本就没问题了.

1. 了解语言的长处: 对标的是哪些语言; 2. 找到对标语言的有名气的应用, 找到它们的可优化的地方(效率?可维护性?); 3. 可行性分析, 是否有开源框架可以使用, 开源资源是否丰富; 4. 找到优化的点后码代码; 5. 写论文: 目标; 实现架构; 特别优化的点; 对比对标应用; 小结, 下一步优化的展望. 搞定.

现代软件工程的目标就是分层模块化; 平时就是搬个砖, 去学材料学真没必要.

阿里云的 repository 或者挂梯子.

不在一个概念层次.
异步相对概念是同步, 是一种编程范式, 同步是 block 当前 process 等待返回, 异步是不 block 而是等待通知, async/await 就是在概念上把异步变成同步的语法糖;
多线程 /单线程是一种计算资源分配方式; 同步操作可以用多线程实现, 虽然异步操作一般是有多线程计算的.

思想上没有进阶的动力的话, 就去干点脏活累活(无法很好优化, 或者优化成本不值得的那种活), 把这些事情干得靠谱也是一条出路.

没有 context, 没有 constrain, 没有目标, 谈优化无意义; 就像一楼说的, 加个年字段肯定是最快的的.

深圳移动墙中墙.

如果不是想着赚快钱也不会被骗.

这种网络红人谈专业, 内行人一看就是扯, 想想就知道, 又不是神仙怎么可能什么都懂. 但是外人看起来很专业的样子.

三十才经济独立太晚了吧, 本科毕业就应该开始养家了, 所以肯定不是.
立不是"独立", 不需要参照物, 有自己的价值观和原则, 不轻易改变.

绝对支持 LZ, 我愿意自愿加班, 但强制加班就是 SB.