想要用 Light 字体的话，进字体册里面，找到对应的字体，把除了 Light 之外的都禁用了，就行了

自举是为了证明语言的表达能力，同时语言的设计者也可以通过这样一个实际的复杂的项目来验证语言的设计

程序设计是从需求分析阶段就开始了...不过现在干 php 的都挺不重视这个的

设计类最主要的还是需要学习面向对象设计方法论，经典的比如 grasp 的创建者模式和信息专家模式在划分类时都是很有用的指导。这方面可以看看 uml 与模式应用 这本书

进一步地，可以看看领域驱动设计，尽管可能受限于环境因素不能照搬，但理解它的领域模型聚合实体值对象领域服务领域事件等概念还是挺有用的。这方面的书写得都挺难看的...随便找本书翻翻了解下概念，然后可以去汤老师 cnblogs.com/netfocus 的博客上看看，他的文章写得很好

最后，我的感觉，不一定对， php 这行业平均水平就这样了，写写过程式代码完成需求就行了，你弄些复杂的概念进来同事不一定看得懂，还影响同事间关系...业务代码翻来覆去就那样，平时工作里干的那些零零碎碎的工作对自己的技术提升真是有限，有时间多学点基础知识，搞点完整的复杂项目，这种提升才是真实的

以我浅薄的语文水平回答下

lend/lent 是动词， lend time 是一个动作（借谁的时间给谁？）而不是一个名词
形容词修饰名词（美丽的姑娘，牛逼的码农， created time ），组合后还是名词
多个名词组合在一起，一般也是一个词修饰另一个词（码 农，英 语 ），也还是名词

毕业多年，还记得这个网址 202.202.43.125/web

我在 v 站的回复还真没怎么复制粘贴过别人的东西。昨天吃饭的时候看到这个问题，用手机打了一点字，吃完回来在电脑上编辑了一下，删掉了附图，因为是项目的测试代码不应该发出来

我的回复里一直在强调测试代码的可维护性，因为这是切身的体会，我们团队早期对单元测试也不熟悉，照着文档就开写，追求 100%的覆盖率，每个 private 方法都用反射搞出来把测试写了，这样做了之后覆盖率报告 x 是很好看了，全是绿色，但是到了之后需求来了要修改代码的时候就很难过了，不仅要改业务代码，还要修改大量的测试代码，这对开发来说是个很大的负担，并且由于每个测试代码写得也很庞杂，导致理解和维护这些测试代码变得比维护业务代码还麻烦，进而就导致了开发人员消极对待单元测试

因为我们项目在上升期，每期迭代都有很多需求要做，也发生过新需求的修改影响到别的业务的正常使用的问题。所以我们团队对于单元测试最大的期望就是能及时发现新的代码修改对整个系统的影响，同时尽量减少开发人员的负担，所以我们现在基本只测试 public 方法，虽然如此，因为类写得比较内聚，对 public 方法完善的测试其实也已经覆盖到了大部分代码

关于 DataProvider ，为什么我烦它呢？也是在早期，大家基本上就是按照一个业务方法对应一个测试方法这样来写，对于复杂的业务方法，有很多异常情况处理，这些都需要测试，于是就在 DataProvider 里面弄上十几条各种数据，然后在一个测试方法里面对所有这些场景编测试代码，一堆的 if ，等于是把十几种测试用例一股脑地揉在一个方法里面，你可以想见这种测试代码在维护的时候是什么感觉。所以之后我们一般就按照一个测试用例一个测试方法这样来组织测试，很少用 DataProvider 了

关于为什么追求测试代码的简洁性，因为我改过几个之前我自己写的测试，这些测试方法或者是依赖于一些外部接口，或者是会调用一些重型操作，我们测试的时候是通过向被测试方法注入 MockObjectBuilder 构造出来的 Mock 对象来做的，于是出现了一个测试方法前面几十行都在构造测试环境，后面几十行各种 assert 检查数据细节是否达到了要求，很不好看，一眼看不出测试，所以基本上现在测试代码就写成这个样子:

/**
* 成功调用 add 方法后，应该持久化消息数据
*
* @return void
*/
public function testShouldPersistMessage_afterAdd()
{
$this->assertMessageNotExist($this->message);

$this->service->add($this->message, new SampleDataProvider());

$this->assertMessageExist($this->message);
}



所以上一条的回复都是我近些日子里实际的一些体会，不一定对，也不适合所有人，权且当作一个参考吧

首先要明确你为什么要写单元测试？你希望它解决什么问题？回答了这个问题之后写测试的思路可能就比较清晰了

对于我来说，单元测试主要的作用是提高代码的可维护性，确保以后修改代码能及时发现影响范围，重构是否破坏了原有的业务逻辑？修改是否影响到了其他业务逻辑？如果程序写完之后就不需要维护了，那就完全没必要写测试

那么由此再说说我的一些体会

1. 测试代码要简洁清晰
测试代码比业务代码更追求可读性，它唯一的用户就是维护者，不需要考虑性能之类的问题，而混乱的测试代码比混乱的业务代码更让人不想维护。一个测试应该遵循三段论: 初始化场景，执行被测试方法，验证执行结果，所以一个理想的测试方法应该只有三行（ clean code 书里已经说得很清楚了）

2. 测试范围
所有 public 方法，重要的 protected 方法，几乎不测试 private 方法
public 方法是类的公开 api ，可能被各种业务调用，所以一定要保证任何改变了 public 方法行为的修改都被检查到
同样 protected 方法是对子类公开的，对于被很多子类使用的 protected 方法，需要确保对它的修改不影响子类的行为
private 方法很不稳定，可能经常被修改，它只在类内部被调用，对 public, protected 方法的测试已经把它覆盖到了

3. 针对方法特性测试，而不是针对实现测试
可以把被测试代码当成一个黑盒，给它一个需求要求的输入，然后验证它是否返回了期待的输出。不需要去验证它在处理这个东西的过程中干了什么，没必要，因为具体实现可能会因为各种原因而修改，我们只要确保测试能检查到修改后的程序是否满足需求要求就行了
同时，又要保证测试覆盖了方法的所有的需求点，包括异常情况都需要写测试覆盖到。一个测试用例写一个测试方法
比如这个测试文件，这些测试方法都只在测一个 public 方法（不要吐槽方法命名...）
http://i.imgur.com/eBtG2j1.png

4. 其他
- PHPUnit 的 DataProvider 慎用，不是它不好，是它很容易就搞出一些特别难维护的测试代码，比如把正常流程和异常流程的测试都放到一个测试方法里，然后用 DataProvider 提供的参数来进入不同的测试流程，整个测试方法一大坨， DataProvider 里面的数据又是一大坨，看得人想死
- 很多时候写测试会反向地要求你优化你的程序设计，最常见的例子就是依赖注入了，这里是之前 google 的一个 guide ， http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf

class Test
{
private $dynamicMethods = [];

public function __get($name)
{
return isset($this->dynamicMethods[ $name ]) ? $this->dynamicMethods[ $name ] : null;
}

public function __set($name, $value)
{
if ($this->isClosure($value)) {
$this->dynamicMethods[ $name ] = Closure::bind($value, $this, self::class);;
}
}

private function isClosure($value)
{
return is_callable($value) && get_class($value) === \Closure::class;
}

public function __isset($name)
{
return isset($this->dynamicMethods[ $name ]);
}

public function __call($name, $arguments)
{
if (!isset($this->dynamicMethods[ $name ])) {
trigger_error('Call to undefined method ' . self::class . "::{$name}", E_USER_ERROR);
}

return call_user_func($this->dynamicMethods[ $name ], $arguments);
}
}

$a = new Test();
$a->test = function () {
var_dump($this->dynamicMethods);
};
$a->test();

think in java 有点老了，看 core java 吧

@just4test 理论上重构的第一步是写单元测试，保证重构后和重构前程序运行结果一致
如果一上来直接就开始改代码，那当然容易出问题

... 只是看起来好看而已，后面维护代码的人如果要保持风格的话，一个空格一个空格地手动对齐的时候不知道心里会想些什么东西...


说回主题吧，我一般用 vim 这个插件做这事： https://github.com/junegunn/vim-easy-align ，你这个格式比较简单，直接按照逗号对齐就行了，可以再自己录一个宏

phpstorm 本身的 formatter 不支持这种样式的对齐，需要用一个插件： String Manipulation ，选中一段代码，右键 -> string manipulation -> align -> align columns ，估计要重复操作几次才行，而且这个插件有问题，处理后的段落都没有缩进了，还需要自己手动再调整下

java 的单例就考一个 double check 吧

川大没什么好逛的，没川大的朋友带着只能在校园里走走，图书馆之类的地方进不去，当然没去过也可以去看看，望江校区不大，还是挺漂亮的

一个人的话，我可能会推荐这些地方:

浣花溪公园，然后旁边的四川省博物院
大熊猫基地，然后旁边的成都市植物园
春熙路，然后周围的方所书店，西西弗书店

@bulldozer 嗯，这个地方确实有需求，可以代替一部分白板的功能