××底层开发手记--第一次负责项目随笔

2006-8-05

    今天接到了一个开发任务－－新架构的××底层开发。
    老××底层开发到了今天这个地步，可以说已经相当出色地完成了它的责任和历史使命，但是目前也越来越体现出各种不足和缺陷.
    首先，几个主统计程序修改起来相当困难。不知道当时处于什么样的考虑，老的程序底层是用c写的，当时的开发人员可能也没有想得那么全面，使用了过多的全局变量，封装性上做的不好，更不要说面向对象和复用了。其次 每个应用程序是独立的，当然这也有相当的好处，程序之间相互独立，也不会互相干扰。但是当程序的数量急剧增加以后，这样的系统会很分散，部署起来也有相当的困难。最重要的是开发时期，重复工作量比较大，每个程序都需要独立编写，独立维护。
    基于这些暴露出来的问题，决定采用新的××架构进行改写，设计的总体目标是：绝大多数业务只需要通过进行一些配置即可实现。

2006-8-06
   
    今天上面调派了人手过来，三个开发人员，加我一共是4个人，但是要在20号左右，也就是两周的时间完成。又是时间紧，任务重，貌似每次项目都少不了这个话题， 呵呵。“一个人经常以一个角色的角度取考虑问题，他慢慢就会融入这个角色”，，哈哈，这句话可能是我自己在梦里想到的吧。要准备会议讨论内容，初步拟定开发计划了。
   

2006-8-07

    第一次拟定开发计划，着实费了不少时间。
   
    这次的开发要采用公司其他系统的framework来开发，这对于我来说相当陌生， 是个全新的领域，幸亏调来的三个兄弟在这方面都有一定经验。
    团队目前看来只有4个人，三个兄弟是开发方面的高手，其中一个相当有经验，另外两个也不错，对于framework都有不少了解。而我，一方面C++已经很久不用了，重新拾起来需要点时间，对新的framework也不是太了解，所以开始的时候，我以业务主导的方式切入团队，同时一方面熟悉框架，一方面温习C++。我想采用XP的开发方式，集体讨论，结对编程，不过可能结对编程较难实现吧。
    我把这段时间划分为三个阶段，每个阶段有相关的产出，明天要开小组会议了，准备会议室，准备会议讨论议题。
    虽然都弄出来了，不过第一次做这些东西，多少有点心虚啊。

2006-8-08
  
    开会讨论了，对于总体的开发计划大家好像没有太大问题， 可是也忽略了一个最严重的问题，对于开发的三个兄弟，他们对于××开发的需求根本没有了解，对于需求理解的不透彻，导致他们根本无法针对我的计划提出更多想法和意见。
    怎么才能让他们最快的理解需求，这才是目前最需要做的事情。之前安排的计划中， 这个方面的事情完全没有考虑，所以看来计划是白写了。。。
    补救措施： 小组讨论会议和底层开发需求文档同时进行，并且以讨论会议为主！

2006-8-10
 
    经过两天的讨论，三个开发人员基本明白我们目前的底层需求和思路。不过我的需求文档并没有实质性的突破，一方面，我没有时间把它写得很详细，另一方面，就算我能写得很详细，相信也没有兄弟会仔细从头看到胃，有问题还不如直接问我。
    上面催得很紧，领导总是希望在最短的时间看到系统原型。我简化出几个实际统计的例子，通过和主力开发人员讨论业务流程，让他们明白了真正我们想要的东西，同时也明确了：“所有转换通过配置文件进行”这种方式的真正意义。
    在这期间，我也画出了我心目中的第一版类框架图，给大家提供讨论.

2006-8-12

   将我印象中的第一版类图改为0.5版，哈哈， 不过本来就是给大家参考的。在V0.5版类图基础上重新规划了正式的第一版类图。小组会议讨论了工作分工，将类图细化，完成详细设计的阶段开始了.

2006-8-13
  
    开发人员设计的程序架构我完全理解错了，本来我是以为，一个程序独立运作，完成调度，取数，转换和汇总。但是发现他们的想法是“5个程序”，这种程序架构我还是第一次使用，有点心里没有底，不过主开发人员是从之前的计费项目过来的，对于这个结构深有体会，那么就相信他们吧。以有经验的开发人员的思路为主线，再加上自己的体会，应该可以复合整体的要求，又能够互相学习，何乐而不为呢。

2006-8-14
   
    这次的小项目里面，主导开发的哪个兄弟，属于比较“野战派”的，为什么用这个词呢，他本人开发实力还是相当强的，但是却不重视文档，画图也有点不伦不类，这样造成一个困难就是他自己有想法，但是可能我们完全没有理解。今天才知道，他的想法和他画的类图完全不是一回事，所以我把类图做了进一步的修改，方到小组会议上讨论。
    好像我们都有这样的思维惯性，如果自己知道的东西，总会以为别人也是知道的，这时候，就体现出系统结构图，类图的重要性了。这些示意图则可以清晰的描述出自己对这个系统的构想，以达到小组各成员间的相互理解。为了整理概要设计，同时也是自我总结，我画出了系统的工作关系，我不知道是不是该用协作图去表示，没有什么这方面的基础，，先画出来再修改吧。

2006-8-15
    小组会议，他们对我的类图又是没有什么太多意见。。。。。真的有点郁闷了。
    不管怎么说，小组各个成员也基本了解了，项目进入了开发阶段，，离计划书时间只有5天了，，有难度啊。
    我本人也负责了一块代码实现，主要是负责调度器部分的实现。。其中在定时程序启动的功能上，遇到了不少麻烦，既要判断相同的程序是否正在运行，又要判断分钟级的模糊匹配。

摘录一个网游的文章：

以前一直做性能优化方面的工作，考虑问题总是习惯性的从性能方面入手，加上一直以为数据结构和算法在程序中的重要性，尽管原来一直负责系统的架构，但还是养成了一种钻性能牛角尖的坏毛病。当然性能的确是一种功能，设计时应该加以考虑，但不应该因此束缚自己的思想，比如自己也早就知道反射，也知道反射能给项目带来很大的灵活性，但一想到其性能，所以在以前应用到的时候，总是比较谨慎，甚至有些保守，能不用的尽量不用，但这样也的确造成项目在灵活和扩展上有些力不从心。还有包括DataGrid，DataSet,DataTable等的使用上也存在类似的问题。所以以前的系统，虽然在性能上的确不错，但总是感觉不理想。其实作为合格的项目经理或者系统架构师，首先要学习的就是放开自己的思路，充分利用自己掌握的知识，依据具体需求，完成自己的设计，当然作为架构师级别的人物，综合考虑各种技术的利弊也是必须的。比如我们可以在大部分运行在局域网，有限量的人数访问，承载量和网络压力都不是太大的应用程序中，用性能来换取应用程序的灵活性，反而也是。
放开自己的思路，挣开某些固有认识的束缚，才能设计出更新，更好，更有创造力的系统。

2006-8-17

    今天，组内对于一个类的定义产生了较大的争论，一个开发人员A认为某个文件读取类是整个系统的底层，需要独立出来，单独处理，而另外两个开发人员并不愿意用这个类，一方面他们各自负责的代码搞的七七八八了，不想再为这个类做大幅度的修改。另外，时间已经比较紧张，不太允许他们再次修改代码。
    而我对这个类的看法是：读写文件是一个比较公共的类，不只是当前系统，甚至可以复用到其他的地方，但是在本系统中，他的“共用性”没有想像的那么强，只是在解析和转换的地方用的比较多。第二，时间和人力资源的限制，已经没有时间和人力去单独处理这个类，并且其他模块也不能说等这个类做得七七八八再搞。所以，基于上面的考虑，我决定暂不将这个类独立出来让其他模块使用，而是让开发人员A根据自己的需要先处理，如果日后这个类写的足够好，自然可以推广到其他模块使用，提高代码的复用度。目前最主要的目的是发布一个能够工作的最原始版本，然后再不断叠代改进。

    晚上写笔记，回想起来问题应该出在： 开始时对基础类的定义不清晰，以至于开发人员不知道如何使用，自然也无从使用。就会用自己的方法取处理。由于对基础类的定义不清晰， 也导致了对基础类的工作安排根本没有，固然也没有时间去仔细写这些基础公共类.

 2006-8-21
    今天在数据入库的时候又做了一些改动，就是汇总器单独进行数据汇总，而另外写一个入库程序，负责对汇总好的数据进行入库操作，这个东西应该是有现成的代码，拿来稍微修改一下就可以使用的。
    经过三四天的努力，调度器和取数器终于可以联合调试了，还真是出了不少问题。之前写代码的时候， 只是保证能够编译过就好了，也没有连接数据库，没有在实际UNIX环境下运行。联合运行的时候后，发生了不少异常和core down的情况。总结原因，很大方面也是对环境的不熟悉造成的，这里的环境包括对新的frameworkf的了解以及对UNIX环境的了解。
    在这两天的开发中发现几个自己急需加强学习的地方：第一个是STL相关的东西，尤其是map，hash_map.第二个就是排序，这部分是和第一部分是相关的，尤其是各种容器所使用的排序算法，以及在各种不同条件下判断应该使用哪种排序算法最优。

2006-8-22
    对进度方面有些担心。进度方面越来越不好把握了。不论我怎么解释，一个开发兄弟总觉得时间并不紧急，已经延误计划2天了。
    截至晚上10点，在两个测试用例上，调度器和取数器已经可以联合工作了。这是目前唯一值得稍微欣慰的事情。明天开始我就要暂放下程序开发的工作，而去做一些文档汇总的工作，要开始编写“操作手册”初稿了。即要写代码，有要写文档，又要协调各兄弟间的工作，好累，真的好累。
    晚上11点， 和老沙（开发兄弟之一）一起回家，路上我问他，是不是我对他的工作复杂度估计得太低了，他没有直接回答，只是说软件这东西的复杂度和工作量很难估计，能够不翻倍就算很准了，如果想估算得很准确，首先要对系统架构，底层非常谅解，并且要非常了解开发人员的能力才能达到。我不知道他是在安慰我还是怎样，这次的开发中，采用了新的framework，新的语言，新的数据库环境，并且彻底打翻了之前的程序架构，在这些种种不稳定因素之上， 还附加有开发周期是那么的短，我甚至有点怀疑在这么短的时间内，使用这么多新的方案和技术，领导层的决定是否正确……
   
2006-8-24
    今天的一件事情对我教育深刻。
    一位同事在浏览××（底层开发成员之一）写的代码的时候，觉得他程序的可读性不够强，逻辑也不够清晰（我本人也有点这个意思）。由于小史和那位同事没有直接的工作关系，所以也不好说什么，之后在找我聊天的时候，他又提及了这个事情，问我的想法。当时我也没有多想，就说我比较认同另外一位同事的看法。××的观点认为本来模块的复杂度就不高，没有必要再分很多模块调来调去，之后就稍微有了一点争执。
    晚上回想起来，自己的观点虽然没有什么问题，但是提出的时机和场合是非常有问题的。设想自己是××，自己辛辛苦苦写好了代码之后，被这个人说，被那个人说，心里是什么滋味。这时，真的突显出谈话技巧和心理学的重要性了。并不是每个人都是对自己代码追求精益求精的“狂热者”，当他在别人处听到逆耳的声音后，能够来找我聊，应该是在潜意识中已经把我划在了统一战线，而我却直接给他泼了盆冷水……这件事应该这样处理：要揣测当事人的心理，当我表达出自己的看法以后，如果对方没有接受的意思，那么在那种情况下，我应该立即转移话题。把这个话题放在之后的代码优化主题讨论中，或者向我们的直接上级反应这种情况，让他去协调。尤其是当我和谈话人没有直接隶属关系的时候后，尤其要注意。

2006-8-26
    在我自己的开发基本完成以后，我主动把撰写相关文档和手册是工作揽下来了。虽然从整个小项目角色方面考虑，我做这方面工作完全是多余，但是从实际的角度看，在开发这段时间，我主要的工作是完成自己的功能模块，然后协调其他兄弟的工作， 所以我对他们代码的熟悉程度非常低。这三个开发的兄弟中间肯定有开发完这个项目然后调离小组的，这样的话，至少我必须对他们的代码有一定了解才能行。处于这样的考虑，我才主动请缨，将这份文档的活揽了下来。同时，也能当成只用锻炼吧，
    截至到晚上，几大模块基本都完成了，明天整个小组放假休息一下，一张一弛文武之道嘛，下周开始，就不进行独立的功能性测试了，而是将工作终点从测试转向实际业务，我们会将已经写好的概要设计“放进”我们的系统中，模拟是实际的情况，边试运行边调试.

2006-8-28
    这两天仿佛进度陷入了僵局，各部分联调的时候，不是这里出问题，就是那里出问题， 没有想到根本的办法根治。。。
    还好的是开始将业务逻辑放到配置表中，实际测试了， 这也算是一种进展吧……？不知道这里该用什么标点符号， 是问号还是省略号。

2006-8-29
    在取数器做数据集的转换的时候后，各个字段的转换顺序， 有时候需要依赖定义的顺序，而我们将公式数据做了排序映射到共享内存中，这样会导致某些字段转换不了。
    如果一个小组内对某个问题的看法有分歧，应该怎么协调解决呢？
    一位朋友说， 应该根据他们各自的看法， 谁的对系统开发的推动力最大来权衡。“推动力”这个词用的好， 而不是仅仅用一个“谁有道理”来解释。比如某个人的看法是，系统观应该更灵活，更有弹性，应该慢慢开发，不要着急。而另外一个人说要先开发出系统原型，在不断叠代改进。就纯观点来说， 两个想法都是没错错误的， 而在实际的开发当中，则需要考虑开发周期，设备资源，人力资源等诸多问题才能决定。并且人与人之间的交互也并不是一件简单的事情。

2006-8-31
    截至今晚， 终于将所有流程跑通了， 能够成功转换出数据， 也可以入库了， 可是效率还真是个问题，目前1W条9个字段的记录，转换时间要2分钟多，如果上千万，那不是死人了。。。下面就要把优化放到首要位置上来考虑了。
    考虑最近大家开发都比较累，拼死给几个兄弟申请了各一天轮休的机会，也算自己尽的一点绵薄之力吧。
    代码规范和代码优化还是一个不容忽略的问题，等做了这一部分工作以后，将现有的东西完善， 沉淀，形成新的框架就要逐步得提到日程上来了。 回家， 睡个安稳觉了。
    Zzzz...

2006-9-04
    最近的进度还算比较顺利， 看着一个又一个业务逻辑放进我们的底层框架，顺利的运行，一颗悬着的心也逐渐平静下来。此时，又有一个问题摆在眼前，那就是：总会有一些比较怪异的取数、转换逻辑，在现有的系统中不能通用的，遇到这种情况该怎么办呢？经过讨论，有下面几种方案可以选择：
   
    在现有转换器中加入特殊处理模块，
    独立的特殊处理接口程序
   
    结合目前的情况，转换器功能还在不断稳定中不希望在大范围得更新转换器代码，所以想采用“独立的特殊处理接口程序”的方式来实现，同时，考虑到上载时候的需要， 采用动态挂载so文件的形式处理。这样做的好处和坏处都是比较明显的：
    好处是：功能强大，处理灵活，实现方便。
    坏处是：由于有过于灵活的配置，有可能导致放弃规则配置，而只使用这个自定义接口进行处理
    我们还是决定采用这种配置方法进行处理，至于他带来的坏处，我们还是先通过行政上的方式进行管理吧。
    在小组讨论这个问题的时候后，又一个问题浮出水面。自我评价， 还是可能有我做错的地方在里面。小组一位兄弟，一直比较要求说程序都需要支持双操作系统平台运行，即windows平台和unix平台都可以运行。我也觉得这是个不错的方法，所以就考虑在不增加太多工作量的情况下，如果可以在windows下调试程序，当然是个极其爽快的事情。所以我也比较接受这个想法，也没有考虑太多，就积极推行这个想法的实施。但是直到今天我才意识到， 我可能犯了个管理的大忌：我不应该在没有争求全组大多数成员同意的情况下，强行推行一项新的政策和规定。
    再好的东西，如果强行要在一个新的环境中推行，都有他的难度和风险，尤其是当小组里面的成员，并不十分认同的时候。虽然听课也听过，看资料也看过， 例如，UML是好东西，但是在实际的应用中又不能生搬硬套，一点一点实施和改进。但是当遇到实际问题的时候， 还是考虑不到。经验啊经验，又是一个教训。
    
2006-9-06
    今天，我向组长全面地汇报了一次目前小组的工作状况，包括程序的进度，小组成员之间的问题。我最近有点迷茫，不明白自己的定位，不明白自己是否值得复出这么多。太累了。。。
    还好有一点，组长对我的工作有一个比较中肯的评价，优点和缺点都比较明明显，优点就是能将几个兄弟比较好的团结在自己周围，共同为一个目标战斗。缺点就是对全局的掌控不足，这里又主要体现在“技术背景的不足”。
    他也明确提出，最近基本没有怎么跟进我这边的事情，可以说是放手让我去搞。这可以说是一个挑战和机遇并重的环境。
    我是不是要考虑考“系统设计师”去了，自身的能力急待提高。

2006-9-14
    很久没有写日记了， 最近也没有发生很多事情，一直都是“套业务－修bug/加功能－套业务”这个循环，到了这个节骨眼上，想不用这个框架都不行了，经过一段时间的努力，系统的处理速度也得到了一定的提升。稳定性也不错了。目前只是希望上到正式系统上的时候可以正常运行。
    到了现在，在这个项目里面，我的工作也算基本完成了，回想起来，好坏参半吧。几个明显的缺陷有：对系统某些部分的难度评估不足，导致到了开发后期，这几个模块的开发进度拖延。对系统的整体把握不足，由于自身的积累和知识有限，在某些方面做决定的时候，显得犹豫了。还有一个不算好也不算坏的地方：由于为了学较多的东西，自己动手才与了较多的代码开发工作，这样带来的好处和坏处都是很明细的，好处就是能够掌握较多的代码细节，坏处就是在管理上花费的时间就大打折扣。当然，这种情况在几个人的小型团队开发中也是在所难免的。在这段时间里面对人际关系的处理，也学习了不少东西，总得来说，还是颇有收获的。
    项目日记到这里也算一个段落吧， 以后如果遇到大的版本更新再进行追加。也不再写什么大口号类语句作为结束了，嘿嘿。