C++博客-(define (cuigang) (coding))-随笔分类-软件工程

切和剥

cuigang — Fri, 21 Dec 2007 11:36:00 GMT

——关于重构方式的设想

我们重构部分代码时，往往想到的是稳定，最好是不变接口，只变实现，保持接口的稳定性。但现实往往没有这么轻松，接口不变，意味着有着一个良好的结构设计，至少在功能职责划分上没有大的问题。而我们却时常遭遇这种职责的混乱，这种Martin Fowler不愿详谈的事情，对我们来说很麻烦。我们不能横切式的改变，这将导致大规模的变化，特别是对于层次靠下的部分，范围的扩大，无论是从控制能力上，还是工作量上，包括对系统稳定性的影响方面都是巨大的，兼容旧组件也许并不亚于推倒重来。

“剥”也许是个好办法，另辟蹊径绕开原来的设计，从底向上建立一条新的结构通路，将旧的部分一片一片的剥开，合并到新的部分中来，直到完成重构。就像做一个心脏搭桥手术。

cuigang 2007-12-21 19:36 发表评论

灌水

cuigang — Mon, 17 Dec 2007 14:17:00 GMT

有两种方式构建软件设计：
一种是把软件做得很简单以至于明显找不到缺陷；
另一种是把它做得很复杂以至于找不到明显的缺陷。
——C.A.R. Hoare

cuigang 2007-12-17 22:17 发表评论

20070419备忘——关于代码审查

cuigang — Mon, 17 Dec 2007 13:24:00 GMT

      代码审查除了显而易见的对源码本身正确性以及可维护性等方面的验证，交流和学习也应该是其目的之一。和白盒测试相比，在很大程度上有共通之处，但侧重点不同。代码审查更偏重整体性，而白盒测试更偏重局部性。
      代码审查一般基于3种目的，包括审查代码风格，审查正确性以及是否与设计相符，还有特定目的的审查，比如效率、容错性、安全性等等。对于我们来说，对于不同部分的代码，可能有不同的目的，有时候甚至多种目的结合起来审查。但是不论如何，每次代码审查都应该确定目的，有的放矢，否则可能很难控制时间和质量。
      形式上应该是多样的，针对审查对象，应该有自查，互查，小组走读等各种方式以区别对待，否则可能难以发现隐藏较深的问题，或者因大量的讨论和会议丧失效率。但是如何区别就成了一个问题，对我们来说，什么样的问题才需要小组走读，由谁来判断，如何判断是需要明确的。
      代码审查的资源消耗是非常大的，这取决于审查的形式，审查的目的（涉及深度和广度），以及审查的频率。要认识到成本收益比和边际收益递减的规律，当然我们目前审查不足，增加审查力度的边际收益应该还是比较大的。还有一个问题就是过程成本，或者说管理成本，如何保证审查的有效性以及缩减组织审查造成的资源损耗，制度化、规范化应该是一个办法。
      审查人员的素质也是关键的。不是说任何人都能成为审查人员，他必须在对象问题上具有一定的权威性，否则审查错误比不审查还要糟糕。而我们目前的情况是，所有具有一定资质的人员，都肩负着管理任务，大多数时间都消耗在公共、行政或者其它事务上，造成在审查力度上的不足，如何协调也是我们需要解决的一个问题。
      最后的一点是期望收益的问题。如果我们希望审查发现所有问题，或者实行对审查人员的问责制，可能会造成大家都不愿意去审查代码。审查只是一个保证手段，就好像测试一样。如果一旦发现问题，就责怪审查人员为什么没有发现，那是不可取的。

cuigang 2007-12-17 21:24 发表评论

20070206备忘

cuigang — Mon, 17 Dec 2007 13:17:00 GMT

究竟如何评估软件成本（工作量）？COCOMOII太复杂，其它的计算方法并不适用我们，Deiphi？我们缺少真正的专家。仅仅从需求页数、代码行数、人月生产率、千行故障率、bug消除率、测试用例数、等等是否能够估算出我们的工作量？我们的历史数据是否足以代表我们的真实状况？我们还要考虑到人员无法100％投入，在线问题的维护、部门或公司公共事务的处理，到底我们能投入百分之几？太多的变数，让这成为一个无法求解的方程式。
或许，只能慢慢地试，让这个公式逐步求精，要接受失败。

cuigang 2007-12-17 21:17 发表评论

20070104/05/06 备忘

cuigang — Mon, 17 Dec 2007 13:16:00 GMT

MOI——激励、组织、创意
MOTIVATION(激励)、ORGANIZATION(组织)、IDEAS/INNOVATION（想法/创意）
作为管理者，首先应该能激发下属的工作激情，树立他的自信心；然后能够组织和协调整个团队，在发生冲突，或者出现障碍时，能够提出好的见解，虽然可能不是解决方案。

处理复杂问题的方法
鉴于人能处理复杂问题的规模，我们在解决一个复杂问题时，首要要想到的就是“分而治之”，而这一切的前提是，确定问题的范围，没有范围的问题，是无法分割的，这就是规约的作用。

软件风险管理
没有任何一个软件是没有风险的，隐藏风险不如正视它，把风险列举出来，在项目早期去规避它或者为它做准备，临危不乱，可能更有效。但要注意的是，这一切的根本是如何识别风险，这需要领导者具有丰富的经验和敏锐的观察力。

cuigang 2007-12-17 21:16 发表评论

20060612备忘

cuigang — Mon, 17 Dec 2007 13:12:00 GMT

开始改bug，在改bug中，有4点感受：
1、一个类不宜写得太大，很难想象一个有四五十个成员函数的类能具有很好的可读性和可维护性。在着重考虑可读性和可维护性，将效率次之的情况下，可以有比较多的办法来实现。
2、与程序行为无关的全局变量，特别是一些数据和表格，比如我们的缺省配置，报警配置等等，应该引入机制，放到程序外面，这样，无形中程序就小了（因为这些变量都将放到程序的.data段），也便于统一处理。
3、基类企图统一共有操作，但职责不明确。我的观点是，不管用什么办法，能统一处理的，就统一处理，不让别人插手；存在差异性，不好统一处理的，决不处理。欲言又止的事情还是少一点。
4、在包含头文件时，还是尽量避免 include all 的情况，这样每次头文件改动，基本上需要重新编译一遍。还是用哪个包含哪个比较好。

cuigang 2007-12-17 21:12 发表评论