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%部分就实现了,新增的功能不是核心的、必须的,它们带来微小的价值,却往往导致原有设计概念的一致性受损,原有软件的范围模糊不清。

你可能感兴趣的:(编程,软件测试,TDD,领域模型,UML)