关于BPL开发过程中，对依赖包的编译管理问题

[Harryfin]

实际用过BPL开发的应该知道，这种结构虽然好，但是有个很麻烦的地方就是难以判断哪些包需要重新编译。尤其是较深层次的核心包变动后，有时会引起上层包出现莫名其妙的地址错，即使是增量添加东西，有时也会如此，似乎是视乎变化程度的。当然如果只是改内部实现，一般就没影响。

欢迎大家讨论开发过程中是如何管理这种变化的，或者列举必然会导致上层重新编译的一些情况，以便在开发过程中保证好程序的稳定性。

应avan_lau版大建议重新开贴讨论。我先抛砖，坐收宝玉：

管理方法：

对界面以下的逻辑层BPL编写测试用例，通过自动化测试尽可能发现这些编译引起的回归BUG（参考判断条件：更新后发生，已查看代码确定没问题，但实际地址错）；一般下层把这些问题消灭了，界面出现问题的几率就低很多了。界面暂时没好的方法，有可能的话也自动化测试吧，但是有一定难度，因为CS客户端界面操作一般都比较复杂。实在不行就手动点一下主要的功能吧

[shuicaitian]

太不幸了，刚花了40分提问了一个类似的问题，就发现诸位达人在这里的讨论，怎么没早30秒发现呢~~

[kirin_zjl010]

fdsafsdafsdafdasfdsafsad

[wozhuchuanwei]

昨天我也遇到同样的问题，从大家的回复来看，目前应该还是没有一个好的办法解决这个问题。如果每次都依靠BUILDALL去解决这个问题的话，模块一多，到时候分发出去也很麻烦的。哎……

[勉励前行]

用接口也是会产生依赖的,是否產生依賴與是否使用接口無關。
關鍵是通過各種接口能將依賴去掉，所以　包依賴　只與設計者相關，也就是說：
“你想讓兩個包有依賴關系”或者說，程序設計人員　不想花時間將兩個包之間的依賴去掉，只想自己方便。

設計出了問題，不去討論如何解決設計問題，反而努力想辦法為不良設計打補丁，捨本逐末不是上策。

開發管理是讓程序井井有條，程序亂七八糟的象蜘蛛網樣，也叫管理，只是有個專門名稱：放羊式管理，那是為天才程序員而做的管理方法。

程序管理，不只是體現在文檔的管理上，不只是多作注釋代碼規范化，不只是列出BUG修復BUG...
分了層而不去遵守，分了包而任意引用，分了模塊而任意復制...這些不良行為應該納入管理的范疇。而不是聽之任之，然後讓後面的人去幫前面的人擦屁股。那些代碼文檔規范，如何寫注釋，如何分行，如何起變量名,如何等等只是枝節。切莫撿了芝麻丟了西瓜，很多管理者只會抓些細節，而對類層次體系前景，良好的模塊及接口，問題分解建模等與程序性命相關的東西卻不加經營管理，直接放羊，只見樹木不見森林，是管理不好一座生態森林的。

程序井井有條，應該有一個清晰的類體系，有明確可行的設計目標。團隊間更多地討論如何分工合作，如何更有效合作解決新問題，而不是只會埋頭苦干，管理得好就是 1+2 > 3 ，管理差勁就是一盤散沙，1+2 < 3 .

寫著寫著，跑題了。　當是發牢騷好了。

[Harryfin]

[Quote=引用 123 楼 ppower 的回复:]

用接口也是会产生依赖的,是否產生依賴與是否使用接口無關。
關鍵是通過各種接口能將依賴去掉，所以　包依賴　只與設計者相關，也就是說：
“你想讓兩個包有依賴關系”或者說，程序設計人員　不想花時間將兩個包之間的依賴去掉，只想自己方便。
[/Quote]
接口包之间存在依赖很正常啊。。。。

上层接口包继承下层接口包的时候，两个接口包不是依赖了吗？下层接口包依赖公共包的时候，不是依赖了吗？这种依赖都是正确的依赖啊。。。

我现在是宏观地去讨论这种当包之间有依赖关系时的一个管理问题，管它这个包是接口包还是实现包。为什么大家就是不明白我的意思，唉。。。

[Harryfin]

感觉大家绕来绕去还是在说分离接口和实现这里，请大家相信我已经把这步做好了，做法请参看spring的思想。

所以，请提出其它方面的建议。

[「已注销」]

讨论的前提，先搞清楚包为什么需要重新编译？
被依赖包的接口部分(就是单元的interface部分和窗体文件的dfm)变化了的时候，才引起依赖包需要重新编译。这一点是确定的。

接下来的事情，见仁见智。我的原则是低耦合。

[勉励前行]

我的看法是：包的依賴是設計時就定下的，如果因為包的依賴而產生管理上的問題，那難道不是設計上的問題嗎？
或許Harryfin的看法是：只要使用包來設計，就不可避免產生包依賴的問題，就肯定會存在包依賴的管理問題。

我覺得這是我們看待這個問題的嚴重程度不一樣而出現的情況。我認為良好的設計可以忽略包依賴帶來的問題，不良的設計則會讓包依賴的問題放大。這是一個程度問題，就如BuildAll,深度依賴時，BuildAll影響很多包，BuildAll時間會長，如果只是少少依賴，BuildAll並不會花多久時間。我們可以從設計上避免深度依賴。如果說，這項目已經是深度依賴了，所以要找方法對付它。直接的方法就是將深度依賴轉化為簡單依賴，更進一步明確包的用途。如果是想辦法去管理一大堆深度依賴的包，就如我上面所說的捨本逐末了。

就如合理設計的樓房不會有諸多的采光不良通風不良問題。　當討論采光不良通風不良時，自然不可避免設計問題。

正常情況下，因包依賴而進行的管理是很輕微的，當因為包依賴過多而產生很大的管理代價的話，是設計者的問題。這就是我的看法。因為有多種設計方法避免這種現象的發生。當出現這種現象後，也能通過更改設計而減輕包依賴的管理至可以忽略的地步。包越多，依賴體系越清晰明確而不是相反，絲毫不會造成管理上的困難。

從另一個側面說，我是不願意討論如何不更改設計而管理一大堆復雜依賴的包。

[Harryfin]

[Quote=引用 127 楼 ppower 的回复:]

我的看法是：包的依賴是設計時就定下的，如果因為包的依賴而產生管理上的問題，那難道不是設計上的問題嗎？
或許Harryfin的看法是：只要使用包來設計，就不可避免產生包依賴的問題，就肯定會存在包依賴的管理問題。

我覺得這是我們看待這個問題的嚴重程度不一樣而出現的情況。我認為良好的設計可以忽略包依賴帶來的問題，不良的設計則會讓包依賴的問題放大。這是一個程度問題，就如BuildAll,深度依賴……
[/Quote]
你的意思我明白。

但是我不明白为什么你老是强调是设计有问题呢？我想向你请教124楼说的设计哪里出问题了呢？例如说几个项目都要引用一些项目间通用的组件时，几层的传递是很容易就出现的，你的讨论是只盯着一个项目吗？

[Harryfin]

还有你对我为什么要减少BUILD ALL的理解搞错了。

尽量少BUILD ALL，完全不是为了节省时间，能省多少时间呢？为什么要BUILD，要BUILD就说明你的组件（可能）还存在不稳定的因素。从组件化开发的角度来理解，稳定的组件都是直接拿来用的。而且我BUILD ALL一般也只是BUILD项目自身的部分，公共部分是不BUILD的（或者说是有需要的时候单独BUILD，绝对不会项目BUILD一次就跟着BUILD一次）。我是在这个前提下来提出这个问题，分析哪些情况需要BUILD，哪些情况可以不BUILD的，有没有办法可以做好这方面的管理的。

[Harryfin]

最后我想说你对“依赖”这个词太敏感了。

我想你应该明白“依赖”和“耦合”的含义是不同的吧？“依赖”分正确的依赖和不正确的依赖，不正确的依赖才可能会导致“高耦合”。

[勉励前行]

公共部分是不BUILD的,这个前提太苛刻了。相信写公共包代码的那部分人不甘心受此限制的。

几层的传递是正常的，不正常的是跨层的引用。一层超过3层的都会小心论证是否需要那么多层，超过5层的就罕见。包引用的是否合理并不在于层数的多少，如果包引用是明确而简单的，即一个包明确于体系中的哪一个层次，并依赖于哪几个包。它的修改会影响什么包都是事先知道的，那管理上的问题在哪里呢？

“要BUILD就说明你的组件（可能）还存在不稳定的因素”不是这样的，当上一层包修改时，包机制就是要BUILD，否则选择使用COM组件开发，那会好很多，但也不能保障不用Build。

BUILD ALL一般也只是BUILD项目自身的部分，公共部分是不BUILD的, 这个建立正确的项目组文件就能达到。哪些情况需要BUILD，哪些情况可以不BUILD，这个只有该包的编写者才会知道，现在delphi编译器也没有智能化到这地步。当然如果你只是要列出什么情况下的代码修改需要rebuild，那话题会不一样。

我不是针对你而说，我只是就事而论事。正确的依赖不会给管理造成多大的难度，并不是说没有依赖。到现在我的理解是：你所说的包管理难题，只是如何少Build，或者说如何知道哪些包要build,如果设计有清晰的包引用体系，这不是一目了然的吗？分层的设计，就如看着地图说出哪几个省与北京相连一样，难在何处。如果包体系设计成公交车路线，蜘蛛网一样，要说出某个点的改动影响了多少路线，就有难度了，所以我认为管理的难度是包体系设计的问题， 就多花笔墨在合理的包体系设计上。

如果公共部分不修改当然不用Build那部分,难道是想公共部分要修改，其他包又能不用Build,只有有限的特例才行，那不是包机制所能达到的。相信这点大家都清楚。

[火龙岛主]

[Quote=引用 100 楼 harryfin 的回复:]

貌似大家的回复已经变成讨论接口实现了，这个道理我明白。。。

其实我主要是想讨论的是管理方式，就是说，不管你怎么分，都要面对的一个事实。
[/Quote]
接口也是一种管理方式啊，就是为了解决耦合而产生的一种技术。
没有什么东西是绝对的，条条大路通罗马。

[Harryfin]

[Quote=引用 119 楼 smallhand 的回复:]

引用 100 楼 harryfin 的回复:

貌似大家的回复已经变成讨论接口实现了，这个道理我明白。。。

其实我主要是想讨论的是管理方式，就是说，不管你怎么分，都要面对的一个事实。

接口也是一种管理方式啊，就是为了解决耦合而产生的一种技术。
没有什么东西是绝对的，条条大路通罗马。
[/Quote]
我已经在回复中反复说明我已经进行接口实现的分离了，而且做到了动态配置实现包。

问题用接口也是会产生依赖的呀，这是无法避免的。所以本文的重点在于讨论依赖方面的问题。

[sandok]

学习学习

[Harryfin]

[Quote=引用 120 楼 harryfin 的回复:]
貌似大家的回复已经变成讨论接口实现了，这个道理我明白。。。

其实我主要是想讨论的是管理方式，就是说，不管你怎么分，都要面对的一个事实。

接口也是一种管理方式啊，就是为了解决耦合而产生的一种技术。
没有什么东西是绝对的，条条大路通罗马。

我已经在回复中反复说明我已经进行接口……
[/Quote]
例如说Release Build，或者PPower提到的一些管理方法，是我期望的讨论方向。

[Harryfin]

[Quote=引用 131 楼 ppower 的回复:]
“要BUILD就说明你的组件（可能）还存在不稳定的因素”不是这样的，当上一层包修改时，包机制就是要BUILD，否则选择使用COM组件开发，那会好很多，但也不能保障不用Build。
[/Quote]
我的意思肯定是说在不修改的前提下了，修改了就可能要BUILD，其实现在想跟大家一起总结经验，归纳下哪些情况要BUILD，哪些情况不用BUILD而已，例如说接口变了、类属性变了肯定要BUILD，但是类方法实现的更改就可以不BUILD。从而我提出了是否可以通过判断DCP版本的变化来达到自动化判断的目的，因为我们知道DCP是BPL的编程接口，就象DLL的EXPORTS一样。就算从发布的角度来讲，对于应属稳定的部分，也是越少重新发布越好。

至于你谈到的合理包依赖我想就不用继续展开了，我明白你的意思，实际中我认为我的包划分上是合理的。所以我希望重点还是放在编译问题的解决方法或预防措施，而不是花大时间去谈接口和实现的解耦，有需要的话，我可以再开一个帖子讨论。即使你说的可以很好管理，但是随着时间的推移，引用公共部分的项目越来越多，版本不断变化，即使再好的管理，也难免会有疏漏的时候，假如有一个好的检验方法，不是更好吗？

[勉励前行]

通过判断DCP版本的变化来达到自动化判断的目的,是不行的，至少是不可靠的。因为DCP文件并不会记录内存布局的改变。而且不能对比DCP不同版本间内存布局是否产生变更。

如：当类(结构)中变量(虚函数)的次序只是改变后顺序时，此时内存布局更改，DCP无法识别。而原则上，内存布局改变，函数接口改变，均要rebuild。一些库，因为使用编译开头的原因，使得DEBUG版本与release版本的内存布局或接口不一样，这类包，需要使用正确的包，否则是比较容易出问题的。

一个好的检验方法但不是一个可靠的方法，不如简单的BuildAll。我还是坚持是否需要rebuild 由包修改者提出通知，通过版本管理系统(SVN等)分发源码或成品包给其他小组。如果不这样做，采用项目共享全部源码的方式，建立适当的项目组文件，可以由MakeAll来识别是否需要重新编译。MakeAll就是做这项工作的，在项目组文件及项目文件适当的时候，MakeAll可以做得很好。 MakeAll可以避免buildAll产生的文件日期更新引发的其他项目也自动build的问题。 我的经验是为每个小组建立易于工作的项目组文件及适当的批处理文件或脚本。

利用批处理文件删除当前项目产生的BPL文件，通过MakeAll快速重建BPL,此时会正确连接最新版本的依赖包,可以解决部分问题，但内存布局更改可能会使得旧的dcu文件失效，还是要Build才可靠。当然，有条件的话，服务器自动的每日BuildAll，然后自动分发，会工作得更可靠，小组成员只要每天早上工作前 update 一下。

我的观点：
通过判断DCP版本的变化来达到自动化判断的目的,是不可靠的,无法达到目的。

[Harryfin]

嗯。。

听听还有没其它高见，然后结帖

[jAmEs_]

正被这个问题所困，好烦，我以为都用Delphi开发为主，所以编译都是静态编译的，没有什么感觉，因公司是BCB和用BPL发布的，现在考虑做公共包，才现在这个依赖问题非常严峻，处理不好会很麻烦。
我就不明白D/BCB为何每个单元都要导出Initialize/Finalize，为何不是包自己管理，为什么这样说呢？我们知道，当有A.bpl/B.bpl，A依赖B，B开始有B1类，双双编译后，A引用了B1，所以产生依赖，后来B增加B2类，尚未被其他程序使用，A此时无需编译，运行很好，说明B2类导出与A无关，但是你重新编译A，就会发现A要依赖B2所在的单元甚至是B2的函数，完全没有理由。。。如果你此时B移除B2，很不好意思，你A必须重新编译，完全晕倒。。。