以下是根据超哥（overtrue）「演讲」所整理出来的，如有问题请及时联系 Me 。

首先我们要熟记几个原则：

第一个原则：单一职责

一个类应该只做一类事情。

一个方法最多只做一件事情。

例如： 邮件类就应该只发送邮件，但是不关心发给谁，你告诉我发给谁我就发给谁。 如果你发现你在 Mail.php 里使用了 User::find()，这样的语句存在的时候，就真的是在乱搞了！

第二个原则：不要做超前的设计

就是，你不要觉得「这代码以后应该会用到，先留着吧」这样是不正确的，用到的时候再加吧，不要做这些提前的过度设计（当然，一个良好的可拓展的系统是以后方便拓展的基础啦）。

第三个原则：三次原则

如果一段代码，你在一个地方写了一次，两个地方写的时候你在想，我是不是该封装到另外的方法或者抽到另外的类里去呢？ 答案是最好在你第三次重复它的时候才抽出。

当然这个为啥是三次，我的理解是：

重复一两次（当然不是大段大段的，一般是一个小的转换代码这样的几行）对于阅读来讲比打开另外的一个类，一个文件去找这个方法要方便得多（也不是很冗余，所以说在第三次重复的时候才抽出去，这只是一个折中的点吧）。

这三个原则是比较基础的了，还有很多当然是可以让你代码写得更好的原则定义，可以去翻阅大神的一些文章。

超哥个人写代码的一些思路

超哥个人写代码的一些思路，及从大神同事那里学到的一些技巧。

写代码的方法，可以考虑以树状结构来写：

什么是树状结构呢？

比如我们现在写一个公司内部用的图书馆，其中的一个逻辑是拥有一本书的人通过表单创建一条贡献，那么这是一个 action 要完成的业务逻辑。

我们第一步，对它进行拆分：

  1. 验证输入
  2. 拿输入的 ISBN 从豆瓣取书的信息
  3. 创建 Book 实体并写入数据库
  4. 创建 Contribution 实体并写入数据库
  5. 响应

这是 postContribution 这个动作所包含的最顶层的逻辑划分：

.
.
.
public function postContribution(Request $request)
{
    // 1. 验证输入
    // 2. 拿输入的 ISBN 从豆瓣取书的信息
    // 3. 创建 Book 实体并写入数据库
    // 4. 创建 Contribution 实体并写入数据库
    // 5. 响应
}
.
.
.

我们的代码第一步已经完成了。

下一步怎么办？给每个逻辑起个名。

当然了，第 1 与第 5 就不用了，框架封装的比较好了。

于是代码变成了这样：

.
.
.
public function postContribution(Request $request)
{
    // 1. 验证输入
    $this-validate($request, $rules);
    // 2. 拿输入的 ISBN 从豆瓣取书的信息
    $bootInfomation = $this->getBookFromDouban($isbn);
    // 3. 创建 Book 实体并写入数据库
    $book = new Book($bookInformation);
    // 4. 创建 Contribution 实体并写入数据库
    $this->createContribution($book);
    // 5. 响应
    return back()->withMessage('贡献成功！');
}
.
.
.

这时候 getBookFromDouban、createContribution 这些方法都还没有写的，所以参数设计并不一定正确，后续发现不对再回来修改。

然后你再去创建这些子方法。

记住：创建子逻辑方法的时候同样使用这个方式去拆分。

那其实这就是我说的树状结构的写法：

  1. 拆分逻辑变成步骤的注释；
  2. 将注释视复杂度变成方法；
  3. 递归对方法使用此技巧。

如何拆分「类」

做一个复杂模块的时候，很多人一听到这个需求描述的时候就吓晕了。

比如：

例1：我们现在要做一个登录模块（以微博 API 的登录为例）,微博 API 的认证流程分为 4-5 类（有些已经废弃）。

例2：1. 账号密码登录，2. 扫码登录，3. QQ，支付宝等 OAuth 登录，4. 短信登录（真的很奇葩），5. 其它同站业务使用 access token 登录，每个业务的实现都不一样。

怎么办？

很多新手已经傻了，打开 IDE，if ($method == 1)..elseif ($method == 2).... N，就开始写了。

这是不对的！

那么这时候就是理清思路的时候了。

几个词：Who（谁）, How（怎么做）, What（做什么）

参与者：这个逻辑里的参与者， 凭证（Credential），会话状态（Session），用户（User）

怎么做：这个是动词，所以不应该以动词来为类命名，最终它的产物应该是设计模式，比如这个模块可以用适配器模式。

做什么：它通常定义了整个模块的名称，Login

所以最终的代码可以写成：

Manager

Credential\Password
Credential\SMS
Credential\Token
...

Authenticators\BaseAuthenticator
Authenticators\SMSAuthenticator
Authenticators\TokenAuthenticator
...

User
Session

Manager 是主控，负责接收输入，创建对应的登录器 Authenticator，完成登录动作，并返回登录用户，保存会话这么一些大局观的动作。

Credential 完全就像模型了（或者实体），只是承载对应授权方式所需要的信息，比如 Credential\Password 里应该有用户名与密码，同时 getUsername()，getPassword() 提供这些方法。

最后两个就不用讲了，User 是同一个，无论你用什么方式登录，最后都得到的是一个用户，所以它只是最后的产出。

Session 这里就不讲了大家都熟悉。

然后在 Manager（或者 AuthorizeManager）里应该有一些方法，比如：login（CredentialInterface $credential）， getAuthorizedUser() ....

AuthorizeManager
CrendentialInterface

Credential\Password
Credential\SMS
Credential\Token
...
AuthenticatorInterface

Authenticators\BaseAuthenticator
Authenticators\SMSAuthenticator
Authenticators\TokenAuthenticator
...

User
Session

所以文件与职责已经拆分完成了。

过了一个月后，老大说：我要加一个微信登录！！！！

没问题，不就是加一个 Credential 与 Authenticator 就完事了，互不干扰。

原文链接