净值
- 主账户 :1.0732
- 父母的养老金:1.0001
- 我的养老及:1995
;
本周操作
- 主理财账户
- 买入1500的货币三佳
- 父母的养老钱
- 买入2000稳稳地幸福
其他
没啥好些的,睡觉
敏捷开发读书笔记五
敏捷开发读书笔记五
command模式
类图先行
templete method(模板方法)模式和strategy(中介者)模式
- 优先使用对象组合而不是类继承(老生常谈的问题)
- 模板方法模式和策略模式体现了继承和委托之间的区别.他们要解决的问题类似,但是模板方法模式利用继承解决问题,策略模式利用委托来解决问题
模板方法模式
类图先行
策略模式
类图先行
- 模板方法和策略模式都可以用来分离高层算法和低层具体实现细节.都允许高层的算法独立于它的具体实现细节重用.
facade(外观)模式和mediator(中介者)模式
- 这两种模式都是把某种策略施加到另一组对象上,facade模式从上面施加策略,mediator模式从下面世家策略
- 如果策略涉及范围广泛而且课件,可以使用facade模式从上面世家策略.如果策略隐藏并且具有针对性,mediator则是更好的选择.
- facade通常是约定的关注点,每个人都去使用facade而不关心其下隐藏的对象.mediator则对用户是隐藏的.他的策略是既成事实而非一项约定事务.
facade模式
类图先行
- facade对用户隐藏了下层的复杂性,并且与用户约定必须通过facade来操作下层的操作而不能绕过.
- facade模式是明显且受限的施加策略.
mediator模式
类图先行
- mediator模式以隐藏且不受限的方式来施加策略.
singleton模式(单例)和monostate模式
- singleton和monostate都有单一的含义.singleton通过将构造函数私有化来维持单一实例,monostate通过将所有字段注册为静态字段(static)来保证所有实例都是统一状态.
- 多数情况下,这两种模式的实施代价远低于它们的表达力带来的收益.
- sigleton强调结构上的单一性,只能创建一个实例.monostate强调行为上的单一性,所有实例操作的都是同一字段.
- 如果希望通过派生去约束一个现存类,并且不介意他的所有调用者都必须调用instance()方法来获取访问权,那么singleton最合适的.
- 如果希望类的单一性本质对使用者透明,或者希望使用单一对象的多态派生对象,那么monostate最合适.
singleton模式
优点:
- 跨平台
- 适用于任何类(只需要将构造函数私有并添加相应的static函数和变量)
- 可以通过派生创建(可以创建一个给定类的sigleton子类)
- 延迟求值(sigleton未使用的时候就不需要创建)
缺点:
- 摧毁方法未定义
- 不能继承(singleton派生的子类不是sigleton)
- 效率问题(instance方法中的if)
- 不透明性(使用者知道操作的是sigleton对象)
monostate模式
优点:
- 透明性(使用者不知道操作的是monostate对象)
- 可派生性(monostate所有的派生类都是monostate)
- 多态性(monostate的派生类可以overwrite父类的方法)
缺点:
- 不可转换性(普通类不能转换成monostate)
- 效率问题
- 内存占用(static变量,即使没有使用,也会占用内存)
- 平台局限性
null object模式
定义一个接口,实现接口时候分为null实现和implementation实现,当出现null情况的时候,返回null实现,从而避免琐碎的判空代码.
null object的实现代价要高于它的收益.好像陷入了复杂性的badsmell?
焦虑清单
焦虑清单
2019年已经过去了马上三个月整,对已经在进行的几件事情还比较满意,主要包括:
- 节食和减肥,年后回来体重已然减少了10kg左右.
- 跟老刘的读书都按时完成,没有落下进度.
- 水滴阅读的英语坑填上了,虽然不是完全消化,也算是可以以后会去看看.
然而因为17/18两年荒废了太多,总是经常陷进焦虑之中,莫名烦躁.所以想起来把这些焦虑列举一下,搞清楚自己究竟是在焦虑什么,然后再想办法对症下药,解决问题.
关于工作/工资/技术/学习
- 工作没有多少技术难度，技术提升空间和职位提升空间都没有，工资也低于平均水平，工作没有太多难度无法谈涨薪事宜。
- 工作速度变慢，下班就走，担心在同事和领导的看法。
- 按目前的状况职业生涯不明朗，不提升技术跳槽不到好公司。当前职业前景灰暗。
- 可替代性太高，不能经受住失业。
- 技术严重落后，17、18两年荒废，有太多的东西需要追赶。
- 学习具有滞后性，过程中不免产生是否有用的焦虑。
- 计划总是多于实际,完不成计划让自己产生挫败感
- 工作/工资/技术这些东西,与同学比,与同事比,与微信群里的陌生人比,总是有种挫败感.
关于钱
- 工资太少，相应的资产积累速度不够。
- 17年跳槽耗光了精力，到现在存款相较同龄人太少。
- 父母养老，自己保险，自己生活品质的花销堪堪够用,还有很多的欲望等待金钱实现。
- 自己当前承担不起父母的老年生活。
- 积蓄太少，经受不住失业。
- 没有谈婚论嫁的经济能力。
体重
- 还很胖。虽然已经从210->190.
- 按照目前的习惯正在有条不紊的降低，明显不是一个短时间可以完成的目标，但是前途是光明的。
健康
- 目前还顶着脂肪肝和高尿酸，身体亚健康。
- 亚健康状况导致饮食有太多禁忌。
- 不能熬夜。
恋爱和婚姻
- 二百斤的胖子是没有对象的。
- 没谈过恋爱，无限羡慕谈恋爱中的情侣。
- 到了谈婚论嫁的年龄，自然而然的感受到各方面的压力。
- 祝地铁上的每一对黏在一起的情侣都是失散多年的兄妹:)
人际关系
- 交际圈变小，变小的交际圈明显会让你感到对少数朋友的依赖。
- 保持着对同事的距离，不认同吧同事和朋友的相交叉。因为平时又两点一线的生活，所以导致交际圈不能发育。
- 跟小雪吵过以后明显不愿意跟大学好友谈论事情。
- 没人说话的心理状态很不爽.
敏捷开发读书笔记四
敏捷开发读书笔记四
Liskov替换原则(LSP)
Liskov替换原则(LSP):子类型(subtype)必须能够替换掉它们的父类型(basetype)
- IS-A(是一个)关系又是被认为是面向对象分析的基本技术之一.
- 一个模型,如果孤立地看,并不具有真正意义上的有效性.模型的有效性只能通过它的客户程序来表现.
- 像所有其他原则一样,通常最好的方法是只预测那些最明显的对于LSP的违反情况二推迟所有的其他的预测,直到出现相关的脆弱性的臭味时,采取处理他们.
- IS-A是关于行为的.从行为方式的角度来看,Square不是Rectangle(关于正/长方形的例子),对象的行为方式才是软件真正所关注的问题.
- 基于契约设计(Design By Contract,DBC):使用DBC,类的编写者显示的规定针对该类的契约.客户代码的编写者可以通过该契约获悉可以依赖的行为方式.契约是通过为每个方法生命的前置条件(preconditions)和后置条件(postconditions)来制定的.要使一个方法得以执行,前置条件必须要为真.执行完毕后,该方法要保证后置条件为真.
- 大多数情况下,接受一个多态性为中的微妙错误都不会比试着修改设计使之完全符合LSP更为有利.接受缺陷而不是去追求完美这是一个工程中的权衡问题.好的工程师知道如何接受缺陷比追求完美更有利.
- 提取公共部分是一个设计工具,最好在代码不是很多时应用.
- 完成的功能少于基类的派生类通常是不能替换其基类的,一尺就违反了LSP
- 在派生类中存在退化函数并不总是表示违反了LSP,但是当存在这种情况是,还是值得注意一下.
- 另外一种LSP的违规形式是在派生类的方法中添加了其基类不会抛出的异常.
- LSP是使OCP成为可能的主要原则之一
依赖倒置原则(DIP)
依赖倒置原则(DIP):
a.高层模块不应该依赖于低层模块,二者都应该依赖于抽象
b.抽象不应该依赖于细节,细节应该依赖于抽象.
- DIP是框架设计的核心原则.
- 倒置不仅仅是依赖关系的倒置,也是接口所有权的倒置.应用DIP的时,往往是客户拥有抽象接口,而服务者则从这些抽象接口派生.
- 低层模块实现了在高层模块中声明并被高层模块调用的接口.
- 程序中所有的依赖关系都应该终止于抽象类或者接口
- 我们在应用程序中所编写的大多数具体类都是不稳定的,我们不想直接依赖于这些不稳定的具体类.通过把它们隐藏在抽象接口的后面,可以隔离它们的不稳定性.
- 面向对象的程序设计倒置了依赖关系结构,使得细节和策略都依赖于抽象,并且常常是客户拥有服务接口.这种依赖关系的倒置正式好的面向对象设计的标志所在.
- 如果程序的依赖关系是倒置的,它就是面向对象的设计.如果程序的依赖关系不是倒置的,它就是过程化设计.
- DIP的正确应用对于创建可重用框架来说是必须的.
接口隔离原则(ISP)
接口隔离原则:不应该强迫客户依赖于它们不用的方法.
- ISP用来处理”胖(fat)”接口所具有的缺点.如果类的接口不是内聚的(conhesive),就表示该类具有”胖”的接口.换句话说,类的”胖”接口可以分解成多组方法.每一组方法都服务于一组不同的客户程序.
- 多参数形式通常都应该优先于单参数形式使用.
- 每个原则在应用时都必须小心,不能过度使用它们.
- 客户程序应该仅仅依赖与它们的实际调用方法.通过把胖类的接口分解成多个特定于客户程序的接口,实现这个目标.
敏捷开发读书笔记三
第七章 什么是敏捷设计
- 软件项目的设计是一个抽象的概念.它和程序的概括形状/结构以及每一个模块/类和方法的详细形状和结构有关.可以用不同的媒介去描述他,但是他最终体现为源代码.源代码就是设计.
敏捷设计是一个过程,而不是一个事件.它是一个持续的应用原则/模式以及实践来改进软件的结构和可读性的过程.它致力于保持系统设计在任何时间都能尽可能得简单/干净和富有表现力.
实际上满足工程设计标准的唯一软件文档,就是源代码清单.–Jack Reeves
- UML图只描绘了设计的一些部分,但是它并不是设计.
- 敏捷开发人员对待软件设计的态度要像外科医生对待消毒过程的态度是一样的.
- 设计需要保持干净/简单,并且由于源代码是设计最重要的展示,所以它同样需要保持干净.职业特性要求我们,作为软件开发人员,不能忍受代码腐化.
软件腐化的坏味道
- 僵化性(Rigidity):很难对系统进行改动,每个改动都会迫使许多对系统其它部分的其它改动.
- 脆弱性(Fragility):对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题.
- 牢固性(Immobility):很难解开系统的纠结,使之成为一些可在其它系统中重用的组件.
粘滞性(Visosity):做正确的事情比做错误的事情要困难.
- 粘滞性有两种形式:软件的粘滞性和环境的粘滞性
不必要的复杂性(Needless Complexity):设计中含有不具有任何直接好处的基础结构.
- 不必要的重复(NeedLess Repetition):设计中包含有重复结构,而该重复的结构本可以使用单一的抽象进行统一.
- 晦涩性(Opacity):很难阅读/理解.没有很好的表现意图.
- 开发人员必须站在代码阅读者的位置.
软件腐化的原因
- 变化而又改动急迫的需求/修改人员对原设计思路不熟悉/以上变化的日积月累
- 我们需要意识到,需求是项目中最不稳定的要素.大多数软件项目中最不稳定的东西就是需求.需求处在一个持续变动的状态之中.
- 如果设计因为持续/大量的需求变化而失败,就表明设计和实践本身是有缺陷的.
敏捷团队不允许代码腐坏
敏捷团队依靠变化来获取活力.团队几乎不进行预先设计,不需要一个成熟的初始设计.团队更愿意保持系统设计尽可能的干净/简单,并使用许多的单元测试和验收测试作为支援.
团队在开始设计的时候以最简单的方法编写.直到需求最终明确变化时,他们才修改模块的设计,是之对该变化保持弹性.
敏捷开发人员如何知道做什么.
- 遵循敏捷实践去发现问题(一二章内容)
- 应用设计原则去诊断问题(单一职责/里式替换/依赖倒转/开闭/接口隔离)
- 应用适当的设计模式去解决问题.
第八章 单一职责原则(SRP)
单一职责原则:就一个类而言,应该仅有一个引起它变化的原因.
- 如果一个类承担过多的职责,那么引起它变化的原因就会有多个.多个职责在一个类中后合在一起会导致脆弱(fragile)的设计.在发生变化的时候可能会遭受意想不到的破坏.
- 什么是职责?在SRP中,我们把职责定义为”变化的原因”.如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.
- 每一个职责都是一个变化的轴线. 该变化会反应为类的职责的变化.变化的轴线仅当变化实际发生时才具有真正的意义.如果没有征兆,那么去应用SRP或者其他原则都是不明智的.
- SRP是所有原则中最简单的之一,也是最难正确运用的之一.我们会自然地把职责结合在一起.软件设计真正要做的许多内容,就是发现职责并把这些职责相互分离.
第九章 开放-关闭原则(OCP)
开放-关闭原则:软件实体(类,模块,函数等等)应该是可以扩展的,但是不可以修改.
如果程序中因为一处修改就发生连锁反应,那么它的设计就有僵化性的坏味道.OCP建议在发生变化的时候,对系统的设计进行重构,确保以后在进行同样的改动的时候能够只增加新的代码,而不需要做更多的修改.
STARTEGY(策略)模式和TEMPLATE METHOD(模板方法)模式是实现OCP常用的方法.
无论模块多么封闭,都存在一些无法对之封闭的变化.设计人员必须对于他设计的模块应该对那种变化封闭做出选择.
封闭建立在抽象的基础上.
OCP的应用应该限定在可能发生的变化上(原因:OCP的代价是昂贵的,正确的抽象需要花费开发时间和精力,抽象也会增加系统的复杂性,开发人员有能力处理的抽象是有限的)
什么时候考虑/适合应用OCP
变化真正发生的时候.
- 只受一次愚弄.最初编写代码的时候,假设变化是不发生的.当变化发生的时候,重构系统,创建抽象隔离以后的同类变化.
- 刺激变化.通过编写测试/短迭代周期/首先开发重要特性/尽早的经常的发布软件.
遵循OCP原则可以带来面向对象技术所生成的巨大好处(灵活性,可重用性和可维护性)
- 抽象应该针对程序中频繁变化的那部分.
- 拒绝不成熟的抽象和抽象本身一样重要.
敏捷开发读书笔记二
第六章读书笔记
纸上得来终觉浅,绝知此事要躬行
- 自己的代码确实low,应该多接触一些大佬的代码.
- 断言的简单引用(以后写单元测试可以用)
- 单元测试代码也应该重构.同一类的单元测试代码可以整体重构优化.
- @before来初始化可以让单元测试的代码更优雅一些.
- 在+1和-1的过程中胡乱调整,直到可以正常工作.//基于巧合的编程???
- 完整的测试集合可以为程序的修改提供保障
- 编码前的设计要适当,避免复杂的过度设计.在编码的过程中完善设计.”想清楚来再写代码”这一点要更重要一些.具体的工作过程中要合理掌握度量.
看书碰到代码内容过多的地方,应该动手码一下这些代码.看似是比较麻烦的事情,其实恰恰相反,相比于靠脑袋去运行一遍书上的代码,手敲下来让电脑去运行反而是相对容易的一件事情.
而且在敲代码的过程中,自然而然的会带入到作者的思路里,这样远比一边思考代码思路,一边在脑子里想代码如何运行要简单的多.
而且敲代码所需要的注意力集中程度要更小一点.至少在现阶段自己的段位不足以长时间维持读代码的注意力集中,所以碰见类似的尽量自己敲一下.
敏捷开发读书笔记一
敏捷实践
一个大而笨重的过程会产生它本来企图去解决的问题.
每一位软件开发人员/每一个开发团队的职业目标,都是给他们的雇主和客户交付最大可能的价值.
敏捷联盟
敏捷联盟宣言包含如下四条:
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
个体交互胜过过程和工具
合作/沟通以及交互能力要比单纯的编程能力更重要
使用过多的庞大/笨重的工具就像缺少工具一样,都是不好的.工具最好的状态,是够用就可以了.
团队的构建要比环境的构建重要的多.
可以工作的软件胜过面面俱到的文档
过多的文档比过少的文档更糟.
正确的文档应当是短小的(short一二十页)/主题突出的(salient仅论述系统高层结构和概括的设计原理)
给新的团队成员传授知识方面,最好的两份文档是代码和团队.
Martin文档第一定律
直到迫切需要并且意义重大时,才来编写文档.
客户合作胜过合同谈判
成功的项目需要有序/频繁的客户反馈.
大多数情况下,合同中指明的条款远在项目完成之前就变得没有意义.
响应变化胜过遵循计划
计划不能考虑的过远.
较好的做计划的策略是:为下两周做详细的计划,为下三个月做粗略的计划,在以后就做极为粗略的计划.
原则
- 我们最优先要做的是通过尽早的/持续的交付有价值的软件来使客户满意.
- 即使到了开发的后期,也欢迎改变需求.敏捷过程利用变化来为客户创造竞争优势.
- 经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好.
- 整个项目开发期间,业务人员和开发人员必须天天在一起工作.
- 围绕被激励起来的个人来构建项目,给他们提供所需要的环境和支持,并且信任他们能够完成工作.
- 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈.
- 工作的软件是首要的进度度量标准.
- 敏捷过程提倡可持续的开发速度.责任人,开发者和客户应该能够保持一个长期的/恒定的开发速度.
- 不断地关注优秀的技能和好的设计会增强敏捷能力.
- 简单–使未完成的工作最大化的艺术–是根本的(简单是根本的).
- 最好的构架/需求和设计出自于自组织的团队.
- 每隔一定时间,团队会在如何才能更有效的工作方面进行反省,然后相应的对自己的行为进行调整.
敏捷开发并不看重对于明天会出现的问题的预测,也不会在今天就对那些问题进行防卫.
极限编程概述
极限编程由一系列简单却相互依赖的实践组成.这些实践结合在一起形成一个胜于部分的结合整体.
1.客户作为团队成员.
客户指定义产品的特性并且排列这些特性优先级的人或者团队.
2.用户素材
了解需求只需要做到能够估算它的程度就足够了.
需求的特定细节很可能会随时间而改变.
3.短交付周期
迭代计划
- 通常耗时两周.
- 本次交付不一定会加到产品中.
- 迭代开始,用户就同意不再修改当次迭代中的用户素材的定义和优先级别
发布计划
- 规划随后大约6次迭代的内容的计划,通常需要三个月.
- 发布计划不是一成不变的,客户随时可以改变计划内容.
4.验收测试
一旦通过一项验收测试,就将该测试加入到集合中,并且决不允许该测试再失败.每次系统被创建,都要运行这个验收测试集.
5.结对编程
6.测试驱动开发
测试先于开发,测试用例与代码共同演化.快速迭代,通常几分钟左右.
7.集体所有权
没有程序员对任何一个特定的模块或技术单独负责.
8.持续集成
- 提交代码应该非常频繁.
- 提交前应当确保所有的测试都能通过.
9.可持续的开发速度
- 团队必须要有意识的保持稳定,适中的速度.
- 不允许团队加班.版本发布前一个星期例外.
10.开放的空间
充满积极讨论的屋子会提高生产效率.
11.计划游戏
每次发布和迭代计划之前,开发人员根据上一次迭代或者发布计划中所完成的工作量,给客户提供一个预算.客户选择成本合计少于预算的用户素材.
12.简单的设计
用最简单的方式实现第一批用户素材.
指导原则:
- 考虑能够工作的最简单的事情
- 你将不需要它(拒绝过度设计)
- 一次,并且只有一次(拒绝重复代码)
13.重构
重构就是在不改变代码行为的前提下,对其进行一系列小的改造,旨在改进系统结构的实践活动.
运行单元测试以确保重构没有造成任何破坏.
重构是我们每隔一个小时或者半个小时就要去做的事情.
14.隐喻
通过比喻让用户素材更形象的表达出来
计划
解释极限编程(XP)中的计划游戏.探索/发布计划/分解迭代计划/计划分解为任务/完成任务/完成计划,一系列流程像游戏中的发布/承接/完成任务.
初始探索
项目开始的时候,开发人员和客户确定所有真正重要的用户素材.不是全部用户素材,这是不可能的,随着项目的进展,用户会不断编写新的用户素材.
开发人员共同对这些素材进行估算.
引入”点数”的概念来分配,点数代表的时间并不确定,但是可以确定的是8个点数耗费的时间一定是4个点数的两倍.
适度分解素材,过大或过小的用户素材都难以估算.
引入”速度”的概念对应”点数”,比如”两天完成一个点数”.
随着项目的迭代,”速度”与”点数”的对应关系会越来越准确.一般的,从项目开始不明确速度到速度有一个较为明确的定位,大概会花费几天时间.
发布计划
速度明确后,客户对每个素材的成本有所了解.客户可以根据用户素材的优先级和开发代价(对应的点数)来选择想要最先完成的素材.
开发人员和客户对项目首次发布时间达成一致,2-4个月.客户挑选该发布中要实现的素材,并确定这些素材的实现顺序.
客户不能选择超出开发速度的更多素材.
开发速度会在迭代过程中进一步明确,根据明确的开发速度,进一步调整和完善发布计划.
迭代计划
开发人员和客户决定迭代规模,一般是两周.
客户决定要实现的功能,但是不能与当前开发速度不符.
迭代期间开发人员决定素材的开发顺序,采用最有技术意义的顺序.
迭代开始后,客户不能更改迭代内要实现的素材.但是可以随意更改迭代外的素材.
即使没有完成所有用户素材,迭代也要在先前指定的日期结束.
根据本次迭代所完成的素材点数,计算出本次迭代的速度.这个速度用作下一个迭代周期的速度.比如完成21个素材点,那么以后的开发速度就是每个迭代周期21个素材点.
任务计划
新的迭代开始时,开发人员和客户共同制定计划.
开发人员按照”一个开发人员4-16小时内可以实现的一些功能”来将素材分解成开发任务.开发人员在客户的帮助下,尽可能的列举出所有任务.
每个开发人员都知道在最近一次迭代完成的任务点数,这个数字是下一次迭代的个人预算.不能领取超个人预算的任务点数.
根据任务的分配情况,与客户要求删除或者增加素材.
迭代进行一半的时候,进行会议.这个时间点应该有半数的素材完成.如果没有达成这个目标,考虑重新分配没有完成的任务和职责,以保证迭代按期望完成.如果分配好还是悲观,与客户协商删减素材或者排列素材优先级.
迭代中点期望的结果是有一半素材点数的完整的素材被完成.
迭代
每次迭代结束,给客户演示当前可运行的项目.
测试
单元测试是一种验证行为/设计行为/文档行为.单元测试可以避免相当数量的反馈循环.
测试套件运行起来越简单,就会越频繁的运行他们.测试运行的越多,就会越快地发现和测试的任何背离.
测试驱动开发的方法
在设计和编写产品代码之前,先编写好相应的测试代码.
影响:
- 为以后的开发提供支援.完善的测试套件可以告诉我们做出某些修改之后程序是否还在成功的运行,这样我们就可以更自由的改进程序.
- 迫使程序员使用不同的观察点.
- 迫使自己把程序设计成可测试的.
- 测试是一种文档形式.
测试促使模块之间的隔离.在编写产品代码之前,先编写测试常常会暴露程序中被耦合的区域.为了测试而对模块之间进行隔离的需要,迫使我们以对整个程序都有益的方式对程序进行解耦合.
验收测试
单元测试是用来验证系统中个别机制的白盒测试.
验收测试是用来验证系统满足客户需求的黑盒测试.
验收测试由不了解系统内部机制的人编写.
验收测试是有关系统特性的可编译/执行的文档.
验收测试会迫使程序员从很高的系统架构层面对系统进行解耦合.当前的很多成熟的系统架构,已经做出了很成熟的分层解耦实践,比如经典的mvc/后端三层架构等,引入这些架构而非自己去从无到有造轮子.站在前人的肩膀上.
自动化验收测试应该从项目初期就必须设计实现,以保证项目得到自动化测试带给系统进行解耦合的促进力.
创建一个验收测试框架是一件很困难的事情,不同迭代内只需要完成对单个迭代包含的特性进行验收测试所需要的那部分.
重构
软件模块的三个职责:
- 完成功能.这是该模块得以存在的原因.
- 应对变化
- 与阅读他的人进行沟通
重构的目的在于,在完成功能的大前提下,让软件模块更易于阅读,易于修改.
提取出函数所增加的可读性是值得花费额外的一些微小开销的.先假设这些微小开销并不会影响系统运行,如果真的出现影响的情况,再去解决.
重构就好比用餐后对厨房的清理工作.每天清理你的代码,不要让脏乱积累.
在<重构>里提到过,重构应该是对程序员来说应该是一件频繁的事情,对程序员来说就像空气一样,出现在编码的所有地方.