软件开发实战（一）

架构设计

• 保证抽象层次性一致。
• 对于非常大型的项目来说，物理设计是项目成功的决定性因素。
• 软件架构，很重要的一条就是open-close原则，要清楚哪些是可变的哪些是不可变的。
• 面向對象本身只解決了“結構”和“編程方法”的問題，而並沒有對“流程”加以改造。

编程语言

• 语言只是软件开发的一环而已，单凭语言并不能应付业务和工程上的问题。
• 语言方面，若已掌握了了C/Java，那么C++/Python/Bash/Javascript等都应该了解一下概念，至少要理解在一个完整的产品链里，它们分别适用于哪个环节。

构建与运行

• 重用别人的包时，将build下的内容清空，因其中可能包含有机器相关的信息，如路径信息等，这些信息将导致编译无法通过。
• 当编译器给出的错误信息涉及“.cpp”、“.h”文件时，有可能是头文件路径配置有误，当错误信息涉及“linker”、“.obj”、“.lib”时，则往往可能是库文件路径或依赖输入项配置有误。
• 头文件是和编译器无关的；而库文件及可执行文件是和编译器相关的。
• 使用编译器的最高警告级别。

编码风格

• 头文件集中存放，而不要分散开来。
• 除std名字空间外，其他名字空间一律不打开。
• 头文件的名字都是类名。
• 与所维护文件中已有的体例保持一致。
• 全大写字母表示宏。
• 不用Tab，用若干空格，如4个空格，以表示缩进。
• 取函数地址的时候，显示地使用&运算符。
• 不在注释中重复写代码语义，因为这会造成不一致。应该写的是解释方法和原理的说明性注释。
• 消除代码中所有的字面值。禁止任何的写死操作。ROS系统是“把代码写活的生动例子”。
• 当工程规模逐渐增大时，文件的规范命名就是重要的。
• 完全封装好的类没有公有数据。从逻辑角度来看，数据成员只是类的实现细节。
• 不要写自己都不想读的代码。
• 请从作为代码提供者的角度体谅代码作者：
  1.编译配置文件的书写是机器相关的，需要使用者主动修改；
  2.注释大多为自注释，这是人之常情。
• 後台的計算應一貫地採用標準單位，否則後患無窮。只有需向用戶顯示信息時，才採用非標準單位的數據。
• 每个函数须经过彻底的测试方可投入使用。
• “好”的函数的一个特征是，既有入口参数，又有出口参数，返回值则是一个状态标签，用于表征函数的执行状态。
• 建立自己的程序工具箱，是一个提升效率的不错选择。
• 能用加法的不用乘法，尽量避免浮点数的除法运算，因为浮点数的除法运算非常慢。
• 力争把程序写活。例如，从文本读取参数就不需要重新编译程序，这个体验很好。
• 編寫軟件系統時，各個模塊要高內聚低耦合。一个文件包含不必要的頭文件，是造成C++中過多耦合的常見原因。
• 当需要传递给函数一个大对象的时候，千万不能传一个对象，而要传址（要么用指针，要么用引用）。不要说这样的内存开销非常巨大，就算开销不大，也禁止使用，因为运行错误可能在所难免。
• 不要混合使用绝对路径和相对路径。

数据结构

• 關聯容器一般是用二叉樹實現的。其元素默認已按升序排好序。
  例如，set的插入方法時間複雜度是O(log(n))。

算法设计

• 掌握住循环就掌握住了程序的生命。
  而掌握循环的关键是当循环嵌套时，分步写内层循环，并归纳出外层循环的规律。接着，对其正确性进行全方位测试。
  这玩意儿有点可意会不可言传的赶脚。

并发设计

• Linux平台下创建多个进程比较容易实现。Windows下就比较困难。两个经典的案例是：ROS和對管道操作的天然支持。
  在Windows环境下，尽量用多线程而不是多进程。
• 线程安全的设计方法：RAII 。
• 参考链接：https://solarianprogrammer.com/2011/12/16/cpp-11-thread-tutorial/
  It is the programmer’s job to ensure that a group of threads won’t block trying to modify the same data.

实用工具

• 做代碼維護時，beyond compare和Meld Diff是必不可少的工具。