6/12/2009，2009-6-16

11:58 AM 6/12/2009
关于RaymanHD Tracker想到的：
    雷曼工程非常大，重新编译一次要花费很长时间。如果测试中出了问题，就要从新打包
    发给QC部门，需要更多的时间。这就要求程序的子模块有很高的灵活性。比如，当雷曼
    在测试过程中出现丢帧，那么我们可以关闭一些繁重的模块来进行观察，因此要求模块
    有很好的可配置性。

    Tracker在结果JF审查后，在模块初始化的时候加入了网络检测，如果网络不可用,
    Tracker就不做任何事情。在雷曼出现丢帧以后，我们可以断开网络，这样就关闭了
    Tracker模块，方便定位丢帧的源头。
    当然，还可以有比这更好的设计。

    所以在这里，模块的需求包括了：       
        调用模块的程序员需要方便的接口
        项目组需要稳定高效地实现功能
        测试人员需要灵活地更改配置以快速测试功能
        模块的实现者需要方便地跟踪模块的运行情况以修复出现的问题
        其他程序需要代码有很好的可读性，方便维护
        为了满足自己的虚荣心而炫耀的技术
   
    这么多需求，可见写代码的时候需要考虑很多因素，因此要非常小心仔细。可以在写代
    码的时候，把所有你能想到的需求全部罗列出来，有针对性的进行设计和编码，可以避
    免以后发生的很多问题。

    思考：
    如果“发现问题，修正问题，测试”的过程非常快速，我们还有必要进行预见性的设计吗
    ？
    测试驱动的开发倾向于根据验证需求的测试来指导开发，那怎么处理那些不能代码化的
    需求呢？

无情的设计
    越高级的语言，可优化的地方越少，因为细节被封装起来了。 --《unix编程艺术》
   
    拿C++的STL中的字符串函数来说。如果不清楚一些函数的复杂度，大量使用这些函数就
    成了非常低效的代码。那么对于STL来说，把一切复杂问题都封装起来，确实给用户带
    来了很大的便利，但是却强制要求用户理解底层模型，写出高效的代码，程序的执行效
    率问题无情地扔给了用户，这是很不负责的表现。
       
    我的意思是，如果强调程序的执行效率，又不找个好的方式来解决，出了问题就是你自
    己的责任了。
   
    对于STL字符串的问题，我的建议是，如果强调执行效率，就要以某种方式提醒程序员
    这个函数复杂度高要少用。可以在文档里面写，可以通过培训，可以写到代码审查里，
    甚至可以严厉禁止。你不能要求程序员对所有的函数底层模型都很了解。。。

2009-6-13
关于《unix编程艺术》中的程序清晰原则：
    使程序的内部清晰可见，那么程序就会被很好地受你的控制。这些技术可以运用到程序
    中：
    日志系统：监视程序的运行状态
    错误输出：unix在很早就将标准错误输出加入到标准流设备中，日志系统的另一种形态

2009-6-16 10:47:19
关于设计和态度
    设计是一项值得花精力做好的事情。        --《unix programming art》
   
    我现在遇到的问题是，知道设计应该花很多时间弄，于是在计划的时候估计的时间比较
    久。但是实际上我在时间到了以后，设计并没有做好。其中，我感觉是态度的问题。我
    觉得事情简单，然后三下五除二就弄完了，然后就自己看其他东西去了。。。在实现的
    时候才发现很多地方没有考虑好。。。
   
    自我建议：
        自己觉得弄完了，实际没有，这说明没有明确设计要满足的需求。可以将所有能想
        到的需求写出来，再让用户或者同事帮你审查一下。
       
        设计好不好，只有应用以后才能得到反馈。提前写一些伪代码来验证一下你的设计
        未尝不是一个好办法。
       
        别人的设计，在理解的基础上进行应用。简单的模仿别人的设计，又明白为什么他
        要这样设计，那设计出了问题谁负责，找原作者？这样的话，与其做一个仿制品还
        不如直接用别人的好。
   
自己实践的软件开发步骤
    需求阶段，明确软件是什么样子。what
        收集原始需求。用文字描述原始需求是比较合适的方式。原始需求往往直接明了，
        但是却很重要。
       
        需求归类。对需求进行简单归类，得到原始的需求模型。原始需求太散，需要把相
        关的功能进行归类，方便下一步分析。有的功能可以放在一起，而有的却不应该放
        在一起。
       
        完善需求。用活动图等工具来帮助整理原始需求模型，添加或者删除类和功能。原
        始需求模型并不完整，也不能展示需求的所有细节。完全弄懂软件该怎么工作是非
        常重要的。
       
    设计阶段，明确软件该怎么做。how
        系统架构。
            先尝试一种架构模型。画图先勾勒轮廓，轮廓决定形状，就像有的人画人物，
            先画骨架。架构就像骨架，支撑起整个软件。是用分层模型还是C/S模型等；           
           
        分析系统复杂度。
            合理的架构需要把复杂度管理在可控制范围内。
       
        分析关键需求。
            架构必须很好的满足关键需求，否则架构就没有了意义。
            根据之前的分析做系统架构。系统架构应该产出一个可用的系统框架。
               
        设计模型并验证。
            设计需要用需求来验证。如果发现有不合理的地方就要调整设计。
       
        将原始需求模型转化成符合架构的类模型。
            设计出来的类应该是演化而来的，不是凭空捏造的。演化的目标是能够放入框
            架中工作。类就像骨头上的肉，附在骨架上。            
           
        将关键活动图转化成顺序图。
            顺序图可以在一定程度上验证设计，也可以找人帮你看看你的设计到底存在什
            么问题。
       
    实现阶段，开始做软件。do   
        根据设计阶段的类图填充代码。       
        做单元测试。单元测试保证代码按照要求工作。
       
    测试阶段，验证软件的质量。complete
   
关于软件工程
    目前我们需要开发软件，从需求到实现，全部是由程序员来做。一个问题是，3个阶段
    需要3种不同的思维模式，一个职责单一的程序员很难做到一个阶段只用一种思维考虑
    问题，而且很难考虑周到。明确的分工是必然需要的。