阅前提醒
本人 phper 不善 java，虽然能看懂本书中大部分的例子，但关于 java 特有的一些讲解暂时没有触及，并且我会对一些优化方案提出自己的一些主观看法，并不会完全按照书中的优化方法去做。
命名 (part.1)
计算机界有两大难题：缓存和命名。一个好的命名是对事物最准确的描述，代表了程序最清晰的表达，命名是最简单的实现，却又是最难做好的事情。关于如果有一个好的命名，书中提到了一些方法论，不管是函数名、变量名、类名......凡是用到名字的，都是可以参考的。
- 命名能够体现上下文的关联
$goodsNumber = 10;
$price = 2.5;
$a = $goodsNumber * $price;
$a 对于程序执行不会产生任何影响，但从代码可读性上来说，它和上下文没有任何关联，本来可以一扫而过的代码却要被迫深入的看下逻辑，增加阅读难度。
- 避免使用数据类型、系统关键字、相似度高的名字
$orderList = Order::query();
$define = 'haohaoxuexi';
$order0bserver = Order::boot();
$orderObserver = Order::boot();
$orderList 中的 list 有可能是被人认为是指代链表这个数据结构的，用 $orders 或 $orderGroup 来表示一个数据集合更好，define 在 php 中是一个定义常量的函数名，至于最后一个例子，数字 0 和字母 O 会造成混淆。
主观看法：关于名字中包含 list 的问题，说实话工作中见到了太多这样的代码，一般多见于列表相关的逻辑块中，查下列表的翻译，第一个就是list，更多人在命名时想到的是业务相关列表而不是数据结构，硬说是数据集合也解释的通，总之我是不提倡，不反对
- 名字精简不要废话
$nameString = 'zhangsan';
名字只能是字符串，总不能是布尔值吧，命名也要遵循常识，$name 就可以了。
- 要能读出来的名字
$hahahahaha = 'kaixin';
名称完全表达了内容，但是在大庭广众真的能念出来吗？
主观看法：平时真没什么人直接念的，命名不要太离谱就行了
- 遍历中的变量多次使用可以起个合适的名字
foreach ($orders as $value) {
$price = $value->price;
$sn = $value->order_sn;
$address = $value->address;
express::send($value);
}
遍历中最常见的用 $value、$item、$v 作为元素，但是在遍历中用更有意义的名称观看会更直观，尤其是在遍历体中的逻辑代码较多时，没有意义的名称让人困惑。
- 代码前缀
$m_order = Member::order();
$a_order = Administrator::order();
用前缀来区分是普通成员还是管理员订单，只能说偷懒吧，除了当事人，没人能明白什么意思。
- 类名应该是名词，方法名是动词
class Buy {}
类代表了一个事物的抽象，应该用名词表示，可以放入 Person 这个类下作为一个动作
- 每个概念对应一个名字
$order = Order::query();
$goods = Goods::select();
$express = Express::find();
个人的编码风格，在同一套代码中能尽量保持一致的话，阅读会很舒适，查询如果都是 query 或是其他，不管代码用在何处，阅读代码都会顺畅很多。
主观看法：纯粹个人编码风格的培养，长时间的代码生涯都有自己的一套逻辑，如果团队有要求就按规定，没有就随意
- 英文变量名要表达准确
$orderHao = '2020210229999999';
这是真实的出自一位5年后端之手的代码，原意是想表示一个订单号。中国人不为难中国人，就是全拼我也是能理解的，但是这样中英文混用的就真的无法接收了。这个不是书中的方案，只是个人实际工作中的总结。
函数 (part.2)
- 保持短小
function orderTotal () {
//去掉参数空值和页码
$condition = $this->filterParam();
$query_time = $this->formatTime();
//设置分页用参数
$page_query = $condition;
$page_query['create_time'] = $query_time['create_time'];
$orderList = OrderModel::where($condition)->whereTime('create_time',[$query_time['start_time'],$query_time['end_time']])->paginate(10,false,[
'query' => $page_query //绑定额外参数
]);
$orderGoodsSingle = OrderGoodsSingleModel::getInstance();
//遍历添加订单商品
foreach($orderList as $key => $order){
$orderGoods = $orderGoodsSingle::where('order_id',$order->order_id)->field('name_cn,name_shop,number,main_picture,link')->select();
$orderList[$key]['goods'] = $orderGoods;
}
$page = $orderList->render();
$total = $orderList->total();
$websiteList = WebsiteModel::all();
$this->assign('websiteList',$websiteList);
$this->assign('param',$condition);
$this->assign('query_time',$query_time);
$this->assign('page',$page);
$this->assign('total',$total);
$this->assign('orderList',$orderList);
$this->title = '订单统计';
$this->assign('title',$this->title);
return view();
}
函数体的代码不宜过长，当出现过长的代码也意味着可以考虑封装了，建议是不超过20行
主观看法：20行只是个建议，不一定适用所有业务场景，但一个函数体搞个上百行代码就过分了
- 流程控制语句不要嵌套太多层级
if ($order) {
if ($order->total > 100) {
if ($order->address == 'shanghai') {
//逻辑
}
}
}
流程控制是编程复杂性的一大来源，减少层级嵌套是最为直接对代码优化的做法
- 函数应该只做一件事
function createOrder () {
//创建订单
OrderService::create();
//给下单人发邮件
$customer = Order::getCustomer();
Notificatoin::send($customer);
}
该函数是负责创建订单的逻辑，但是在该函数中还有发送邮件的逻辑，所谓“同一件事”就是处于同一抽象层级的，发邮件和订单生成不属于统一抽象层，应该封装后分离。
主观看法：什么是统一的抽象层级，书中并没有给更多的例子来说明，函数的拆分粒度我觉得需要根据代码复用情况来进行，没有人能一步到位写出好的代码，项目前期还是要以功能实现为首要任务，后期如由必要可通过重构来优化
- 向下规则
function calculateOrderAmount ()
{
orderGoodsPrice();
discount();
expressPrice();
}
function orderGoodsPrice () {}
function discount() {}
function expressPrice() {}
函数按照向下规则，依次排布，看的时候方便点。
主观看法：感觉作用不大，排顺序本来就是个增加工作量的事情，再一个现在 IDE 都有追溯的功能，直接跳转也很方便
- 参数尽量少
function sendOrderBill ($customerName, $email, $orderTotal, $billAddress) {
//给客户发账单
.....
Notification::send();
}
给客户发订单账单，参数均为订单相关信息，过多的参数给外部调用增加很大负担，调用者需要弄清楚每一个参数的含义，并且如果函数扩展，参数和外部调用者都需要修改。如果只传入一个订单对象，就解决了这些问题。
- 参数不要包含布尔
function createOrder ($isCancel = false|true) {
if ($isCancel === true) {
Order::cancel();
} else {
Order::create();
}
}
通过传入是否取消订单的布尔值，执行不同的创建订单还是取消订单操作，其实这个还是强调函数只做一件事。
主观看法：有时候确实需要，毕竟是参考，以实际情况为准，先实现后优化
