技巧 1——将生成的代码与手写的代码分开
当团队开始使用RAD工具时，遇到的一个大问题是，他们将自己的代码集成到RAD工具生成的代码中，而不是相反。这样做的问题是RAD生成的代码决定了应用程序的软件架构、编码风格和一般构造。团队不应该这样!相反，RAD工具应该生成一个带有挂钩的库，团队的代码可以调用和利用这些挂钩来完成所需的任务，无论是运行状态机还是AI引擎。
主要目标应该是将RAD生成的代码与手写代码分开。根据工具的不同，这可能不会立即实现。例如，通常会在开发人员希望插入代码的地方找到代码块，如下所示:
/ USER CODE BEGIN 2 /
/ USER CODE END 2 /
RAD工具试图推动嵌入式开发人员更加依赖该工具!不要在这些块中插入你的应用程序代码，而是插入包装器代码，该代码调用独立于RAD工具的应用程序代码。代码将更加灵活，对手写应用程序代码的更改可以在不更改RAD生成的代码的情况下完成。
技巧2——为你的软件建模
为应用程序代码开发软件模型可能是一个强有力的工具。模型将允许团队构建他们软件的可视化。然后，可以在主机环境中模拟和执行该模型，以确定所提议的体系结构和组件是否会按需要工作。如果它不起作用，那么可以进行微调和调整。如果确实有效，开发人员可以自动生成或自己手工编码模型。
模型驱动开发是许多嵌入式系统团队经常忽视的技术。通常会有一个匆忙的编码，因为项目开始晚了，而且缺少资金。在开发周期的早期花时间创建模拟和验证正在构建的东西可以节省大量的开发时间。如果嵌入式开发团队能够利用从他们的RAD工具中生成的代码，节省就更好了!
技巧3——拒绝“重新编码”的诱惑
RAD工具经常产生一些差的C / C++代码。如果你期望你的工具交付的代码像你的代码一样，这可能不会发生。使用RAD工具的开发人员通常有两种选择来处理他们糟糕的代码输出:
l 仅将RAD工具用作快速原型制作工具，并在概念验证后手工编写代码
l 接受RAD工具的输出并继续前进
尤其是对代码质量和编码风格要求严格的嵌入式开发人员，就是扔掉所有RAD生成的代码，从头开始。然而，在这种情况下，RAD工具给出了手写代码试图模拟的功能性概念证明。
记录RAD工具输出的问题是，如果需要进行更改，RAD工具中生成的模型和设备上使用的代码之间不再有任何联系!bug潜入代码的可能性很大。虽然许多RAD工具的输出并不美观，但它们非常实用。如果代码可以处理极限情况并按预期工作，就使用RAD模型，不要看输出!无论如何，测试它，但是把你的注意力放在别的地方。
结论
快速应用程序开发(RAD)工具可以帮助团队极大地加速他们的软件开发。不幸的是，RAD工具经常试图成为架构的中心，或者产生难以阅读的代码。这篇文章表明RAD工具可以通过将它们生成的代码与手写代码分开来驯服。今天的RAD工具比十年前要好，但是我们仍然有很长的路要走，直到他们产生嵌入式开发开发团队引以为豪的代码。然而，如果使用得当，RAD工具可以极大地加速开发。
