软件设计复杂性的体现

封面来源: https://www.pexels.com

《A Philosophy of Software Design》读书笔记(2)

软件设计的复杂性到底有哪些表现呢?

一般表现为三种方式,并且每一种方式都会是开发任务更难执行。

1. 当新增特性时,需要修改大量的代码


首先,复杂性会体现在代码修改上,看似很简单的一处代码修改,往往需要涉及到很多地方。比如,一个网站由许多页面组成,每个页面都需要显示一个带背景的导航栏,最糟糕的方式是这个背景颜色分别定义在每一个页面上,如果要改变这个网站的背景颜色,我们就必须针对每一个页面手动修改,如果有数百个页面这就很不现实。解决办法是我们可以将这个背景颜色定义到一个单独的样式文件中,在每个页面引用这个样式文件,这样如果要修改背景颜色就只需要做一次修改。好的设计可以减少受每个设计决策影响的代码量,因此设计更改不需要太多的代码修改。

2. 当需要完成一个功能时,开发人员需要了解许多知识


这种体现在当我们要完成一个任务时,我们要对代码有多深入的理解。理解程度高,就代表我们要花更多的时间来阅读代码,我们都知道读别人写的代码是很艰难的,可能还得骂人。在这过程中,很可能就会产生bug,因为我们会疏忽某些地方的代码。比如有一个C函数用来申请内存空间的,并返回指针,设计这个函数的人想着调用者自己释放内存,这种情况就增加了对代码的理解成本,后面的人如果忘记释放内存,就会导致程序内存溢出。如果这个函数在设计的时候,不需要调用者关心内存的释放,这就可以降低对代码的理解程度。

一般,有多个方法的API、全局变量、代码的不一致和模块间的依赖都会使代码难理解。

系统的设计者通常都会用代码的行数来衡量系统的复杂性,他们认为代码行数越少,系统就越简单,在修改代码时,修改的越少那么这个修改就越简单。但是,这种观点忽视了前期理解代码的成本。相反,行数多的代码事实上才是简单的,因为它不需要花费很多精力理解代码。

3. 当新增/修改功能时,不能明显地知道要修改哪些地方


第三个就是在修改代码时,不能很明显的确认哪一部分代码需要修改或者是在修改时不清楚需要注意的点。比如在一个控制器中,我们给一个Model设置一些筛选条件来获取列表数据,由于这个Model已经有了base条件,后加的条件有可能会和base条件产生冲突,在不清楚的情况下,我们添加筛选后就可能会返回空数据。还是拿上面的背景颜色举例,我们把背景颜色放在了一个单独的样式文件中,只要修改一个地方就能使所有页面更新,但是在某些页面,导航栏还需要一个深色的阴影,更改了导航栏背景色后还需要修改阴影的颜色,如果没有意识到这一点,网站看起来可能就不协调,尽管有人会意识到这个问题,但也需要搜索每一个页面查看是否有这个阴影并修改。

上面三个代码复杂的体现中,第三点是最糟糕的,不知道不知道意味着有些点你应该知道,但是你没有办法发现它,这存在很大的隐患,只有出现bug时你才会发现。修改的复杂也是很恼人的,但只要让需要修改的代码保持干净清晰,系统就会正常工作,同样的,对于第二点,只要保证有清晰的文档就可以使修改正确,第三点因为不知道不知道,最保险的方式就是去阅读每一行代码,当然这也不太现实,项目中往往会有很多依赖,也许某些依赖还没有文档。

对于一个设计良好的软件系统来说,工程师能很快理解现有代码并很快修改它,而不会有任何疑惑。

关于软件设计的复杂性

封面来源: https://unsplash.com

《A Philosophy of Software Design》读书笔记(1)

通常,在描述一款软件系统的开发过程时,都会使用复杂性来衡量,而这里所说的复杂性是指:任何与软件系统结构有关并使整个系统难以理解和修改的设计。在软件设计时,复杂性有很多不同形式的体现,比如:某一段代码很难理解;一些小的代码修改却要花费很大的精力,或者是修改代码时不确定这段代码是否必须修改;修改一个 bug又会引入新的bug。事实上,如果一个软件系统很难理解或修改,那么这个系统一定是复杂的,相反,就是简单的。

同时,软件设计的复杂性也和成本相关。在一个复杂的系统中,哪怕是一点小小的改进都需要消耗大量的资源(人力物力财力),而在简单的系统中,大的改进往往只需要很小的精力。

上面所说的复杂性是开发人员在尝试实现特定目标时在特定时间点所体验到的,它不一定与系统的整体大小或功能有关。人们通常用“复杂”这个词来描述一个有很多复杂功能的系统,但如果这个系统使用起来很方便,那么使用我们上面说的“复杂性”衡量是有失偏颇的。

当然,鱼和熊掌不能兼得。事实上几乎大多数大型的复杂的软件系统使用起来都不简单。

软件设计的复杂性通常是由一些常见的活动决定的,如果一个系统中有些部分特别复杂,但是这些部分从来不会被使用到,那么它们就不会影响到整个系统的复杂性,我们可以用如下的数学公式来描述一下:

整个系统的复杂性(C)是由每个部分的复杂性(cp)决定的,cp的权重是开发人员在该部分花费的时间(tp)的比例。

相较于开发人员,复杂性对使用者来说更加明显。比如你写了一段自认为很简单的代码,如果别人阅读你的代码时感觉到复杂,那就说明这段代码是复杂的。当遇到这种情况时,我觉得有必要向别人讨论复杂的原因,与别人交流观点也是很有意思的。工程师的职责并不只是写出你认为简单的代码,也需要让同事之间的合作更方便。

PHPStorm中快速选中多个相同的单词

如何在编辑器中快速选中相同的单词,类似于Visual Studio Code中的Command+D,强大的IDEA怎么会不支持呢。拿PHPStorm来说一下吧。

Preference里面,选择keymap,在右边搜索select next,会出现如下结果:

phpstorm preference

Add Selection for Next Occurrence就是我们想要的,默认是^+G,就是control+G,这两个键的距离里的还是很远的,我们可以手动设置,同时,这个选项的上一个选项Find Next / Move to Next Occurrence,这也是一个很实用的快捷键,可以快速调转到下一个相同的词,快捷键为Command+G

不止于此,插件市场中还有相关的插件,在插件市场中搜索browse wor(不需要写全,会自动出来)

BrowseWordCaret

但是这个插件我并没有弄懂它的快捷键在Mac上怎么用的,于是果断卸载用自带的快捷键。

简单聊聊PHP中的反射(Reflection)

简单聊聊PHP中的反射

和Java一样PHP中也提供了一套完整的反射API,何为反射?以前我们是先写类,再在类中添加各种方法和属性,最后实例化一个类对象调用属性和方法。那有我们没有办法只通过这个实例对象获取到关于这个类的全部信息呢,包括有哪些方法和属性它们分别在多少行?答案就是反射

几个常用的反射API的类
类名 作用
Reflection 为类提供摘要信息
ReflectionClass 对类提供反射
ReflectionMethod 对方法提供反射
ReflectionParameter 对方法参数提供反射
ReflectionProperty 对类属性提供反射
ReflectionFunction 对函数提供反射
ReflectionExtension 对扩展提供反射
ReflectionException 对异常提供反射

ReflectionClass

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
class People {
protected $name = 'Foo';
protected $age = 18;

public function __construct($name,$age)
{
$this->name = $name;
$this->age = $age;
}

public function toString()
{
echo "Name: $this->name, Age: $this->age" . PHP_EOL;
}
}

class Student extends People {
public $major;

public function __construct($name, $age, $major)
{
$this->major = $major;
parent::__construct($name, $age);
}

public function toString()
{
echo "Name: $this->name, Age: $this->age, Major: $this->major" . PHP_EOL;
}
}

$reflect = new ReflectionClass('Student');
Reflection::export($reflect);

输出结果如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Class [ <user> class Student extends People ] {
@@ /…/demo1.php 18-31

- Constants [0] {
}

- Static properties [0] {
}

- Static methods [0] {
}

- Properties [3] {
Property [ <default> public $major ]
Property [ <default> protected $name ]
Property [ <default> protected $age ]
}

- Methods [2] {
Method [ <user, overwrites People, ctor> public method __construct ] {
@@ /…/demo1.php 21 - 25

- Parameters [3] {
Parameter #0 [ <required> $name ]
Parameter #1 [ <required> $age ]
Parameter #2 [ <required> $major ]
}
}

Method [ <user, overwrites People, prototype People> public method toString ] {
@@ /…/demo1.php 27 - 30
}
}
}

可以看到,Reflection::export几乎提供了Student类的所以信息,包括属性和方法的访问控制状态,每个方法需要的参数以及每个方法在脚本中的位置,和var_dump相比,在使用var_dump前总是需要实例化一个对象,而且无法提供那么多详细信息。

var_dump输出如下:

1
2
3
4
5
6
7
8
object(Student)#1 (3) {
["major"]=>
string(2) "CS"
["name":protected]=>
string(5) "Jason"
["age":protected]=>
int(21)
}

虽然var_dumpprint_r是打印数据的利器,但对于类和函数,反射API提供了更高层次的功能。

PHP代码优化—getter 和 setter

PHP中要实现类似于Java中的gettersetter有多种方法,比较常用的有:

  1. 直接箭头->调用属性(最常用),不管有没有声明这个属性,都可以使用,但会报Notice级别的错误
1
2
$dog = new Dog();
$dog->name = 'hey';

  1. 添加settergetter方法,类似于Java
1
2
3
4
5
6
7
8
9
10
class Dog 
{
private $name = '';
public function setName($name) {
$this->name = $name;
}
public function getName() {
return $this->name;
}
}
  1. 使用魔术方法(最装x)
1
2
3
4
5
6
7
8
9
10
class Dog1
{
private $_name = '';
function __set($property, $value) {
if ($property === 'name') $this->_name = $value;
}
function __get($property) {
if ($property === 'name') return $this->_name;
}
}

上面三种方法,大部分人能都想到的也就是前两种方法,对于第三种方法PHP小白看了第一感觉就是好厉害(心中暗想这人一定是大佬),但是这样写真的能体现出编程水平吗?

对这几种方法,我们来对比下它们的执行效率:

方法一代码:

方法二代码:

方法三代码:

主要就是两个for循环,外层循环10次,内层一百万次,总计循环了一千万次convert函数只是用来输出可读性更高的内存使用情况。现在在我本地测试一下,测试的机器时2015款的MBP,i5 16GB内存,PHP7.2.13(cli)版本,执行结果分别如下:

方法一:

方法二:

方法三:

会什么方法三会这么慢?有人可能会说可能因为魔术方法里面的if判断,那我现在把if去掉试试:

执行结果如下:

发现if的影响很小,而且这种写法也并不推荐,这里的魔术方法就相当于一个拦截器,当调用未定义的属性时就会调用魔术方法,但这里只是测试,真实环境一定不能这么写。

从结果可以看出,我们直接使用箭头函数速度是最快的,最常用最简单的方法执行效率也是最高的,后面两种方法不仅代码行数多了一些,而且执行效率不及第一种,特别是使用魔术方法,执行效率是第一种的6倍左右,是第二种的2倍左右,古人常说“智者千虑必有一失,愚者千虑必有一得”大概就是这个意思吧,在这里代码行数和执行效率都增多了。

不过,对于第一种方法,可读性就不是很高,不管属性有没有定义都能随便调用,代码并不规范,其他人在审查你的代码时就不是很方便,建议属性属性使用前声明下。

####魔术方法还有哪些?

PHP中的魔术方法

PHP中,__call()方法可能是最有用的魔术方法了,用它可以实现很tricky的东西。当要调用类中未定义的方法时,__call()会被调用,第一个参数是调用未定义的方法名称,第二个参数是传递给调用方法的所有参数,是一个数组,__call()的返回值会返回给调用者,这样就好像调用一个真实存在的方法一样。

同时__call也可以用来实现委托委托是指一个对象转发一个请求给另一个对象,把请求的处理委托给另一个对象。这就有点类似于继承,和在子类中调用父类的方法有点相似。但在继承是父类与子类的关系是固定的,而使用委托可以在运行时改变使用的对象,委托比继承具有更大的灵活性。代码如下:

代码中Doctor类接收一个PersonWriter对象作为构造函数的参数,并将它存储在$printer中,在__call()中检查PersonWriter中是否存在$methodName方法,如果存在,就委托PersonWriter对象来处理,并将当前类Doctor的实例传给它,运行结果如下:

这样我们就不用在Doctor中手动调用如下方法:

1
$this->printer->printMe($this);

如果此时给PersonWriter增加几个新的方法,使用委托可以节省很多时间,但代码也会变得不清晰,不易理解。对于调用者来说,你提供的是一个动态的接口,没有办法进行反射(reflection),因为调用的类与被委托的类之间的交互比较模糊,使用时需要提供说明文档。

回到文章主题,我们对PHP的gettersetter相关使用进行了对比,以Java程序猿的思维看第二种方法中规中矩,没有任何套路,第一种和第三种应该是PHP才有的,但第三种方式执行的效率远不及前两种,而第一种方式虽然效率最高,但使用时尽量还是把属性声明下,使代码的结构更清晰。

正义的程序猿