shijingshijing

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

@defunct9 都没必要学，不会了开个 ssh 让你上去看看就行。