软件架构的一个设想以及谈一下过去两年开发软件的过失

最近在思考关于如何优化我们所做的软件的一个构想，是因为我们所做的软件在开发过程随意性很大，开发的时候准备不足，时间比较紧张，加上当时开发的时候软件几乎都是应届毕业生，反正没什么牛人，都是要自己一步一步研究过来的，现在公司的核心项目代码臃肿，结构混乱，维护麻烦，虽然需要增加的功能都能有，但是随着越来越臃肿的代码，现在问题已经凸现出来了，经常改动一个BUG需要动到好几个模块的地方

1.最严重的是数据和界面没有分离，有些东西甚至是存储在界面里面的，比如一个物品的状态，当时的代码是存储在界面里面的，去年年末需要根据产品做一个东西，需要收集大量的数据，结果傻眼了，很多东西都是要从一个界面里面去拿，一个函数依赖了大量的界面，这个有点搞笑

2.因为界面跟数据没有分离，导致模块间的通讯都是在界面层里面的，逻辑处理也放置在界面层，代码臃肿，最大的一个文件大概有6000多行，大概有100+个类成员函数，这样想维护都懒得维护

3.还是界面跟数据的问题，因为软件的数据有一部分是通过界面来通讯的，也就是说，一个UI的控件一旦没有创建，你的数据将无法获取，甚至导致程序崩溃，所以我们在软件的修改过程中，一旦一个功能确定一个UI控件不再使用了，我们不会不把他创建出来，而是hide掉

4.扩展性问题，我们的软件需要根据面对不同的客户来修改，我们是使用宏或者配置文件来使用的，经常因为需要一个小功能而增加一个宏，时间久了连有这个功能或者连这个宏是干什么的都不知道

5.版本管理问题，因为版本管理不是我在负责的，我也没有参与，但是我能明显感觉到一个问题，就是混乱，一个版本有时候连是哪个客户的也不知道,软件内部是根据一个宏或者配置文件来判断是否要改变，也就是说如果版本是发送给其他客户的，有时候需要开启一个宏来改变软件

6.通讯协议，整个软件都是使用原始的二进制的，包括需要存储到文件或者网络通讯的，这样的一个问题就是扩展性很差，一个协议一旦修改，另外一个通信程序的断言就会报错，为了能最大地兼容过去的协议，所以我们在增加协议的时候都是在结构体尾部进行添加，那天在调试程序的时候突然想到内存对齐的问题，我们的开发环境不同，有的人还在使用XP，有的则是WIN7，还有的是IDE是VS2008或者2010，而且就算是同一个平台或者IDE，可能编译器的优化也会不一样，毕竟用户的设置都是不同的，这样的话如果直接二进制读取的话将会有很大的问题，虽然这个问题现在还没出现过，但是还是要小心一下比较好

7.各个不同的进程间进行同步，也就是分布式软件间的同步，我们在对软件进行扩展的时候，有一个扩展就是视景，现在的一个问题就是由于软件的操作是即时响应的，但是视景的步骤是慢慢地来的，比如一个操作，我们在软件上按下后，如果在有视景的情况下，需要一个人走到指定的位置，然后其他的电脑上的进程才能继续往下做，现在我们的做法是，使用定时器而不是网络通讯来判断，定时器时间到了后就会继续往下执行，其实这个可以改成视景动画播放结束就发送消息通知，但是因为原有网络消息以及网络层的架构，加上如果这样，没有视景的话则无法调试(其实可以判断视景是否有连接，但是因为不想让程序继续膨胀，还是作罢)

8.代码大量重复，比如一个元素的绘制，因为在不同的软件上面，虽然最终绘制出来的形状差不多一样，但是因为原有软件的结构原因，以及编程过程中没协调的原因，最终几乎绘制代码是每个平台都一份

核心软件设计的反思:

我们的核心软件开发主要是使用C++，库主要使用wxwidgets，我这几天看了下，wxwidgets有一个库，可以根据xrc文件来创建窗口，但是没有事件响应，我在想把事件响应放在lua或者python的脚本文件里面，这样就可以实现界面，核心数据，逻辑的分离，整体的架构大概是这样子的，C++只负责来编写核心的计算部分以及数据处理

UI的消息处理主要由脚本语言写成，因为这个设计是仿照WOW的，所以我原本是想让UI消息处理使用lua，但是我后来想想还是使用python会更好，考虑有这么几个方面:

1.wxPython比wxLua成熟

2.python的应用比lua广阔

3.python的功能比较强大，库也比较多，以后尽量把功能放在python脚本里面而非核心程序里面

4.我看见了boost里面有python，因为lua跟C++的类结合还是挺麻烦的，如果能够有boost之类的库辅助的话，是很强大的，对于boost我还是很放心的

至于程序则使用单进程的模型而不是多进程，因为这样可以很方便地进行数据的通讯，因为毕竟我们做的东西更多的是跟数据打交道

这样的话，扩展性比较强，修改也比较容易，开发速度应该也能加快一点，当然前提是熟悉python，更重要的是，强制分离代码，因为在我们团队中有的代码还是写的比较随意，这种强制性的措施我想比批评以及惩罚来的让人容易接收

如果要使用这种开发方式，我需要考虑下面这几点:

1.团队配合是否足够??因为这种强制性的分离措施对于团队的配合还是很重要的，我记得当初写另外一个东西的时候我曾经强制性的要求别人不要修改另一个人的模块，结果导致开发进度缓慢，因为有时候一个人刚好需要这个功能，但是这个模块没有，他就需要通知另外一个人去添加，但是这个人没空，进度只能暂停下来

2.文档是否足够，因为是不同的dll使用，不像以前可以直接跳过去看代码内容就能知道这个函数是什么意思，如果这样的结构

3.C++和python的交互问题，这个也是我最关心的，比如list，如果UI消息处理需要获取到核心程序的一个list，那么python的接口是否方便，我该怎么样才能把一个数据传输给C++中的结构体

4.效率问题，因为很多人都说脚本语言的效率不高，那如果处理的数据太多或者频繁了，python是否需要花大量的时间去优化??

5.部署问题，因为我们的代码是不想让别人看见的，python能否满足这个需求??是否需要在别人的机子上安装python解释器??(其实我想可以写一个exe，exe什么都不干，就是把python的解释器嵌进去，并且运行一个脚本，这个脚本就是我们的启动脚本了)，即最后会有一个core.dll,很多的python脚本和xrc，以及一个负责启动程序的start.exe