ZX编程随笔(二)

1. 2006-12-04
   性能是很难臆测的事情，在设计的时候不要过多地考虑性能，只有这样才能促使你按照简单的原则行事。
   下面是一些测试报告，告诉你完全可以使用一些简单的设计方案：
   1)用字符串连接比指针连接简单：在100个最大长度为30的字符串数组中查找一个字符串只需要<0.003毫秒(测试代码)。
2. 2006-12-14
   Analysis Paralysis ( 分析瘫痪 ) ：系统分析师为求完美或过度仔细而延误规格确立，挤压后续工作的时程，其解决方案是采用递增式开发流程 (Incremental & Iterative development process) 。
   英国首相邱吉尔有句名言：完美主义等于瘫痪——很精辟的阐明了完美主义者的害处。
   一个不停地寻找“正确”答案的人容易患上“分析瘫痪症”，这种病看起来似乎影响了很多有学问的人。其实，我们学习是通过犯错误实现的--我们通过犯错误学会了走路、骑车以至开车。
3. 2007-01-18
   DDD->OOD->TDD
   OOD： DIP->(SRP)->ISP->(LSP)->OCP
   使用接口隔离类，引入Mock对象隔离测试；
   一个接口代表了一个抽象，接口即是对细节的隐藏；
   接口限制了TDD单元的规模，最终降低了耦合度。
4. 2007-02-07
   正如Robert C. Martin所描述的，对象组合的思想可实现对象调用的90、180度转向，这大大扩充了三种基本执行结构（顺序、分支、循环），引起妙不可言的变化。对象组合、职责委托的目的是什么？－－调用转向，产生力矩效果。
   通常平行类体系表明未产生力矩效果。
5. 2007-02-28
   设计的目的是什么？除了很自然的回答：为了实现! 还有一个更为深远的目的：为了不实现，也就是说，通过设计的权衡决定实现什么、不实现什么。这是一个边界控制的问题，太多的项目失败不在于没有实现什么，而在于因为实现的过多而迟迟不能交付。
6. 2007-03-17
   编程技术的学习，主要方法是读别人、读高人的程序。自己的开发实践或练习，只能使接受的思想得以消化，运用更熟练，并不能真正产生新思想。
7. 2007-03-19
   消除企业浪费：只要是用户看不到或感受不到的产品投入，都是一种浪费。
8. 2007-05-11
   建模的目的是交流，建模过程不是发现过程，因为不能试错。对于新领域的研发，唯一的途径仍然是不断TDD/重构，持续集成，这时的建模更多的是反相工程，以供交流、评测，吸取宝贵的建议。
9. 2007-05-11
   当大致的分析之后，马上就会用TDD写出一堆令人头疼的代码，这时，重构就应该登场了。重构的第一要义：在杂乱无章的代码中识别抽象--忽略细节、放大本质。当抽象被发现之后，重构的第一手法就是接口隔离，这时或许需要开辟几个新的单元，起几个新的类名，引入几个新的测试单元，原有的代码应该迅速变得简单，而抽取出的代码应该是高内聚的。
10. 2007-05-23
    形象的说，最好的程序结构是悬挂式的，就像在钢索上悬挂着一个个密封的金属桶。悬挂点是接口，金属桶就是解耦的包或模块，钢索就是架构。也就是说，架构完全是由接口构成的。
11. 2009-03-09
    敏捷过程的起点是一次次的头脑风暴(brainstorming)，别忘了把这个过程中产生的创意、构想、随手涂鸦、代码片段等点点滴滴全记下来，分门别类地整理到开发文档，并按照可行性、优先级等原则进行排序，这些将是推动开发进程的燃料，也是构成开发文档的核心价值。
12. 2009-04-08
    设计过程总是受到有关性能的无尽骚扰，干脆别再管它了！正确的做法总是遵循简单、直观的原则——性能问题应留到优化阶段去解决。
13. 2009-10-27
    成熟小组每天需要完成三件事情：
    1.每天都有可以工作的代码被打包、发布；
    2.每天加入新任务到滚动规划，小步前进；
    3.每天都有详细的开发日志，描述了对代码的所有添加、删除、修改操作，便于跟踪、回溯。
14. 2009-10-29
    TDD方法最易令人接受的是对自由重构的支持，最不易令人接受的是对OO原则的遵循。
15. 2009-10-31
    接口分为两种：悬挂式接口和注入式接口。这在UML图中可以看得很明显：好的设计画出来的UML图，接口总是层层向下分解(或者委托)细节，高层的抽象模型位于最上面醒目的位置。注入式接口也总是位于最上层，它为该模型的工作提供一些基础设施或者前提条件。
16. 2009-11-15
    对应于“抽象与细节”的最好术语是“框架与接口”，还有许多类似的描述，如：“一个对多个”、“全局与临时”、“稳定与易变”、“反复重用与一次性使用”、“长代码与短代码”、“循环等复杂语句与几条简单语句”...
17. 2009-11-30
    代码每删除一半，功能及灵活性便强大一倍。
18. 2009-12-15
    代码都是垃圾，它不便于交流，也没有任何抽象和灵活性，仅能起到验证模型的作用。唯有用模型表示的思想是有价值的，这些思想大都是在开发过程中不断学习、积累的领域知识(即对需求的理解)。所以说，开发过程其实是不断学习领域知识的过程。有些大师甚至提出：最好的开发方式是开发两(N)次——深有同感。几乎所有的软件都是在3.0之后才变得好用。
19. 2009-12-29 (项目工作需努力改善的方面)
    1.坚持结对编程与统一模型原则，加强小组间、成员间的交流与知识共享，鼓励积极轮换的工作方式；
    2.摆脱结构化编程思想的束缚，努力提高面向对象的建模水平，交付合乎质量要求的成果；
    3.四个循环步骤——迭代开发、小步前进
    　建模：围绕UML类图的交流和讨论
    　设计：写测试，简单、意图、解耦、文档
    　实现：快速通过测试，完美主义=瘫痪
    　重构：改名，提炼概念模型，删除垃圾代码
    4.四个工作文件——培养良好的工作习惯
    　工作清单：滚动规划，按优先级工作
    　模型文件：UML类图，加强交流和理解
    　测试用例：需要反复学习TDD开发方法
    　实现代码：保证测试通过，每日构建
    补充：
    　建立功能核对表，逐项比对检查，落实完工的水平和程度；
    　模型必须是可理解、可交流的，需要项目组共同参与、持续改进；
    　“代码是用来删的，架构是用来改的”；
    　可以工作的软件胜过面面俱到的设计，尽早与客户交流合作可以事半而功倍；
    　提炼统一模型（领域的、概念的、共同的）；
    　及时推出可工作的软件（每日构建、频繁交付）。
20. 2010-01-11 (项目工作中的问题)
    1.模型是领域模型，在模型里只能够出现来自客户领域的术语，任何计算机专业的术语都不属于模型。
    2.关于“统一模型”，是指概念的共享，是理解、交流、合作的基础，不是为了提高耦合度——低耦合是必须永远坚持的原则之一。各小组代表不同的应用场合或客户群，通过迭代得出自己的接口，即使这些接口实际上对应相同的底层实体对象，为了保持概念模型的清晰，也不应随意地合并这些接口——领域模型来自于客户，不依赖于任何实现或物理模型。
    3.“迭代开发、持续集成”的含义：尽早地、持续地交付可以工作的软件。迟迟不能交付可运行、可观察的软件是大多数项目失败的最根本原因。所有的软件都需要从一个原始的版本开始迭代、成长，越早越好！只有可运行、可观察，才能衡量和控制，才能找到开发节奏，才能保持可持续的开发速度，才能完成进度！目前发现的一个重要原因：包划分不合理。
    4.包的划分与对象划分原理相同：简单——能够控制，低耦合——灵活、可独立演化。一些启发性规则：包要能单独测试、运行、发布；包中的对象要用则一起用，要改则一起改；更新或拆卸一个功能包不能影响其他功能的使用；包之间通过接口依赖，依赖必须遵循无环、稳定、抽象的原则；包不能跨小组开发、维护。
    5.最常见的建模问题：方向错误！通常是过于关心底层的东西而不是从范围说明出发。不应该去建模不属于自己范围的任何东西——把它们留给接口！所谓“接口是迭代出来的”正是这个含义。一个简单有效的办法：试试对你的范围说明书使用“名动词法”——名词即对象，动词即职责。
    6.建模是反复讲述、倾听、提问、修改的过程，其中一个人负责使用UML记录（通常是最了解模型的人）。好的模型一定能够通过简短、清晰的几句话轻易地描述。要重视维护UML图与代码的同步，它们是可交付成果的重要组成部分（另外还有频繁更新的工作清单和可以运行的测试程序）。
21. 2010-05-28
    值对象是一种非常简便、灵活的设计，但在现实系统中存在更多的是实体对象，如果能够分离实体对象的创建、持有、销毁、持久化等职责到一个类似仓储的结构中，则对实体对象的引用可以设计为值对象，这样，实体对象的使用者就可以享受值对象带来的巨大利益。通常，值对象的操作封闭是值得追求的一种设计（参考数学中实数集上的算术操作）。
22. 2010-09-04
    类设计和数据库表的设计有一个相似的地方：适度的冗余是有益的。不必要求基类的每一个属性在派生类中都是有意义的，某些属性在某个子类中可能是无用的，这种冗余可能使整个类体系保持简单和高效，至少可以避免引入一些中间类来消除这种冗余。
23. 2010-09-06
    当你打算为一个包或类体系添加新的功能时，首先应考虑：这样做是不是有点复杂化了？新的功能是不是该由新的类实现，客户将新的类与原有代码组合是不是就能实现目标？这样做是因为，包的核心功能往往在早期就确立了，也就是“二八原理”里面的20%部分就实现了，新增的功能不是核心的、必须的，它们带来微小的价值，却往往导致原有设计概念的一致性受损，原有软件的范围模糊不清。