自底向上地给出解决方案
自底向上地给出解决方案: 先看看现在有什么，再考虑怎么弄 1. 做方案之前先看看系统中对类似问题是否已有方案. 这个方案说不定你可以直接用，甚至不用再开发任何东西 2. 全面地了解你可能用到的子系统、模块，然后再去找相关的接口人；这不是为了评估对方所说是否正确，而是为了更好地倾向对方，避免自己产生似是而非的理解。
Month: November 2011
Trust Nobody
“你这个怎么做的？” “你们已经有这个接口了吗？” 不要轻信对方的回答。如果他没查代码，他给你的回答在一定概率上是不准确的。 你可以做的是： a. 问对方具体是哪个类里的哪个字段，自己校验一下。 b. 对于一个接口，既要问提供者，也要问当前的使用者；如果他们两个口风一致，可信度才高 不过，这过程中尽量不要让人觉得你不信任他。这需要技巧，这方面我还很弱。
需要掌握系统分析的一些模式
做初步解决方案的时候，往往只能抓住关键性需求做出一些比较粗粒度的方案。粗糙不要紧，但仍然需要可靠，即满足可行性。要做到这一点，就必须在构思方案(time bound)时，头脑快速响应，迅速地在脑子里对自己的方案进行校验。 要想快速思考，就得掌握一些常用的系统分析的模式；当一个问题点出现时，你可以自然而然地想到从哪些方面来考虑。 不知道有没有这样的模式大全。我自己能想到的有这些： 1.不要漏掉关键的名词性领域模型。通过比较细致的Use Case可以避免这种遗漏。 2.名词性模型是可以按业务来分类的，你可以迅速定位某种模型的类别，然而快速考虑一下它的核心特征是否满足你的方案。四色原型提出了一种分类办法，但我完全看不懂。我目前能想到的有： a.某些东西是静态的物品，如商品 b.某些东西代表一个动态的过程，如订单；这时你应该考虑它的时间属性，它依赖的静态物品，和它的状态转换。 c. … 3.领域之间关系应该搞清楚，是1:1, 1:m还是m:n
“A,B,C一起开会”未必比得上”A找Ｂ,再找Ｃ,又找Ｂ…”
如果一件事要三方一起沟通,惯常的作法是三方一起开会，这样效率比较高，因为说话人说一遍，就可以让其它两方同时知道（广播式）。 如果不这样而是采用点对点模式的话，A跟B说完之后，还得再跟C说一遍。 但有些经验表明,这并不是绝对的。有些“人”的因素，可能会使第二种模式效率更高。三方同时沟通在“人”的方面有一些缺点： 1. 三方碰头开会可能只允许有两三个小时的时间，因为这样往往会漏掉一些关键的东西，得出的解决方案很有可能会有可行性的问题。 2. 如果没有强势的主持人，三方沟通可能意味着七嘴八舌，会议无组织，效率反而更低 ３. 多数压倒少数效应。如果B和C意见一致，气场强大，则A可能会有点退缩，怕大家觉得自己笨而不敢乱发言。 4. 如果A和B,C并不平等， 则Ａ需要注意的礼节禁忌也会多一些 5. 以上缺点随着参与方的数目和每方人数的增加而增加。 在这种情况下，还不如换用点对点模式。按谁受益，谁主动的原则，让其中一个人来穿钻引线，不厌其烦地打扰其它各方： 1.其它人就像分时系统，一边回应，一边可以做自己的事；因此不会觉得时间有太大浪费。你也可以因此问的细一点，做出的方案更靠谱一点。 2.一对一模式下，你可以从容引导沟通的进程。因为只有你主动，别人都被动。 3.其它的一些人的因素也减轻了很多。 不过，你仍然要时不时地发一起阶段性的结论出来，发给所有人：to make sure all are on the same page, 这样可以弥补点对点沟通的一个缺点：无法当场取得所有人的一致。
project 2007学习笔记 — 草稿状态
project 2007 notes 1. 给定计划后，就要把它当作一个baseline，以后的追踪就是基于实际执行情况与baseline的比较 2. 追踪并调整计划 — 这时baseline怎么办？ Project 2007的作用： 1. 计划 a. 查看重大变更对项目的影响 b. 在取舍资源与进度时帮你做一些计算 c. 设置任务优先级 d. 找出critical path(关键路径) f. slack (摩擦损失时间) 2. 资源管理 3. Trackiing 4. Reports Project 2007中的工具： 1. Gantt chart 2. Network Diagram: 体现从一个任务到另一个任务的流动 3. Resource Grpah & …
项目管理中的Units, Work, Duration
我是看了这个PDF才明白的: http://pmpspecialists.com/WhitePapers/PMP_Specialists_Task_Types.pdf. 本贴里我再用自己的语言复述一下. Units, Duration, Work是什么? Units就是参与任务的"人力", 如果一个人100%干, Units就是１; 如果两个人各50%干,Units也是1 (2 * 50%) Duration就是任务完成所花的时间. 如果一个任务从周一干到周五, 那Duration就是5天 Work则是一段时间内所有人实际投入的"汗水",也就是"工作量". 如果两个人各100%一共干了5天,那Work就是10天. 简单地说, Work = Units * Duration Fixed Units, Fixed Duration, Fixed Work MS Project里的任务类型必定是Fixed Units, Fixed Duration, Fixed Work其中一种.那又分别是什么意思? 1. 先说一个最容易理解的, "十月怀胎"这种任务就是典型的Fixed Duration. 一个女人生一个孩子要10个月,十个女人只生一个孩子还是要10个月! 那投入十个女人后,上面几个参数会怎么变呢? a. 一个女人的时候, Work = Units * Duration = 1个月 * 10人 = 10 人月 b. 十个女人的时候, Work …
活学活用一把: 通过引入Indirection来降低Connascence
有句著名的话叫做"All problems in computer science can be solved by another level of indirection". 另有人(page-jones)研究过耦合(connascence)的种类,并提出 通过把某种耦合变成另一种耦合,可以减弱耦合的程度. 今天终于有机会使用这两个著名的东西了. 问题是这样的. 你的合作方比较强势, 不愿意按契约来设计. 你的系统想知道"这个流程执行完后,倒底谁拿到了标书? ", 对方告诉你, "我们不提供’谁拿到了标书’这个接口,你可以使用’竞标者是不是市委干部的儿子或女婿’这个接口,因为他们一旦竞标,合同肯定就是他们的" 而你又相信"人间或许还有点公义,现在他们能拿到,以后就未必了". 但前面说了,对方很强势,于是干脆不搭理你. 如果你按他们的意思来,那你们就没有严格地按照契约来定义接口: 他给你的东西不是你直接想要的东西,而是你想要的东西的背后的东西. 如果你直接依赖"竞标者是太子"这个接口,万一这玩意儿靠不住了,你就得改你的系统. 从Connascence的角度来说, 这里存在一个Connascence of Algorithm(算法耦合性), 你们两个系统之间的正确交互依赖于 "高干子弟必定拿标书" 这个脆弱的业务规则(算法). 那怎么解决这个问题? 既然对方不愿给真正的接口,那你就无法避免这个耦合; 但你仍要想办法减弱它对你的系统的影响; 也就是说, 算法被改变时,你的系统所做的修改要尽量小. 举例来说,如果你的系统中多处用到了这个接口,那一旦算法被改变,你的系统就有多处要改. 说到这里,解决方案已经呼之欲出了. 你要引入一个Adaptor作为indirection, 这个Adaptor在名义上提供你要的接口:"倒底是拿到了标书? ", 实现上它再依赖对方系统的"高干子弟拿标书"这个潜规则; 你的系统里要调用标书逻辑的地方都必须通过这个Adaptor, 而不能直接依赖对方的系统.如果对方改了这个逻辑,你只需要改你的Adapter这一个地方就可以了. 没错,耦合性还是存在,但你对未来的担扰至少少了些. 从Connascence的角度来说, 你是把耦合性 从"Connascence of Algorithm" 减弱为 "Connascence of name", …
关于component-based软件开发，收藏几本书
基于组件开发为SOA提供了一些理论基础。据说下面这两些书不错。 Component-Based Software Engineering: Putting the Pieces Together Component Software: Beyond Object-Oriented Programming Component-Based Development for Enterprise Systems" by Paul R. Allen Component-Based Software Development" by Kung-Kiu Lau 基于组件的企业级开发 by Peter Herzum, Oliver Sims
OO方面的散乱笔记：《UML面向对象设计基础》
作者：Meilir Page-jones 1. 面向对象软件的可理解性和可维护性，以及其它一些特性都是以封装性和Connanscence为基础的 2. 包：里面的类来自同一领域，但它们未必相互发生影响；组件：里面的类相互作用完成一系列业务逻辑 (启示：平时应该注意把内聚、耦合这种理念扩展到对象之外，扩展到包、组件或者更高的级别) 3.高内聚/低耦合并不是oo的专利，在结构化时代就已有比较系统化的研究；这方面可以看作者的另一本经典书籍：’practical guide to structured systems design’，它里面提出的一些东西在OO时代照样有用. 4. Encumbrance: 一个类的encumbrance就是它直接引用和间接引用的所有类的数量。 越低层次的类，它的encumbrance就应该越小； 越高层次的类，它的encumbrance就应该越大。 5.一些错误的内聚： a.混合事例型内聚：比如在“几何图形”这个类里搞一个“对角线”属生就是这种不当内聚，因为虽然四边形有对角线，但三角形并没有对角线。 b.混合领域型内聚：比如在“实数”这个类里写一个“华氏温度转摄氏温度”的方法，这样做会从扩大一个类的encumbrance,引入不相关的领域，导致可重用性降低 c.混合角色型内聚：比如在“人”这个类里写一个“拥有狗的数目”的方法。人和狗可能都属于业务领域，但人和狗完全是不同的角色。
connascence & coupling
越来越感觉到，弱耦合性是系统可维护性的关键, 有必要研究一下各种耦合的形态及相应解耦手段。 Robert C. Martin 在他的《敏捷软件开发》里提出了很多面向对象的原则，《代码大全》里也有一些，本质上都是为了实现弱耦合。 对耦合这个概念本身贡献最大的人可能是Meilir Page-Jones，他在他的《UML面向对象设计基础》中使用了connascence这个词(单词里的第一个a发/ei/音)。 Connascence就是Coupling的同义词，Page-Jones给出了它的定义，还指出了它有几种类别。 另有一个叫 Jim Weirich的Ruby高手对connascence非常感兴趣。他把它称为OO理论中的Grand Unified Theory(物理学术语). 他在一次演讲中专门介绍了这个东西，并有一定的展开。 我本想找一本专门讲弱耦合的书，但可惜目前没有； 于是只好自己研究一下上面提到的材料，下面是一些笔记。 附资源： connascence的wiki页面： http://en.wikipedia.org/wiki/Connascent_software_components Meilir Page-Jones的书：Fundamentals of Object-Oriented Design in UML, 看第三部分就好 Jim Weirich的演讲：http://confreaks.net/videos/77-mwrc2009-the-building-blocks-of-modularity ==================================================================== Connascence的定义：两个软件元素A和B之间，如果A改变，B也就必须改变, 或者当某第三方元素发生改变时，A和B必须同时改变。 ———————————————————- 各种Connascence: 静态Connascence： 1. connascence of name methodA()改名为methodB()时, 调用methodA()的地方都要改名 2. connascense of type or class 如果变量从值100变成了一个很大的数, 则变量类型可能要从int改成BigInteger 3.connascense of convention magic …