ROSE 编译器框架/经验教训
我们在这里收集一些过去经验教训需要做的事情。
教训
- 一位开发人员试图理解一位员工的源代码。但是他发现代码的缩进对他来说不正确。因此，他重新格式化了源文件并提交了更改。后来，这位员工发现他的代码被更改得太大了，他再也无法阅读它了。
- 更糟糕的是，人们将难以合并混杂着缩进更改和实际更改的更改。
解决方案
- 请不要重新格式化你不拥有或不维护的代码。
教训
- 我们有一名学生被分配了一个办公桌，它位于一个大房间的角落里。这台办公桌距离其他实习生也很远。结果，这位学生与其他人的互动减少了。他不得不解决问题时获得的帮助也更少。
解决方案
- 位置很重要！坐在你应该经常与之互动的人旁边。让你的办公桌/办公室对其他人来说容易接近。物理上孤立的办公室/办公桌可能会对你的工作效率产生非常负面的影响。
教训
- 不知何故，新的实习生默认被分配了 Mac OS X 机器。但他们中的一些人可能不熟悉 Apple 机器，甚至不喜欢 Mac OS X 的用户界面，包括键盘、窗口系统等（对 Apple 产品的爱恨情仇）。因此，他们感到被困在一个不舒服的开发平台上。我们有一些实习生即使在一个月后也无法在 Mac 键盘上流畅地打字。这是不必要的。
解决方案
- 提前提供选择：Linux 或 Mac OS X。提醒人们，他们可以选择自己喜欢的平台。
教训
- 一位开发人员使用同一个 Git 仓库的不同分支来执行不同的任务：修复错误、添加新功能和编写文档。后来他发现他无法提交和推送一项任务的工作，因为其他任务的更改还没有准备好。
解决方案
- 为不同的任务使用独立的 Git 仓库。这样一项任务的状态就不会干扰其他任务的进展。
教训
- ROSE 最初不依赖于 Boost C++ 库。但后来，一些开发人员看到了 Boost 的好处，并提倡使用它。最终，Boost 成为使用 ROSE 的必备软件。
- 但是 Boost 库也有其缺点：难以安装（看看我们公开邮件列表中有多少 Boost 问题），缺乏向后兼容性（使用旧版本的 Boost 的代码在新版本上会出错），巨大的头文件，包含复杂的 C++ 模板，这会减慢编译速度，甚至会破坏一些编译器。
- 我们仍然在内部就如何处理 Boost 进行辩论。这通常是一个痛苦且情绪化的过程。
解决方案
- 非常谨慎地引入大型软件依赖项。否则你会很容易陷入困境。
- 至少要求那些提倡新的软件依赖项的人负责维护它 5 年，并同时提供一个关闭它的选项。
教训
- 一位开发人员创建的测试过于宽泛，主要是因为它们是在开发后期才包含进来的。这会导致本不应该通过的测试通过，也就是说，即使代码已经损坏，所有测试也都会通过。
解决方案
- 确保测试仔细检查结果。通过确保你的函数只有一个目的，这会变得容易得多。例如，如果你需要转换数据并对转换后的数据进行操作，请将转换和操作拆分成两个函数（至少）。
教训
- 一位开发人员在最初编写代码时没有添加注释，后来又回到了代码中，不得不经历一个艰巨的任务，去理解
他自己的不可读代码。
解决方案
- 保持变量和函数名有意义。边写边做完整文档，不要留到以后再做。
教训
- 一位开发人员在编写代码时没有考虑到结构。这导致了臃肿且难以阅读的代码，需要多次
重构。
解决方案
- 程序员必须编码和设计，而不仅仅是编码。结构良好的代码比结构不良的代码更容易阅读。
教训：一位开发人员编写代码时，没有了解用户真正需要什么。这导致了严重的重构，如果他一直专注于用户，这些重构本来是可以避免的，或者至少可以变得更简单。
解决方案：尽可能向用户征求意见。从长远来看，这将为你节省很多麻烦。
教训：一位开发人员编写了一个相当难懂的组件，而没有完全理解用户可能想要用它来做什么。
解决方案：至少检查输入和输出是否符合用户期望，这将节省大量时间和烦恼。