@yanque 这个有可能是因为 m 系列不再有显存的概念的原因吧。4G 的显存没了，但是各种桌面应用的需求一直都在，自然就会不够用了。

记得好像有不少人说如果只会 SwiftUI 不会 UIKit 的话早晚会卡住…所以大概两者并不是二选一而是先后顺序的关系。

当然这个也有待确证就是了。从初学者的角度讲，SwiftUI 应该是合适的。

github 满绿…羡慕了（

我也经常想多写点东西，但精神状态一差就玩完了（

话说回来，虽说在网上发简历的人挺多，像 op 这样的有能拿得出手的项目和贡献的真的不多，感觉 op 应该可以争取不错的待遇的。

adecco 在国外就是临时工中介的存在吧，国内的话，之前听人说感觉好像风评也很差…

感觉和开源与否没什么关系，因为看下来很多都是新人容易犯的错误，在私有仓库里面估计也是泛滥成灾。而且开源项目也不是只有 java 吧。

话说过来一大半的截图都有下划线，也就是说很多问题都是可以靠 intellisence 和 lint 来解决的吧。感觉把 idea 的提示用好，并且装上一个够用的 linter ，基本上就能避免大部分这样类型的错误顺便学到一些良好的编码习惯。

op 的题目会让人认为是和开源项目的贡献、组织管理或者维护有关的事情，多少有点名不副实了。

感觉能想到的大概就是 drawio 和 mermaid 了……drawio 倒是挺全的，就是画起来挺繁琐，mermaid 不知道能不能满足需求

好奇 WPF/WinUI 方面的形势怎么样……虽然不在国内但是还是有点关注这方面的情况。

说实话 Unity 和 WPF/WinUI 算是两个不同的路径了吧。Xamarin/MAUI/Avalonia 的话估计就太小众了……

感觉在我的使用场景下没遇到不稳定的情况……Parallel 的效果也极好，甚至可以在 Windows 上打旮旯 game 或者装个 Linux 发行版自己随便折腾……都在考虑要不要入正了。

加强针应该是不可以的，必须先把原始针打了过一段时间再打。

看项目情况、这个类库的复杂度、可修改程度、完善程度和这个项目的期望（？

如果项目本身有一定的「研究或者玩票」性质，不太指望直接写出纯 prod 的产品，同时不保证以后会不会开源代码，这种情况下是尽量优先选用技术成熟、开源协议友好的类库，并且比较倾向于 fork and dev 的。

再比如说如果类库质量并不是很好，可能就有必要去自己做深度开发甚至重写，当然这个成本对于大部分项目想必都不是一件可以考虑的事情。

理想情况下当然是遵循 solid ，自己写一层扩展，但是很多场景下，受到语言、框架、具体的技术栈限制，能找到一两个可用的 lib 已经不容易，lib 也很有可能并不是遵循良好设计的。

显然的，在面向 prod 的项目里面就是另一个故事了。可能在源代码协议方面可以通过闭源（这样不道德但是也没法强求所有人）来绕过，但如果手上没有多少可选的、设计良好的 lib ，那感觉很大程度上还是需要 fork and dev 的…

这个是 sum type ，typescript 里面有不错的支持。kotlin 和 java 都没有，得用 scala ，不然就是纯 fp 的 ocaml 、haskell 之类的语言才有了。

sealed class 模拟的问题在于不能用再已有的类型上，必须手写一层例如 IntWrapper 、StringWrapper 之类的层来套着，对数据互转很不方便。

如果请求内容无效，直接返回错误报告。

然后…在后端程序里面，毕竟无法保证程序状态永远正确，所以需要用异常来检查和保证程序尽量正确运行。

唔，我倒是没怎么写过后端，但是我对程序的理解是这样。感觉重要的还是如何保证请求的内容健康有效这一个环节，当然可用的工具也很多就是了。

至于随地抛异常，我是反对的，因为异常意味着程序状态发生了不正常的情况，即使可以在上层捕获，这种用法给人的感觉就像用异常处理 NPE 一样（

感觉应该区分「输入 /输出数据不合法」和「程序内部状态错误」吧。

在我的理解里，一个程序应该是只对特定的输入有效，产生期待中的输出，对于这以外的其他输入，应该直接拒绝运行，避免产生意想不到的结果。

在后端里面，这个逻辑应该可以等价于……一个大的事件循环在监听外部的请求，首先检测请求的有效性，对于有效的请求，开始执行这个程序（启动线程、调用服务之类的），

砸壳网站的安全性如何呢，感觉有点不太放心。

完全可以，其实 2020 年的 i9 版玩起来就很流畅了。

国外也是 Java 最多的吧…简直铺天盖地

如果不是同一个项目，当然代码不会随之更新了…
submodule 看起来是个不错的解决办法，但其实用起来很不方便，尤其是在 idea 系 IDE 下，commit 等操作的时候都要十分留心避免错误操作。
大体上如果工作流是这样的话，好像并没有很好的解决方案。