修改升级程序

　　今天花了点时间在修改升级程序。这个程序完成后，一直没有进行过有效的测试，而是直接给别人用了，呃，这里的别人指的是部门内的其他有项目升级需求的同事。实际上，至少有3个其他项目中使用了这个升级程序，但我自己却没有真实地体验过。总的说来，这个程序在功能上，基本能满足当前的绝大部分需求，从当初的质量部的地个项目中独立出来后，一次大规模重构，代码结构作了不小的调整，当然这调整的原因是原来的架构已经不能适应后面增加新特性的需求了。
　　曾经倒也是规划过一个比较长远的版本计划，呃，也许不能称之为版本计划，称为需求实现计划更合适一些。不过后来还是剩下几条没有实在，因为没有工作量分配过来了。今天的投入则是现在发现，在某些情况下，它会崩溃，这是最不能容忍的致使问题。不过很无奈的是，原来没有使用google breakpad来生成dump文件，现在加入了这功能后，暂时也没能把它弄崩溃，于是也压根不知道问题出在哪里。只能听天由命了！

今天面了几个人

　　也算是体验了一把面试官的感觉，好好玩哦，看着有些人紧张的样子，想想当年自己在学校时那紧张的情形，只能感叹时间的匆匆流逝！

兴致缺缺

　　又要开始做环境设计编辑器了，几乎是全部重新做过。这次的计划是自己画，可是现在的我却兴致缺缺，想当年，嗯，也就是一两年前吧，我是多么的希望可以自己动手专心地实现一个这种图形编辑器啊。
　　我现在的想做的是把自动分析崩溃报告的事情做好。不过这种事情收益有一些，不过却不是主要业务，因为对用户来说，没有多少良好的体验可以从中体现出来。唯一的好处是，开发人员可以减少工作量，嗯，这点上我倒是真有点典型的程序员风格——懒惰！

同样的操作，三处代码错误

　　今天下决心修改一个崩溃的问题，只要快速打开多个文件，再通过菜单“关闭所有”窗口时，就会崩溃，通过一次又一次的崩溃实验，分析每一次的dump记录，居然意外地发现每次崩溃最后的堆栈信息都不一样，总共有三处代码。
　　把这三处代码仔细推敲之后，发现确实有可能引起崩溃的原因，而这样的代码如果让我仅仅是通过正常的审视，是绝对看不出什么问题来的。修改完这三处代码，再实现，又暴露出另外一个崩溃的问题，也是那些代码附近，真是汗颜啊！

多线程下载有问题

　　给升级程序加了多线程http下载后让同事试用，结果今天他打来电话报怨下载速度太慢了，甚至比以前单线程的时候还慢。用netmeeting看了一下，发现本来预计有5个线程同时下载的，现在居然是5个线程一个接一个地进行下载，这样明天会比单线程的要慢了，因为多了几次等待网络连接的时间，而且事实上自从改用多线程后才明显感觉到有时候一个网络连接的等待是好久，可能是十几秒。我在虚拟机里又试用了一下，还是5个线程并行的，那就郁闷了！
　　后来又想到一些可以改进的地方，但没动手，只是记到todo list里了。
　　唉，钱好少！

线程阻塞在连接操作

　　今天终于把升级程序的http下载部分改成多线程下载了，用的WinINet用5个线程同时下载，发现总是会有1到2个线程会阻塞在连接操作上，这是花费时间最多的地方！暂没想到好的办法，先这样了，对于大文件来说，确实能提升不少下载性能。

挨批评了

　　唉！！！

超级牛掰的升级程序即将现世

　　发现在有很多事可以做，发现自己一件都不想做，哈哈！
　　今天老大跟我说，是不是忘了件事，那个gem升级也得做进升级程序中去。我说那不是说另外还要用wxRuby做个程序的嘛。老大说，这种建功立业的好机会，怎么可以让。我狂晕！
　　找原来开发这个功能的同事咨询了一下基本原理，发现简单得令人发指，当然这种实现方案在我看来也是丑陋得一塌糊涂。看了一下他的代码，发现原来真的是那么一回事，基本的代码结构和思路都是很清晰的，除了有一些废旧的注释和代码。
　　我开始头痛界面的问题。原来的实现使用了XTP的ReportControl，我想这么一个原本应该尽量精简轻巧的升级程序现在已经被我弄得渐渐肥大起来了，再加个XTP就太恶心啦！而且另外一个问题也已经浮现，越来越多的命令行参数，已经让眼下那种依次比较字符串的方式不再继续适用，引入boost::program_options也势在必行，天哪！

让人恶寒的囧问题

　　今天发现一个很囧的问题，在保存文件的时候出现堆破坏。跟踪了一下，看到的代码才让人一阵恶寒。先到文档类中的保存代码，该函数会在之后向主窗口Post一个消息，主要是把保存的文件路径发送过去，这个文件路径保存的空间是在堆里动态分配的，到了主窗口中处理该消息的代码直接把该消息Send到另一个视图，而这个视图中处理该消息的函数会取出这个路径，最后销毁这块内存。问题就出在这块内存上，原先发送方把这字符串以ANSI形式表示，后来整个工程从ANSI转换到UNICODE后，只修改了处理消息的那边，而没有跟着修改发送消息的这边，于是两边认为的内存块大小就不一样了，于是就堆破坏了。而让我恶寒的是另外一个原因，为什么要向主窗口Post个消息，再由主窗口转发一遍。一方面运行效率低下，另一方面就是接口变动后不容易找到受影响方，这次就是活生生的例子。我想，用个observer就可以缓解这些问题吧！

今天进度不错

　　花了近半天时间，把about对话框弄完了，不过有点小问题，不能设置tab页的title。整天琐事很多，最近把崩溃问题解决方案稍微整理了一下，说实在的，我心里是没底的，这个任务对我来说似乎要求高了些。我也希望程序能7×24小时地运行不中断，可是无论怎么弄，稍有点复杂的功能肯定就埋藏了大量的bug。

要被Excel整死了

　　今天发现原来我的机器上一直跑得好好的程序，到其他机器上就不行了。于是另外找了个装了Win2003和MS Office2003的机器上调试，发现首先我用了一个Excel2003中不存在的接口，Excel2007中是有的。于是绕了个圈子也勉强达到原来的目的了。
　　接着发现把图表copy到系统剪切板中再取出来存成图片的文件不行了，根本枚举不到GIF类型的剪切数据。在网上找了个剪切板观察工具，发现确实没有那个数据，不是程序的问题，原来Excel2003的接口功能就是要比Excel2007弱。于是绕了好远的路，换个接口，把图表当成图片copy到剪切板中，发现剪切板中有Meta file picture类型的数据，再用Win32 API把这数据保存成文件。很扯的是这文件不知道是不是需要什么句柄释放操作，反正直接是不能修改或删除的，不过还好能复制。接着用GDI+把这个wmf文件转换成jpg或gif。结果郁闷地发现，转换后的图表背景变成全黑的了，想了好多办法，转来转去都是黑的，只有wmf和png看起来是白的。其实大概是透明的，整了好久都没办法，下班的时候跟老雷说起这个事情，老雷说先设置一下背景色。我真想拍一下自己的脑袋，怎么就没想到这点呢！
　　明天再去弄了。

有点儿疯

　　星期天去参加1783的石头河溯溪，结果被小路晃点了。溯溪回来跑去南山找阿布拿手机，然后去他家吃晚饭，见到了他老婆，真没想到啊，他儿子居然2岁多了，真以为是90后的呢！吃完饭，坐了一会儿，一群人决定去唱K，结果不知道喝了多少酒，反正第二天是谁把我送到的士上的我也不记得，迷迷糊糊回到家，倒头就睡，于是，一天没上班！
　　今天去上班，不知怎么的，情绪很低落。整了个版本给人测试，发现根本没法用，几个严重问题，崩溃、崩溃、还是崩溃！以前的设计有问题，或者说压根没考虑到后来会需求会变化那么大，这实在是可以原谅的。这次还有一个重大的变化是，模板文件中加入了宏，于是用COM操作后再关闭会问你要不要保存修改，尝试了半天，发现只要先关闭workbook，再关闭workbooks，再退出就可以了。因为关闭workbook时有个参数可以指定是否要保存修改，而且关闭workbooks时则没有，会自行弹出个消息框来确认。

同事要走

　　今天旁边的同事突然问我有没有空一起去吃饭，本来还以为算是几个同事的年终聚餐，结果到了餐桌上才知道，原来他马上要离职了，就在这三四天里会办完手续。
　　这样自发地跟项目组里的同事出来吃饭，我还是第一次。我真是个很奇怪的人，当年在测试组时，第一年，也是不跟测试组的人一起活动，直到后来搬了家，才开始慢慢和他们一起玩。发现自己其实很势利啊。
　　今天喝了一点啤酒，话也多起来了。平常跟同事说的话也不多，而且脾气也挺坏的。说了很多公司的事，有点惆怅，也许跟我这几天心情本就不好有关吧。
　　人来人往，没有终点。

检测不到Excel文档的修改

　　昨天偶然发现，我的程序根本检测不到Excel文档的修改，太让人郁闷，之前完全没料到这个结果啊！后来回想一下也想通了，Excel文档那么复杂的一种文件格式，不使用像txt之类的修改方式，完全是可以理解的。不过理解归理解，问题变得棘手了，怎么才能实现那个需求呢！
　　今天没写代码，倒是在自己建的wiki上写了几篇文档，有关于设计方案的，也有关于使用说明的。我要开始准备撤退了，出于道义上的，或者说职业道德上的考虑，也是为了让自己以后少被人骚扰，我要输出尽量能解释清楚我目前所做的一切的文档。
　　写文档也是个很累人的体力活啊，也许是因为几乎从来不写文档，让我觉得很多事情都不知道从何说起。心中很清楚明白其中的每个细节，却不能用文字表达出来，或者说即使能零碎地写些文字出来，却不能有效地串连起来，形成完善的文档。
　　今天质量部的老大把我叫去，谈了一下之后的计划，我刚好趁此机会明白地告诉他，我对之后的维护性质的工作实在没多少兴趣的，而他居然出乎我意料地说，如果是这样的情况，可以换个人，而且还肯定了我之前所做的，这让我心里比较高兴，哈哈，仰天长笑！

最近脾气比较坏

　　被另外一个同事说了两次了，说我最近越来越酷了。今天我就问哪里酷了，他说竟然敢当面顶撞王总了。我心中冷笑，多从来不认为公司里这种领导对下属可以指手划脚，颐指气使，我从来只觉得领导也不过是个打工的，只不过与其他下属的工作内容不一样，他的职责不是领导人，而是协调各种资源，包括人力。
　　不过最近脾气比较坏倒是真的，我完全是被搞烦了，我也顾不上那么多了，气不过我就要反驳。今天早上的站立式会议时，我还对老大出言不逊了，我就直言他们对COM的过度热衷和盲目崇拜。
　　后来老大找我沟通，说我是不是对现在的项目很有情绪，我说是不爽，而且感觉付出和回报不成比例，付出得太多，回报得太少。
　　下午在回顾今天发的版本发现的问题后，质量部的人又在那里摆了很久龙门阵，知道我们想要撤出，便在那里说了一通项目的前景，个人的前景，画了好大好大一个饼，呵！

解决构建时间超长的问题

　　今天终于搞明白为什么昨天构建我的项目要2个小时了，原来是内存耗完了！
　　本来一直没这种问题的，也就昨天突然发现，我的项目集成构建一次，最多的时候要206分钟，瀑布汗！当时还以为是中间的哪个环节出问题了被阻塞在那里了，看了下进程状态都是好的，主要的时间都花在doxygen生成文档上了。但看看doxygen也是正常的，有条不紊地dot。
　　其实昨天就已经搞好了，因为当时发现本来2GB的物理内存，又设了2GB的虚拟内存，可是看看整个系统的内存使用量居然也是3GB多。关了一票的没用的进程，包括普通应用程序和系统服务，发现又变快了。
　　今天重启了系统，同样关掉那些没用的服务和应用程序，再看CruiseControl，终于恢复正常了，15分钟就能完整地执行完一次构建！
　　唉，服务器资源还是有限啊！

用wiki记录开发文档

　　前天，公司请MS的人来做交流，我也去听了一下，虽然只听懂了20％～30％，还有有翻译，尽管翻译的水平不咋的，连蒙带猜的大致上也能搞明白他在讲什么。其中让我印象最深感触最深的一个实践，是用wiki记录开发文档，其他人也可以修改文档，有新人加入时，就可以通过wiki进行学习，我深以为然。
　　昨天，老大提出，我们项目组也要组建公共知识库，也包括开发文档。有个同事提出，他倾向于使用Word文档来进行记录这些内容。这不禁让我开始思考，用wiki和用Word来记录开发文档，各有什么优缺点。
　　大体说来，我是倾向于用wiki的，因为我觉得wiki的形式更能鼓励人们不断跟着代码变化而自发地更新文档，并且wiki一般自带版本管理功能，使用更方便，另外一方面，开发文档并不需要多丰富多样的格式，有简单的文本和插图一般够用了，而Word文档拥有的其他功能，可算是累赘了，比如要比较两个版本的差异，就相对要麻烦一点点。
　　说到底，我其实最看重的是wiki形式的约束下，人们会更多地完善文档，我们项目组目前的一大问题是，并没有多少文档，代码中偶尔有几行注释就算是全部的文档了。假如我们也像产品开发人员那样有非常详细的从SRS到HLD，再到LLD，那用wiki和用Word文档，或者其他什么记录形式，根本没有区别。

加多4个tab页

　　今天整了一天，把原来的一个列表，整成了5个tab页分成的5个列表，每个列表显示不同的内容。
　　这次是深切体会到当初设计的草率，把许多应该放在文档类中的数据成员和方法都放到视图类去了，结果现在本来还是同一份数据，要给多个视图共享使用时，就需要大量的修改。
　　不过这样的修改从长远看来，说不定是塞翁失马。不光结构上有调整，在某些接口实现上，也有修改。总的说来，比又前更合理，更简单。
　　当然一天下来，功能匆匆忙忙实现了，代码实现细节上却没有多加考虑，还是需要后续重构的。比如有一份代码，在4个视图类里各写了一遍，应该是用模板方法可以重构掉的，还有份代码，在2个视图类里各写了一遍。以前遇到这种情况可能会头痛一下，现在有了之前的使用boost.funciton和boost.bind的经验，应该很自然地能解决了。
　　本来这个需求并不是最紧急的，但是一方面我自己比较想做，另一方面，它涉及到的面比较广，早弄好，其他部分也方便点。

轻车熟路的需求实现

　　今天去整编辑器了，加上了函数定义的跳转功能，总共大概花了4个小时左右吧，因为没有功能良好的语法解析器支持，所以基本没什么技术含量可言了，就是判断一下当前光标所在位置的单词，假设该单词是一个类的方法名，去数据库中查询一下该方法所在的文件路径和行号，如果有多条记录，则弹出个对话框，列出所有的位置，让用户自己选一个。
　　下午的时候跟老大说，老大竟然说我做那么快，看来以后得多分点任务。我郁闷！不过做这部分的时候，倒确实有点轻车熟路的感觉。添加对话框，给对话框添加必要的控件，给控制添加必要的消息响应，等等。以及添加新的类，在类中实现该它实现的功能。
　　不过又想到语法解析器，没有它，做什么都是残废的，唉，什么时候一定要抽时间实现一个。

对目前项目状态的不满意之处

　　程序终于改得主要的核心功能比较稳定了，这是最让我觉得安心的事了。这个项目无疑是到我投入时间和精力最多的项目了，中间过程也是竭尽全力、绞尽脑汁、使出全身解数，充分发扬拿来主义，使用了好几个第三方的开源代码，大概列数一下就有ACE、Boost、iconv、zlib等。眼下流行的工程方法，开发方法也被我有选择地用了一些，感觉自己的水平确实也有了一定的提高。
　　但是我还是对项目、对我自己并不满意，随便列举一下。
　　对系统的总体架构不满意，目前只有客户端，我的想法是至少要是C/S结构的，但是这样无疑会大大增加工作量，这也是眼下的无奈之举。
　　对系统的性能和稳定性不满意，这是代码规模稍微大了点就出现的问题，而且一直也是无能为力的，这方面要有所改进，可能会涉及到整体架构的变更。
　　对开发模式不满意，纯粹的乱搞方式，没有完善的流程和规范，敏捷很好，却没有实行起来。
　　对程序结构和编码能力不满意，有不少看起来很丑陋的设计，有不少看起来很丑陋的代码，这点基本上可以通过开发人员的主观努力慢慢提高的。
　　对自动化程度不满意，现在可以在每次build时自动修改资源中的版本号，每次commit后又可以通过CruiseControl自动集成最后生成安装文件，但测试却只有少量单元测试，还有崩溃报告每次只是通过邮件发送到邮箱中，照我的理解状况是有一个后台服务可以自动收集这些崩溃报告，然后自动进行分析，把尽量详细明显的分析报告提取出来，而且对于已知问题可以直接提示用户。
　　对持续集成程度不满意，中间的各种测试、度量功能没有好好地利用起来。比如圈复杂度度量、源代码行数度量、重复代码行度量、PCLint、单元测试等等，有的没做，有的做了却没关注。
　　对与客户之间的关系非常不满意，开发人员太弱势，对于需求基本上没有拒绝的权力，在我看来做了一些可有可无的功能，还做了一些愚蠢错误的设计，对于版本规划等主动权也不够。
　　这些是大的几点，有的是可以通过自己努力得以改进的，而有的则会涉及到其他方面的人，则只能听天由命了，呵呵。