代码的结构。

从底向上有A，B，C三层，每层有一些模块，上层调用下层模块。不同的客户，C的差异很大，C层有很多并列的分支，A和B

与客户的合作有不同的方式，有的是不给客户源代码，任何变动的需求都由公司完成；有的是给C层的代码，部分变动的需求客户自己解决；有的是给B层和C层的源代码，几乎全由客户自己完成变更。

有一个客户，合作方式是第三种。客户拿到代码后在B层和C层做了一些改动，改动部分模块以增加功能，或者是改变部分行为方式。

一年以后，主干树上的A层和B层经过多次升级，整个工程升级到新的版本，该客户希望能同步，但是要求保持其自主改动。

矛盾是：该客户在B层做的改动不可能合并到主干树上。而另建分支增加了与主干树B层的更新保持同步的合并动作，增加测试工作量，增加错误可能性。

怎么办？

我们只能是为其另建分支，而同步代码的维护工作长期占用了一个工程师的几乎全部工作时间。

事实证明，替客户维护已经发布给他的源代码是一件非常不可取的事情。

应该告诉他们，如果希望得到源代码发布，那我们将不再对这份代码做维护。

在实际的工程中，往往会出现callback函数的参数类型，定义和实际使用的并不一致。要注意强制类型转换。

在某个 struct 定义中使用了 union，而此 union 中定义了两个结构，第一个结构包含5个 UINT8 类型的成员，第二个结构包含1个指针类型成员，1个 UINT16 类型成员，1个 UINT8 类型成员。工程中两个结构都会使用到，而编译器无法知道程序使用的是 union 中的哪一个成员，默认为第一个。由此产生类型不匹配的编译警告，这里有产生错误的隐患。

一个项目，编译出近千条warning。

大部分大部分大部分是下面这四条导致的。

      1）局部变量定义后使用前没有初始化。
      2）函数体在调用处后，调用前没有声明。
      3）类型转换。
      4）比较运算符两边变量的类型不同。

输入：本地经度，本地纬度，卫星经度。

输出：卫星天线的方位角，仰角。 

需要数学库的支持，可调整M_PI的精度。