今天考评，结果还是不出我所料，有点麻木地失望。不过这失望不是本篇blog的主题，这里要谈的是目前项目组里的重头项目，那个已经历了超过一年半开发的IDE。
这东西说要重构，我也已经开了个头，现在的情况是，老大说要在VSS上建分支。可是很明显的是，VSS根本就不支持这样的开发方式。这样就会引入一种新的问题，模拟分支，就有两份明显独立的拷贝，如果进行同步。修正问题在原有代码的基础上进行，重构则在新的一份拷贝上进行，以后合并代码对于现在的几个人来说，估计是个挑战，但我猜更多可能的直接是个灾难。
其次是架构和代码实现。现有的架构方式已经寸步难行了，但还是要在那个基础上继续进行。现在我是切实地体会到，编码产量高的，一点都不稀奇，相对来说架构设计则真的重要得多。一个文件，一个类实现，用C++代码实现，居然有18000行，这样的实现，功能确实做出来了，但后续的工作却举步维艰。一点小的修改，一点小特性的增加，都会牵扯到很多地方，可能引发很多问题。模块间的交互耦合，都没有经过良好的设计，都是觉得怎么容易实现，就怎么写，结果一堆一堆的重复代码，一个个超大的文件超大的类。
再次是加入特性没有经过认真评估，加入了一些完全不实用，花里胡哨的东西，而真正有用的功能并没有加入或增强、完善。比如about对话框，居然是一个视频文件，直接调用MCI接口播放实现。视频的周围则是一张背景图，背景图上的文字都是在图形处理程序中固定写死的，这样在以后每次显示信息修改的情况下，凭空增加了图片维护的工作量了。另一个是状态栏上的动态新闻，嵌入IE直接显示远程服务器上的内容，程序内部截获打开链接操作。大概是实现方式有问题，如果远程服务器宕掉了，则在程序启动时试图连接时，花费好几秒时间在那里阻塞等待。诸多问题，恕不一一列举。
最后是没有好好利用持续集成。虽然装了个CruiseControl，却只是为了实现点个按钮进行编译，连“持续编译”都算不上。一方面，没有实现“持续”，都是在需要时，手动点击一个按钮，进行force building；另一方面，只有编译，没有其他行为，比如代码度量、单元测试、打包发布等等，完全是个空架子。
其实回头看看这些问题，我觉得都是管理上的问题，单纯从管理层的角度出发，就能解决绝大多数。
总之，我对那东西很失望，因为管理者如果没有意识到问题根源，将在以后的很长很长一段时间一直存在，并继续恶化。而我能做的，大概就是假如有机会，把编辑器部分做完善点，在我能顾及到的范围内，实现一个类似Eclipse的扩展机制，仅此而已。因为今天听说，有人对编辑器评价很高，有人甚至就因为这个功能，就想把这东西拿到家里去用，这是我唯一的动力了。
支付宝扫一扫
微信扫一扫