这是大多的敏捷工程实践都有个共同的特征：就是要求在一系列的开发活动（编码、构建、测试、调试）之间快速循环。
然而，因为 C/C++ 是编译型原生(native)语言，存在两点特殊之处：
一是需要较长的编译时间才能运行，不像解释型语言可以直接执行，编译必不可少。
二是编译的生成物是平台相关的，不像 Java 之类基于虚拟机执行的语言。平台相关带来的问题是：
- 开发人员的办公环境与要开发的程序的目标（运行）环境是不同的，意味着生成物不能直接在开发环境上运行
- 更糟糕的是，如果没有良好的 C++ 可移植编码的实践，开发人员的办公环境甚至可能无法直接编译目标程序（交叉编译是一种解决方案，但只能解决编译的问题，不能解决测试及调试的问题）
障碍过多，最终的结果通常是：开发活动被割裂到不同的机器上。比如：在 Windows 系统上编码，把代码同步到远端Linux上构建，使用 ssh 在远端运行测试，使用 gdb 在远端进行调试。中间的代码及成生物（artifacts）同步需要手动操作，命令需要使用使用 CUI，尤其对于调试而言，操作极为不便，效率较低。
- 生成物（artifacts）及命令的流转应尽量自动化。
- 数据和流程的呈现应尽量可视化。
- 体验应该尽量接近本地开发。
解决方法是通过使用现代化的IDE提供的（或者插件提供的）远端开发模式及远端调试功能，承包代码及生成物的同步，命令的传递，接近甚至达到本地开发一致的用户体验。
现代化的 IDE 比如 CLion、Visual Studio，甚至一些编辑器都能通过插件提供这类功能。
CLion 提供了强大的 Remote Development 功能，当中有个 Full remote mode，经过配置后，几乎能做到与本地开发完全一致的体验（当然，虽然远程的操作是自动化的，但受限于项目及网络因素，操作完成的时间可能会不同），支持本地体验的远程调试功能，目前只有 CLion 的覆盖率等少数功能不能在 Remote Development 模式下工作。CLion 官方有非常详细的文档指导如何配置，使用方法完全可以参考：https://www.jetbrains.com/help/clion/remote-development.html
添加 custom VM options (help | Edit Custom VM Options...) 以修改编码，然后重启
-Dconsole.encoding=UTF-8
-Dfile.encoding=UTF-8TBD