【讨论】VS C++代码管理的问题

[u_lever_2]

我有一个自己编的动态库A，然后基于这个库的功能编了几个功能软件B C D……，也就是B C D都依赖于A，B C D经常需要改进升级，同时可能会对A做相应的改动。
为了保证A的唯一性并且方便调试，我现在是这么弄的：建立一个解决方案【S】，A B C D分别作为【S】中的4个项目。

这样做有几点好处：
1）跳转调试方便：比如我在开发升级B功能，但是发现需要对A进行扩展，这样在统一的解决方案中，可以方便的用F12在B和A的函数之间跳转，包括跟踪调试。
2）同步修改：接上例，如果A被改动了，我在编译的时候C D也会自动被编译为采用新版本的A。

现在发现的局限性：
1）系统复杂，容易出错：相当于编的所有的软件全部都在一个解决方案当中，随着新项目的增加，这个系统越来越复杂，而且互相之间要保持很好的兼容性。
2）移植性不好：我的程序结构是底层部分都在A里，表层部分在B C D里。比如B功能的底层支持需要一个第三方库LB，C功能需要一个第三方库LC，这样一来A就include并且在编译时链接LB和LC。问题来了，我在发布C软件时，运行会要求LB的存在。这意味着C的发布受到了B的拖累。
我也想过静态调用，但是还有一些其它原因制约了必须采用动态调用的方式，我无法解决更精细的编译控制（哪个静态哪个动态）。

请问大家，针对我的问题，有没有更好的项目代码的组织方式呢？

[赵4老师]

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

[u_lever_2]

老大，知道您水平很高，但是说的有点高深，能不能具体一点或举个例子说明一下

[u_lever_2]

引用 1 楼 zhao4zhong1 的回复:

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

老大，知道您水平很高，但是说的有点高深，能不能具体一点或举个例子说明一下

[u_lever_2]

引用 1 楼 zhao4zhong1 的回复:

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是说我遇到这些问题，本质上还是程序结构不合理而不是代码管理不合理是么？

[赵4老师]

引用 4 楼 u_lever_2 的回复:

[quote=引用 1 楼 zhao4zhong1 的回复:] 请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是说我遇到这些问题，本质上还是程序结构不合理而不是代码管理不合理是么？[/quote] 意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。 试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George 对学习编程者的忠告： 眼过千遍不如手过一遍！ 书看千行不如手敲一行！ 手敲千行不如单步一行！ 单步源代码千行不如单步对应汇编一行！ 单步类的实例“构造”或“复制”或“作为函数参数”或“作为函数返回值返回”或“参加各种运算”或“退出作用域”的语句对应的汇编代码几步后，就会来到该类的“构造函数”或“复制构造函数”或“运算符重载”或“析构函数”对应的C/C++源代码处。 VC调试时按Alt+8、Alt+7、Alt+6和Alt+5,打开汇编窗口、堆栈窗口、内存窗口和寄存器窗口看每句C对应的汇编、单步执行并观察相应堆栈、内存和寄存器变化，这样过一遍不就啥都明白了吗。 对VC来说，所谓‘调试时’就是编译连接通过以后，按F10或F11键单步执行一步以后的时候，或者在某行按F9设了断点后按F5执行停在该断点处的时候。 （Turbo C或Borland C用Turbo Debugger调试,Linux或Unix下用GDB调试时,看每句C对应的汇编并单步执行观察相应内存和寄存器变化。）

[u_lever_2]

引用 5 楼 zhao4zhong1 的回复:

[quote=引用 4 楼 u_lever_2 的回复:] [quote=引用 1 楼 zhao4zhong1 的回复:] 请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是说我遇到这些问题，本质上还是程序结构不合理而不是代码管理不合理是么？[/quote] 意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。 试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George 对学习编程者的忠告： 眼过千遍不如手过一遍！ 书看千行不如手敲一行！ 手敲千行不如单步一行！ 单步源代码千行不如单步对应汇编一行！ 单步类的实例“构造”或“复制”或“作为函数参数”或“作为函数返回值返回”或“参加各种运算”或“退出作用域”的语句对应的汇编代码几步后，就会来到该类的“构造函数”或“复制构造函数”或“运算符重载”或“析构函数”对应的C/C++源代码处。 VC调试时按Alt+8、Alt+7、Alt+6和Alt+5,打开汇编窗口、堆栈窗口、内存窗口和寄存器窗口看每句C对应的汇编、单步执行并观察相应堆栈、内存和寄存器变化，这样过一遍不就啥都明白了吗。 对VC来说，所谓‘调试时’就是编译连接通过以后，按F10或F11键单步执行一步以后的时候，或者在某行按F9设了断点后按F5执行停在该断点处的时候。 （Turbo C或Borland C用Turbo Debugger调试,Linux或Unix下用GDB调试时,看每句C对应的汇编并单步执行观察相应内存和寄存器变化。） [/quote] 确实高屋建瓴，多谢赵老师。我好好体会一下。