@frodez 实际上你并不知道，甚至只是了解一下 Java 的异常机制。Java 的异常机制是：该是自己的事就 catch 住自己处理，不是自己的事就 throw 出去。该自己处理的自己处理，不该处理的抛出去而不要隐藏，这是即正确又方便的事。按照你的思路，来了错误不管是不是自己的就硬去处理，那才是不正确的事。

此外，统一的错误处理逻辑也不是偷懒，它要在全局层面管理异常，需要花费更多而不是更少的精力。那种捕获到异常就只提示一个“有错误”的统一错误处理才是偷懒，但这不是全局异常处理专属的，if (err ） then print "有错误"，也能这样偷懒。

@Cmdhelp #4 Lambda 就会让你多一份技能，而 Stream API ，会引导你走向流式数据处理的大门——艺多不压身。
@statumer #12 当数据量级小的时候二者没区别，当数据量级上去之后，stream API 对性能更好。

抛弃上面的不说，Stream API 在编码友好性（主要是链式操作），跟可读性上（ Java 8 的还因为 API 不完善导致由局限，9 、10 之后就差不多完善了）都有很大的提升。OP 的观点只是略有不妥，而上面有些人，那是不学无术还要瞎叫。

Spring 6 / Spring Boot 3 要以 JDK 17 为基准版本了，这回 JDK 8 终于要到头了。

很多人不会，不代表不主流。JVM8 也不是主流，不管是 Eclipse 还是 Idea ，老早就强制升级 JVM 了，所以至少 IDE 端，已经早就不在 JVM 8 跑了。

@unt #5 不对。我猜你们这个 adev + bdev 混合体是丢弃历史手动合并到 dev 的（所以才需要由专门的人在专门的时间干这事）。不管 adev 还是 bdev 都是多余的，可以扔掉，用随时创建并且用完即删除的个人分支（本质上是特性开发分支或者 bug 修复分支）代替。

git 的分支多分支协作，是一个或少量几个长期分支，加无数个临时分支构成的。长期分支越多越难管理，不要搞出 adev 、bdev 这样，仅用于合并的长期分支。另外，要想 git 协作，PR/MR ，或者补丁，最少要用到一个，不能像 SVN 那样只有更新和提交。

@James369 #2 他这个，release 分支是用完即删除的临时分支，长期分支只有 master 和 develop ，所以自然不可能在 release 分支上打 tag 。

nodjs 、php （移除后端之后），就是前端，你的图画的不对。如果是服务器渲染，那应该是：浏览器——前端——后端。

用于将后端的核心服务，映射为页面直接可以使用的接口的东西，这个可以是后端的接口层，也可以是前端的转换层，并不需要单独弄个端。但是如果在后端接口与前端之间，又专门弄了个鉴权、负载均衡的服务，那这个是网关。

除了你说得这个补贴，没有其他好处了，本质上就是你以补贴的价格把发明权力卖给了公司。

还是来说说坏处吧，首先就是，卖了的东西你自己就别想用了，这东西只会成为你跳槽的麻烦，不是动力（除非你打算将来被人不惜重金挖走）。

其次，这个是重点，去好好看看专利发明人你是第几顺序，如果不是第一，那么你这这就基本等同于你们老版的学徒。——爱迪生的几千专利，就是这么来的。

真是瞎了我的狗眼，匿了

提示一下：android 谷歌账号，是跟 SIM 卡都绑定的超强实名，不要绑定，除非你是真想实名。身份验证器，要用还得用微软的，那个至少目前跟微软自身的业务还没有关联。

自己没说清楚，怨不得别人。连“活动记录”这种敏感数据需要重新登录认证都不懂，也别摆高姿态。

首先，账户活动记录属于敏感数据，访问的时候必须临时性的重新登录。
其次，android 手机的 GMS 的谷歌账号验证，是强实名验证，自然要比 IOS 上单纯的 TOTP 验证更具安全性，首选 andorid 手机验证无可厚非。
再次，在你选择“谷歌身份验证器”并验证通过，仍然被要求使用 Andorid 验证的时候，那就说明，谷歌已经不信任你在 IOS 上的“谷歌身份验证器”了。
最后，不信任一个东西的时候，最好的处理是默默不动，而不是去通知它不信任了，所以你 IOS 上的“谷歌身份验证器”不会收到任何反馈，只是不会再起作用了。


“谷歌身份验证器”并验证通过，仍然被要求使用 Andorid 验证，还有另一种可能，谷歌就是想要做一下强实名认证。但是没有手段来测试确定是这种可能。退出 andorid 后 IOS 又能用了不能说明是这种可能，因为你退出 android 的前提是要先登录 android 环境，这时候你即做了强实名认证，又给 IOS 上的身份验证器加了信任保证，不能确定是哪种导致 IOS 又能用了。

看你怎么算开发，如果只把核心程序编程的当开发，那不会超过 100 个人，因为核心程序纯编码超过 50 个就是庞大团队，超过 100 个那是得是世纪工程才能有得配置。

如果把所有编程都当开发，那人数是没上限的，各种临时活动需要大量的代码民工。

此外，游戏开发的主力从来都是美术、剧本、模型这些艺术创作，国内的游戏还要在最前面插入司马策划。上面这些人员才是通常意义上的游戏开发。

只用“密码+TOTP”两部验证的账号，是完全匿名账号，而国外的服务并不都是接受完全匿名的。当然国外的要求通常只是非完全匿名，不是实名。要求低点的你随便搞个第二邮箱就可以，要求稍微高点的需要拿手机号认证一下（但不绑定）。常用的账号，还是添加一些第二认证手段好些。

不过以上不包括谷歌，Facebook 这些依赖广告的，他们必须依赖实名账号来做数据分析。

作为被国内各种验证荼毒过的人，不应该分不清账号登录安全验证，跟账号共享验证的区别。现在这个验证，并不是因为账号异常登录，就是特么的怀疑你共享账号了。谷歌这点上，跟国内差不多。

谷歌搜索一直都不屏蔽别的二道贩子搜索，也是非常奇葩。

@pandachow 国外环境下，Senior 应该不比 Principal 低吧。
@libook 在 Windows Server 支持 WSL2 之前，是这样的，（为此我还嘲讽过嘲讽 Windows Server 不支持 WSL2 的人）但是微软专门给 Windows Server 弄了个支持 WSL2 的更新，那后面就不好说了，毕竟在某些领域微软变脸比翻书还快。

需要定语，基于劳动合同上的工作岗位或者隐式契约上的工作要求产生的问题，跟领导产生的问题，是两码事。