NAT 的没啥用，独立 IP 都没有

#45 错了，Community 不确定，Express 我确定是无法使用 Form Designer 来直接拖拽控件开发的。

@Chad0000 我没记错的话 Community 还有以前的 Express 版本，是无法开发和编译 Winform 的，WPF 的我不知道。

@Chad0000
@JustinL
@a33291

当然是 Visual Studio IDE 收钱，如果用了某些库，还会单独收授权费。Win 10 以后微软各种暗藏的 Telemetry Service 背后运行，取证不要太方便，Win 11 搜集信息的能力更厉害。

C#如果做大了，微软也会找你们收钱的啊

不要选 C#，不好招人，简单的上 PySide 用 Python ，复杂的上 Qt 直接 C++。

而且 APUE 是以 Unix 环境的应用开发为主，书本身是经典，但年代有点久了。还有一本《 The Linux Programming Interface 》 TLPI 其实写的也很好，发布时间也较新，不过中文版翻译的很烂，有时间可以翻翻。我觉得做*nix 相关应用程序开发这两本基本上就够了。

《 linux 内核设计与实现》和《 unix 操作系统设计》 这两本书感觉你现在还消化不了，如果后面不做 Linux 开发或者云原生、Infra 相关开发，基本上很少用到，现阶段还不如看《鸟哥的私房菜》，把基本的 Linux 应用和 Shell 脚本弄清楚。

Linux 相关的开发需要 C 基础，需要 Linux 系统相关的知识，我觉得还是有门槛的。

@IMengXin 这个真不错，不过好像缺少了容器相关的。

所有带 Gnome 3 或者基于 Gnome 3 的真的都可以洗了睡了，设计反人类，资源占用还奇高，真不明白一个桌面怎么会做成这样。。。

@lostberryzz 现在基本上全是自动生成的代码了，顶层基于 XML 的 SysML 进行系统级建模，MBD 和 MBSE 只关注模型，代码全部自动生成，已经是行业的事实标准了，国内深入做底层 MCU 的不多，目前以自己做车机相关的为主，主要是 Android Auto ，基本上不会用到这一套，而国际 Tier 1 基本上都在用 MBD 和 MBSE ，只关注模型，模型到代码是自动生成的。

这样做有几个好处，第一是系统高度抽象，高度模块化，便于工程开发、调试和管理，这也是大型复杂系统的唯一解；第二是模型到代码这个过程，基本上都需要经过 Ceritification 认证，这个过程是用形式化验证来保证的，生成的代码性能不一定是最优的，但稳定性和鲁棒性一定是有保证的，这也是嵌入式最核心的关注点；第三是模块化能保证复用，以往的手工开发，复用最多也就是函数和库这一级别，还是跟底层关联太紧密，而基于模型的方法做出来的是按照模型打包的，很多通用的系统应用到不同的型号上，只需要修改参数即可。

最后，很多人一说到汽车电子就都以为是车机那一套，其实真实的汽车电子一直是底层 ECU 一脉相承而来的，车机的那一套，很多情况下你不要也行，导航用个手机就能替代。或者这样理解，现在的汽车电子分为应用层和底层，大部分人关注的其实是应用层的，底层接触的人不多。

这样下去，又回到十几年前大家买水货手机的时代了

正常操作不是 fork 一个分支，社区进行自治么？不管作者是弃坑还是有其他骚操作，都不影响啊。。。

目前看下来：
1 ，多加 try... excep...是可行的，特别是涉及用户输入，文件访问，网络连接相关的功能，可以猛搞，而且显得专业，考虑周到。
2 ，封装成 Class 也会大幅增加代码数量，但是感觉需要改动的地方可能有点多，后续如果老板有大功能，重构的话倒是可以考虑。
3 ，适当自己造轮子这个已经弄过了，有部分输出 xml 就是 writeline 搞的，复杂的还是用标准库的 ElementTree ，程序复杂度有提升，估计后面接手的人看了会皱眉。

大家继续集思广益，我弄好了一起 Append ，也给有类似需求的人参考。coders help coders.

一步到位 JIRA

@nauhc 很多公司拿微信来办公的，比如商务上的，有的甲方用微信，有什么事情就是一长段语音丢给你，你用不用？再比如有的老板喜欢不管什么问题都拉一个微信群里谈，以后出了问题还得翻微信记录来撕逼，你敢删？还有很多政务方面的，只提供小程序，你用不用？