楼主说的这种呢，就是需要一个人，把整个框架搭建起来，定义清晰的接口，实现模块或子系统之间的接口层
然后子模块子系统内部，你管他怎么做

还有，建议没事不要用继承了，很容易滥用，不可控。组合配合清晰的设计，是最理想的

Java 这种为了抽象而抽象还算好的，毕竟灵活度没 C++高。恶心的就是，用 C++做的，然后为了设计而设计，为了抽象而抽象——简单点就是过度设计，用烂了，一堆坑，全是坑。

——————————————————————
更恶心的是没注释，没文档；变量命名用的全是缩写——有拼音缩写的，有英文缩写的
当然，代码量还大，将近上百 M 的代码量

这也是为什么很多人现在，毕竟喜欢 go 那样的风格。简单，清晰——语言层面提供足够多的基础功能

现在一些人的逻辑连基本常识都不如，

1. 所谓的一堆，一群，请问多大的样本？！
有统计学意义么。如果没有，就不要把个例当真理

2. 存在不是合理
为什么现在还一堆人认同所谓的存在即合理，然后就什么都不做，让其自然消亡？！
这个逻辑真他妈搞笑——若真是这样，现在应该还是大周大夏，数千年之前一样


用嘴巴抵制 996，总比嘴巴都不愿意动的人好
用行动去抵制 996，自然比只用嘴巴的好

本身问题的解决、大环境的改善就需要一个逐步渐进的过程。为什么一些人，就因为没有找到一了百了的方法去解决问题，就否决可以改善问题的做法与方式

罗马不是一天建起来的！

其实若 go 再成熟下（对不同平台的支持——主要是移动平台），做跨平台的客户端 go 应该是最合适的做法。UI 层与业务层通过 RPC/MQ 这样的方式提供接口或服务

UI 用各个平台的原生来做，也可以用 h5 的方式（如 electron 或 flutter ）

楼上很多人若无大型应用的经验就不要随便给建议，也包括对 C++一知半解的人

1. 大型应用
若都用原生开发的话，成本是极高的（包括不限于人力、开发与测试等等），当然，最大的是后期的维护成本。你要知道，就一端就有可能需要 5-10 个人的研发团队。光移动端就有 iOS/Android 主流的这两个。

而对于大型应用，一般根据公司的长远产品规划，逐步支持非移动端及智能硬件上也是会初步处于规划中的，比如 Window/OSX/Linux，以及智能硬件（如嵌入式的），若是这样的话使用原生的开发对于后续的运维与扩展（新功能、新平台）基本是不可行的，而且成本极高

而且还可能需要提供 sdk 给第三方（有这样的需求的）

2. 小型应用
这样的，随便是原生或是 h5 的方案或别的跨平台方案都是随便的，这个可以根据公司内部已有人员的技术栈选择就可以

3. C++跨平台应该怎么构建
对于这个的话，参考 google 维护的 WebRTC 就可以了——一个平台源码包括构建工具 >10GB

一般的做法，都是“C++库 + 平台接口层 + 原生（一般做 UI 与简单业务）”

稍微有些不一样的就是这个平台接口层的做法某，
a ） 比如可以直接用各个平台的原生语言封装一层提供接口
这种是目前主流的做法，WebRTC 也是这样。比如 Android 则是用 jni 封一层提供接口，iOS 就是 OC 一层；对于 Linux/OSX/Window 等，也是类似的做法。每个平台封装一层做接口

b ）可以网络的方式（如 IPC/MQ/RPC ）
这种更为灵活，这个做服务端是很成熟的做法；对于做大型客户端，有但是不太多

对于具体那种做法，是要根据业务进行综合评估的。

4. 对于 Qt 框架
其实 Qt 之前主要的应用场景是工业或嵌入式（如汽车电子、工控、各种智能设备）这些，对于跨平台这块，若 Qt 敢称第一，应该没有别的框架敢说第二。别拿基于 h5 的方案来说事，不是一个级别上的东西（包括性能、支持的平台等等这些）

做客户端，基于 Qt 好处的地方就是，
a ）提供统一的开发环境与构建方式
QtCreator + qmake/cmake，基本可以应付绝大多数场景与开发环境（ Linux/Window/OSX ）
输出根据自己的方案，可以是动态库或执行文件，都是没有问题的

b ）封装完善的基础功能
包括不限于常见的数据结构、网络（ http/ws 这些）、硬件接口等。简单点就是，很多基础功能不用自己维护，也不需要自己构建或寻找第三方的库（这个可以省事很多）

简单点就是，常用的基本都有提供


其实这最大的困难的地方就是，要用 C++做跨平台，团队内需要有非常资深的人可以 hold 得住整个框架，只要能够确保这一点，基本是不会有问题的。

另外，C++真的没有如外界所传的那么难。很多时候说难用，其实就是缺乏把握框架与方向的人，因为特性诸多，很容易给滥用。其实不管是什么语言，都存在这个问题，只是 C++更为明显而已。


注：本人维护过基于 C++/Qt 跨平台的客户端软件，源码量 > 50W 行以上，所以对于这块有足够的发言权。

详细情况可参考这里，
https://slack.engineering/introducing-nebula-the-open-source-global-overlay-network-from-slack-884110a5579

感觉有点意思，就是不知道性能怎么样。看了下介绍，似乎 slack 内部的服务器已经基于 Nebula 使用超过 2 年

@Insignificant
那就是单片机基础，转嵌入式 Linux 吧，然后加上 Qt （ C++），这样选择也会多很多
当然，若涉及到过 wifi、ble 或 lora 这些，就更好

自动化的话，行业可以选择智能硬件、工业（目前这个方向需求不少）或者物联网
自学 Java 转 Java 后端，除非刚刚毕业，不然几乎不可能。比较现实是工作中内部转岗

目前工作偏硬件，那么就转 C/C++，这才有竞争优势。目前国内对 AI+IoT 类似的需求是越来越多，所以
1. C/C++
稍微深入下数据结构+算法，对 UI 如 Qt 也有一定经验

2. ARM 汇编（如 neon ）+ 深入学习基础

3. 硬件加速
如 cuda+CV 这些，选择面比半路出家的 Java 后端好多多

当然，若有 fpga 经验，那就是更好

若是对 IoT 类感兴趣，可以直接基于 freertos，研读其源码与进行测试。因为如上所说对 lwip 感兴趣，那么就非常适合，freertos 网络部分就是集成了 lwip。进一步，还可以对 ble、wifi、lora 这些做进一步深入，包括协议类如 mqtt 这些

若是要考虑跨平台+网络类应用，go 是最理想的选择。开发效率高，易学，是非常理想的跨平台开发方案。利用 golang 的 qt binding 也可以做 UI

看了一整楼的都在反驳楼主的看法，却又提不出有效的意见——简单点就是，连个可以正常讨论的氛围都没有。就知道一个劲的抬杠，就事论事有多难？！

1. 技术只是专业技能
若要尝试往更高的位置走，比如高层或创业，自然不能单单依靠专业技能；还有很多之外的、必须的需要去锻炼去训练，让自己不断的成长。楼上很多人说得对，我们不能只单单的看到别人的短处——短处用于警醒自我，长处用于学习，让自己成长。

2. 管理岗就是一个萝卜一个坑
这个如楼主说的，绝大多数公司（包括相当的所谓互联网公司）能上去的不外乎就是运气好或比你来得早，确实有相当的能力很强——但是也不要无脑封神，连个平等思考讨论的资格都把自己剥夺了。大多数管理岗的（极少数能力极强的除外）确实是不是不想走，是确实走不了，这个是各种原因都有。

但简单点的，对于管理岗，对于公司层面来说，只要不找死，基本都不会有人要搞走你——这对公司来说，叫不引起动荡。不然你以为为什么国内所谓的 996 越来越多，不外乎就是给基层员工给管理层背锅。

因为相对做制度、流程的创新来提高效率，加时间是最简单也最有效的做法——当然是边际效率递减。这也就是对于绝大多数公司来说，你会发现你的直属上级、上级的上级，极有可能不管是专业技术、还是软实力（情商——不只是会说话）均不如你，这个是常态；他们就是运气好，比你早出生

3. 人情社会使然
或者这也就可以理解，为什么国内绝大多数中小企业一直都是中小企业，在某细分领域成为全球性的企业也是极少数。这是人情社会使然——管理制度、流程做不到能者上，而是排资论辈。

1. 对于刚刚毕业或项目经验不丰富的
侧重是基础（笔试），兴趣及学习能力。若有兴趣，自然有侧重的方向，稍微深入下自然就知道是否有兴趣，及学习能力或学习方式如何

2. 对于经验丰富的
a ）挑关注或熟悉的项目涉及的技术栈、框架，看了解到什么程度；另外，则是对涉及的技术问些常见的问题的处理，自然就知道项目经验是否真实可靠

b ）工程化能力（这个很重要——不然坑死人不偿命）
简单点就是实现某个子系统或子模块的时候，解决问题的思路。可以从思路，是否关注维护性与扩展性考量

这个与是否培训班，使用什么语言及工作年限都无关。反正遇到过各种坑

一个团队或公司里，不同的人有不同的需求，一个理想的团队，就是
1. 要钱的有钱
2. 要学技术的，有机会学到流行的技术或框架
3. 要成长的，有机会参与设计或架构

所以，一个 leader 很重要；产品的前景也很重要。不然只能提供某方面的机会，最差的就是一个都没有