钛节点

胡乱唠嗑，唠唠技术人员

发表@2020-06-29 13:57:54

更新@2023-04-27 18:42:02

大家好，我是彷徨、迷茫且失落许久的神棍局二号人物 --- 副局长兼谢顶道人老李。

前段时间吧，确切说自从《PHP网络编程》基本结篇后，巨大的真空以及某些原因导致我断更许久，天天泡在群里发小图小视频，最近理智逐渐恢复正常，遂写一篇唠唠。

先说后边我打算开个新的系列，叫做《API安全指东》，看完后去面试犹如上如天下入地，糊住面试官要50K，糊不住了要5K。放心，依旧是不要钱的套路，主要还是说：不要钱腰杆子就是直！说话就是硬气！拖更说拖就拖！这个系列呢，初步预期在八至十个章节左右，不限语言，你整完后真的是「小母牛周游世界 --- 走哪儿牛B到哪儿」。

最近一直在琢磨出路、未来、预期，思来虑去结论依然是一句废话：技术人员出路依然是技术，而且是深度到具备护城河效应。这里要给各位提个小醒：我知道有人说转管理，转管理没问题，只是你不要把当个技术小组长与管理划等号即可，这里边压根就不是一回事。「深度上，好好筑基；业务上，多思考沉淀」，其实，至少要占据深度上这一席之地！

（以上为个人想法，百花争鸣，以你为准）

有些小老弟可能会有疑惑：可公司项目重构啊、设计啊，不都组长带头么？逻辑上肯定得组长带头啊，但没有人阻碍你主动参与。如果你遇上个爱划水骗工资的组长，他没准巴不得你冲到前边。你要收获的是积极参与过程中的经验、教训，而不是一个虚职。

此处再次借郭大爷一句话修改一下：技术人拼到最后，全是基础。

基础好，粘贴过来的代码就是靠谱；基础不好，无论你粘啥语言的代码都粘不好。尤其是对于PHP这种语言来说，非常容易就能看出这代码写的靠不靠谱。就比如下面这段代码：

```php
<?php
class Order {
    /*
     * @desc : 大概就是获取订单，然后如果订单为线上支付，获取卡号 
     */
    public function getOrderInfoById($id) {        
        $order = $this->order->where('id'=>$id);
        if($order['pay_type'] == 'credit'){
            $creditInfo = $this->credit->where('id'=>$id);
        }        
        $order['creditInfo'] = $creditInfo;
        return $order;
    }
}
```

你要说这代码能用不，反正也能用，倒是满足「又不是不能用」的底线。一个稍微比这个靠谱点儿的，应该写成这样：

```php
<?php
class Order {
    /*
     * @desc : 大概就是获取订单，然后如果订单为线上支付，获取卡号 
     */
    public function getOrderInfoById($id) {    
        // 默认给个兜底空对象，以防客户端闪退
        // 不能给空数组，json序列化后结果不一样
        $emptyCreditInfo = (object)[];
        $order = $this->order->where('id'=>$id);
        if(empty( $order )) {
            // 如何如何如何...抛一个异常
            // 一般说没有该订单，属于核心逻辑故障
            // 直接给错误，就不要走兜底返回空了，而是返回错误
            throw new Exception();
        }
        // 这种==判断，反着写，保证不会因你手残少写一个=
        // 而变成true        
        if('credit' == $order['pay_type']){
            // 没有拿到支付方式，根据业务取舍，如果在你
            // 业务里属于关键数据，那就也抛异常
            // 如果不算核心，直接走兜底空数据也可接受
            $creditInfo = $this->credit->where('id'=>$id);
            // 判定获取信用卡结果错误，这里用 ！抽象代替了
            if(!$creditInfo){
                $creditInfo = $emptyCreditInfo;
            }
        }    
        $order['creditInfo'] = $creditInfo;
        return $order;
    }
}
```

上面这种写法，足以保证当你的调用方为静态语言时候，由于PHP过于「灵活」导致的解析失败继而crash，如果反馈到APP，修正前的写法极有可能直接导致APP闪退。如果你还想进一步完善一下，还可以这样再升级一下：

```php
<?php
class Order {
    /*
     * @desc : 大概就是获取订单，然后如果订单为线上支付，获取卡号 
     */
    public function getOrderInfoById($iId) {    
        // 默认给个兜底空对象，以防客户端闪退
        // 不能给空数组，json序列化后结果不一样
        $oEmptyCreditInfo = (object)[];
        $aOrder = $this->oOrder->where('id'=>$iId);
        if(empty( $aOrder )) {
            // 如何如何如何...抛一个异常
            // 一般说没有该订单，属于核心逻辑故障
            // 直接给错误，就不要走兜底返回空了，而是返回错误
            throw new Exception("如何如何如何...");
        }
        $aOrder['creditInfo'] = $oEmptyCreditInfo;
        // 这种==判断，反着写，保证不会因你手残少写一个=
        // 而变成true        
        if('credit' == $aOrder['pay_type']){
            // 没有拿到支付方式，根据业务取舍，如果在你
            // 业务里属于关键数据，那就也抛异常
            // 如果不算核心，直接走兜底空数据也可接受
            $aCreditInfo = $this->oCredit->where('id'=>$iId);
            // 判定获取信用卡结果成功，这里用 if（）抽象代替了
            if($aCreditInfo){
                $aOrder['creditInfo'] = $aCreditInfo;
            }
        }    
        return $aOrder;
    }
}
```

就是变量命名方式：
- 数组类型加个a前缀
- 对象类型加个o前缀
- 字符串类型加个s前缀
- 整数类型加个i前缀
- 浮点类型加个f前缀

这样，你在看到代码第一时间就能知道每个变量在正常时候应该是什么类型的数据。

如果你再讲究点儿，对于之前数组传参的地方都可以考虑使用对象传参，因为PHP数组永远都不能确定里边会有几个字段，但是PHP对象的成员对象可以替你保证字段永远存在。比如下面这个：

```php
<?php
function test( array $condition ){
    // 业务逻辑...
}
// 但是很难保证$condition数组中某些字段一定要存在
// 所以使用对象代替，对象声明好成员变量即可
class Object{
    public $age;
    public $name;
    public $gender;
    public $level;
}
$oCondition = new Object();
test( $oCondition );
```

或许你觉得这是代码风格与编码习惯的问题，实际上不是。就说$aEmptyCreditInfo = (object)[];这一句吧，为啥用object而不是空数组；甚至还会有人问：这个让调用方修改一下兼容一下不就行了？少年，你可以知道静态语言真的满足不了你这个要求吗？假如你的调用方是Golang，协议是HTTP+JSON，一个字段你一会儿给他返回[]，一会儿返回{}，你看看Golang那里他心态炸不炸？如果他要做，他就只能将他那里字段类型修改为interface{}，然后运行时动态判断是否以为[开头以]结尾这种方式来判定类型，勉强满足需求，这还得说还好Golang有interface，他要没有呢？但是更合理的做法不应该是你这里来保证约束吗？基础太差，意识不到这后边会有多少问题。

基础好，你跟他说：你那个代码别粘到全局里，协程／线程不安全，小心挂了。他一听就知道是什么意思，基础不好，先得搜一把什么叫协程／线程不安全，当然对于PHP而言，这些都不是问题。

所以技术人以技术维生／工作／赚钱／做生意，拼到最后全是基础。

还有就是两个常见的错觉：
- 我工作时间长了，工资就一定得跟着涨
- 我换个语言，就能工资更高

让你工资变高的不是语言，是那个岗位需要的人所具备的价值以及你是否能应聘得上，主要点是：人，而不是语言。

最后我要说的是从《穷查理宝典》里学到的一句话：关键行业的关键知识。这个和你的深度护城河是有直接联系的，因为往往是关键知识代表护城河，我举个例子来说明我想表达的。

比如说LBS这块儿，有业务需求我相信各位腿子们肯定都能纷纷通过Redis、MySQL、Mongodb等等等等实现业务要求，这一层大伙儿都没问题。

再往下一层，无论是你是用Redis、MySQL、MongoDB、ElasticSearch、PostGre等等等等，其实他们都是基于不同的geo索引实现GIS查询，无外乎Geohash、Google S2、H3、RTree等，知道点儿这些数据结构，就知道关键点在这里，这算是二层。

深入了解这些数据结构和算法的实现，其实你就发现大伙儿不为别的，都是为了一个词语：降维。三维变二维，二维变一维，然后抛给CPU去计算距离去判定范围，这算是三层。

再往下是这些理论的理论支持，Geohash的理论基础依据是皮亚诺曲线，那么皮亚诺曲线是如何降维的，有什么缺陷？为什么后来的希尔伯特曲线更好？这些已经是纯理论支撑了，可以当作是第四层。能到这一层的，已经一定程度涉及到数学了。

大多数人可能都在第一层晃荡，所以你看完后，你觉得如果你深入了解LBS这块儿的东西，关键知识是什么呢？克服了哪些就可以逐渐形成与同行之间的绝对护城河优势甚至是碾压呢？

没事儿思考思考这些。最后总结一下就这点儿想表达的：
- 河挖宽、墙筑高、粮积广，深度走深，形成对大多数同行的优势
- 某个领域的关键知识，这是你进军任何领域都要第一点要意识到的
- 不要拿幸存者偏差当榜样，把自己当作没有任何运气的大多数