关于BPL开发过程中，对依赖包的编译管理有关问题
关于BPL开发过程中，对依赖包的编译管理问题
实际用过BPL开发的应该知道，这种结构虽然好，但是有个很麻烦的地方就是难以判断哪些包需要重新编译。尤其是较深层次的核心包变动后，有时会引起上层包出现莫名其妙的地址错，即使是增量添加东西，有时也会如此，似乎是视乎变化程度的。当然如果只是改内部实现，一般就没影响。
欢迎大家讨论开发过程中是如何管理这种变化的，或者列举必然会导致上层重新编译的一些情况，以便在开发过程中保证好程序的稳定性。
应avan_lau版大建议重新开贴讨论。我先抛砖，坐收宝玉：
管理方法：
对界面以下的逻辑层BPL编写测试用例，通过自动化测试尽可能发现这些编译引起的回归BUG（参考判断条件：更新后发生，已查看代码确定没问题，但实际地址错）；一般下层把这些问题消灭了，界面出现问题的几率就低很多了。界面暂时没好的方法，有可能的话也自动化测试吧，但是有一定难度，因为CS客户端界面操作一般都比较复杂。实在不行就手动点一下主要的功能吧
------解决方案--------------------
对于客户端界面操作的自动化测试，不知Harryfin是否用过test Complete？只要录下每个功能的操作，以后每次 就可以自动化执行测试了；
对于依赖包的管理，我认为这在运行期判断，应该比较有意义吧。
1、包管理器：记录每个包的版本——可以透过package的版本信息选项控制，更新bpl时一并更新；
2、自行加载包时，取得实际包的版本，比对包管理器中的版本，判断是否一致，依次给出提示；
也应该写一个编译工具，这个编译工具应该具有哪些功能：
1、source：添加工程项目，给定目录，自定取得相关包的source；
2、路径：取得delphi中的环境路径的设置；取得工程文件或包中的路径设定；
3、批量编译，同时输出编译信息；
4、维护一份该工程所用包的版本（编译后自动记录新版本）；
5、还没想到..
^_^ 个人愚见，不足之处，请见谅！
要写这个工具，有点复杂。要先挖掘一下DCC的命令
------解决方案--------------------
尽量减少包依赖关系.被依赖的包的功能尽可能精减,这样平时就很少需要修改被依赖的包,被依赖的包不被修改,就不会出现这个问题了
------解决方案--------------------
我的理解是
要么想办法 把 Delphi 编译器 和 源代码都提供给程序（隐藏起来），自己去编译。
否则，就用版本号来控制哪些bpl变动过。（千万不能吝惜 Build 号）。
最坏打算就是全部更新。
------解决方案--------------------
除了重新编译，实在想不出更好的办法，事实上，也是这么干的。
公共BPL包一旦确认，几乎不用修改，除非有Bug存在，所以，基于这个话题的前提根本不存在。
从管理角度讲，公用包更新了，及时通知分发、项目协调倒是更直接的难题，感觉讨论这个更有意义。
------解决方案--------------------
实际上包之间的依赖中，直接依赖还是比较明显的，也是比较容易剥离的。
困难的是间接依赖，就是说如果有A,B,C三个包，A引用B，而B引用了C，这个时候A也相当于引用了C包。
当这种层次嵌入过多的时候，就比较的困难区分了。
因此，要避免这种情况的发生，就需要规划好包的分类。
不能够简单的按照业务或者功能来分，有时需要二者结合起来效果会更好。
需要Leader根据业务需要不断的总结和调整才能达到满意的效果。
------解决方案--------------------
实际用过BPL开发的应该知道，这种结构虽然好，但是有个很麻烦的地方就是难以判断哪些包需要重新编译。尤其是较深层次的核心包变动后，有时会引起上层包出现莫名其妙的地址错，即使是增量添加东西，有时也会如此，似乎是视乎变化程度的。当然如果只是改内部实现，一般就没影响。
欢迎大家讨论开发过程中是如何管理这种变化的，或者列举必然会导致上层重新编译的一些情况，以便在开发过程中保证好程序的稳定性。
应avan_lau版大建议重新开贴讨论。我先抛砖，坐收宝玉：
管理方法：
对界面以下的逻辑层BPL编写测试用例，通过自动化测试尽可能发现这些编译引起的回归BUG（参考判断条件：更新后发生，已查看代码确定没问题，但实际地址错）；一般下层把这些问题消灭了，界面出现问题的几率就低很多了。界面暂时没好的方法，有可能的话也自动化测试吧，但是有一定难度，因为CS客户端界面操作一般都比较复杂。实在不行就手动点一下主要的功能吧
------解决方案--------------------
对于客户端界面操作的自动化测试，不知Harryfin是否用过test Complete？只要录下每个功能的操作，以后每次 就可以自动化执行测试了；
对于依赖包的管理，我认为这在运行期判断，应该比较有意义吧。
1、包管理器：记录每个包的版本——可以透过package的版本信息选项控制，更新bpl时一并更新；
2、自行加载包时，取得实际包的版本，比对包管理器中的版本，判断是否一致，依次给出提示；
也应该写一个编译工具，这个编译工具应该具有哪些功能：
1、source：添加工程项目，给定目录，自定取得相关包的source；
2、路径：取得delphi中的环境路径的设置；取得工程文件或包中的路径设定；
3、批量编译，同时输出编译信息；
4、维护一份该工程所用包的版本（编译后自动记录新版本）；
5、还没想到..
^_^ 个人愚见，不足之处，请见谅！
要写这个工具，有点复杂。要先挖掘一下DCC的命令
------解决方案--------------------
尽量减少包依赖关系.被依赖的包的功能尽可能精减,这样平时就很少需要修改被依赖的包,被依赖的包不被修改,就不会出现这个问题了
------解决方案--------------------
我的理解是
要么想办法 把 Delphi 编译器 和 源代码都提供给程序（隐藏起来），自己去编译。
否则，就用版本号来控制哪些bpl变动过。（千万不能吝惜 Build 号）。
最坏打算就是全部更新。
------解决方案--------------------
除了重新编译，实在想不出更好的办法，事实上，也是这么干的。
公共BPL包一旦确认，几乎不用修改，除非有Bug存在，所以，基于这个话题的前提根本不存在。
从管理角度讲，公用包更新了，及时通知分发、项目协调倒是更直接的难题，感觉讨论这个更有意义。
------解决方案--------------------
实际上包之间的依赖中，直接依赖还是比较明显的，也是比较容易剥离的。
困难的是间接依赖，就是说如果有A,B,C三个包，A引用B，而B引用了C，这个时候A也相当于引用了C包。
当这种层次嵌入过多的时候，就比较的困难区分了。
因此，要避免这种情况的发生，就需要规划好包的分类。
不能够简单的按照业务或者功能来分，有时需要二者结合起来效果会更好。
需要Leader根据业务需要不断的总结和调整才能达到满意的效果。
------解决方案--------------------