背景

长话短说，就是在2022年6月的时候加入了一家很小创业公司。老板不太懂技术，也不太懂管理，靠着一腔热血加上对实体运输行业的了解，加上盲目的自信，贸然开始创业，后期经营困难，最终散伙。

自己当时也是不察，贸然加入，后边公司经营困难，连最后几个月的工资都没给发。

当时老板的要求就是尽力降低人力成本，尽快的开发出来App(Android+IOS)，老板需要尽快的运营起来。

初期的技术选型

当时就自己加上一个刚毕业的纯前端开发以及一个前面招聘的ui，连个人事、测试都没有。

结合公司的需求与自己的技术经验(主要是前端和nodejs的经验)，选择使用如下的方案：

1. 使用uni-app进行App的开发，兼容多端，也可以为以后开发小程序什么的做方案预留，主要考虑到的点是比较快，先要解决有和无的问题；


2. 使用egg.js + MySQL来开发后端，开发速度会快一点，行业比较小众，不太可能会遇到一些较大的性能问题，暂时看也是够用了的，后期过渡到midway.js也方便；


3. 使用antd-vue开发运营后台，主要考虑到与uni-app技术栈的统一，节省转换成本；

也就是初期选择使用egg.js + MySQL + uni-app + antd-vue，来开发两个App和一个运营后台，快速解决0到1的问题。

关于App开发技术方案的选择

App的开发方案有很多，比如纯原生、flutter、uniapp、react-native/taro等，这里就当是的情况做一下选择。

1. IOS与Android纯原生开发方案，需要新招人，两端同时开发，两端分别测试，这个资金及时间成本老板是不能接受的；


2. flutter，这个要么自己从头开始学习，要么招人，相对于纯原生的方案好一点，但是也不是最好的选择；


3. react-native/taro与uni-app是比较类似的选择，不过考虑到熟练程度、难易程度以及开发效率，最终还是选择了uni-app。

为什么选择egg.js做后端

很多时候方案的选择并不能只从技术方面考虑，当是只能选择成本最低的，当时的情况是egg.js完全能满足。

1. 使用一些成熟的后端开发方案，如Java、、php、go之类的应该是比较好的技术方案，但对于老板来说不是好的经济方案；


2. egg.js开发比较简单、快捷，个人也比较熟悉，对于新成员的学习成本也很低，对于JS有一定水平的也能很快掌握egg.js后端的开发。

中间的各种折腾

前期开发还算顺利，在规定的时间内，完成了开发、测试、上线。但是，老板并没有如前面说的，很快运营，很快就盈利，运营的开展非常缓慢。中间还经历了各种折腾的事情。

1. 老板运营遇到困难，就到处找一些专家（基本跟我们这事情没半毛钱关系的专家），不断的提一些业务和ui上的意见，不断的修改；


2. 期间新来的产品还要全部推翻原有设计，重新开发；


3. 还有个兼职的领导非要说要招聘原生开发和Java开发重新进行开发，问为什么，也说不出什么所以然，也是道听途说。

反正就是不断提出要修改产品、设计、和代码。中间经过不断的讨论，摆出自己的意见，好在最终技术方案没修改，前期的工作成果还在。后边加了一些新的需求：系统升级1.1、ui升级2.0、开发小程序版本、开发新的配套系统(小程序版本)以及开发相关的后台、添加即时通信服务、以及各种小的功能开发与升级；

中间老板要加快进度了就让招人，然后又无缘无故的要开人，就让人很无奈。最大的运营问题，始终没什么进展，明显的问题并不在产品这块，但是在这里不断的折腾这群开发，也真是难受。

明明你已经很努力的协调各种事情、站在公司的角度考虑、努力写代码，却仍然无济于事。

后期技术方案的调整

1. 后期调整了App的打包方案；


2. 在新的配套系统中，使用midway.js来开发新的业务，这都是基于前面的egg.js的团队掌握程度，为了后续的开发规范，做此升级；


3. 内网管理公用npm包，开发业务组件库；


4. 规范代码、规范开发流程；

人员招聘，团队的管理

人员招聘

如下是对于当时的人员招聘的一些感受：

1. 小公司的人员招聘是相对比较难的，特别是还给不了多少钱的；


2. 好在我们选择的技术方案，只要对于JS掌握的比较好就可以了，前后端都要开发一点，也方便人员工作调整，避免开发资源的浪费。

团队管理

对于小团队的管理的一些个人理解：

1. 小公司刚起步，就应该实事求是，以业务为导向；


2. 小公司最好采取全栈的开发方式，避免任务的不协调，造成开发资源的浪费；


3. 设置推荐的代码规范，参照大家日常的代码习惯来制定，目标就是让大家的代码相对规范；


4. 要求按照规范的流程设计与开发、避免一些流程的问题造成管理的混乱和公司的损失；
   
   
   
   1. 如按照常规的业务开发流程，产品评估 => 任务分配 => 技术评估 => 开发 => 测试 => cr => 上线 => 线上问题跟踪处理；
   
   
   
   


5. 行之有效可量化的考核规范，如开发任务的截止日期完成、核心流程开发文档的书写、是否有线上bug、严谨手动修改数据库等；


6. 鼓励分享，相互学习，一段工作经历总要有所提升，有所收获才是有意义的；


7. 及时沟通反馈、团队成员的个人想法、掌握开发进度、工作难点等；

最后总结及选择创业公司避坑建议!important

1. 选择创业公司，一定要确认老板是一个靠谱的人，别是一个总是画饼的油腻老司机，或者一个优柔寡断，没有主见的人，这样的情况下，大概率事情是干不成的；
   
   
   
   1. 老板靠谱，即使当前的项目搞不成，也可能未来在别的地方做出一番事情；
   
   
   
   


2. 初了上边这个，最核心的就是，怎么样赚钱，现在这种融资环境，如果自己不能赚钱，大概率是活不下去的@自己；


3. 抓住核心矛盾，解决主要问题，业务永远是最重要的。至于说选择的开发技术、代码规范等等这些都可以往后放；


4. 对上要及时反馈自己的工作进度，保持好沟通，老板总是站在更高一层考虑问题，肯定会有一些不一样的想法，别总自以为什么什么的；


5. 每段经历最好都能有所收获，人生的每一步都有意义。

以上只是个人见解，请指教。

大家好，让我们继续DDD&微服务系列，今天，我们看看在DailyMart项目中如何基于DDD实现库存扣减功能。

1. 库存模型

1.1 核心概念

库存是一个非常复杂的概念，涉及在仓库存，计划库存，渠道库存等多个领域实体，在我们《DailyMart微服务&DDD》实战中，主要关注的是在仓库存模型。

在这个模型中有三个重要的概念：可售库存、预售库存、占用库存，他们的定义如下：

可售库存数（Sellable Quantity，SQ）
可售库存即用户在客户端所见的商品可销售数量。当SQ为0时，用户不能下单。

预扣库存数（Withholding Quantity，WQ）
预扣库存是指被未付款的订单占用的库存数量。这种库存的存在是因为用户在下单后可能不会立刻付款。预扣库存的作用是为用户保留库存，直到用户完成付款，才会从中扣减相应数量的库存。如果用户未能在规定时间内付款，预扣库存WQ将被释放回可售库存SQ上。

占用库存数（Occupy Quantity，OQ）
占用库存是指已经完成付款，但尚未发货的订单所占用的库存数量。这种库存与仓库相关，并且牵涉到履约流程。一旦订单发货，占用库存会相应减少。

根据上述定义，对于一个商品，可售库存数量与预扣库存数量之间的关系是：可售库存（SQ） + 预扣库存（WQ） = 可用库存。

由于每种商品通常包含多个不同的 SKU，在商品交易链路中，无法通过商品id来精确定位库存。为了更高效地管理库存查询和更新请求，我们需要设计一个具有唯一标识能力的 ID，即库存 ID（inventory_id）。此外，在库存扣减操作中还需要存储库存扣减记录，一旦用户取消订单或退货时，可以根据扣减记录返还相应的库存数量。

1.2 领域模型

通过对库存领域概念的分析，我们很容易完成DDD领域建模，如下图所示：

库存 (Inventory)： 库存对象充当库存领域的聚合根，负责管理和跟踪商品的可售库存、预扣库存和占用库存等信息。库存对象也具备唯一标识能力，使用库存 ID（inventory_id）来标识不同库存。

库存记录 (InventoryRecord)： 库存记录是一个实体，用于记录库存的各种操作，例如扣减、占用、释放、退货等。每个库存记录都有一个唯一的记录 ID（record_id）来标识。

库存 ID（InventoryId）和记录 ID（RecordId）： 这两者都是值对象，它们负责提供唯一标识，分别用于标识库存和库存记录。

库存扣减状态（InventoryRecordStateEnum）：这也是个值对象，用于标识扣减库存的状态。

2. 库存扣减

库存扣减看似简单，只需在用户支付后减少库存即可，但实际情况要复杂得多。不同的扣减顺序可能导致不同的问题。比如我们先减库存后付款，可能会出现用户下单后放弃支付，导致商品少买或未售出。另一方面，如果我们先付款后减库存，可能出现用户成功支付但商家没有足够的库存来满足订单，这又非常影响用户体验。

一般来说，库存扣减有三种主要模式：

2.1 库存扣减的三种模式

• 
  

  拍减模式：在用户下单时，直接扣减可售库存（SQ）。这种模式不会出现超卖问题，但它的防御能力相对较弱。如果用户大量下单而不付款，库存会一直被占用，从而影响正常交易，导致商家少卖。

  
  


• 
  

  预扣模式：在用户下单时，会预先扣减库存，如果订单在规定时间内未完成支付，系统将释放库存。具体来说，当用户下单时，会预扣库存（SQ-、WQ+），此时库存处于预扣状态；一旦用户完成付款，系统会减少预扣库存（WQ-、OQ+），此时库存进入扣减状态。

  
  


• 
  

  付减模式：在用户完成付款时，直接扣减可售库存（SQ）。这种模式存在超卖风险，因为无法确保用户付款后一定有足够的库存。

  
  

对于实物商品，库存扣减主要采用拍减模式和预扣模式，付减模式应用较少，在我们DailyMart系统中采用的正是预扣模式。

2.2 预扣模式核心链路

接下来我们重点介绍库存预扣模式的核心链路，包括正向流程和逆向操作。

2.2.1 正向流程

正向流程涉及用户下单、付款和发货的关键步骤。以下是正向流程的具体步骤：

1）用户将商品加入购物车，点击结算后进入订单确认页，点击提交订单后，订单中心服务端发起交易逻辑。

2）调用库存服务执行库存预扣逻辑

3）调用支付服务发起支付请求

4）用户付款完成以后，调用库存平台扣减库存

5）订单服务发送消息给仓储中心，仓储中心收到消息后创建订单，并准备配货发货

6）仓储中心发货以后调用库存平台扣减占用库存数。

2.2.2 逆向操作

逆向操作包括取消订单或退货等情况，我们需要考虑如何回补库存。逆向操作的步骤如下：

1）用户取消订单或退货。
2）更新扣减记录行，状态为释放状态。
3）同时更新库存行，以回补库存。

2.2 库存扣减的执行流程

每一件商品的库存扣减都至少涉及两次数据库写操作：更新库存表（inventory_item）和扣减记录表（inventory_record）。

为了确保库存扣减操作的幂等性，通常需要在扣减记录表中给业务流水号字段创建唯一索引。此外，为了保证数据一致性，修改库存数量与操作流水记录的两个步骤必须在同一个事务中。

关于系统的幂等性实现方案，我在知识星球进行了详细介绍，感兴趣的可以通过文末链接加入。

在数据库层面，库存扣减操作包括以下关键步骤：

• 
  

  用户下单时：insert 扣减记录行，状态为预扣中，同时 update 库存行(减少可销售库存，增加预扣库存，sq-,wq+)；

  
  


• 
  

  用户付款时：update 扣减记录行，状态为扣减状态，同时update库存行(减少预扣库存，增加占用库存，wq-,oq+)；

  
  


• 
  

  仓库发货时：update 扣减记录行，状态为发货状态，同时update库存行(减少占用库存数，oq-)；

  
  


• 
  

  逆向操作时：update 扣减记录行，状态为释放状态，同时update库存行(增加可销售库存，sq+)；

  
  

通过下图可以清晰看到库存扣减时相关相关数据状态的变化。

3. 核心代码实现

接下来，让我们从接口层、应用层、领域层和基础设施层的角度来分析库存扣减的代码实现。（考虑到篇幅原因，省略了部分代码。）

3.1 接口层

接口层是库存操作的入口，定义了库存操作的接口，如下所示：

@RestController

@Tag(name = "InventoryController", description = "库存API接口")

@RequiredArgsConstructor(onConstructor = @__(@Autowired))

@Slf4j

public class InventoryController {

	...

	

    @Operation(summary = "库存预扣",description = "sq-,wq+,创建订单时调用")

    @PostMapping("/api/inventory/withholdInventory")

    public void withholdInventory(@Valid @RequestBody InventoryLockRequest lockRequest)  {

        inventoryService.withholdInventory(lockRequest);

    }



    @Operation(summary = "库存扣减",description = "wq-,oq+,付款时调用")

    @PutMapping("/api/inventory/deductionInventory")

    public void deductionInventory(@RequestParam("transactionId") Long transactionId)  {

        inventoryService.deductionInventory(transactionId);

    }



    @Operation(summary = "库存发货",description = "oq-,发货时调用")

    @PutMapping("/api/inventory/shipInventory")

    public void shipInventory(@RequestParam("transactionId") Long transactionId)  {

        inventoryService.shipInventory(transactionId);

    }



    @Operation(summary = "释放库存")

    @PutMapping("/api/inventory/releaseInventory")

    public void releaseInventory(@RequestParam("transactionId") Long transactionId)  {

        inventoryService.releaseInventory(transactionId);

    }

    ...

}

3.2 应用层

应用层负责协调领域服务和基础设施层，完成库存扣减的业务逻辑。库存服务不涉及跨聚合操作，因此只需调用基础设施层的能力，并让领域层完成一些直接的业务逻辑。

@Service

@RequiredArgsConstructor(onConstructor = @__(@Autowired))

@Slf4j

public class InventoryServiceImpl implements InventoryService {    

    ...

    @Override

    @Transactional

    public void withholdInventory(InventoryLockRequest inventoryLockRequest) {

        Long inventoryId = inventoryLockRequest.getInventoryId();

        //1. 获取库存

        Inventory inventory = Optional.ofNullable(inventoryRepository.find(new InventoryId(inventoryId)))

                .orElseThrow(()->new BusinessException("No inventory found with id:" + inventoryId));



        // 2. 幂等校验

        boolean exists = inventoryRepository.existsWithTransactionId(inventoryLockRequest.getTransactionId());



        if(exists ){

            log.error("Inventory record with transaction ID {} already exists, no deduction will be made.", inventoryLockRequest.getTransactionId());

            return;

        }



        //3. 库存预扣

        inventory.withholdInventory(inventoryLockRequest.getQuantity());



        //4. 生成扣减记录

        InventoryRecord inventoryRecord = InventoryRecord.builder()

                .inventoryId(inventoryId)

                .userId(inventoryLockRequest.getUserId())

                .deductionQuantity(inventoryLockRequest.getQuantity())

                .transactionId(inventoryLockRequest.getTransactionId())

                .state(InventoryRecordStateEnum.PRE_DEDUCTION.code())

                .build();



        inventory.addInventoryRecord(inventoryRecord);



        inventoryRepository.save(inventory);

    }

    ...

}

3.3 领域层

领域层负责处理直接涉及业务规则和逻辑的操作，将库存预扣、扣减、库存释放等操作封装在聚合对象 Inventory 中。同时，领域层定义了仓储接口，如下所示：

@Data

public class Inventory implements Aggregate {

    @Serial

    private static final long serialVersionUID = 2139884371907883203L;

    private InventoryId id;

	

	...



    /**

     * 库存预扣 sq-,wq+

     * @param quantity  数量

     */

    public void withholdInventory(int quantity){

        if (quantity <= 0) {

            throw new BusinessException("扣减库存数量必须大于零");

        }



        if (getInventoryQuantity() - quantity < 0) {

            throw new BusinessException("库存不足，无法扣减库存");

        }



        sellableQuantity -= quantity;

        withholdingQuantity += quantity;

    }

  

    /**

     * 释放库存

     * @param currentState 当前状态

     * @param quantity 数量

     */

    public void releaseInventory(int currentState, Integer quantity) {

        InventoryRecordStateEnum stateEnum = InventoryRecordStateEnum.of(currentState);

        switch (stateEnum){

            //sq+,wq-

            case PRE_DEDUCTION -> {

                sellableQuantity += quantity;

                withholdingQuantity -= quantity;

            }

            //sq+,oq-

            case DEDUCTION -> {

                sellableQuantity += quantity;

                occupyQuantity -= quantity;

            }

            //sq+

            case SHIPPED -> {

                sellableQuantity += quantity;

            }

        }

    }

	...

}



/**

* 仓储接口定义

*/

public interface InventoryRepository extends Repository {

    boolean existsWithTransactionId(Long transactionId);



    Inventory findByTransactionId(Long transactionId);

}

3.4 基础设施层

基础设施层负责数据库操作，持久化库存状态，如下所示：

@Repository

@Slf4j

@RequiredArgsConstructor(onConstructor = @__(@Autowired))

public class InventoryRepositoryImpl implements InventoryRepository {

    ...

    @Override

    public Inventory find(InventoryId inventoryId) {



        InventoryItemDO inventoryItemDO = inventoryItemMapper.selectById(inventoryId.getValue());

        return itemInventoryConverter.fromData(inventoryItemDO);

    }



    @Override

    public Inventory save(Inventory aggregate) {

        InventoryItemDO inventoryItemDO = itemInventoryConverter.toData(aggregate);



        if(inventoryItemDO.getId() == null){

            inventoryItemMapper.insert(inventoryItemDO);

        }else{

            inventoryItemMapper.updateById(inventoryItemDO);

        }



        InventoryRecord inventoryRecord = aggregate.getInventoryRecordList().get(0);

        InventoryRecordDO inventoryRecordDO = inventoryRecordConverter.toData(inventoryRecord);



        if(inventoryRecordDO.getId() == null){

            inventoryRecordMapper.insert(inventoryRecordDO);

        }else{

            inventoryRecordMapper.updateById(inventoryRecordDO);

        }



        return aggregate;

    }

    ...

}

小结

本文详细介绍了库存领域的关键概念以及库存扣减的三种模式，同时基于DDD的分层模型，成功实现了预扣模式的业务逻辑。在库存的预扣接口中，通过业务流水表确保了接口的幂等性，不过更新库存的接口暂时还没实现幂等，幂等会在下篇文章中统一解决。同时，值得注意的是，本文所展示的方案采用了纯数据库实现，可能在高并发情况下性能略有下降，当然这也是我们后面需要优化的点。

今天看抖音上“三根葱”演绎了一个片段：

老张指使老王干活，别人问为啥老让他干，他说：谁让他听话呢？

老李骂老王磨磨蹭蹭，别人问为啥不骂老张，他说：老张脾气大，不好惹！

最后总结，懂事的会承担更多，脾气好的都在受气，照顾人的没人照顾。

看到这里，我多少有点共鸣。

我想到，我经历过两类不同的领导。

第一种，善用权衡之术，有时特意挑起内部斗争。比如挑起产品部和技术部对立，加剧技术部和市场部不和。一开始，我还不明白，他为什么要破坏团结？

后来，我的技术领导给了我答案：

我们和产品部吵架，要找人评理，这个裁判就是他（副总），他会站在谁那边呢？这全看我们平时的表现。我们比产品部更讨好他，他就会偏向我们。下一次，产品部让他更满意了，他又会站在产品部那边。

这种权衡之术，是公开的。但是，只要你还有欲有求，你就无法破解。帮派越多，各方越对立，领导就越如帝王般尊贵。这一套，封建社会玩了几千年。看到这里，估计你不会再骂那些“昏君”了，因为他们比你清亮。

我还有一个领导。他从不挑起各部门的对立。反而，他默默地维持和谐，调和职能部门各司其职。这一点，我也能看出来。因为，如果产品部对技术部有意见，他不但不会煽风点火、添油加醋，而且都不说是产品部提的意见，他说是自己的想法。

结果呢，如同当年“不知尧舜是吾君”一样，老百姓说：我们自己过得好，和皇帝什么关系？真格的，我们皇帝是谁啊？

员工也觉得，我们部门间完全可以自驱运转。那位领导如不存在一般，不受敬畏，员工都不向他谄媚。

在我们传统的观念里，会将挑事者定义为小人，将默默行善者定义为好人。

我们从小受的教育是要当个好人。然而，长大了，我们发现，当个小人却能少受罪，更容易获得世俗眼里的成功。

想要赢了竞争，设局毁了对手效果最快。

想要笼络人心，搬弄是非，一起诋毁对方，能够快速团结一批人。

你看，利用别人的人风生水起，成就别人的人却穷困潦倒。

既然做好人没有好结果，那么当好人的意义又是什么呢？

说实话，我也一度迷茫、动摇，甚至否定。

我想，历史长河中，有没有人和我有同样的疑惑，但是他却找到了答案，而且还流传了下来，并且还恰好被我能看到。

于是，我就去古籍中找。我喜欢去找古籍，解读古籍。最好只看文言文，别有翻译。因为有时候，你读不懂，读不懂又没有翻译，你就会自己去脑补。看白纸是脑补不出来的，有那么零星几个能看懂的字，其实是古人给你一个引子，其他是你自己想出来的。你想出来的答案，肯定合乎你的逻辑，你不会抵触，反而正好解决了你的困惑。你又不是想让答案变成金条，你不就是要一个能通顺的解释吗？

这个疑惑，我在《幽梦影》中找到了答案：

黑与白交，黑能污白，白不能掩黑。此君子小人相攻之大势也。

然人必喜白而恶黑，此又君子必胜小人之理也。

把君子比做白色，小人比作比黑色。黑色很容易就能污染白色，但是多少白色都很难掩盖住一点黑色。

从这里看，君子是干不过小人。因为，小人的势力很大。

但是下一句神奇的事情来了，你喜欢君子？还是喜欢小人？

人们肯定是喜欢君子讨厌小人。谁又愿意和尔虞我诈的人一起共事呢？从这个角度看，“君子又必胜小人”。

现实中，大家虽然对小人前呼后拥，但是每个人心里却是向往光明的，选择是无奈的。

很多坚持当好人的人。并非不知道当小人的套路，只是坚守一份志向罢了。

那么，做好人的意义就有了：在这个纷纷扰扰的世态下，公序良俗依然是人们美好的向往。多数普通人只是向往，而好人却已经做到了。难道这不是碾压式的胜利吗？

至于代价，都是每个人自己选的。

「我应该如何提高解决问题的能力？尽管我掌握了 JavaScript，却无法解决实际问题或理解复杂的 JavaScript 代码。」

经常有年轻的开发者朋友问我类似的问题。对开发者来说，解决问题非常重要。编写优秀的代码是一门创造性的艺术，而要成为出色的开发者，就必须成为富有创造力的能够解决问题的人。

我发现新手程序员犯的最大的错误是专注于学习语法，而不是学习如何解决问题。—— V. Anton Spraul

尽管我观察到，解决问题的技能需要时间和经验的积累，但我坚信掌握它并不需要很多年；只要勇敢地直面问题，就会有所提高。我曾与许多初级开发人员一起工作，年轻人们也比他们的老伙计更善于解决问题。

本文将详细讲解三个技巧，让开发者可以像技术专家一样解决问题。重头戏开始之前，我们先来看看技术专家和技术小白在解决问题方面有哪些不同。

专家思维 vs 新手思维

大多数人会回避或胡乱处理问题。优秀的思考者和领导者则会主动寻找问题，他们也拥有能够更好地解决问题的方法。—— Michael Simmons

Robert J. Sternberg 教授根据美国心理学家 Herbert A. Simon、Robert Glaser 和 Micheline Chi 等人的研究，揭示了技术专家解决问题比技术小白更有效的秘密。

Arnaud Chevallier 在 Work forward in solving problems, not backward 一文中犀利写道，「逆向工作法是一种从假设出发的方法。如果想要提高利润率，逆向工作法会指引你去寻找增加收入的办法，因为增加收入可以带来更高的利润率。那减少成本呢？难道在确定最终的解决方案之前，我们不应该先全面地了解各种可以实现目标的办法吗？」

可以看到，技术专家通常会花大量的时间寻找、明确和定义问题，并且使用正向工作法解决问题，同时密切关注问题解决的过程。下面就跟大家分享，技术专家们常用的问题解决技巧。

三个专家级的问题解决技巧

01 问题十二连 The 12 What Elses

提问题听上去没什么难度，但要找到正确的、缺失的问题并准确地描述出来却不容易。Lenedra J. Carroll 介绍的「问题十二连 The 12 What Elses」可以有效帮助我们摆脱这个苦恼。

在头脑风暴时，先提出一个问题，并生成 12 个答案；然后选取其中一个答案转化为下一个问题，再生成 12 个答案。不断重复此过程，直到获得一个明确的解决方案。

通过连续地提问，我们会得到一个「问题回答地图」，它对假设的测试和结构化解决复杂问题很有帮助。

提问和追问是如何将我们往正确方向上引导的？下面两个例子可能会给你答案。

02 根本原因分析法 Root Cause Analysis

我们经常在多次解决失败后，才发现问题的情况跟预期有所不同，所以在开始解决问题之前，就要先了解其根本原因是什么。

只有消除错误的选择，才能更好地定义问题并找到有效的解决方案。根本原因分析法有助于避免在错误的方向上浪费时间和精力。

当需要修复 Bug 时，开发者可以使用以下任意方式，进行根本原因分析：

• 确定问题在哪个环境出现，并尝试在相同和不同的环境中重现它，以掌握更好的理解。


• 如果与 Web 性能有关，可以分析捆绑文件。


• 进行单元测试和集成测试。


• 进行日志文件分析。


• 进行交互式调试。

03 使用多元思维 Spectrum Thinking

二元思维认为事情的状态是非黑即白的，只有互相对立的两种可能。有些时候它是正确的，但其他时候，它可能是一种错误的简化。

与二元思维对应的是多元思维，也可以称作频谱思维（Spectrum Thinking）。它会考虑更多选择、更多替代方案和可能性，比如「两者共存」「介于两者之间」「其他的可能性」或「二者皆否」等。

通过培养多元思维，开发者可以有效提升创造力；你会惊讶地发现，修复 Bug、解决冲突、设计/执行客户需求的实现方案等居然会有这么多种解决方案和方式。

以展示信息详情为例，二元思维认为，信息详情要么通过弹窗展示，要么跳转到一个带返回箭头的新页面进行展示。

多元思维认为还有其他可能性，比如新增 Tab 页直接查看和更新信息，无需关闭当前列表页面。

多元思维还可能认为，可以提供一个支持三种布局的动态模板，让用户自主选择要用以上哪种方式。

二元思维和多元思维各有利弊，在实际工作中可以配合使用。

写在最后

解决问题能力是一个超出软件开发范畴的话题，它高度取决于我们的心态和态度。要想培养和提高解决（复杂）问题的能力，首先要对问题和挑战充满好奇心，而不是感到沮丧。

就像 Tim Hicks 说的那样，「问题就像赛车道上的弯道。处理得好，便可以在接下来的直道中状态满分；如果过弯太快，很可能会引发侧翻，影响后续赛程。」

（原文作者：Rakia Ben Sassi）

了解更多开发者提效、研发效能管理、前沿技术等消息，欢迎关注 LigaAI@稀土掘金。

LigaAI 助力开发者扬帆远航，欢迎体验我们的产品，期待与你一路同行！

莫琳：”你会去很久吗？“

哈罗德：”到街尾就回来“

    一个童年缺少母爱，父爱，中年丧子，一生都在低头做事，不敢正视他人，可以在一个小酒厂工作四十年，却不求升职加薪，与人无争，与人无交的退休老头，跋涉六百多公里，穿越整个大不列颠，拿着一封信去拯救患了癌症的老友，听起来应该是无聊透了。远远没有，帅气潇洒，带领古巴人民与美国死磕几十年，躲过n = 700次暗杀，成功睡到美国中情局女特工，并令其爱上自己，传闻睡过35000个女性的菲德尔＊卡斯特罗的故事令人感到有种有趣有料。的确，哈罗德是一个平凡以至于差劲糊涂的人，但远没有那么简单，哈罗德、哈罗德，作者是借哈罗德写我们的父母，我们的孩子，我们的朋友，我们亲爱的自己，我们每个人身上可能都有哈的影子，如今这个影子开始征程，或叫朝圣，我更倾向于叫“做梦”。因为这真的像是哈罗德的一场梦。

  这里没有艺术，没有历史，儿女情长，伟大，浪漫。

  这里只有回忆，哈罗德 距离终点很近很远，近的是，一生真的很短，远的是，回忆又是那么漫长。

”没有爱的生活不叫生活“

    哈罗德有一个酒鬼父亲，从不关心他的儿子，在十六岁生日那天，将哈赶出了家门，而他的母亲，早在很久以前已经抛弃了这个家庭去周游世界。在父母那里哈罗德没有得到一丝爱，好像还不如很多人养的宠物的到的关爱多，没有得到爱的哈罗德好像也吝啬于给予爱，路上他在回忆道：“他欠过去一点点慷慨”，但他本人是“喜欢和人交往的，希望明白她们之所爱，之所失”。哈不是一个自私心眼坏的人，（和生活中大多人一样，心眼不坏，好多父母也说，自己孩子“心眼不坏”，这个词有参考价值吗？）他只是不会表达，这种表达好像也不仅仅只是 羞于对儿子说：“爸爸爱你”，也不是：“儿子，你真棒，爸爸为你自豪”（他的儿子没有过任何亲昵的经历）。更不是对爱人说一句：”亲爱的“，好像这个人本身：”没有多少爱“，就好像爱是水，爱是食物，是力气，我们能看到摸到能展示给别人看，”看我有的是力气，我有的是爱“，就像没有力气的男人，哈罗德是一个没有爱的男人。哈罗德倒不是冷漠，也不是自私，在我看来，哈罗德一个60岁的老头，其实是个孩子，一个没有被给予爱与鼓励多的孩子，一个没有受到爱的给予的孩子，是不会轻易去爱别人，爱这个社会的。他们没有爱人的能力，更很难让人感受到来自他内心的热情与爱（友爱，情爱，亲情……）。

  哈罗德是一个“没有妈的孩子”，上学时，哈总是被小伙伴们这样嘲笑。它是一个极其脆弱敏感的孩子，他不敢交朋友，他不敢直视别人，甚至整个屋子的人看他一眼，都会脸红到脖子，他对儿子很少给予父爱，对妻子关怀，理解不够，这些都源于童年，缺失的亲情。

    一个人的成长的表现就是爱越来越多的人，事。即使受到伤害。

  （我不是鼓吹爱与自由可以战胜一切，不是让别人去滥情，只想说，帮帮我们身边的人，每个人，哪怕一个微笑，这也是脆弱的哈罗德坚持走到终点的原因之一）

”婚姻“

  莫琳，哈的爱人，总爱重复哈的话，要不就是”我不这么认为“，两人因为儿子的悲剧分道扬镳，只是名义上的夫妻，在哈走后，莫琳经历了一系列的情绪波动，先是惊讶，抱怨，而后焦虑不安，后是平静的回忆，直到对哈的日夜思念，莫琳因为哈罗德对儿子的不作为，而抱怨，恨着哈罗德，二十年之久，莫琳本身是一个普通的女性，无论作为母亲，妻子，都算是合格的，那什么让两人冷漠二十年，让婚姻只剩下房子一个躯壳，是哈罗德的性格缺陷？两人沟通不够？是残酷的现实？…………，

  哈的徒步之旅让他们重新走到了一起，值得一提的是，两人对于初见时的回忆时如此的不同。（男人女人是两个物种）

  莫琳的回忆："他微弯下腰，嘴唇贴近她的耳朵，伸手拨开她的一绺头发，才开口说话。这大胆的举动让她感到一股强烈的电流顺着脖子传上来，甚至今日想起，肌肤下仍能感受到那一份悸动。他说了什么？无论说了什么，都肯定是极其有趣的内容，因为两人都笑得歇斯底里，还尴尬地打起嗝来。她想起他转身走向酒吧取水时衣角扬起的样子，想起自己乖乖地站在原地等他。那时好像只有当哈罗德在附近，世界才有光。那两个跳得、笑得如此畅快的年轻人如今去了哪里？"

  哈罗德的回忆：“哈罗德在跳舞，突然发现隔着一整个舞池的莫琳在看着他。他还记得那一刻疯狂地挥舞四肢的感觉，仿佛要在这个美丽女孩的见证下甩掉过去的一切。他鼓起勇气，越跳越起劲，双腿踢向空中，双手像滑溜溜的海鳗扭动。他停下来仔细观察，她还在看着他，这次她碰到他的目光，忽然笑了。她笑得那样乐不可支，抖着肩膀，秀发拂过脸庞。他生平第一次不由自主地穿过舞池，去触碰一个完全的陌生人。天鹅绒一样的秀发下，是苍白而柔软的肌肤。她没有回避。“

  维系婚姻的到底是什么？A爱情，B浪漫的回忆，C未来的期盼，D，子女 E，两个人的时候感觉孤独，一个人时更孤独（莫琳回忆道）F，安于现状G，人丑又穷离不起（老婆太厉害，不敢提）

……敲黑板！！！这道题超纲，考试不考……

信仰与理智

  读完之后，我问过自己，哈罗德为什么要徒步去远在千里的贝里克？支撑他的是什么？

  他在经历一路的跋涉到底吃了多少苦？值不值？关键是他是个沉闷、死气沉沉没有活力的哈罗德。做出这个选择不可思议，作者提到将这归为“期待一种比不言自明的现实更大，更疯狂也更美好的可能”。在我看来，哈罗德身上有很多缺陷，他自己给自己贴了太多标签，沉默逆来顺受，软弱，羞涩……，但人不是一个个标签构成的，通过一个个的标签并不能完全解释一个人的行为，事实上，作者没有解释也不用解释，哈为什么做了这个决定，因为包括这件事在内的很多事都是有一种奇思妙想甚至吓到自己，自己也不知从哪冒出来的想法开始，首先，在那一时一刻，理想梦想狂想疯想轮奸了理智，从此孕育了伟大，自己被惊讶、震撼、感动，从而迈出了一步，两步，就像疑问自行车就两个轮子为什么可以冲的那么快，疑问它为什么不倒一样，没有人告诉你为什么？而你同样可以骑上去，跑的比风还快，还自由。你做到了，哈罗德的决定也做的那么简单与自然。

  做决定容易，简单的决定，简单的计划不一定成功，仅仅一双帆布鞋（属于海洋，却行走于陆地），一路上，哈曾羞于解释自己的计划，但一路的陌生人，即使有再多的不理解，不可思议，也都给予了支持，或物质上，或精神上，他们都是哈罗德走下去的动力，哈罗德感谢他们，正是这些动力让他尝试去冲破囚禁它一生的牢笼，束缚，释放了年轻时候，转瞬即逝的野性，冒险与激情，但是哈罗德毕竟只是哈罗德，标签解释不了全部，却注定哈罗德在那么一个阶段，否定自我，否定这次徒步的意义。

  人生就像一个缓冲区，就像数据库buffer，操作系统buffer，各种buffer一样，缓冲区存在的意义，在于解决通信双方处理信息的速度不同的问题，人生的buffer，怎么讲？得与失，的是写入buffer，失  是移除buffer。

  朋友有失有得，太多照顾不过来，就要失去热度低得，太少，你会感到孤独，又会去交新朋友，

从人生来讲，不只是朋友，童年，青年，中年，老年，童年的我们是空的buffer，接受各种各样的信息，我们每天都在快速的成长，不曾感到失去，直到青年，我们开始困惑，感伤，为了长大，活下去，为了责任，不得不得到很多不想得到的，失去很多宝贵的，（大话西游的主题，成长，得与失）。到了中年，可能渐渐的习惯了得失，不再多愁善感，这是我们可能是很多人心中的英雄和榜样，只有我们自己知道，我是个什么样的混蛋，到了老年，得到的可能仅仅是白发，失去的与日俱增，缓冲区越来越小，我们没有了憧憬，只剩下回忆，我们已经不是年轻的感伤，更多是一种超然的释怀。因为除了生命，任何都不属于我。

哈罗德在救赎曾经的哈罗德

  哈罗德呢？他老了，他在徒步，他在救赎自己，他在朝圣，但他并不是英雄，他正在失去很多，跟普通人不同的是，他早就失去了很多，甚至很多不曾得到，父爱，母爱，朋友，儿子，爱人，这些失去放在有这么一个性格缺陷的老头身上，有点残忍，但上帝在决定你命运的时候，才不会管你是不是很可怜了，更不会征询你的意见，就这样 ，哈罗德在失去唯一的陪伴——小狗后（一条小狗，它的名字就叫“小狗”，哈罗德就这么叫），崩溃了，没有了时间概念，没有了距离，以前用英里丈量到终点的距离，现在用回忆，在一幅幅回忆前 ，哈罗德真的要放弃了，莫琳在哈走的日子里也在回忆，回忆年轻，回忆自己对哈罗德过分要求，与缺失的理解，在哈崩溃时，莫琳恢复了以前的温情与鼓励，哈罗德蹒跚的走到了终点，老朋友，结束了，但她们的婚姻好像重新开始。

后记：

在我观察，这本小说，有爱需要表达，婚姻，信仰，三个主题，这是一本鸡汤小说，出自英国作家蕾秋乔伊斯，这是第二本我非常喜欢的女作家写的小说，以前以为女作家只会写给女孩的鸡崽文学，什么女孩你必须优秀…………，XXX，或者儿女情长，纯粹YY的爱情小说，现在证明，我错了，女作家也可以写出能体现对社会对历史对人性的深刻理解的作品（《穆斯林的葬礼》），他们对人心理的细腻把握，同样让人感到有趣，这本小说里，我并没有对哈罗德，旅途的见闻，中间媒体炒作，投机分子借机包装，哈罗德与荃妮的友谊做过多感想，因为我觉得这只是路上的故事，大树的枝叶，任何一部小说都要有插曲丰满主人公的形象，但主题从头贯穿到结尾，其中婚姻的主题很明显，但是我经历有限，不能提出特别的见解，望请见谅。

🔊整理了七八年的笔记(包括收藏别人的)，感觉很累，回顾后好像并不值得那么做，于是对收藏文章，做笔记，学知识有了一些不一样的感悟，于是写下此文，警示自己。

📚一、收藏怪

1. 
   

   收藏不等于吸收，收藏的文章不消化，还是别人的，收藏不等于学会了知识点,警惕陷阱。

   
   


2. 
   

   重复的事情不要做第二遍，当初偷懒没理解收藏的文章，到头来还得从头开始理解；但却做了一些重复的事情。生命其实很宝贵。

   
   


3. 
   

   收藏文章要精选，收藏的文章过多会增加未来的负担； 再看是消耗未来的时间，未来的时间一定比现在的时间更加宝贵，请慎重地做文章收藏。好的文章点个赞，不想错过知识就及时总结消化。

   
   

去阅读了那些以前收藏的文章，当初没有懂的，现在也可能没有懂；现在懂的也并不是因为收藏了才懂的。

📒二、断舍离

那些似懂非懂的知识，要学会断舍离。收藏的文章，记录的笔记；并不是越多越好，数量可能带来质量的下降，可能充斥重复，甚至废话。

1. 做减法，该丢掉就丢掉。 这是生活经验；也是哲学道理。


2. 似懂非懂的知识，多了只会让自己难受。通透才能轻松。什么都想要，什么也达不到最好，反而容易让自己撑着。


3. 少即是多，抓重点。什么都想学，什么也学不好。知识也是有二八定律的。


4. 不要废话，保持简单，一句话能说清楚的事情，就不要两句话。


5. 知识是会给增加烦恼、负担的。别让知识给自己制造无形的麻烦、也不给自己未来添堵。


6. 允许自己有知识不会，也别想着什么都会；更别想着什么都学。

📑三、兴趣

1. 不喜欢就不要学，讨厌的知识容易遗忘。学习知识也要取悦自己。


2. 学习自己感兴趣的，这样才能深耕，深耕那些不喜欢的知识，会让自己痛苦。


3. 学习是需要时间成本的，而且很大，对自己也要投其所好。

📜四、偷懒

1. 记录再多不理解的笔记、知识，不及时消化，还是不会理解的，有用吗？这样建议别做。


2. 摒弃那种笔记做越多越充实的自我欺骗行为。要做一个偷懒的人。

✒️五、总结

最近整理大量以前的学习笔记，以及各种技术收藏文档；发现了很多无用的，累赘的；不懂的还是不懂；似懂非懂的还是似懂非懂。而做笔记的过程却花费了太多时间。 把事情寄托于未来，成本更高。思维上要学会偷懒。别用笔记上的勤奋来掩饰思维上的懒惰。

🔊注：有一些偏激的观点，但本文仅代表当下自己的想法。

双十一的烟味还没散，昨天下午至晚间（11月12日），阿里云又崩了，而且语雀又没逃过去，从出现故障到完全恢复长达3个半小时，这次又是怎么回事呢？

这次受影响最大的是OSS服务，也就是阿里云的对象存储服务，对外提供的是图片、视频，以及各种文件的读写服务，可千万别小看这个服务，我们平常聊天发图片、发文件，网站上展示的图片、视频，以及各种js、css、字体等文件可能都是放在OSS服务中的。

从网友的反馈来看，仅阿里系受影响的产品就包括：阿里云OSS、语雀、钉钉、阿里云盘、淘宝、闲鱼等，应该还有些用户相对少的服务没有爆出来，毕竟阿里系产品众多，对象存储在每个产品中都是不可或缺的。

使用阿里云OSS服务的外部公司产品估计就更多了，只是大家量小体微，没有掀起什么狂风巨浪，我这里也多多少少受了一点影响，上传文件出错。

对于这次故障阿里云发了一个公告，文字不少，大家看看是否清楚明白。

根源是某个底层管控服务组件出现了问题，不过没说这个组件是干什么的，起到什么作用。再看受影响的产品还是挺多的，队列消息服务都被波及了。我猜测可能是底层存储的某个控制程序又出问题了，而且是个广泛部署的服务，可能是鉴权，否则不会影响这么广泛，恢复这么缓慢。

话说同样是阿里系的语雀前段时间刚崩了七个多小时，这么快阿里云又崩了，还恰逢双十一，再往前翻，去年阿里云香港机房还挂了两天，这不免让人对阿里的技术心生疑虑，加之社会对阿里的管理文化颇多吐槽，如此下去，阿里在人们的心中可能就要堕落下去了，可以说有向悬崖边滑落的风险。

频繁的出现问题，可能不仅仅是技术上的问题了，管理制度上可能也存在一些风险，相信阿里的王博士和周大佬也想得到，这里就不瞎指挥了。

不知道阿里云这次怎么给大家交代，看看网友们的期待吧。

不过我们使用阿里云的产品，以前多多少少都出现过一些问题，前几年产品经理会主动给些补偿，不过最近几年，影响不大的话，用户不要求，也少见阿里云主动补偿。对于此事，后续我会继续关注。

书中内容涉及哪些方面？

新人如何学习编程，如何进入这一行，对职业人的建议



进来以后职场中的一些经验，这一职业经常面临的问题



全栈工程师的相关问题，面试招人环节



除了技术你应该怎样提升自己，如何建立自己的品牌



如何教育自己的孩子编程，作者的自学设计经验分享



程序员的未来和作者的美好希冀......

可以看出来作者写了很多，对程序员各个阶段都有思考和分享。看起来都是些老生常谈的建议，也有些都是职场的潜规则。但是还是得说出来，摆到明面上，这样大家才能学习、思考、践行。这也是这本书的意义所在。

我也说说自己的一点想法，一方面是对书的内容的消化吸收、一方面也是有自己的感悟，及时记录下来。

1. 保证健康的体魄

身体是革命的本钱，最近看《去有风的地方》，主角的闺蜜第一集就死了，为什么呢？没有照顾好自己的身体，胃不行，太可惜了。前些年 github 的996 项目还有越来越多的猝死现象也让大家对行业内司空见惯的加班潜规则加以抵制，都说明大家对自己的身体越来越重视了。说到底还是得（心里）坚持锻炼。

锻炼在现实中是怎么实施的呢？

很多人说，哎呀，我办了健身卡可是都没去过几次，太浪费了，就在家锻炼吧。

退而求其次，买了哑铃甚至跑步机，用上几次一直吃灰。

再或者，买了瑜伽垫，开通健身会员，跟着练上一个月，舒展筋骨，体能恢复什么的。坚持打卡，一旦哪天没打，完了，开始断断续续直至把各类健身会员订阅关掉。

说下楼跑步，冬天嫌冷夏天怕热.......

没错，这就是我，甚至遛狗都是骑着电动车让狗跑。但是，我是真的想让身体越来越好。所做的这些努力，哪怕放弃的次数再多，我也会继续下去，比起因为放弃过就不努力，我这样算不算越挫越勇呢？到现在，我已经不怕放弃了，只会遗憾没有开始。

2.读书、旅行与思考不能停

精神与身体都需要锻炼，什么软技能、代码重构、艺术审美，你不会真指望一本书能让你学会这些吧？

《自我修养》书里说的那些道理，更多的像是旅游景点的指路牌，告诉你方向，你想往哪个方向走，你就读哪方面的书充实自己，而不是把路牌拍张照站原地不动。多读书，现在这年头，你就是读狗血的网络小说，说不定哪天还能看到同名影视剧上映。

旅行嘛，去年被辞职以后我出去旅游了两周，回来身心俱疲，开始思考旅行的意义。看惯了全国统一的网红景点，我悟了。旅行也得带点脑子去，我想从这个城市看到什么？历史、不一样的人文、自然，总要有点不同吧，要是冲着网红景点的噱头去，那指定被坑。酒吧、小吃，哪个地方没有。旅行，就是要看不一样的东西。

关于思考，之前的我，对技术思考最多的时候就是在找工作的时候。那确实是每天都很充实，被面试官各种问题轰炸，工作中呢，差不多的管理系统，差不多的业务，差不多的逻辑，有复杂的也不会超过两天，超过了就把需求打回去，或者找别人一起想，最后说一声：实现不了。现在的我，几乎每天都在思考，一个是做的业务之前没做过，还有个是观念转变，面向面试上班，主动思考。

展开说说面向面试上班，既然面试问的最多也难回答的是：你遇到的问题有哪些，怎么处理的。那我上班就开始整理问题，碰到难题就思考，解决了就复盘。没问题我想问题，（1）想之前工作的几家后台系统的难题是什么，没有？那你搞的不是核心，难题都让别人解决了或者引入一个包搞定了。你要说实在没有，这个系统就我一个人写的，那可以想下通常这种系统比较难实现的是哪部分业务，比如权限、审核、排班等等，然后记录下解决方案（2）由点及面，css遇到了一个问题，比如移动端适配问题，单位是用vw呢还是rem呢，布局是flex还是百分比呢，搜结果的过程中顺便可以看看解决方案都有哪些，对照下优缺点和适用场景，最终选择最佳方案。

3. 认真工作、诚信做人

书里有这样一段话：

那些优秀的程序员有时看上去很懒，他们会在上班时间做那些与工作毫无关系的事情，比如，在纸上随意地乱涂乱画，长时间坐在那里发呆，甚至玩手机。但一旦他们进入编程状态，你又会发现他们变得像打字员般，指尖飞舞，瞬间完成他们的工作。 —第三章第一节第5小节 很懒却又很高效

这就是我们现在说的“摸鱼”，我之前一直觉得摸鱼的时候有种羞愧感，同事路过我会马上放下手机，假装在敲代码。真正意识到这是一个正常的行为，我也就心态上轻松了。除了无所事事的时候，有一堆工作还摸鱼的情况，我内心是这样的：**，太难了，等会再看吧，然后拿起手机。刷了一会，想到活还没干完，果断放下手机，开始敲代码或者接着想。越是在忙的时候，这样的情形重复次数越多。很显然，这是给大脑休息的机会，摸鱼基本上不用动脑子，只需要眼睛浏览，因为有这样的机会，接下来才能更高效的完成任务。

特别忙的时候，手机拿起放下的速度也越来越快，这个时候会比较着急，想上厕所也憋着，憋不住了上厕所一路上也在想逻辑，从第三视角去审视自己这个行为又觉得很有意思，不知道在心理学上是怎么解释的。说这一点，不是为了摆烂，而是认真的工作，这样无愧于内心，也肯定是有产出的。在读《人人都是产品经理》的时候，也有一段话很应景：

任何情况下 我们都要做好手头的事情。 确保就算这事儿对公司来说又黄了，我也要通过做事有所收获。

那面试你拿的出手的自然也就是这些收获。

诚信做人，这一点毋庸置疑，书中说的职场经验、软技能、建立自己的品牌啦，这些都能和认真工作、诚信做人挂的上钩。工作认真完成了，你的个人品牌效应自然能提升，职场中大家对你也会尊重。打个比方，初入公司，你活干不下来，是个人都想骂你两句。

差不多了，就写这么多感想吧。

概要

  今天通过一个项目问题解决过程来分享，两种不同的思维方式在解决项目问题时的碰撞,中间引起的带入问题,请忽略不计。

背景

  先说说前提,本身的技术路子比较野,啥东西都能摸两把,基本的思路和习惯都是以结果优先,技术作为手段,但这并不代表我没有标准化的基准和要求,只不过这个次序和容忍度有不同的理解、而我作为程序猿中的代码收容所,杂货收割机,可能是绝大部分标榜 “技术控、理论控、优雅控” 最不屑的。

  文档、PPT、事务性、管理性、运维、交付、架构、甚至是商务、咨询、售前支撑都有涉及,这两年又对工控、数采非标互联网进一步在学习,说这些不是为了标榜啥，只是想说明我对技术的态度，是只要感觉缺的就会去补充学,早先,从一直排斥文档，认为这项工作是 “不务正业”,到后来慢慢发现实际是有点儿恐惧写文档,天天被批判，再到后来反感的PPT和"跟傻子讲技术",心态上变化，看到差距，尊重别人的成就,就会自然而然的追赶,直到无所畏惧。

前因

  Java属于可能我最先了解和尝试的编程语言,但怎么说呢,在当时的环境里面,C++、C# 是我选择的结果，期间也涉及了其他乱七八糟的语言,也都是副业需要，涉及到就捡起来用,可能内心觉得Java比较 “简单”,直到工作里面不得不顶着运维和维护，说实话，没啥太大障碍，真正接受生态,也就近两年,心态的变化，感觉看到了不一样的新大陆,当然主要是各位开拓者的不断努力,不断的思维碰撞和实践努力,而我本身也不能说是专职做这块,只是有些块别人解决有问题，思维碰撞一下,以下就说说关于问题解决的剖析。

过程

   同事A属于入行就做Java，也有个8年多工作经验,技术能力，执行力都不错，就是这个行业通病,沟通有所欠缺,这个只是一个点的分享，只是从思维上去谈问题，（我本身是个大白菜）,还是规则引擎的点,之前有过分享，整体是由我设计的方案，之前有分享,聊聊规则引擎的调研及实现全过程，因工期等其他影响，我把人员能力问题也考虑在内,在正式应用交互过程中,关于Mqtt处理相应速度问题和数据重复入库的问题得以复现，同事A有不少的参与度，因为某些原因（我不得不负起主责,前后端整体调整）,这是问题的大背景

复现排查

• 尝试1：这个问题同事A经过问题复现,初步确认是多线程循环引起的问题,解决的办法很粗暴，判断如果循环超过1000次就终止线程,导致的结果就是性能损耗和任务丢失,(这种情况在采集上是可以容忍的,数据是不间断的),就此就准备收手。我认为这个种解决办法是最终没办法下的妥协处置，而且问题也没分析定位清楚,做进一步尝试,此处是应该要执着的地方,


• 尝试2：于是A经过一顿跟踪，用了各种线程跟测工具和理论检索,通过方法锁尝试去解决该问题,造成的第二种后果是结果正确了,但及时性达不到，根本发挥不了性能。进一步也发现了消息密集的情况下会产生问题,中间也进行过任务队列的分组处置，（此项尝试基本属于A的各种线程理论一顿分析，进行尝试，得不出来啥有效结果，各种理论分析）


• 尝试3： 我经过不停得添加代码,定位异常，定位到了异常代码块，属于递归循环调用侧发生得异常,之前线程循环调用得问题也基本定位到,是因为父子线程得优先级，加上规则本身深度遍历及结果等待造成得问题，也就是Future得get等待引发得,此时,要验证该问题，把规则内部得递归任务添加调整为同步,（只涉及到一句代码）,循环得问题得以解决，处理速度也跟得上,（线程放置到了外侧处理消息（消息接收本身也是多线程）），但又引起了新得问题，入库得数据发生重复和不正常了（如果问题回溯，其实很快能发现，当然有点儿马后炮了）


• 尝试4：此时，同事A又尝试想放弃，认为在入库侧判断是否重复插入即可,并把别人得关于多线程入库重复得解决常规办法得内容做了共享,我给得理由是：“再往前尝试以下，感觉马上就能找到真相，正是学技术得好时候，不要此时妥协”，很显示A在口头上答应，行动上已经放弃了,我就消息重复产生得地方又进行了各种锁尝试,也基本定位到了产生消息重复的地方，加上方法锁，结果和执行均验证没啥问题。


• 补上最后一药： 最后的相同broker相同主题下多个规则执行问题，其实不是啥大问题，很容易就解决了，两种方案，但实在是实践浪费的太久，我尝试了复杂的理想办法，交付中的问题都得以解决。

回溯

   其实这个问题在回溯过程来看，在尝试4的时候，应该马上就能反应过来去解决的，但实际可能是周期和脑子都有点儿混乱，还是分析了执行结果和操作才做了验证，实在是我已经不敢太过相信线程理论，还是实践出真知,所以，这个过程中，我对Java的语法半吊子，但并不妨碍我去参与分析解决问题，而同事A，虽然知道线程的理论和各种语法，各个线程分析结果,但依然妨碍了他去解决此项问题，之前有听过软件的思维最重要，经验有时候会成为负担，可能在你们看来，这个问题其实有充足的理论基础，一定很容易解决定位这个问题，但怎么说呢，记得上计算机理论的时候，老师说过一句，编程就是抽象化具体事务到编程语言的过程、

  在其后的过程中，好像绝大多数都是把问题分解成实现，排查分析问题的过程，我理解就是把具体的事务反推到程序上，很可惜这个过程，被归集到个人的能力或者习惯上,毕竟，对过程负责，是常态，项目的面试过程也就是说清过程，至于是谁解决的问题，并没有那么重要，这造成了两种分化，掌握全貌的失去了动手能力，对结果负责，不对过程负责，掌握单一的，失去了对结果负责的能力，掌握着对过程负责，新的纷争和各种千奇百怪的妥协结果也就是值得接受的。

分析

   当你在执着各种编码规范，各种优雅简洁之道的同时,是否也能思考一下，我们所专注的语法，面试理论，就具体问题而言，真就是理论精通了之后，不会成为 “赵括”,指点江山，飞扬文字。

  而这种分化性，我已遇到了不下3种典型，要不点了吹牛逼的和撕逼的技能点、要不就点了技术理论的技能点，要不就去点了文档管理技能点,当然，只是个现象，躺平是常态，没啥压力和责任，谁愿意变成受虐狂，但有没有可能，也有那么一丝，对这个职业和技术的热爱? 可能又会变成鸡汤和躺着说话不腰疼，至于外在因素、想法和处境的不同,咱姑且就图一乐，从容面对吧、总之是,事不临身，我不愁，事临身，愁也没用，那能不能，稍微有一些，哪怕只有一丝希望的掌控呢，要说起怨怼，我有一肚子，但总不可能变成情绪发泄机吧，对结果有预期，但不放弃努力的过程，也许这是我此刻能够坚持做的。

PS

  在这里申明一下，同事A的各方面能力我很认可，此处也只是精力有限下的小分享（有个小背景是，我们基本上背着2.5个以上的事在解决此项问题）、所以请各位不要基于我个人的认知有指摘。

关键词：代码、编程、业务、技术、数据、面试、成长、开发、逻辑、能力

一、心得

1. 
   

   说说我自己理解的编程：编程就是要教会只会0和1的电脑去解决现实生活中各种复杂的问题，电脑只有与或非三种逻辑，只有顺序循环分支三种控制结构。我一直觉得编程某种意义上是一门“手艺”，因为优雅而高效的代码，就如同完美的工艺品一样让人赏心悦目，最主要、最容易被我们直观感受到的问题就是：烂代码实在是太多了。后来，在亲历了许多个令人不悦的项目之后，我才慢慢看清楚：即便两个人实现同一个功能，最终效果看上去也一模一样，但代码质量却可能有着云泥之别，好代码就像好文章，语言精练、层次分明，让人读了还想读；烂代码则像糊成一团的意大利面条，处处充斥着相似的逻辑，模块间的关系错综复杂，多看一眼都令人觉得眼睛会受伤

   
   


2. 
   

   越简洁的代码，越清晰的逻辑，就越不容易出错。而且在实际工作中不是用代码量来评价一个程序员的工作强度和等级，高端的同学总是用最简短精妙的代码来解决问题。代码变得越来越简洁，代码看起来更加结构化和规范化、扁平结构比嵌套结构更好

   
   


3. 
   

   在团队合作中，你的代码不只有你在维护，降低别人的阅读/理解代码逻辑的成本是一种良好的品德

   
   


4. 
   

   简单的代码，只会用到最基本的语法糖，复杂的高级特性，会有更多的依赖（如语言的版本）

   
   


5. 
   

   一个公司如果数据库从来不出问题，那一定是因为没有业务量或者流量

   
   


6. 
   

   所有技术的选型和设计，都有它的应用场景，除去那些让人开心的案例，剩下的毫无疑问就是坑；如何尽可能地避开这些坑，如何在出现问题的时候可以用最快的速度去修复，这些都是至关重要的因素

   
   


7. 
   

   任何项目在早期，整个数据基本处于裸奔状态，没有做任何的权限校验与审计，用户可以对数据为所欲为，这个阶段主要考虑效率优先，随着业务的发展，数据安全的重要性愈发突显，大数据权限系统则会应运而生

   
   


8. 
   

   现实中大部分程序员都属于是斐波那契程序员

   
   


9. 
   

   关于代码意见：我的看法是，一个处理代码行数超过四五十行，就可以考虑缩减抽离了，为什么要这么做，其实很简单：出于可维护性，一个业务再复杂，离不开一个主干逻辑（也可能是多个）和 N 个子逻辑，你不能把臃肿的子逻辑代码放在同一个处理代码内部，这样太影响可读性，影响可读性的后果就是提高了维护成本
   

   
   


10. 
    

    首先从成长的角度来看，追求代码质量是一个优秀程序员对自己的要求，我想任何一门工艺、手艺，从业者想要把他做的更好，这是一个非常自然的目标，我们既然靠写代码谋生，就应该对代码有追求，对代码有自己的审美和判断，代码质量真的只是一个底线，在这条底线之上，才有可能谈稳定，谈伸缩，谈性能，谈架构，优雅与否则是区分顶级程序员与一般程序员的终极指标所在，能用不是代码的标准，能被维护才是代码的标准

    
    


11. 
    

    程序员大厂面试三板斧：八股文、算法、项目经验

    
    


12. 
    

    切记切记：不要用战术上的勤奋来掩盖战略上的懒惰

    
    


13. 
    

    写代码是要有感觉的：感觉到了思如泉涌、键盘啪啪作响，一个需求很快就做完了，搬砖速度飞起

    
    


14. 
    

    我们是一群与画家有着极大的相似性的猿/媛，是在创造，而不是完成某个任务，会在求解问题过程中产生精神愉悦或享受，我们崇尚分享、开放、民主、计算机的自由使用和进步

    
    


15. 
    

    真正工作中都是写写业务代码，哪有那么多深度的技术问题；其实我觉得写代码最重要是逻辑思维够强，代码的规范工整，思路清晰，化繁为简，否则你说你写了多复杂的海量并发处理，多有深度，但是代码乱得一团糟，别人没法维护，再牛逼有何用

    
    


16. 
    

    软件开发的任务应该是思考，思考手头的问题，设计出一个完美的解决方案，然后再把这个方案转变成可供用户使用的软件

    
    


17. 
    

    阅读他人的代码是一种很棒的学习方式。正如一位作家所说，“阅读其他人的作品是让你成为一个更好的作家的最好方式”，这同样适用于代码

    
    


18. 
    

    优秀程序员绝不只有技术：

    
    

    (1)问题解决能力

    
    

    (2)业务理解能力

    
    

    (3)沟通能力

    
    

    (4)产品思维

    
    

    (5)管理能力

    
    

    (6)分享表达能力

    
    

    ...

    
    

二、总结

最后再开个玩笑哈哈：所以在感慨，在这个行业可能确实需要像前任这样的码农，挖坑，填坑，坑更多了，再填......生生不息，这样行业才能长久生存，没有 bug 可以修复，没有屎山可以铲，我们真的就失业了，如果每个程序员写的文档详细，逻辑清晰，注释清楚，拿什么让老板离不开你，靠什么威胁老板给你高工资，所以我现在的处境用一句话形容：全凭同行衬托

入职一周年啦！对过去这一年的工作和生活都做个总结吧，经历的时候总觉得前方迷雾重重，回首看去每个脚印都清清楚楚。

工作

我还记得入职第一周的时候，交给我的第一个任务是修改几个页面的文案。工作确实不难，只是项目比较老了，整体结构比较复杂。开始的一些任务都是修修补补，只要找对了地方，写个几行代码就可以了。

后面我也慢慢独立做一些新功能了。当亲朋好友问起我的工作时，我还能说出来我做了xxx。整体来说，我的工作都不算难，有些也只是比较麻烦复杂。现在的我就是个搬砖小工，告诉我需要做什么，然后我把它做完。

接下来我比较感兴趣的一个方向是提升开发效率。梳理日常的工作流程，通过一些工具或工程化的手段，来提供更好的开发体验。

学习

专业知识的学习上，感觉没有学习很多。平时的工作内容都不算太专业，也就是个基础的开发。虽然写的代码不少了，但也基本上就是使用一些语法和组件，不涉及太多原理上的东西。

前半年基本上都是学了一些跟开发密切相关的基础知识，后半年开始进行体系化的学习，每天早上到公司后学一会。在极客上学了一些课程，目前在看《vue.js的设计与实现》，一边看一边敲代码，快看完了，对于vue的原理确实更清楚了，平时写代码也更清晰了。

只是要具体说说学了点什么的话，又啥也想不起来了。还是要多写学习总结啊，写了会对所学的东西有个更深刻的理解。定个目标好了，以后一周写一篇学习总结。

生活

生活还是过得比较满意的。一开始找房就比较顺利，住了一年了，除了疫情期间邻居装修，整体还是比较满意的。

这一年也基本坚持下来了跑步的习惯，虽然也就养生跑了。除了疫情期间，每周会去跑个步。身体状态也都还不错。

今年对做甜点非常感兴趣。做了各种奶油蛋糕和慕斯蛋糕。天气热了之后，开始做糖水，杨枝甘露、各种水果奶昔还有烧仙草等等，还做了我非常喜欢的香草冰淇淋。

读书

读书想单独列出来，感觉能反映一个时期的思想状态。入职前半年看书时长40个小时，算是看书比较少的时段了。入职一个月后，我就开始看《工作的意义》和《生命的意义》了，还看了一些重生小说，半本《原则：应对变化中的世界秩序》，看完了《群体的疯狂》、《置身事内》和《梁永安：阅读、游历和爱情》。

上半年看的书比较杂乱，整个人也是迷茫和焦虑，看的基本都是一些热门书。

入职下半年就感觉好多了，看书74个小时。看完了《论生命之短暂》、《撒哈拉的故事》、《结构性改革》、《始于极限》、《庄子》、《道德经》、《孟子》、《传习录》等。看的都是一些我感兴趣的书，偏哲学的书。

下半年整个人也不那么焦虑了，虽然裁员的消息还是满天飞，但我也不担心了。看前方还是迷雾重重，只是我不再紧盯着前方，我看着脚下每一步。

总结

工作上算是中规中矩。生活上是丰富多彩，体验了许多之前没玩过、没做过的，但是我最爱的依然是跑步。最满意的是心态上的变化，从初入职场的迷茫焦虑，到逐渐平淡释然。只是一直困惑我的问题是方向，我始终没有找到人生的方向，一直以来也没有什么追求。不过也慢慢释然了，好像也没必要非要有目标。但行好事，莫问前程。

回头望一望过往，从13年毕业至今，用手指数一数刚好能数过来，创过业，上过班，也搞过个人项目。

能力栈也从java、php、前端、产品经理、UI和平面设计之间反复横跳，反复折腾，🤣创过业的苦逼人应该都懂，后来主攻了前端，已经做了5年高级前端了。

最近自己行色匆匆地整理了一些编程方面的思考，聊聊自己对高级程序员的想法，当作是给自己这些年的一些总结吧。通过6个方面聊聊除了技术水平外，高级程序员应该具备什么样的职业能力。

一、代码风格很大程度决定了你的态度

代码需要有自己一贯的风格，包括命名约定、逻辑代码习惯、不写无用坏代码、语句块风格（如lambda表达式中只有一句话时省略return）、模块或函数注释、逻辑复杂部分注释，且注释需包含联系方式和时间，这样可以让后来者在需要求助的时候找到当事人，这也是对事负责的态度。

同时编码风格的追求体现了一种编码的热爱、一种不随意妥协的态度，当然也有可能是强迫症或洁癖发作，看不得不美观的东西。

二、人人都应具备解决问题的能力

通过百度、google、或者寻求同事帮助等方式解决编码中遇到的问题也是一个程序员的基础能力，而更高阶自独立思考能力在这边可以为你带来很好的提升效果。这边的问题可能会分很多类：

1、功能性问题，如上传文件时怎么才能成功、如何生成一张图片并返回图片流等等，这类问题通常是查资料、问同事朋友解决；

2、技术性问题，如怎样通过一个字符串生成二维码图片（当然你也可以直接用别人的库，省的自己造轮子），这可能也是钻研精神的一种体现，毕竟会造手机的人比会用手机的人厉害得多的多。这样一直钻研的人，久而久之就可以解决各种各样的问题，了解各种底层原理，离大牛之路原来越近了，但此时的你，可能头发也就少了好几根；

3、结构性问题，以下三个问题是更高阶人员才会遇到的问题，如我应该如何组织代码结构，模块与模块之间又是怎样的一种关系，当然你也可以完全不考虑这个问题，然后随便找个地方保存你的代码，或者干脆就写到一个函数里就好了，对功能和性能完全没有影响，但这样做你的心真的不慌吗？没有人给你code review出来吗？

4、协作性问题，一个项目大部分时候毕竟是很多人一起开发维护的，如何能保持大家的共同认知很重要，谁都不希望在同一个项目里重复造轮子，谁也不希望看到有人把代码搞乱，或把自己的代码搞乱。这时你应该需要用各种协作规则、编码规范，并用文档的形式记录下来，简单举几个例子，第一个编码规范让团队内的编码风格保持一致，这个最好理解却也最容易被忽视的东西。第二分工明确职责明确，编码前做好充分沟通进行分工且明确结构方案和技术方案，执行时不要干涉他人写的代码，而通过提交问题的形式让当事人处理迭代，同时将沟通时分配给自己写的公共模块记录到准备好的模块文档中并通知其他成员，做到信息一致。执行起来光有这些自然不够，还需要不断地code review来调整未按规定执行的代码。

5、项目性问题，正常是项目经理或产品经理需要考虑的事，项目迭代如何按时交付，这就要求项目内需要建立一个可行的开发计划，很多人可能会觉得制定开发计划就是一个坑，每天把自己坑到晚上10点才下班，久而久之就成了公司压榨员工的现象了。做计划是一件很难的事，我认为要解决这个问题，特别需要注意以下三点，第一个需避免计划谬误，每个人都会把计划美化，觉得可以做很多事，但做起来确是另一幅景象，遭受了挫败感，所以具体的事情要减少到原计划的50％到70％，让自己切实可完成，让计划为你带来成就感，第二个是预留30％左右缓冲时间让计划避免突发事情的破坏，第三个是保证执100％完成，这是达成任务获得成就感，从而增强信心的环境，如果任务制定太高了，就每天再往下降一点，知道可以确保100％按时完成。

其他问题也就不再举例列出了。

最后总结一点就是，问题解决固然重要，但不要为了解决问题而解决问题，知其然不知其所以然，又或者干脆网上搜索到的代码复制粘贴过来试，能跑通就不管了，全然不知问题的根本原因所在。

更好的做法是要去理解问题本身，找到原因并在自身内化。

三、模块抽象能力很大程度区分了程序员的层次

这个也可以理解为我们常说的封装，但又不仅仅是抽出代码封装，而包含了更多的设计思维在里面。

我认为这是区分中高级程序员很重要的一点，模块抽象能力代表了代码的组织性、灵活性、可理解度以及可维护性。

每一种流行框架或库的出现都代表了作者在模块抽象部分的新思维，ViewModel、Promise、Spring的ioc、aop这些，都代表了作者在抽象上的理解，才孕育出我们现在的各种技术、社区等。那我们在实际项目中的模块抽象，同样可以让代码结构拥有上面所说的四个特征，让项目更加美观。

模块抽象能力可以在项目设计阶段，以及下面说到的微重构阶段进行，让代码始终可以保持高维护性的状态。

四、用写开源库的心态设计你的每个模块

可能我是个开源爱好者的缘故吧，虽然我也没上传几个代码库，也没什么时间来维护。

但是在设计项目模块的时候都会不自觉地想象如果我要把它开源出去，它应该会有什么功能，哪些功能是我们现在会用到的，在编写前就把它设计得更加灵活，这样设计的目的是为了让模块或组件更能够减少日后项目变化带来的重构成本，也许有些功能在后面使用时已经就具备了，再到后面愈加成熟后再开源出来，供大家使用也是一个快乐的分享，而这些东西也就成了你的门面，当然前提是有足够的时间来维护，而不能让那些使用的人困惑于bug和未满足的需求。

五、微重构能力可让你的项目持续保持高可维护性状态

好的产品经理对产品会有更好的把控力，会制定出稳定可行的路线图，这对于开发来说是一件很好的事，因为这样开发人员编码时就可以根据产品路线图预留好相关功能的接口，从而让代码在日后迭代更方便。

但大部分产品可能不是这样的，产品路线图并不总是制定好的，产品经理经常需要根据市场反馈才能制定出近期策略，或者上面所说的路线图突然改变了，这时候预留的代码可能也要作废了，久而久之项目在这样的环境下改来改去，坏代码越来越多，可维护性越来越差，统一重构成本又太大，到后面谁都不愿意接这块烫手山芋了。

谁都没有对一个项目从开始就完美设计以后不再修改的能力，微重构就要求你在平时迭代时对之前因为需求限制，或没有考虑到的散装代码、未抽象的代码进行抽取重构，让代码一直保持在高可维护性的状态。

虽然会在迭代时额外花费一小部分时间，但这是为了在日后节约更多的时间和精力，同时也让新来者更容易接受项目维护。

一个微重构的例子：原本一个前端项目只需要和一个ip的服务器交互，此时的ajax请求可能一个简单的函数封装就可以满足需求，随着项目迭代，这个项目需要和多台服务器交互，很多人觉得函数中加个ip参数就可以了，需求实现了改动也小，心里美滋滋。但这样却违背了模块抽象的原则，灵活性也大大减小，此时根据微重构的角度则应该封装成一个ajax类，在创建对象时都有其独特的特征参数一一对应每台服务器，这便有了受欢迎的Axios。

并不是所有需要复用的代码需要微重构。

它大致可分为以下三点：

1、可复用抽取，绝大多数开发人员都知道这块内容，对原本只有一个地方使用到的散装代码在某一天给的需求中也需要这块代码，此时就是抽取这块代码的时候了，这边所说的“这块代码”不仅仅是包括一个代码块，它还包括一个更细微的字符串或数字的常量、一个配置项等；

2、相关聚合，在平时项目中，我可以很肯定你一定会把视图文件放一个文件夹，把工具文件放一个文件夹，把相关controller、service、dao放到一个文件夹，但在代码中可能又是另一幅景象，你可能会在想要的调用接口的地方直接调用接口，也可能会在A文件和B文件写满了sql语句，这些都和上面的文件分类截然相反。为了便于维护和统一管理，我们就需要将相关代码聚合在一起，如序列化和反序列化、构造和解析、接口操作、数据库操作等等，这些都可以看作是一些相关操作，可将它们挂载到一个相关类上，可单独写一个文件导出方法，也可以写成一个类。

3、模块抽象，这就和上面第三、四点所说的一样了，利用抽象能力重构原本应该抽象却没有抽象的代码。

六、让你的好习惯辐射到更多人

也许你自己也有一套行之有效的编码或项目管理心法，无论如何都请不要独享，把它传播给更多需要的人吧，因为这至少在两个方面可以让你受益：

1、与你的同事分享可以增进团队融合度，谁都希望与自己价值观相近的人共事，但要遇到这样的同事很难，这样的事大多数只存在于理想中，所以如果你的团队相处很好，请好好珍惜吧。

大部分情况是核心价值观和能力匹配度可接受，并通过不断地磨合来相互适应，提高融合度，这时团队成员的分享、辩论等都可以持续提高团队融合度，当然，从相反面也可以过滤核心价值观不够匹配的成员。

2、与朋友或陌生人等非共事关系的人分享进行价值输出，可以把这种分享看作是一种服务或一个产品，通过产品或服务对外输出价值，既让这份价值产出了更多的收货，又可以提升自身品牌信誉度。

从辐射渠道上，你可以写成文章、做成分享PPT，让它在同事之间流动，让它在BBS上传播。

如果你时间精力充沛，你也可以做成视频，然后去qq群、微信群、知乎、segmentfault、简书等等各大社交网站去传播。

前言

自从我看冯唐老师推荐的《资治通鉴》之后，对历史有那么一丢丢的兴趣，直到在短视频里面刷到《百家讲坛》里面几位老师的讲解片段，以及跟自己经历结合，瞬间满满的共鸣，是啊时代一直在变化，而里面的为人处事、社会规则凡此种种却从来没有太大变化，这就是我们需要去学习历史的原因。

所以有了以下感慨。

<<百家讲坛>> 不愧是经典，整本历史歪歪斜斜写着两字：权谋，谋事、谋人，加上不确定因素，天时地利人和，最终变成命运。
人的一生就像书中一行字轻描淡写，绘成一笔～

人需借以虚名而成事

这里解释一下，人需要倚靠外部的这些名号、头衔从而能有比较大的作为。为什么这么讲呢，听我细细道来～

人生需要四行

这是王立群老师讲的，人生要想有点成就需要四行，首先你自己行，你自身本身够硬，能够做好事，其次是有人说你行，从古代的推荐机制，比如说优秀的人推荐其他优秀的人才对不对，李白的大名远扬，唐玄宗在公主引荐之下见了皇帝，第三个说你行的人要行，推荐你的那个人本身能力要强，不然没有说服力，第四是身体行，很多机会是熬出来的，比如司马懿伺候了3位君主，兢兢业业，最终才能完成自己的大业。

何为借以虚名？

1、刘备的例子，他在比较年长的时候还无法实现自己的基业，寄人篱下，他登场的时候是怎样的呢，名号叫刘皇叔，翻开长长的祖谱，八辈子打不到杆哈哈哈，不过因为当时被曹操挟持，所以需要有汉族帮忙自己，所以顺理成章的提拔上来。

2、项羽出生在一个贵族家庭。他的父亲项梁是楚国将领，曾经在楚汉战争中和刘邦一起作战。而他的母亲也是楚国的贵族，是楚王的女儿。

相比之下，刘邦的出身则比较低微。他的祖父是一个农民，父亲是一个小县官。他自己也曾经当过一个普通的县尉，但因为功绩不够而被罢免。

尽管项羽出身高贵，但他的性格比较豁达，喜欢豪情壮志和享乐人生，行事大胆不拘小节。刘邦则更加谨慎稳重，注重政治规划和长远发展。

3、王立群老师讲述过他自身的故事，小学的时候成绩优秀得到保送，后面名额被学校给了别人，自己去了私立的学校，半工半读，到了大学还是遇到了同样的遭遇，后面就到比较好的大学教书，但是有一天校长跟他讲他的成绩还是出身问题需要去另一所低一点的学校教书，他当时就哭了，命运比较坎坷的。

4、工作中，我们常常会听到，某位领导自我介绍某某大厂经历，还有某某大学毕业，还有当你投一些大厂的核心部门的时候，都会对你学历进行考核。

所以我们从上面3个例子来看，人生确实正如王立群老师讲的，需要四行，当你自己不行的时候，即使有机会也会最终流失掉；当没有推荐你的时候，也会埋没在茫茫人海中，并不是说是金子总会发光，现实是伯乐更加重要；当说你行的人没有能力的时候也不行，名牌大学、大厂经历也是这样，通过一个有名声的物体从而表示你也可以，也很厉害哈哈；最后身体是本钱，这个就不用过多的讲解了。

读历史的目的，从前人的故事、经历中，学习到点什么，化为自身的经验、阅历。

我发现现在很多人都喜欢出去玩，说的开阔视野，扩展见识，在我看来读历史才是真正的拓宽自己的眼界，原来几百年前也有人跟我一样遇到同样的问题，也有那些胸怀大志的三国名将郁郁不得志。

历史是一本书籍，它可以很薄，几句话、几行字就概括了一个朝代，它也可以很厚，厚到整个朝代的背景，比如气候情况、经济情况、外交情况、内政情况，各个出名的人物事迹，那岂是几页纸能讲得完的，是多么的厚重。

如果人不能借以虚名怎么做事？

修炼两件事情

同样百家讲坛也给出了一个比较好的见解，一个人想要成事，需要两个明，一个是高明、一是精明。高明是你有足够的眼光去发现，发现机会也好，发现危机也好，往往人生的成就需要这种高瞻远瞩的；另一个精明，是指在做事上打磨，细心主动，王阳明讲的知行合一，里面很关键的一点就是事上练，方法论在实战中去验证总结。

心态上练

李连杰在采访中说了这么一个耐人寻味的故事，他发现不管是有钱的人还是没有钱的人都会生气，比如一些老板在为几百万损失破口大骂，也有人因为几万的丢失是否生气，也有人丢了几块钱很愤怒。他觉得人都会愤怒，只是那个导致他愤怒的级别不一样而已。

他早年给自己定目标，发现当达到目标之后，发现还是有人比自己厉害，所以即使达到目标也没有想象快乐；即使有钱人无法解决痛苦的问题，比如生老病死。

所以人生意义在哪里？

我认为如果你奔着成事的想法，多修炼上面两件事，如果没有发展机会，不如躺平，积累自己的能力，就像道德经里面的无为而为，而心态的修炼是人生终极修炼，因为生死才是人生最大的难关，人应该怎么脱离时间束缚，不受衰老影响。

恰恰历史给了我们启示，要有所作为，能够为人类历史上留下精神粮食，做出浓厚贡献，就像我们都没有见过孔子、老子吧，但是他们的精神至今都在影响着我们。

大家好，我是老三，最近沉迷于听脱口秀，并且疯狂安利同事。

脱口秀演员常常说的一句话是：“脱口秀是冒犯的艺术”。最近我发现，同事们好像有点不一样了。

阳光灿烂的早上，趿拉着我的宝马拖鞋，跨上包浆的小黄车，屁股感受着阳光积累的炙热，往公司飞驰而去。

一步跨进电梯间，我擦汗的动作凝固住了，挂上了矜持的微笑：“老板，早上好。”

老板：“早，你还在呢？又来带薪划水了？”

我：“嗨，我这再努力，最后不也就让你给我们多换几个嫂子嘛。”

老板：“没有哈哈，我开玩笑。”

我：“我也是，哈哈哈。”

今天的电梯似乎比往常慢了很多。

我：“老板最近在忙什么？”

老板：“昨天参加了一个峰会，马xx知道吧？他就坐我前边。”

我：“卧槽，真能装。没有，哈哈。”

老板：“哈哈哈”。

电梯到了，我俩都步履匆匆地进了公司。

小组内每天早上都有一个晨会，汇报工作进度和计划。

开了一会，转着椅子，划着朋友圈的我停了下来——到我了。

我：“昨天主要……今天计划……”

Leader：“你这不能说没有一点产出，也可以说一点产出都没有。其实，我对你是有一些失望的，原本今年绩效考评给你一个……”

我：“影响你合周报了是吗？不是哈哈。”

Leader、小组同事：“哈哈哈“。

Leader：“好了，我们这次顺便来对齐一下双月OKR，你们OKR都写的太保守了，一看就是能完成的，往大里吹啊。开玩笑哈哈。”。

我：”我以前就耕一亩田，现在把整个河北平原都给犁了。不是，哈哈。”

同事：“我要带公司打上月球，把你踢下来，我来当话事人。唉，哈哈”

Leader、同事、我：“哈哈哈“。

晨会开完，开始工作，产品经理拉我和和前端对需求。

产品经理：“你们程序员懂Java语言、Python语言、Go语言，就是不懂汉语言，真不想跟你们对需求。开个玩笑，哈哈。”

我：“没啥，你吹牛皮像狼，催进度像狗，做需求像羊，就这需求文档，还没擦屁股纸字多，没啥好对的。不是哈哈。”

产品经理、前端、我：“哈哈哈”。

产品经理：“那我们就对到这了，你们接着聊技术实现。”

前端：“没啥好聊的，后端大哥看着写吧，反正你们那破接口，套的比裹脚布还厚，没事还老出BUG。没有哈哈。”

我：“还不是为了兼容你们，一点动脑子的逻辑都不写，天天切图当然不出错。不是哈哈。”

前端、我：“哈哈哈”。

经过一番拉扯之后，我终于开始写代码了。

看到一段代码，我皱起了眉头，同事写的，我顺手写下了这样一段注释：

/**

* 写这段代码的人，建议在脑袋开个口，把水倒掉。不是哈哈，开个玩笑。

**/

代码写完了，准备上线，找同事给我Review，同事看了一会，给出了评论。

又在背着我们偷偷写烂代码了，建议改行。没有哈哈。

同事、我：“哈哈哈”。

终于下班了，路过门口，HR小姐姐还在加班。

我：“小姐姐怎么还没下班？别装了，老板都走了。开玩笑哈哈。”

HR小姐姐：“这不是看看怎么优化你们嘛，任务比较重。不是，哈哈。”

HR小姐姐、我：“哈哈哈”。

我感觉到一种不一样的氛围在公司慢慢弥散开来，我不知道怎么形容，但我想到了一句话——

“既分高下，也决生死”。

写这篇的时候，想到两年前，有个叫码农小说家的作者横空出世，写了一些生动活泼、灵气十足的段子，我也跟风写了两篇，这就是“荒腔走板”系列的来源。

后来，他结婚了。

看（抄）不到的我只能自己想，想破头也写不不来像样的段子，这个系列就不了了之，今天又偶尔来了灵感，写下一篇，也顺带缅怀一下光哥带来的快乐。

今天来跟大家讨论一下技术主管需要什么样段位的技术？

首先我要说明的一点，技术主管前提一定是技术出身。对于那些完全不懂技术，但是又身兼技术主管或者总监的同学，我这里就不再赘述，毕竟这个已经超出我目前理解力的范围。比如阿里云的王坚博士，基本上不懂技术细节，但是依然是阿里云的CTO，一手缔造了阿里云。

那我们这里再详细讨论一下，作为一名技术主管，到底应该有什么样的一个技术的段位？或者换句话来说，你的主管的技术水平需要到达什么样的一个水位？

先说结论，作为一名技术主管，一定是整个团队的技术架构师。像其他的一些大家所讨论的条件我觉得都是次要的，比如说写代码的多少，对于技术深度的钻研多少，带的团队人数多少等等，最核心的是技术主管一定要把控整个团队整个业务技术发展的骨架。

为什么说掌控团队技术架构是最重要的？因为对于一个团队来说无非就两点，第一点就是业务价值，第二点就是技术价值。

对于业务价值来说，有各种各样的同学都可以去负责业务上面的一些导向和推进，比如说产品经理，比如说运营同学。技术主管可以在一定程度上去帮助业务成功，甚至是助力业务成功，但是一定要明白技术同学一定要有自己的主轴，就是你对于整个技术的把握。因为业务上的决策说到底技术主管是只能去影响而非去决策，否则就是你们整体业务同学太过拉胯，无法形成战术合力的目的。

对于一线开发同学来说，你只要完成一个接一个的技术项目即可。但是对于技术主管来说，你就要把握整体的技术发展脉络。要清晰的明白什么样的技术架构是和当前的业务匹配的，同时又具备未来业务发展的可扩展性。

那为什么不能把整个技术架构的设计交给某一个核心的骨干研发同学呢？

所以这里就要明白，对于名技术主管来说，未必一定要深刻的钻研技术本身，一定要把技术在业务上的价值发挥到最大。所以在一定程度上来说，可以让适当的同学参与或者主导整个技术架构的设计，但是作为主管必须要了解到所谓的技术投入的产出比是什么。但是如果不对技术架构有一个彻底的理解，如何能决定ROI？

也就是在技术方案的选型里面一定要有一个平衡，能够用最小的技术投入获取到最大的技术利益，而非深究于技术本身的实习方式。如果一名技术主管不了解技术的框架或者某一些主干流程，那么就根本谈不上怎么样去评估这投入的技术产出比。一旦一名技术主管无法衡量整个技术团队的投入产出比，那就意味着整个团队的管理都是在抓虾和浑水摸鱼的状态，这时候就看你团队同学是否自觉了。

出现了这种情况下的团队，可能换一头猪在主管的位置上，业务依然运行良好。如果在业务发展好的时候，可能一直能够顺利推动，你只要坐享其成就可以了，但是一旦到了要突破困难的时期，或者在业务走下行的时候，这个时候你技术上面的优势就一点就没有了。而且在这种情况下，如果你跳槽到其他公司，作为一名技术主管，对方的公司对你的要求也是非常高的，所以这个时候你如果都说不出来你的技术价值对于业务上面的贡献是什么那想当然，你可能大概率就凉凉了。

那问题又回到了什么样的水平才能到达架构师这个话题，可以出来另一篇文章来描述，但是整体上来说，架构的本质首先一定要明白，为的就是业务的增长。

其次，架构的设计其实就是建造一个软件体系的结构，使得具备清晰度，可维护性和可扩展性。另外要想做好架构，基本的基础知识也必不可少，比如说数据库选型、分布式缓存、分库分表、幂等、分布式锁、消息架构、异步架构等等。所以本身来说做好架构师本身难度就非常大，需要长期的积累，实现厚积而薄发。如何成为一名优秀的架构师可以看我的公众号的其他文章，这里就不再详细的介绍了。

第二点是技术主管需要对于技术细节有敏感度。很多人在问一名主管到底应该具备什么样的综合能力，能不能用一种更加形象的方式来概括，我认为就有一句话就可以概括了。技术主管应该是向战略轰炸机在平常的时候一直遨游在大气的最上层能够掌控整个全局，当到了必须要战斗的时候，可以快速的补充下去，定点打击。

我参加过一次TL培训课程，讲师是阿里云智能交付技术部总经理张瑞，他说他最喜欢的一句管理概括，就是“心有猛虎，细嗅蔷薇”，也就是技术主管在平常的时候会关注于更大的宏观战略或策略，也就是注重思考全局，但是在关键的时候一定要关注和落地实际的细节。

换句更加通俗的话来说，就是管理要像战略轰炸机，平常的时候飞在万丈高空巡视，当发生了战斗的时候，立即能够实现定点轰炸。

所以如果说架构上面的设计就是对于整个团队业务和技术骨架的把握，那么对于细节的敏感度就是对于解决问题的落地能力。

那怎么样能够保证你自己有一个技术细节的敏感度？

我认为必要的代码量是需要的，也就是说对于一个主管来说，不必要写太多低代码，但一定要保证一定的代码量，让自己能够最好的，最快的，最贴近实际的理解实际的业务项目。自己写一些代码，其实好处非常多，一方面能够去巩固和加深自己对技术的理解，另外一方面也能够通过代码去更加理解业务。

当然贴近技术的方式有很多种，不一定要全部靠写代码来完成，比如说做code review的方式来完成，做技术方案的评审来完成，这都是可以的。对我来说，我就会强迫自己在每一个迭代会写上一个需求，需求会涉及到各方各面的业务点。有前端的，有后端的，也有数据库设计的。

自己亲自参与写代码或者code review，会让自己更加贴近同学，能够感知到同学的痛点，而不至于只是在空谈说教。

总结

所以对于一个技术主管来说，我认为首要的就是具备架构设计的能力，其次就是要有代码细节的敏感度，对全局和对细节都要有很强大的把控能力。

当然再总结一下，这一套理论只是适用于基础的管理者，而非高层的CTO等，毕竟不同的层级要求的能力和影响力都是不一样的。

这篇也是我分享里为数不多 “进阶” 与 “成长经历” 的文章之一。被别人送到嘴边的食物永远是最香的，但是咱们还是得学会主动去"如何找吃的"，授人以鱼不如授人以渔嘛，我希望通过这篇文章能给正在努力的你，迷茫的你，焦虑的你，带来或多或少的参考、建议或者指引。

十年，谁来成就你？

　　离开校园，一晃已十年，时日深久，现在我已成为程序员老鸟了，从软件工程师到系统架构师，从被管理者到部门负责人，每一段经历的艰辛，如今回忆仍历历在目。各位同行你们可能正在经历的迷茫，焦虑与取舍，我也都曾经历过。

　　今天我打算跟大家分享下我这些年的一个成长经历，以此篇文章为我十年的职业历程画上一个完满的句号。这篇文章虽说不是什么“绝世武功”秘籍，更没法在短时间内把我十年的“功力”全部分享于你。篇幅受限，今天我会结合过往种种挑重点说一说，大家看的过程中，记住抓重点、捋框架思路就行了。希望在茫茫人海之中，能够给到正在努力的你或多或少的帮助，亦或启发与思考。

试问，你的核心竞争力在哪？

　　你曾经是否怕被新人卷或者代替？如果怕、担忧、焦虑，我可以很负责任地告诉你，那是因为你的核心竞争力还不够！这话并不好听，但，确是实在话。认清现状，踏实走好当下就行，谁能一开始或者没破茧成蝶时就一下子有所成就。

　　实质上，可以这么说，经验才是我们职场老鸟的优势。 但是，经验并不是把同一件事用同一种方式重复做多少年，而是把咱们过往那么多年头的实践经验，还有被验证的理论，梳理成属于自己的知识体系，建立一套自己的思维模式，从而提升咱们的核心竞争力。

 　  核心竞争力的形成，并非一蹴而就，我们因为积累所以专业，因为专业所以自信，因为自信所以才有底气。积累、专业、自信、底气之间的关系，密不可分。

核心竞争力，祭出三板斧

　　道理咱们都懂，能不能来点实在的？行！每当身边朋友或者后辈们，希望我给他们传授一些“功力”时，我都会给出这样的三个建议：

1. 多面试，验本事。


2. 写博客，而且要坚持写。


3. 拥有自己的 Github 项目。 

　　其中，博客内容和 Github 项目，将会成为咱们求职道路上的门面，这两者也是实实在在记录你曾经的输出，是非常有力有价值的证明。此外，面试官可以通过咱们的博客和 Github，在短时间内快速地了解你的能力水平等。或许你没有足够吸引、打动人的企业背景，也没有过硬的学历。但！必须有不逊于前两者的作品跟经历。

　　再说说面试，我认为，它是我们接受市场与社会检验的一种有效方式。归根结底，咱们所付出的一切，都是为了日后在职业发展上走得越来越好。有朋友会说，面试官看这俩“门面”几率不大，没错，从我多年的求职经历来看，愿意看我作品的面试官也只占了 30%。

　　但是，谁又能预判到会不会遇到个好机会呢？有准备，总比啥也没有强，千里马的亮点是留给赏识它的伯乐去发现的。

PS：拥有自己 Github 项目与写博，都属于一种输出的方式，本文就以写博作为重点分享。写博与面试会在下文继续展开。

记忆与思考，经验与思维

　　武器（三板斧）咱们已经有了，少了“内功心法”也不行。这里分享下我的一些观点，也便于大家后续能够更好地参与到具体的实践中。

• 
  

  记忆——记忆如同对象一样是具有生命周期，久了不用就会被回收（忘记）。

  
  


• 
  

  思考——做任何事情就如同咱们写代码Function一样，得有输入同时也得有输出，输入与输出之间还得有执行。

  
  


• 
  

  ---

  
  

   

  
  

　　日常工作中，就拿架构设计当例子。作为架构师是需要针对现有的问题场景提出解决方案，作为架构师的思考输入是业务场景、团队成员、技术选型等，而它的输出就是基于前面的多种输入参数从而产出的短期或长期的解决方案，而且最终会以文档形式保存下来。

　　保存下来的目的，是为方便我们日后检索、回忆、复用。因此，在业余学习中同理，给与我们的输入是书籍、网络的资料或同行的传递等，而作为输出则是咱们记录下来的笔记、博客甚至是 Github 的项目 Demo。

基于上述，我们需要深刻意识到心法三要素：

1. 带着明确的输出目的，才会真正地促进自己的思考。蜻蜓点水、泛泛而谈，是无法让自己形成对事物的独特见解和具象化输出，长期如此，并无良益。


2. 只有尽可能通过深度思考过后的产出，才能够形成属于自己真正的经验。


3. 知识的点与点之间建立联系，构成明晰的知识体系，经验与经验则形成了自己独有的思维模式。

多面试，验本事

　　既然“武器”和“内功心法”咱们都有了，那么接下来得开始练“外功”了，而这一招叫"多面试，验本事"。

　　我身边的同行与朋友，对我的面试行为感到奇怪：你每隔一段时间就去面试，有时拿到了 offer 还挺不错的，但是又没见想着跳槽，这是为何？

风平浪静，居安思危

　　回应这个疑问之前，我想反问大家 4 个问题：

1. 是否曾遇到过在一家公司呆了太久过于安逸，也阶段性想过离开，发现真要走可却没了跳槽的勇气？


2. 再想一想，日子一久，你们是不是就不清楚行业与市场上，对人才能力的需求了？


3. 是否有经历过公司意外裁员，你在找工作的时段里有没有强烈感受到那种焦虑、无助？


4. 是否对来之不易的 offer，纠结不知道如何抉择，又或者，最终因为迫于各方面压力，勉为其难接受了不太中意的那个？

　　刚提到的种种问题，那份焦虑、无助、纠结与妥协，我曾经在职场都经历过。我们想象一下，如果你现在随随便便出去面试五个公司能拿到三四个 offer，你还会有那失业的焦虑么？如果现在拿到的那几个 offer 正好都不喜欢，你全部放弃了，难道你会愁后续没有其他机会了么？显然不会！因为你有了更多底气和信心。

　　我再三思考，还是觉得有必要给大家分享一个我的真实经历。希望或多或少可以给你一点启发：

　　2019 年，因为 A 公司业务原因，我离开了工作 3 年的安逸的环境，市场对人才的需求我已经是模糊的了，当我真正面临时，我焦虑、我无助。幸好曾经跟我合作过的老领导注意到了这我这些年的成长，向我施予援手。入职 B 公司后，我重新审视自己，并给与自己定了个计划——每半年选一批公司面试。

一年以后，因为 B 公司因疫情原因，我再次离职。这次，我没有了焦虑，取而代之的是自信与底气，裸辞在家开始了我的休假计划。在整个休假期，我拒绝了两个满足我的高薪 offer，期间我接了个技术顾问的兼职，剩余时间把以前囤下来的书看了个遍，并实践了平常没触碰到的技术盲区。三个月后，我带着饱满的精神面貌再次"出山"，入职了现在这家公司。

　　有人会问：你现在还有没有坚持自己的面试计划？毫无避讳回答：有！仍然是半年一次。

乘风破浪，未雨绸缪

　　就前面这些问题、情况，这里结合我自己多年来的一些经验，也希望给到大家一点破局建议：保持一定的面试频率，就如上文提到的“三板斧”，面试是接受市场与社会检验，非常直接、快速、有效的一种好方式。 当然，我可不是怂恿你频繁跳槽，没有多少公司能够欣然接受不稳定的员工，特别是岗位越做越高时。

　　看到这里，有些伙伴可能会想，我现在稳稳当当的、好端端的，干嘛要去面试，何必折腾自己。假若你在体制内，我这点建议或许参考意义不大。抛开体制内的讨论，大家认为真的有所谓的“稳定”的工作吗？

　　我认为所谓的“稳定”，都是只是暂时的，甚至虚幻的，没有任何的人、资本、企业能给你实打实的承诺，唯一能让你“稳定”持续发展下去的，只有你的能力与眼界、格局等。

　　疫情也有几年了，相信大家也有了更多思考，工作上，副业上等等各方面吧。人无远虑，必有近忧，未雨绸缪，实属必要！

放平心态，查缺补漏

　　面试是相对“主观的”，这是因为“人性”的存在，你可能会听过让人哭笑不得的拒绝你的理由：

• 连这么基础的知识都回答不上，还想应聘这岗位


• 你的性格并不适合当管理，过于主动对团队不好

　　咱们先抛开这观点的对与错。人无完人，每个人都有自己的优点与缺点，甚至你的优点可能是你的缺点。职场长路漫漫，要是把每一次的面试都当成人生中胜负的较量，那咱们最后可能会输的体无完肤。咱们付出任何的努力，也只是单纯提高“成功率”而已。听我一句劝，放平心态，以沟通交流为主，查漏补缺为辅。

　　近几年我以面架构师和负责人的岗位为主，面试官大多数喜欢问思想和方法论这类的问题，他们拥有不同的细节的侧重点，因此我们以梳理这些“公共”的点出发，事后复盘自己回答的完整性与逻辑性，对于含糊不清的及时找资料补全清晰，尝试模拟当时回答的场景。每一段面试，如此反复。

　　作为技术人我建议，除了会干，还得会说，我们不仅有硬实力，还得有软技能。

PS：篇幅有限，具体面试经历就不展开了，如果大家对具体的面试经历感兴趣，有机会我给大家来一篇多年的"面经"。

持续进步

编程语言本身在不断进步，对于菜鸟开发者来说，需要较高的学习成本。但低代码平台天然就具备全栈开发能力，低代码程序员天然就是全栈程序员。

这里非常推荐大家试试JNPF快速开发平台，依托的是低代码开发技术原理，因此区别于传统开发交付周期长、二次开发难、技术门槛高的痛点，在JNPF后台提供了丰富的解决方案和功能模块，大部分的应用搭建都是通过拖拽控件实现，简单易上手，在JNPF搭建使用OA系统，工作响应速度更快。可一站式搭建生产管理系统、项目管理系统、进销存管理系统、OA办公系统、人事财务等等。

开源链接：http://www.yinmaisoft.com/?from=jueji…

狠下心来，坚持到底

锲而舍之，朽木不折；锲而不舍，金石可镂——荀况

　　要是把"多面试"比喻成以"攻"为主的招式，而"写博客"则是以"守"为主的绝招。

　　回头看，今年，是我写博客的第八个年头了，虽说写博频率不高，但整体时间跨度还是挺大的。至今我还记得我写博客的初心，用博客记录我的学习笔记，同时抛砖引玉，跟同行来个思维上的碰撞。

　　随着工作年限的增长，我写博客的内容慢慢从学习笔记变成了实战记录，也越来越倾向于输出经验总结和实践心得。实质上，都是在传达我的观点与见解。

　　而这，至关重要。反过来看，后面机会来了，平台联系人也可以借此快速评估、判断这人会不会讲、能不能讲，讲得怎么样，成的话，人家也就快速联系咱了。进一步讲，每一次，于个人而言，都是好机会。

写博第一步，从记笔记开始

　　我相信不少的同行曾经面临这样的境况，都有产生过写博客的念头，有些始终没有迈出第一步，有些中途停了下来，这里可能有不少的原因：要么不知道写什么、要么觉得写了也没人看、还有一种是想写但是比较懒等等。

我觉得，一切的学习，前期都是从模仿开始的 。 学习笔记，它就是很好的便于着手的一种最佳方式。相信大家在学生年代或多或少都写过日记，就算是以流水账的方式输出，博客也可以作为非常好的开启平台。

　　由于在写博客的时候，潜意识里会认为写出来的东西会给更多人看，因此自己写的内容在不明确的地方都会去找资料再三确认，这是很有效的一种督促方法。确认的过程中，也会找到许多相关的知识点，自然而然就会进一步补充、完善、丰富我们自己原有或现在的知识体系。

幸运，需要自己争取

　　在写博客的这段时间里，除了梳理自己的知识体系之外，还能结交了一些拥有共同目标的同行，我想，这就是真正的志同道合吧。

　　甚至在你的博客质量达到了一定程度——有深度与广度，会有一些意象不到的额外小收获。例如有一些兼职找到自己，各大社区平台会邀请自己合作，也会收到成就证明与礼物等等。

意外地成为了讲师

　　到目前为止，正式作为讲师或者是技术顾问，以这样不同于往常的既有角色，我真切地经历了几次。虽次数不多，但每一次过后，即便时日深久，可现在回想起来，于我的成长而言，那都是一次又一次新的蜕变，真实而猛烈，且带给我一次次新生力量。

　　话说回来，前面提到几次分享，有的伙伴可能会说了，这本来就性格好又爱分享的人，个例罢了，不一定适合大多数啊。说到这儿，我想，我有必要简短地跟你聊一下我自己。

跌跌撞撞，逆水行舟

　　对于过往的自己，我的评价是从小就闷骚、内向的那种性格，只要在人多的时候发言就会慌会怂会紧张，自己越慌就越容易表达出错，如此恶性循环。随着我写博的篇幅越多，慢慢地我发现自己讲话时喜欢准备与思考，想好了再去表达，又慢慢地讲话就具有条理性与逻辑性了。

　　当代著名哲学家陈嘉映先生，他曾在一本书里说过这样一句话，放到这里再合适不过了—— "成长无时无刻不是在克服某些与生俱来的感觉和欲望"

　　回头看，一路走来，我从最初的摸索、探索、琢磨，到看到细微变化，到明显感知到更大层面的进步，再到后来的游刃有余，输出很有见地的思考，分享独到观点。

　　我想，这背后，离不开一次次尝试，一次次给自己机会，一次次认真、负责地探索突破自己。其实，大多数人，还真是这么跌跌撞撞挺过来的。

伺机而动，用心准备

　　2020 年，我第一次被某企业找到邀请我作为技术顾问是通过我的博客，这一次算是小试牛刀，主要以线上回答问题、交流为主。因为事先收集好了需要讨论的话题与问题，整个沟通持续了两个小时，最终也得到了对方老板的高度认可。

　　此事过后，我重新审视了自己，虽然我口才并不突出，但是我基于过往积累的丰富经验与知识融合，并能够正确无误地传达输出给对方，我认为是合格的了。坦率来讲，从那之后我不再怀疑自己的表达能力。同时有另外一件事件更值得重视，基于让自己得到更多更广泛的一个关注，思前想后，概括来讲，我还是觉得落到这句话上更合适，就是：建立个人 IP。

建立个人 IP

　　那么，我希望打造个人 IP 的原因是什么呢？希望或多或少也可以给你提供一点可供借鉴、探讨的方向。

　　我个人而言，侧重这样几个层面吧。

1. 破局： 一个是我希望打破 35 岁魔咒，这本质上是想平稳快速度过职业发展瓶颈期；


2. 觅友： 希望结识到拥有同样目标的同行，深度交流，构建技术圈人脉资源网；


3. 动力 ： 从中获取更多与工作不一样的成就感。有了强驱动力，也会使我在分享这条路上变得更坚定。

链接资源，提影响力

　　在《人民的名义》里祁同伟说过一句话，咱们就是人情的社会。增加了人脉，就是增加自己的机会。当然前提是，咱们自己得需要有这个实力。

　　建立个人 IP，最要提高知名度，而提知名度的主要方式是两种：写书、做讲师。后面我会展开讲，写书无疑是宣传自己的最好方式之一，但整个过程不容易，周期比较长。作为写书的简化版，我们写博客就是一种捷径了。

主动出击，勿失良机

　　而作为讲师，线上线下各类形式参与各种社区峰会露脸，这也是一种方式。不过这种一般会设有门槛。

　　这里不得不多提一句，就是建立 IP 它是一个循序渐进的过程，欲速则不达，任何时候咱们都得靠内容作品来说话， 当你输出的质量够了，自然而然社区人员、企业就会找到你，机会顺理成章来了。反过来讲，我们也得常盯着，或者说多留心关注业内各平台的内容风格，利用好业余零碎时间，好好梳理下某个感兴趣的内容平台，看看他们到底都倾向于打造什么样的东西。做到知己知彼，很重要。

　　我认识的一个前辈，之前阿里的，他非常乐于在博客上分享自己的经验与见解，随着他分享的干货越多，博客影响力越大，某内容付费平台找到他合作出了个专栏，随着专栏的完结，他基于专栏内容又出了一本书，而现在的他已经离开了阿里，成为了自由职业者。

追求成就感，倒逼突破自我

　　每一次写博客、做讲师，都能更大程度上填满我内心深处的空洞，或许是每一个支持我的留言与点赞，或许是每一节分享停顿间的掌声。如果我们抱着非常强的目的去做的时候，可能会事与愿违。就以我做讲师来说，因为我是一个新手，在前期资料准备所花费的精力与时间跟后续的课酬是不成正比的。

　　作为动力源，当时我会把侧重点放到结交同行上，同时利用“费曼学习法”重新梳理知识，另外寻找机会突破自己的能力上限。

　　大家有没有想过，讲课最终受益者的是谁？有些朋友会回答“双方”。但是我很负责任地告诉你，作者、讲师自己才是最大的知识受益者。

　　如前面所讲，写博客为了更好地分享出更具价值性的内容，为保证专业性，咱们得再三确认不明确的点，而讲课基于写博客的基础上，还得以听众的角度，去思考、衡量、迭代，看看怎么让人家更好地理解、吸收、用得上这些知识点，甚至讲师得需要提前模拟、预估可能会在课后被提的问题。

这里总结一下，写博客与讲课的方式完全不同，因为博客是以图、文、表的方式展现，读者看不明白可以回头去看，但是讲课则没有回头路，是一环套一环的，所以梳理知识线的连贯性要求更强。

　　我个人认为，日常工作大多数是重复的、枯燥的，或者说，任何兴趣成了职业，那将不再是兴趣，或许只有在业余的时候获取那些许的成就感，才会重新燃起自己的那一份初心 ——行之于途而应于心。

源不深而望流之远，根不固而求木之长

　　求木之长者，必固其根本；欲流之远者，必浚其源泉——魏徵

　　有些同行或许会问：”打铁还需自身硬“这道理咱们都懂，成长进阶都离不开学习，但这要是天天写 BUG 的哪来那么多时间学？究竟学习的方向该怎么走呢？在这里分享下我的实际做法，以及一些切身的个人体会，希望可以提供一点借鉴、参考。

零碎时间，稳中求进

　　6 年前，我确定往系统架构师这个目标发展的时候，每天都会做这么两件事：碎片化时间学习，及时产出笔记。

• 上班通勤与中午休息，我会充分利用这些碎片时间（各 30 分钟）尽可能地学习与吸收知识，每天坚持一小时的积累，积少成多，两年后你会发现，效果非常可观，这就是一个量变到质变的过程。

　　而且有神经科学相关表明，”间歇式模块化学习的效果最佳，通勤路上就是实践这种模式的理想世界。“大家也可以多试试看。当然，一开始你学习某个领域的知识，可能效率没那么高，我建议你可以反复地把某一节掰开了揉碎了看或者听，直到看明白听懂了为止，接着得怎么做？如我前面说，咱们得要有输出！

　　看过这样一段话，”写和想是不同的，书写本身就是逻辑推演和信息梳理的过程。“而且，研究表明，”人的记忆力会在 17-24 岁达到高峰，25 岁之后会下降，理解力的发展曲线会延后 5 年，也就是说在 30 岁之后也会下降。“

　　你看，这个也直接或者间接告诉我们，还是趁早多做记录、多学习。文字也好，视频也罢，到底啥形式不重要，适合自己能长久坚持的就行，我相信你一定能从中受益。毕竟，这些累积的，可都是你自己实实在在的经验和思考沉淀！

　　话说回来，其实做笔记能花多长时间，就算在工作时间花半小时也有良效，而这时间并不会对自己的工作进度造成多么大的影响，但！一定时日深久，受益良多。

构建知识 体系 ， 丰富 思维 模式

　　由于我们日常需要快速解决技术难题，很多时候从外界吸收到的知识点相对来说很零散，而知识体系是由点、线、面、体四个维度构造而成的。

　　那怎么做能够快速把知识串联起来呢？这里我举个简单的例子，方便大家理解。

　　以我们系统性能调优出发，首先我们需要了解系统相关性能瓶颈的业务场景是什么？该功能是 I/O 密集型还是 CPU 密集型？如果是 I/O 密集型多数的性能瓶颈在数据库，这个时候我们就得了解数据库瓶颈的原因，究竟是数据量大还是压力大？如果是数据量大，基于现有的业务场景应该选择数据归档、临时表还是分库分表，这之间的方案优缺点有什么不同？适用场景怎么样？假如是数据压力大了，我们是否能用 Redis 做缓存抗压就行？

　　再接着从 Redis 这个点继续思考，假如 Redis 内存满了会怎样？我们又了解到了 Redis 的内存淘汰策略，设置了 volatile-lru 策略，由于我们基本功扎实回忆起 LUR 算法是基于链表的数据结构，虽然链表的写的时间复杂度是 O(1)，但是读是 O(n)，不过我们得先读后写，所以为了高性能又选择 Hash 这种 O(1)的数据结构辅助读的处理。

　　你看，我们是不是从问题出发到架构设计，再从数据库优化方案到 Redis 的使用，最后到数据结构，这一些系统的知识就串联起来了？

人生天地之间，若白驹之过隙，忽然而已

这段时间有个同事离职了，其实身边不断有老人走、有新人来，但这回走的同事和别的有些不同，当时我入职面试的时候就是他面试的我，工作中有啥问题都会请教他，转眼间一起共事三年多，亦师亦友，忽然离去，心中不免有些不舍。

同事

其实自从工作以来，我们每天接触最多的不是家人、朋友，而是同事，毕业几年来也认识了很多同事，有很多乐于助人、兢兢业业的，当然不乏一些泛泛之辈。

对于我个人而言，一般和同事都保持不错的一个状态，但如果问我同事间的关系如何相处，那我肯定告诉你：点头之交即可，不要想着你和同事怎么怎么好，转过头来就有可能把你给卖了，这台正常不过了，除非特别熟，不然尽量别说别的。

朋友

已经很久没和朋友好好聊天，吃个饭了，工作以来虽说是双休，但周末一直有事，即使没事，也只想躺在床上躺会，早上晚起一会，起来弄点饭吃完就中午了，又想再睡会，因为在公司里没有午休的习惯，一觉起来就不早了，出去溜达溜达就到晚上了，时间、时间都去哪了，都用来睡觉、吃饭。。。。

记得高中、大学，认识不少同学，但真正从自己内心算作朋友的，其实少之又少。

高中时同宿舍、同学都在一起玩，我以为他们是我的朋友，所以即使高中毕业了，每次回到家都联系着之前同宿舍的一块出来聚一聚，第一年还出来了，之后不是这个有事就是那个有事，或许是真的有事，亦或许不想和我聚一聚，还或许根本没人把你当成朋友。

大学更是这样，大学认识的朋友屈指可数。

其实有时想想，可能并不是别人的问题，是我自己的问题。但转念想想：”人生天地之间，若白驹之过隙，忽然而已“，想那么多干啥？古人曾说：”人生得一知己足矣“，况且我还有朋友呢！

家人

其实自从上小学开始，和家人在一起的时间就没有多少了，上大学后，一年到头也见不了几次，工作后更甚。

尽力对家人好点吧，多打打电话、多打打视频，现在的技术发达，视频通话可以直接看到对方，非常方便，家人最想要的就是在外漂泊的自己能过得好一点。

瞎写

转眼间毕业工作也好几年了，自我感觉技术上没有特别巨大的提升，但是技术厚度及深度较前几年有了不小的提升，也算是一些收获。

此文因一亦师亦友的大哥离职后产生的一些瞎想，希望大哥在新的城市里顺风顺水，未来更好吧！也希望自己能够不忘初心，在技术上更上一层楼。

努力，共勉

今天来跟大家分享一下Leader在一个团队里面到底起着什么样的作用？有一个最为简单的说法，Leader就是把整个组织的所有人通过文化规则和流程组织起来，能够顺利的完成一件或者多件重要的事情的角色。

组织的流程化

我们知道，组织越大事情和人就越多，为了组织好这些人和事，一个组织往往就伴随着有各种各样的标准化流程，又称之为SOP。这个也不难理解，动辄几千上万员工的组织，如果连流程都没有，混乱一团，那可想而知会是一个巨大的灾难，在沟通和协同上面就会耗费大量的成本。

所以相对稳定的公司或者规模越大的公司，它的流程就会越多，这往往导致在做一个事情的时候，进行决策的时间也会更长。流程在一定程度上是解决了很多混乱的问题，但是流程本身也会带来效率低下的问题。但是总体而言，没有流程会造成更大的问题。

那是不是在建立起了流程以后就高枕无忧了呢？如果流程非常完善的情况，Leader又只是把流程做一个管理和编排和组织，那么Leader的价值基本上体现不出来，这种流程极度完善的情况下，那么还要Leader干什么呢？因此我们当代追求的Leader不仅仅是维护和管理这些流程和员工，而应该是企业在对面不确定性事情的法宝。

核心一句话就是Leader是公司面向不确定的事情的压舱石。

面向不确定性的未来

大型组织在流程在规章制度已经比较完善的情况，很多事情员工只要按流程走就可以了，但是我们知道如果一个组织通过流程就能处理所有的事情，那我相信这应该是一个极度老化、极度传统的公司，这种公司已经没有了任何的创造力，所有员工只是机械的去执行公司的命令和流程而已。没有创造性的公司，能面对千变万化的市场吗？

一个不需要公司里面的任何人都有创造力的组织，我相信本身组织就没有创新力。这种组织可能就是非常传统的国有企业，每个人不要有创造力，你只要完成你所要处理的工作就可以了，那这种情况下也只有垄断组织才能做得到，民营企业和国际化的企业是不可能能够实现的，一招鲜吃遍天，在当前这个时代已经不存在了。

所以我认为只有灵活的能够处理不确定的业务，不确定的事情的团队和公司才有成长和逆袭的可能性。因为市场是变化的，客户也是变化的，不可能所有的东西一成不变，用一套服务，一套标准，一套产品就能够解决客户永远的问题的时代早已经一去不复返了。不确定才是当前社会的主旋律，只有一个组织能够尽快的满足变化的需求，才能够拿得出最好最新的产品，才能赢得客户。

那些不确定的事情谁来负责比较合适呢？首先作为整个公司的负责人、一把手、CEO理应是去处理市面上的变化最好的任选，但是不可能所有的变化全部由负责人一个人来处理。这些负责人只能说把握五年，十年的趋势，从这些变化的趋势里面找到确定性的方向来组织和施公司的战略。那不可能所有鸡毛蒜皮，每个分公司，每个分部门，每个普通产品线的业务，如果都要负责人来解决的话，那么这个公司直接在负责人这个层面上面就先崩溃了，比如阿里巴巴而言面对几亿的用户、几千万的商家和合作方、几十万的员工，如果都要负责人亲力亲为，这是完全不现实的。

那能否让一线的员工来处理呢？这个听起来非常美好，每个员工都是公司一份子，理应去接受市场上面的变化，但想想也是不大现实的，因为对于基层一些员工来说，他们往往只有执行的权利，而没有对于很多不确定的情况下的判断的权利。而且很多基层员工由于工作的时间不久，对整个公司的了解也不是特别深，所以往往就算给了他权限，他也没办法能够处理好这些不确定的事情，权限过大反而有可能做出错误的事情。

那公司谁是处理这些不确定的事情里面最好的对象呢？答案就是每一位Leader，也就是每一个层面上不同的Leader，比如财务Leader、业务Leader、销售Leader和技术Leader等等。

一方面公司里面的Leader是整个公司的最核心的节点，他们能够接触到各种各样从上到下的信息，另外由于大量的Leader也是基础一线的负责人，所以往往对于前线的客户需求感知非常的强烈。所以现在的Leader往往是最能够洞察到前线客户需求变化的人，同时也因为Leader一般都有实际执行的权利，通常来说Leader往往在不同规模和不同层面上都有一定的决策权，因此可以快速的组织团队去应对客户需求和市场上的变化。

这个才是Leader最核心的意义，就是要组织小团队去处理这些不确定性的事情和风险，从而给团队，给公司，给业务带来巨大的增量价值。

Leader是不确定性的压舱石

这也是为什么说Leader是整个公司面对不确定性的事情的压舱石，只有整个公司的一线Leader都具备了这样的能力，整个组织才是一个具备有活力的组织，是能够迎接创新和拥抱变化的组织。

这种模式仿佛就是一个动车组一样，每个团队就犹如一起车厢，每个车厢都有自己独特的动力闭环，能够快速的迎接变化，快速的可拆卸组装，而且能够快速的在整个更高层战略的情况下实现更灵活的组合，以应对更大的确定性，以解决更难的问题。

从一些具体的层面上来说，当较大的业务系统发生了比较大的故障的时候，客户有强烈的投诉情绪，这个时候对于一线的开发同学来说，他很难能够确定到底是什么系统引起的，这个时候就需要团队的Leader作为第一业务的接口人来跟进和负责整个事情，从而使得各个团队之间不会相互推诿。所以一旦面对一些不确定性的问题的情况下，在一线同学无法判断问题是什么样根源、什么样的上下游以及什么样的背景的情况下，Leader就是处理问题最好的应急指挥人。

我们的线上有客户提出了大量的需求的时候，我们一些同学往往没有权利去决策是否能支持这个需求。或者有流程可以让一线同学会把这个问题层层上交，一直提交到最高层来审批为止，而往往由于这样流程上的阻碍或者麻烦，所以同学就不愿意去花费这么大的精力向更高层去建议到底要做什么样的东西，大部分员工干脆就不会去提这个建议，直接当这个事情没发生就行了。

有很多非常大的公司往往会倒闭，就是因为适应不了市场上面的变化，当整个市场都发生了很大的变化的时候，这些高层往往感觉不到发生了变化，而很多时候一线的员工往往已经意识到了这些敏锐的变化，但是各种各样的机制，一线员工无法高层传递建议，进而导致了整个公司在面对极大的变化的情况下的话无法应变而轰然倒塌，诺基亚就是一个非常鲜活的例子。

而作为一线的Leader，往往就能够敏锐的去捕获这些信息，而且在整个公司制度流程比较有保障的情况下的话，也能够放权给一线Leader快速做出决策，或者把这些问题快速的反馈给更高层的领导。

比如我在公司的时候就经常去和客户进行共创，就会经常被客户问到我们为什么PC上面还没有定制工作台的能力，而那个时候我们在2018年就有了移动端的能力，但是由于战略方向的问题，我们迟迟没有在PC上面去补足这个短板，进而反复被竞争对手攻击。我接收到了大量的来自于一线客户的反馈，我才做了一个决策帮助整个公司补足了在这一个产品上的短板，进而吸引到大量的增量客户，不仅创造了客户的活跃价值，还创造了商业化的价值。这就是Leader在足够授权下能替组织带来的增量贡献，而远远非整个团队坐等事情发生更有价值。

所以总结一下，各种公司在当今的社会都会面临各种各样的挑战和不确定性。一个公司如何来应对这些挑战和不确定确定性的能力就就决定了这个公司的命运。而面对这些不确定的核心就在于我们组织里面的关键的Leader节点，只有当Leader带领团队主动去拥抱和解决不确定性，才能给组织带来活力，重塑组织的命运。

因此一个公司想要发展的好，就一定要授权给所有听见炮火，两腿带泥的Leader，并且要构建出信任的文化和价值感让Leader带领团队能够以最好的姿态去面对和拥抱不确定性。

马斯克接手Twitter的一年后，在10.27其官方团队发布了一条推文展示这一年的工程成果。

有点国内那味了，论工作量化的重要性。

这一年里，我们在工程技术上取得了许多出色的成就，除了大家在应用中看到的明显变化之外，在幕后我们还做了一系列重要的优化和改进。

• 
  

  将「为你推荐」、「关注」、「搜索」、「个人主页」、「列表」、「社区」和「探索」等功能的技术栈整合到了一个统一的产品框架中。

  
  


• 
  

  彻底重建了「为你推荐」的服务和排名系统，代码行数从700K减少到70k，减少了90%；同时计算资源减少了50%，处理相同请求的能力提升了80%。

  
  


• 
  

  统一了「为你推荐」和视频的个性化、排名模型，显著提高了视频推荐质量。

  
  


• 
  

  重构了API中间层的架构，删除了超过10万行代码和数千个未使用的内部废弃接口，同时删除了一些没人用的客户端服务。

  
  


• 
  

  将获取帖子元数据的时间减半，全局API超时错误减少90%。

  
  


• 
  

  对外部机器人、爬虫的屏蔽，相比2022年，增长了37%。平均每天，阻止了超过100万次机器人注册，并将私信中的无用信息减少了95%。

  
  


• 
  

  关闭了位于萨克拉门托的数据中心，重新调配了5200台机架和148000台服务器，每年为公司节约了超1亿美元，总的来说，节约了48兆瓦的电量，60000磅的网络机架。

  
  


• 
  

  优化了对云服务厂商的使用，开始在本地进行更多的工作，这一转变使得每月的云服务成本降低60%，同时我们还将所有的媒体和大文件从云端迁出，减少了60%的云端存储空间，除此之外，还成功将云数据处理成本减少了75%。

  
  


• 
  

  构建本地GPU超级计算集群，并设计、交付了43.2Tbps 的高性能网络架构。

  
  


• 
  

  提升网络主干的容量和冗余性，每年节省1390万美元。

  
  


• 
  

  开展了自动化峰值流量故障转移测试，以持续验证平台的可扩展性和可用性。

  
  

工作篇

我在8月底结束了第一份工作后，在9月初迎来了我的二份工作，投简历投了大概一周约了12家面试，虽然那时候是疫情相对来说找工作还是比较容易点的，至少约的到面试，面了差不多6家，拿到了2家，当时情绪低落囊中羞涩想尽快入职工作选择第2家，后面的面试都推了，但是问题来了，通勤距离过长，每天公交从首站坐20个站左右去上班，下班在科技园的东门而公司在北门，走大概10分钟，从家里去公交站走路20分钟，于是我就开启了长达单程快2小时的路程上班，房子还有两个月到期我决定到期再搬过来。

这份工作给的工资是6500，试用期80%，也就是拿到手5200，试用期不交社保[刚毕业不太懂社保这个]，毕竟刚毕业，然后我就想努力的转正，这次我面试的职位的 .net开发工程师，离谱的事情我刚入职第一天让我接手一个五年经验大佬的项目[压缩成本也不是这样压缩的]，那我只是一只小喽喽啊，害，我痛苦极了， 很显然很多东西我接不住

但是交接大佬人挺好的这里暂称他为大哥，大嫂还在公司，后面有问题我直接让大嫂帮我问大哥，就暂时还过的去，勉勉强强的干着但是我特别吃力，我的顶头管我的是一个50左右的经理，开发出生头发花白，在公司待了12年，公司是做支付平台的又特别的严格，我之前没有接触过这块，有什么问题我还会问我之前的师傅，就勉强干着，经理每天晚上带我加班，于是我每天早上6点20起床，晚上12点到家，我的长头发嫌洗头发麻烦头发也剪了，不出意外一个月多以后我生病了，大概就是发烧，睡眠不足，经期也有问题，大概休了三天假加周末后来就好了，我当时就想离职了，觉得自己顶不住真的顶不住，第一家公司6天70个小时，第二家6天达到快90个小时，我就差睡在公司了

那段时间我每天都会被骂，就在工位其他同事都听见，我真想找个地缝钻下去，在高强度的工作下，公司每天都在招人，明明已经不缺人，公司试用期三天没工资[如果换我现在肯定告他了]，招人又开人，很离谱这样的公司现在还存在，后大概快两个月后我搬家离公司20分钟的车程附近我的日子稍微好过了一点，但是我却出了点问题，我每天焦虑的睡不觉，周末休息也不爱出门就在家里学习看代码，可能是怕被骂，我的精神状态一直不太好，睡觉喜欢抽，蹬腿特别严重时常蹬腿瞪醒，后来我就想着转正了好了，两个多月过去了快转正了，当时11月多了也想着快过年了，在这家公司我每个月还能存2000块钱，5200的工资，因为我几乎不出门就是吃饭睡觉，每天开销60左右，科技园里面吃饭挺贵的我算很省了，在这个公司除了老板跟经理，其他同事相处挺好的，我是里面最小的也挺照顾我的，他们都是25+，于是我就在这样过着，当时也没有意识去医院看看，就想着转正能加1300的工资，对于我来说是一笔不小的诱惑。。。。。

转眼三个月过去了公司没有给我转正，也没有开我就闭口不谈，我就急了在等我三个月后的10天左右，我就找人事询问，人事姐姐给我的意见是让我去问经理，经理说我被延迟转正了，说我表现不好，于是我又开始emo了，也不知都怎么办想离职又快过年了就这样混着，想着会找我谈，我还是太年轻了，直到12月20号左右，我找经理谈了大概意思就是要我转岗，说我基础太差了什么的，转做实施去客户现场调试工资4000，我拒绝了我知道这就是想赶我走，于是我离职了，离职后没有压力反而是一种解脱，我记得离职当天去看了场电影，那是我第一次在深圳看电影就在坂田，看完电影后回家哭了一场，然后就休息了两天总是失眠加蹬腿（我不知道大家是否也有过这样现象），医院给我建议是精神太紧张长期睡眠不足经期也不正常，让我好好休息，大概休息了几天月底我就和我同学去了张家界旅游去了，就这样我的第二份工作结束了。。。。。。。。。。。。。。。。

薪资追求

作为资深码农，对这个行业还是比较了解的。

大部分年轻程序员可能都只是想着如何提高技术，为拿到更好的Offer尔努力，很多码农到30岁后才突然发现，程序员高薪也就那么回事，自己好像也并没有存到什么钱，结婚生子，房贷，车贷，个人健康问题好像一样也没落下。其实回头看，互联网高薪也就那么几年，大部分没赶上的跟其它专业的差距也没那么大，甚至35失业后可能还不如同时期传统行业的同学，毕竟码农离开了平台，个人能发挥的空间很有限。

薪水档位

避免盲目的埋头学技术，努力工作，我们可以提前算一下，大部分程序员一辈子到底能挣多少钱。从毕业22岁算起，不同路线的码农的职业生涯可能有所区别，我们以互联网聚集的一线城市为例来看下各种情况：

第一档：

毕业即一线大厂，年薪30w-50w；普遍的能干三年，薪资区间在：120w-150w;

普遍三年一跳或不跳，一般不跳30%涨幅，跳槽可能有50%涨幅，年薪40w-55w再干两年能拿：80w-110w;

一般五年会有一波比较大的涨幅，算50%，年薪加股票一般能翻一倍，年薪区间会在80w-120w；能到这个段  位都是相对稳定，一般股票需要四年拿完，就按四年算，能拿到：320w-480w；

这个阶段算下来，大部分已经组建家庭区域稳定，31岁左右也不大会频繁变动，职位基本在P7以上，个人利益与公司利益绑定，如果自身没有想法，不创业基本能保证年薪区间在100w-200w,以40岁为终点来算基本能再多拿:900w-1800w;

总体的薪水在：120w+80w+320w+900w=1420w 到 150w+110w+480w+1800w=2540w；

第二档：

毕业二线大厂，准大厂，年薪15w-25w；普遍干三年，薪资区间在：45w-75w;

普遍三年一跳或不跳，一般不跳30%涨幅，跳槽可能有50%涨幅，年薪20w-40w再干两年能拿：40w-80w;

一般五年会有一波比较大的涨幅，算50%，这个段位基本没有股票，很多公司会卡薪水上限，年薪区间会在30w-50w；社招对标P7基本会在6年经验以上，所以这里普遍能再干两年拿：60w-100w；

这个档位工作7到8年，是大厂比较喜欢的人群，大部分能到P7，加上股票年薪能到60w-120w,一般四年拿完，算下来能多拿：240w-480w；

整体算下来这个段位基本也到33岁左右，稳定来讲大部分人的职级稳定到P7，P8，考虑年龄因素薪水幅度不会太大，维持70w-120w，假设能稳定干到38岁，可以拿到：350w-600w;

总体的薪水在：45w+40w+60w+240w+350w约700w 到 75w+80w+100w+480w+600w=1300w；

第三档：

毕业优质中小公司，年薪10w-15w；普遍干三年，薪资区间在：24w-45w;

普遍三年，五年靠跳槽涨薪，三年涨30%，干两年能拿：25w-40w;

五年跳槽涨50%，年薪30w-45w，干三年多拿：90w-140w；

30岁左右，比较尴尬，能冲一下P7进去也是大头兵，薪资也不会高出很多，年薪基本40w-70w；假设能稳定干到35岁；可以拿到：200w-350w;

总体的薪水在：24w+25w+90w+200w约350w 到 45w+40w+140w+350w约580w；

第四档：

毕业一般公司，年薪6w-12w;普遍干三年，薪资区间在：18w-36w;

起薪低，一般三年能翻一倍，起薪高的30%-50%涨幅，年薪：12w-20w,干两年能拿：24w-40w;

五年跳槽涨50%，年薪30w-45w，干三年多拿：90w-140w；

同第三档差不多，30岁左右，比较尴尬，能冲一下P7进去也是大头兵，薪资也不会高出很多，年薪比第三档第一点基本30w-50w；假设能稳定干到35岁；可以拿到：150w-250w;

总体的薪水在：18w+24w+90w+150w约280w 到 36w+40w+140w+250w约480w；

薪水总结

按照二八法则来看，普通人对应第三档到第四档，向上突破空间有限，也就是说80%以上的程序员在一线城市工作到35岁最多也就能挣500w左右，所以要找到自己的定位，面对一线城市的房价理性做出选择，而且税后的薪水能存下来的最多也就250w左右，所以一线互联网码农最合适的安家还是二线城市。

Hello，大家好，我是雷布斯。

但不少同学还是会问“我是工作了 x 年的前端，该怎么改呢？”，“我觉得我的项目就是没有亮点，该怎么挖掘呢？”之类的问题。

那我们今天继续用一个真实的例子，给大家分享该用什么样的思路去优化自己的简历。

提前说明，参与简历修改分享的张同学，于今年 4 月参加了我们的面试全流程辅导，修改意见由我们团队的 uncle13 老师提供，关键信息已打码，并且已经获得该同学的授权来进行分享。

下面将按照简历中的模块顺序逐一进行分析。

个人简介 & 教育经历

这位同学可能是使用的简历模板，这两部分的内容都写的很简洁。

那么问题来了：

• 简历右上角的二维码，扫出来是某简历网站，而且要求登录后才能查看电子简历，操作这么繁琐，放到纸质版的简历中是有什么目的呢？


• 部分内容不标注清楚，面试官无法快速了解你，比如南京是现居地还是籍贯？zxxxxx.top是个人博客还是项目网站？

所以这部分可以优化下：

• 去掉二维码


• 把关键信息标注清楚。比如个人博客：https://xxxx.top


• 教育经历如果没有太大的竞争力，可以考虑一块放到个人信息中，样式上会好看，改成：陕西理工大学 ｜ 本科 ｜ 网络工程

专业技能

简历中的专业技能是展示自己适合特定职位的能力和经验的重要方式。

但这位同学写的中规中矩，没有什么特色。

一般来说，面试官会从这个模块，了解到面试者的擅长的技术栈，熟练使用的工具等等。

编写清晰、明确的专业技能部分，有助于大家更好地展示自己的专业知识和经验。
但大家还是需要主要，对于自己写的所有关键字，都需要好好准备，面试官可以从任何一个感兴趣的方向进行提问。

针对这位同学的呢绒，可以这样进行优化：

1. 熟练掌握HTML+CSS。熟练掌握弹性布局、网格布局以及响应式布局，能够快速实现Web端和移动端页面搭建。


2. 熟练掌握 JavaScript，能脱离框架进行原生开发，熟悉 TypeScript。


3. 熟练使用 React 框架以及相关生态技术，能够独立完成项目搭建和项目部署，熟悉相关框架原理。


4. 了解 vue 框架技术，有相关实践经验。


5. 熟悉浏览器原理以及计算机网络相关技术，在性能优化方面有实践经验。


6. 了解 Node.js 和常用模块，在此基础上能够使用 Express 等 Web 框架进行简单的服务器应用程序开发。


7. 了解微信小程序原生开发，能够使用小程序原生开发进行开发。


8. 对前端工程模块化有一定理解，熟悉 webpack、vite 等打包工具及其日常开发配置，可以从 0 到 1 独立搭建项目，并优化构建流程。

大家发现没有，同样是描写熟悉的技术，但经过优化后，立马就变得高大上了。

工作经历

接着来看“工作经历”的模块。

其实比较推荐的介绍方式是，写清楚自己在公司的岗位、工作时间、个人的职责，同时也推荐加上公司的业务简介，不用太详细，1 - 2 句话简单介绍下就行。

在公司的个人职责就不要写的太简单了，你完全可以在这个模块，向面试官展示你的职业发展路径，工作经验和成果等等信息。

还有就是工作经历尽量用倒序的方式来组织，把最近的一份工作写在最上面。

还是以张同学的工作经历为例，我们可以这样修改：

• 南京xx有限公司（前端开发工程师）20xx年xx月 - 至今

工作内容：

1. 主要负责xx系统、xx系统等项目的业务开发工作，使用Vue+ElementUI技术栈。


2. 通过使用虚拟列表等技术优化大列表性能，加快页面加载速度，提高用户体验。


3. 参与各类项目，包括SPA应用、PC端和移动端的开发。


4. 深入了解并熟练应用Webpack、ES6、Vue生命周期和组件通信等前端技术，持续提升自身技能水平。


5. 在团队中积极沟通和合作，负责项目的需求分析、设计和开发，并对项目进展情况进行有效的跟踪和反馈。

• 西安xxxx有限公司（实习前端开发）20xx年xx月 - 20xx年xx月

工作内容：

1. 负责xx平台部分功能模块的前端开发工作。


2. 和后端工程师配合完成接口联调，确保数据交互正常。


3. 在实习期间积累了从需求分析到代码实现的全流程开发经验。

项目经历

“项目经历”和“工作经历”都是简历的重点。

之前分享的文章也介绍了很多挖掘项目亮点的方法，我们今天也不再过多介绍了。

现在直接来看张同学的例子。

项目一：生鲜到家

首先还是项目顺序的问题，最近的项目写在前面。

写的很简洁，一看就像是个人练手项目。但商城项目真的烂大街了，而且个人职责也完全体现不出这个项目的难度和亮点。

这样的项目，面试官真的是一点问的兴趣都没有。

不过这位同学附上了项目的访问地址，做了私有化的部署，能挽回一些印象分。

我们可以这样调整：

• 项目名称：生鲜到家

项目简介：生鲜到家是一个在线购物商城，实现了商铺选品、购物计费、购物车、购物下单等功能。

项目地址：xxxx.top/

技术栈：Vue3，Vuex，Vue-router，Axios，Mock.js

主要职责：

1. 负责整个项目前端生产环境的整体搭建(仓库创建、项目搭建、工程发布)以及项目管理。


2. 采用 vue 技术生态开发了核心业务模块（购物车、商品选择等），并针对业务做了一些公共组件的抽离：通信、错误处理、图片优化以及其他业务组件的二次封装。


3. 使用 Mock.js 进行数据模拟，并封装 Axios 发送请求，减少对后端接口的依赖。成功实现了前后端分离开发并独立部署上线。


4. 使用 Vue3 组合式 API 进行项目逻辑的编写，提高了代码复用性和可维护性。同时，在模块化开发过程中，成功将代码行数降低了 20% 以上。


5. 利用 Vue-router 路由钩子函数实现系统角色权限控制，并且统一了前端路由的交互模式。


6. 结合业务以及 UI 规范封装了 css 原子化组件，组件开发效率提升了 30% 。


7. 开发过程学了XX、XX、XX、并沉淀了相关文档 ，在社区与大家分享。

大家要注意，职责中的量化数据，可以让自己的工作更具体、更形象，也更有说服力。

项目二：xx旅行

其实看这个项目的介绍，也像是个人做的 demo。我们还是基于这个项目，再来介绍一种项目介绍方式。

• xx旅行

项目简介：xx旅行是一款基于微信云开发模式的城市旅游小程序，包括景点浏览、预定、支付、评价等功能，并且配有一个后台管理系统。

主要职责

1. 使用微信小程序云开发工具，从0到1完成了小程序的开发，实现了用户注册、登录、浏览、预定、支付、评价等核心功能。


2. 利用Vue框架搭建前端页面，并使用 Koa2 搭建后台管理系统，实现了对景点信息、订单信息、评价信息等的管理和统计。


3. 对小程序的性能进行了优化，提高了小程序界面响应速度和加载速度，缩短了用户等待时间。


4. 借助微信云函数，实现了客户端和服务端之间的交互，提高了小程序的稳定性和可靠性。


5. 配置小程序的各种环境变量，例如AppID、密钥等，成功将小程序发布上线。

项目成果

1. 完成的小程序共计有 15个页面，为 xx 位用户提供了景点介绍服务。


2. 对小程序进行的性能优化，平均响应时间由原来的 2s 降低至 500ms，提高了小程序流畅度和稳定性。


3. 在后台的开发中，广泛应用 Vue 框架和 ElementUI 组件库，提高了代码的可读性和可维护性。

可以看到从项目简介、主要职责和项目成果三个方面对项目进行介绍，结构清晰，内容也很丰富。

张同学还有几个项目，就不再这儿一一列举了。

最后

相信看到了这儿的同学，都有不少收获，修改简历的技能又有所增长，仿佛知道了怎么去做简历的优化。

如果有的同学还要抱怨，“道理我都懂，但我怎么还是改不好自己的简历？”，那么推荐这样的同学报名我们的辅导服务，大厂导师一对一辅导，绝对物超所值。

掌趣科技作为国内老牌游戏上市公司，按道理应该是不错的，然而拿到了他家的 Offer 之后，却感觉套路满满，非常失望！不知道，大家是否有类似的经历？

1.Offer 展示

2.面试题真题

问项目：

讲讲你最好的一个项目怎么实现的 ？

问八股：

1. JVM 的执行流程？


2. JVM 是怎么找到一个类的？


3. JVM 的内存布局？


4. Java 虚拟机是怎么进行垃圾回收的？


5. Java 有可能产生内存泄漏吗，举例？ 内存泄露会导致什么问题？


6. GC 的过程， 内存是怎么分配的， 是一片一片的使用呢， 还是一大块的使用？ 还是想 C/C++ 那样零散的内存呢？怎么解决内存碎片问题？


7. Java 中你都用过什么容器？HashMap 和 HashTable 的区别？ConcurrentHashMap 怎么保证线程安全问题的？


8. 你用过 Java 的多线程锁吗？ReentrantLock 和 Synchronized 的区别？你了解什么是悲观锁？什么是乐观锁吗？


9. Java 是怎么实现多态的？ Java 中能多继承吗？ Java 中的注解怎么实现的？


10. Java 虚拟机是怎么找到一个方法，一个类，怎么根据注解找到对应的方法


11. Java 中反射的作用，反射怎么实现的？


12. 反射可以实现注解吗？


13. 你了解自动拆箱装箱吗？ 拆箱装箱怎么实现的？


14. 项目中有碰见过死锁的问题吗？ 什么是死锁？ 只锁一个对象会产生死锁吗？


15. Netty 用过吗？了解过吗？


16. MySQL 有几种索引？ 按字段特性分，按物理存储分呢？ 索引底层有几种实现呢？ MySQL 的有哪几种存储引擎？ InnoDB 和 MyISAM 有什么区别？有什么优缺点？


17. 做一个查询操作的时候，使用哪种索引？


18. 什么叫回表查询？ 如果没有创建主键，怎么进行回表查询？


19. 什么叫索引覆盖？


20. 一个表是索引越多越好，还是越少越好？


21. 你了解什么叫表锁？什么叫行锁吗？什么情况下使用行锁？什么情况下使用表锁？


22. 如果一个表的写操作比较多，是加行锁比较好，还是加表锁比较好？


23. 你能说一下事务的隔离级别吗？


24. Redis 数据库怎么是实现持久化的 ？Redis 里边都有哪些数据类型？ ZSet 怎么用？


25. 什么是缓存雪崩、缓存击穿、缓存穿透，分别怎么解决？


26. 做过 Java 的网络编程吗？给我说一下 Socket 套接字的创建流程？


27. 讲一讲三次握手，四次挥手的流程？TCP 和 UDP 的区别？


28. 使用 UDP 来传输数据，怎么来保证他的可靠性，就像你刚刚说的后发先至问题？

PS：面试问的还挺细的，但因为做足了准备，所以这些面试题基本都拿下了。

以上问题来自学员的整理，在此感谢。

3.套路来了

拿到 Offer 本来是件开心的事，然而当聊完入职事项之后，整个人就不好了，来看看具体的经过吧：

问题1：正式工作变实习？

秋招明明投递的是正式工作，然而拿到 Offer 之后，HR 却必须先让去实习 5 个月。

投递详情如下：

明确是秋招正式岗位，而非实习。

正常的逻辑应该是拿到 Offer 之后，等明年毕业之后先去公司报道，只有 3 个月试用期，试用期没问题就转为正式员工了。

问题2：实习薪资

实习也是按照实习的工资，而非正式工资的 80% 发放的。

问题3：可能不通过&不谈正式薪资

HR 说明年四月实习期过了之后，再谈正式薪资，言外之意，如果实习期没过，那就不要你了，也就不用谈薪资了。那么请问，投递正式岗位又有什么意义呢？

问题4：实习时间超长

通常实习时间也就是 2-3 个月，而掌趣要求 11 月中旬去实习，至少实习到明年 4 月份，这个实习的时间未免要太长了。

小结

作为国内老牌上市公司，竟然以找正式工作的幌子把入选人悄悄转为实习生，这件事对有经验的人来说，一眼就知道怎么回事，然而对于涉世未深，刚步入社会的年轻人来说，却是满满的套路，还未感受生活的美好，就经历了人心的险恶。

人在做天在看，希望某些公司不要有这样的骚操作，招实习就是招实习，招正式员工就是招正式员工，不要混为一谈，更不要暗箱操作，更不要欺负那些涉世未深的年轻人。

首先说下，目前，我的表哥自己开一家小的背调公司，所以我在跟他的平时交流中，了解到了背调这个行业的一些信息。

今天跟大家分享出来，给大家在求职路上避避坑。

上周的某天，以前的阿里同事小李跟我说，历经两个月的面试，终于拿到了开水团的offer。我心里由衷地替他高兴，赶紧恭喜了他，现在这年头，大厂的offer没这么好拿的。

又过了两周，小张沮丧地跟我说，这家公司是先发offer后背调，结果背调之后，offer GG了，公司HR没有告知他具体原因，只是委婉地说有缘自会再相见。（手动狗头）

我听了，惋惜之余有些惊讶，问了他具体情况。

原来，小李并没有在学历上作假，也没有做合并或隐藏工作经历的事。

他犯错的点是，由于在上家公司，他跟他老板的关系不好，所以他在背调让填写上级领导信息的时候，只写了上级领导的名字，电话留的是他一个同事的。

我听后惋惜地一拍脑门儿，说：“你这么做之前，怎么也不问我一下啊？第三方背调公司进行手机号和姓名核实，都是走系统的，秒出结果。而且，这种手机号的机主姓名造假，背调结果是亮红灯的，必挂。”

小李听后，也是悔得肠子都青了，没办法，只能重新来过了。

我以前招人的时候，遇到过一次这样的情况，当时有个候选人面试通过，发起背调流程。一周后，公司HR给了我一份该候选人背调结果的pdf，上面写着：

“候选人背调信息上提供，原公司上级为郭xx，但经查手机号主为王xx，且候选人原公司并无此人。”

背调结果，红灯，不通过。

基本面

学历信息肯定不能造假，这个大家应该都清楚，学信网不是吃素的，秒出结果。

最近两份工作的入离职时间不要出问题，这个但凡是第三方背调，近两份工作是必查项，而且无论是明察还是暗访，都会查得非常仔细，很难钻空子的。

再有就是刚才说的，手机号和人名要对上，而且这个人确实是在这家公司任职的。

大家耳熟能详的大厂最好查，背调公司都有人才数据库的，而且圈子里的人也好找。再有就是，随便找个内部员工，大厂的组织结构在内部通讯软件里都能看到的。

小厂难度大一些，如果人才数据库没有的话，背调员会从网上找公司电话，然后打给前台，让前台帮忙找人。但有的前台听了会直接挂断电话。

薪资方面，不要瞒报，一般背调公司会让你打印最近半年或一年的流水，以及纳税信息。

直接上级

这应该也是大家最关心的问题之一。

马云曾经说过：离职无非两种原因，钱没给够，心委屈了。而心委屈了，绝大多数都跟自己的直接上级有关。

如果在背调的时候，担心由于自己跟直接上级关系不好，从而导致背调结果不利的话，可以尝试以下三种方式。

第一，如果你在公司里历经了好几任领导的话，可以留关系最好的那任领导的联系方式，这个是在规则允许范围内的。

第二，如果你的直接上级只是一个小组长，而你跟大领导（类似于部门负责人）关系还可以的话，可以跟大领导沟通一下，然后背调留他的信息。像这个，一般背调公司不会深究的。

就像我的那个表哥，背调公司的老板所说的：“如果一个腾讯员工，马化腾都出来给他做背调了，那我们还能说什么呢？”

第三，如果前两点走不通的话，还可以坦诚地跟HR沟通一次，说明跟上级之间确实存在一些问题，原因是什么什么。

比如：我朋友遇到了这种情况，公司由于经营不善而裁员，老板竟然无耻地威胁我朋友，如果要N+1赔偿的话，背调就不会配合。

如果你确实不是责任方的话，一般HR也能理解。毕竟都是打工人，何苦相互为难呢。

你还可以这么加上一句：“我之前工作过的公司，您背调哪家都可以，我的口碑都很好的，唯独这家有些问题。”

btw：还有一些朋友，背调的时候留平级同事的真实电话和姓名，用来冒充领导，这个是有风险的。但是遇到背调不仔细的公司，也能通过。通过概率的话，一半一半吧。

就像我那个朋友所说：“现在人力成本不便宜，如果公司想盈利的话，我的背调员一天得完成5个背调，平均不到两个小时一个。你总不能希望他们个个都是名侦探柯南吧。”

信用与诉讼

一般来讲，背调的标准套餐还包括如下内容：金融违规、商业利益冲突、个人信用风险和有限民事诉讼。其中后两个大家尽量规避。

个人信用风险包括：网贷/逾期风险、反欺诈名单和欠税报告。

网贷这块，当时我有一个同事，2021年的时候，拿了4个offer，结果不明不白地都挂在了背调上，弄得他很懵逼。

当他问这三家公司HR原因的时候，HR都告诉他不便透露。

最后，他动用身边人脉，才联系上一家公司的HR出来吃饭，HR跟他说：“以后网贷不要逾期，尤其是不同来源的网贷多次逾期。”

同事听了，这才恍然大悟。

欠税这个，就更别说了，呵呵，大家都懂，千万别心存侥幸。

再说说劳动仲裁和民事诉讼。

现在有些朋友确实法律意识比较强，受到不公正待遇了，第一想法就是“我要去仲裁”，仲裁不满意了，就去打官司。

首先我要说的是，劳动仲裁是查不到的，所以尽量在这一步谈拢解决。

但民事诉讼在网上都是公开的，而且第三方背调公司也是走系统的，一查一个准儿。如果非必要的话，尽量不要跟公司闹到这一步。

如果真遇到垃圾公司或公司里的垃圾人，第一个想法应该是远离，不要让他们往你身上倒垃圾。

尤其是你主动跟公司打官司这种，索要个加班费、年终奖什么的，难免会让新公司产生顾虑，会不会我offer的这名候选人，以后也会有对簿公堂的一天。

结语

现在这大市场行情，求职不易，遇到入职前背调更是如履薄冰，希望大家都能妥善处理好，一定要避免节外生枝的情况发生，不要在距离成功一米的距离倒下。

最后，祝大家工作顺利，纵情向前，人人都能拿到自己满意的offer，开开心心地入职。

国庆前开始陆续随便投了一点公司试了下行情，确实不很乐观，但是当时还没有特别强烈的感觉。

目前这国庆之后再投了几天的感受特别强烈，就是基本凉凉的节奏。

目前感受下来，招人的公司有限，上海这边就字节、PDD、美团、小红书、得物这些在大量招人，在招聘平台脉脉、拉勾、BOSS上基本上也是这些有反馈，另外猎头基本上推的也就是得物、字节这些公司，大部分都是得物。

总结下来的情况就是，要么就是一线大厂在招人，要么就是在这个经济不好的情况下业务做得好的、没什么影响的在招人，比如得物了。

朋友问了一圈，一些公司有HC，但是在招聘平台上都是没有声音的。

华为朋友告诉我这个学历只能去OD，985都在干OD。

字节告诉我卷死来，心脏和字节只能有一个跳动。

腾讯有少量HC，但是也是一直在裁员，很不稳定，米哈游也一样。

饿了么还有一些HC，但是也是在一边裁员，一边有些部门有少量HC。

SAP目前没HC，也是裁员。

联想也没有HC，早就没了。

携程和一些其他的小一点的公司，还有一些HC，一线开发，但是好像薪资不是很高的样子，没有细问了。

诸如此类。。。

还有一些小点的公司，去年还在招人，问我要不要过去，今年普遍都在裁员，没有HC了。

还有一些在家办公的在招人，这个你懂的，但是也非常的卷。

大致情况市场就是这样，要么去卷，要么失业的节奏。

想找钱多活少的，目前看起来是非常不现实了，甚至于想找个工作都非常困难。

听说大厂现在都要卡学历、业务、大厂经历，三高匹配至少两项。

总体来看，暂时没有什么好的出路，还在继续看。。。

有好公司欢迎拉我入坑。。。

就这样。

这几天搜索我的聊天记录，无意中看到了一个两年前的聊天消息。那是和我讨论出海业务的独立开发网友，后来又去创业的业界精英。顺手一搜，当初他在我的一个开发者群也是高度活跃的人群之一，还经常私下给我提建议，人能力很强，做出海矩阵方向的项目做的很拿手。但是在后来忽然就没消息了，虽然人还留在群里。

我好奇点开了他的朋友圈，才知道他已经不做独立开发了，而且也（暂时）不在 IT 圈里玩了，去帮亲戚家的服装批发业务打打下手，说是下手，应该也是二当家级别了，钱不少，也相对安稳。朋友圈的画风以前是IT行业动态，出海资讯现在是销售文案和二维码。

和他私下聊了几句，他跟我说他现在过的也还好，人生路还长着呢，谈起了自己在现在这行做事情的经历，碎碎念说了不少有趣的事情，最后还和我感慨说：“转行后感觉脑子灵活了很多”，我说那你写程序的时候脑子不灵活吗，他发了个尴尬而不失礼貌的表情，“我以前技术搞多了，有时候死脑筋。”

这种话我没少听过，但是从一个认识（虽然是网友）而且大跨度转行的朋友这里说出来，就显得特别有说服力。尤其了解了他的经历后，想写篇文章唠叨下关于程序员短板的问题，还有这种短板不去补强，会怎么一步步让路越走越窄的。

现在离职（或者被离职）的程序员越来越多了，程序员群体，尤其是客户端程序员这个群体，只要能力过得去，都有全栈化和业务全面化的潜力。尤其是客户端程序员，就算是在公司上班时，业余时间写写个人项目，发到网上，每个月赚个四到五位数的副业收入也是可以的。

再加上在公司里遇到的各种各样的窝囊事，受了无数次“煞笔领导”的窝囊气，这会让一些程序员产生一种想法，我要不是业余时间不够，不然全职做个项目不就起飞了？

知道缺陷在哪儿，才能扬长避短，所以我想复盘一下，程序员创业，在主观问题上存在哪些短板。（因为说的是总体情况，也请别对号入座）

第一，认死理。

和代码，协议，文档打交道多了，不管自己情愿不情愿，人多多少少就有很强的“契约概念”，代码的世界条理清晰，因果分明，1就是1，0就是0，在这样的世界里呆多了，你要说思维方式不被改变，那是不可能的 --- 而且总的来说，这种塑造其实是好事情。要不然也不会有那么多家长想孩子从小学编程了。（当然了，家长只是想孩子学编程，不是做程序员。）

常年埋头程序的结果，很容易让技术人对于社会上很多问题的复杂性本质认识不到位，恐惧，轻视，或者视而不见，总之，喜欢用自己常年打磨的逻辑能力做一个推理，然后下一个简单的结论。用毛爷爷的话说，是犯了形而上的毛病。

例如，在处理iOS产品上架合规性一类问题时，这种毛病暴露的就特别明显。

比如说相信一个功能别的产品也是这么做的，也能通过审核，那自己照着做也能通过。但是他忽略了这种判断背后的条件是，你的账号和别的账号在苹果眼里分量也许不同的，而苹果是不会把这件事写在文档上的。

如果只是说一说不要紧，最怕的是“倔”，要不怎么说是“认死理”呢。

第二，喜欢拿技术套市场。

​这个怎么理解呢，就是有追求的技术人喜欢研究一些很强的技术，但是研究出来后怎么用，也就是落实到具体的应用场景，就很缺点想象力了。

举个身边有意思的例子，有个技术朋友花了三年时间业余时间断断续续的写，用 OpenGL 写了一套动画效果很棒的 UI 引擎，可以套一个 View 进去后定制各种酷炫的动画效果。做出来后也不知道用来干嘛好，后来认识了一个创业老板，老板一看你这个效果真不错啊，你这引擎多少钱我买了，朋友也没什么概念，说那要不五万卖你。老板直接钱就打过去了。后来老板拿给手下的程序员维护，用这套东西做了好几个“小而美”定位的效率工具，简单配置下就有酷炫的按钮动画效果，配合高级的视觉设计逼格拉满，收入怎么样我没问，但是苹果在好几个国家都上过推荐。

可能有人要说，那这个程序员哥哥没有UI帮忙啊，对，是这个理，但是最根本的问题是，做小而美工具这条路线，他想都没想到，连意识都意识不到的赚钱机会，怎么可能把握呢？有没有UI帮忙那是实现层的门槛而已。

第三，不擅长合作。

为什么很多创业赚到小钱（马化腾，李彦宏这些赚大钱就不说了，对我们大部分人没有参考价值）而且稳定活下来的都是跑商务，做营销出身的老板。

他们会搞钱。

他们会搞钱，是​因为他们会搞定人，投资人，合伙人，还有各种七七八八的资源渠道。

大部分人，在创业路上直接卡死在这条路线上了。

投资人需要跑，合作渠道需要拉，包括当地的税务减免优惠，创业公司激励奖金，都需要和各种人打交道才能拿下来。

那我出海总行了吧，出海就不用那么麻烦了吧。不好意思，出海的合作优势也是领先的，找海外的自媒体渠道合作，给产品提曝光。坚持给苹果写推荐信，让自家产品多上推荐。你要擅长做这些，就不说比同行强一大截，起码做出好产品后创业活下来的希望要高出不少，还有很多信息差方法论，需要进圈子才知道。

​

--- 

我说的这些，不是贬损也不是中伤，说白了，任何职业都有自己的短板，也就是我们说的职业病，本来也不是什么大不了的事情。只是我们在大公司拧螺丝的时候，被保护的太好了。

只是创业会让一个人的短处不断放大，那是因为你必须为自己的选择负责了，没人帮你擦屁股了背锅了。所以短板才显得那么刺眼。

最后说一下，不是说有短板就会失败，谁没点短处呢。写出来只是让自己和朋友有更好的自我认知，明白自己的长处在哪，短处在哪。

最后补一个，左耳朵耗子的事情告诉我们，程序员真的要保养身子，拼到最后其实还是拼身体，活下来才有输出。

😰服了，随便起的标题也太擦边了🙈（肯定是我的工作伙伴带坏了我~）

在阿里和京东，会把人才分为“L 型人才”和“T型人才”，其实这个很容易理解，L型 —— 先保证技术深度再保证技术宽度；T型 —— 先保证技术宽度再保证技术深度 。恰好本人对于这个问题也没有明确的答案，所以在这里想跟大家讨论一下：对于一个职业生涯初期的程序猿来说，在职业生涯初期应该以技术宽度为重还是以技术深度为重？

前辈的看法

先po一下几位前辈的观点。

一位掘金朋友的意见：

单向发展局限性比较大，不管是做技术管理还是技术专家，都需要一定的广度，但是这个广度我觉得是建立在已经有深度的基础上，单纯为了扩展广度而去学很多基础的东西，意义不大，毕竟不是为了做外包，所以还是看你处于哪个阶段的瓶颈期吧，如果是1-3年，可能花时间搞清楚原理性的东西带来价值更大，而如果是3-5年，应该是要培养考虑问题的思维能力上吧，这是我的个人看法~

一位字节大佬的意见：

突然发现，前端好像没几个做到 CTO 的……仔细想想，国内的前端界比较出名的前端出身做到很高职位的，玉伯算是一个代表，后期他基本上已经成为一个产品设计方面的负责人了，脱离了单纯前端的范畴。而普遍对于前端天花板的看法都差不多，确实是认为有后端工程背景的人升为 VP/CTO 级别的概率比较高，而前端更倾向于在框架中日复一日的迷失。而整体来说，后端天花板的高度普遍远远高于前端天花板的高度。

职业背景

本人是处在一个制造业公司的前端开发（也是唯一一个前端），公司主要技术栈为sql，公司主要通过sql解决公司业务问题，公司有雇佣外包公司（可以理解为公司大部分业务通过外包实现，公司没有固定的IT产品，也理所当然的没有技术支持，每个人能实现日常业务即可，因此可能对于个人的技术深度发展帮助有限？），其实公司对于职业定位真的区分不大，推崇的理念是你能干活即可，因此对于业务没有特定的划分，因此虽然我是前端，但是我也能碰后端（java）、sql、运维（部署）的活。

我的看法

刚想搜一下资讯，结果就看到了这个沸点。

😅在一个内卷如此严重、形势如此悲惨的状况下，还真的有必要去思考选择走哪条路吗？

我的看法是，其实无论是选择技术宽度还是选择技术深度，如果真的不知道选择什么，与其迷茫停止前进不如跟着环境走？我相信只要持续学习，学到的终归是自己的，到最后肯定是会有所收获的💪。至于怎么选择，好像得以后考虑了...

👀最后

其实这个问题我真的没有答案，如果有大佬有其他看法，希望能为我答疑解惑吧😭

唉，感觉我这个中年程序员叹一口气，都散发着浓郁苦咖啡蒸气的味道。

最近身体有些失调，拉肚子、口臭、眼屎、长痘、口角炎、尿黄、腰疼，哪儿哪儿都不好。在城市里生活，即便一点辣都不碰，依然火气很大，烦躁得很。

国庆假期回了趟老家，天天不忌口，这些问题却奇迹般地消失了。一回来，又反复了。我感觉是喝的水有问题，以至于换了一套净水器的滤芯。结果，商家还少发了配件，没法安装。

烦啊，莫名地烦躁。在老家时，种了2天的地。遇到邻地的村民和父母起了纷争，他说他家的地少了。刚分地时，我家是8米，他家是6米，现在两家各是7米。他不但抢占，还说他家的本来就比我家多。父母都是老实人，我也早读诗书，少小离家，我们都整不了无赖。农村土地管理很乱，没有记录，谁横谁有理，官方也无奈。我倍感无力。

回到城里后，越想越憋屈，又想起他的一句话，他反复朝我说“你给评评理”。我突然意识到，他这是示威，就算儿子回来了，也拿他没辙。突然感觉，人家的城府之深、心机之重，已经渗入骨髓，可随机挥发，而我久久才能参透。自责之感，愈发严重。

久对代码，我不擅长与人有关的一切社会事务。处理事情，害怕冲突，多秉持儒家的“温良恭让”，长久以来都是如此，家风亦然。此事，媳妇诟病久矣，因在底层社会，高道德意味着低资源。

几日借酒浇愁，思考破圈之事，悬而又悬，心慌不已。这日酒多，遂向媳妇诉说心中之不悦。我有红线，不同媳妇讲烦闷之事，因每次皆生矛盾。这日破戒，也未出所料。媳妇说，不是我说你，你就是xxx。你每次都xxx。你看人家xxx，你为什么就不能xxx。

我可精准预测她下一句会说什么。我本内心愧疚求安慰，她却常让这份自责升级到自裁的境地。我遂低头不语，后悔破戒。媳妇眼泪噼啪掉落：你每次都这样，是你找我谈心，我在这里噼里啪啦说个不停，你却跟个闷葫芦一样，连个回应也没有。

我连忙去哄，赶紧说上几句话，她却像一条掉到岸上的大鲤鱼，一碰就扑棱。随后，一周没有好脸色。

我又深深地叹了一口气，暗誓以后绝不再谈。同时，心里挤下一滴泪，孤独之感，油然而生，此事更与何人说。

拖着身体去上班，职场万象，意也难平。5分钟随手就能干完的事情，需要讨论半天要不要干，再辩论1天该谁去干，然后再进行1周的技术调研，干多久再排期。浪费或低效，与我无关，但我长期在这种环境下，我该变成一个什么样的人呢？与众不同会被压制，同流虽能发达但心有不甘。

写文已久，稍有风格，也出过多篇10W+的技术文，约有十几名出版社编辑，询问我是否想出书。遂又开始精神内耗。写书是好事，但必定要投入大量精力，而后续是否能出版，能否赚回机会成本，都未可知。

父母慢慢年迈，小儿正在成长，自己身体愈乏，依然没有找到事业的方向。与同行交流，各家中小型互联网公司，多在萎靡。大厂咱又进不去。

奋斗是终生的事情，但留给自己奋斗的黄金时间不多了。这时间该怎么用？把宝押到哪里，这又是难题。

目前看，啥也不多想，仅仅上班，生活不成问题，也没有烦心事。但是，以后呢？我也分不清这是内卷，还是内耗。只是隐约感觉，以后会越来越难，老的、小的都会越来越依靠自己，而自己还不够强大。

有句古话叫：比上不足，比下有余。此理论可以判我个“身在福中，无病呻吟”或者“安于现状，不够努力”。

抖音上看到一句话，史铁生说的，大意是：我四肢健全时，常抱怨环境不好。瘫痪后，开始怀念可以行走的日子。长了褥疮，怀念坐在轮椅上。后来得了尿毒症，又怀念当初长褥疮。

他没有和撕葱去比，而是和以前的自己对比。

作为互联网最炙手可热的优质岗位，产品经理以其“门槛低”、“工资高“的就业优势深受职场新人青睐，招聘需求榜常年稳居Top3，随着压力和内卷与日俱增，从业多年的产品经理陆续呈现出走的迹象，或自主创业，或退居二线……

选择，各有不同；生活，依旧精彩。本期，小摹采访了6位从事新领域的产品经理，一起谈谈转行，这或许也是你以后的故事。

@ 忧桑的大叔

工龄：10年

曾任职位：P2P产品专家

当前职位：某银行项目负责人

转行原因：前几年的P2P真的太香了，年终分红都有20W+，但风口来的快走的也快，公司2年没有拿到新一轮融资，现金流非常紧，自己也快40了，时间和精力拼不过年轻人，一直在寻找新的机会，好在之前和不少银行都有合作，深得对方领导赏识，经猎头介绍进入国企银行做起了项目管理，工作环境轻松，薪资待遇非常满意。

@ 有妖气

工龄：8年

曾任职位：上市公司产品总监

当前职位：创业公司CEO

转行原因：部门沟通时发现新的产品机遇并在内部有了雏形，可惜高层并不愿意投入成本，为了不让这款产品被扼杀在摇篮里，最终鼓起勇气离职创业，第一年真的非常坎坷，年初招了20个人，10月份不到走了20个，所幸投资人给予足够的资源、现金支持，推荐了技术、运营类的人才，目前已经是30人的成熟团队，虽然离商业变现还很长，但我相信我们能度过这个资本寒冬。

@ 小田阿姨

工龄：6年

曾任职位：CRM系统产品经理

当前职位：客服主管

转行原因：元旦的时候有了意外惊喜，10月怀胎有了小虎崽，我琢磨着互联网行业的加班时间太长，很难能有时间陪陪孩子，所以连续2次和COO提了离职，打算找个加班不多的公司上班。出乎意料，COO将我调任到客服部门担任主管一职，这个岗位和我的契合度很高，加之产品本身是自己设计的，不存在多余的学习成本，就选择继续呆在这里。

@ 写书的海哥

工龄：5年

曾任职位：BAT产品经理

当前职位：自由作家

转行原因：抓住了偶然的机会，有属于自己的公众号，每周三、五会更新推文，分享产品设计的方法和经验，也会鉴赏优质作品的亮点，2年下来累计了3W的粉丝，国庆的时候有个出版商邀请我把5年的经验沉淀一本书，供更多的产品经理学习，也是一个发展副业的机会，看时间很充裕就答应了下来，没成想赶上了双11，一边设计一边写作的压力很大，睡眠时间不足3小时，但已经喜欢上了写书这个过程，拿到年终奖后选择了离职，转行自由作家，现在能更舒服地做自己喜欢的事情。

@ 蒲公英有话说

工龄：3年

曾任职位：某修图公司产品经理

当前职位：网络主播

转行原因：兴趣爱好使然，在美学公司上班，擅长修图、拍照，平常也喜欢在社交平台分享生活记录。这几年公司扩展了直播带货的业务，有一次外聘的主播身体不舒服，出于对自己的颜值和气质的自信，主动客串了一波，讲解过程中发现自己对商品的理解远比主播更加深入，开始去不同的直播间露脸，收入慢慢多起来，半年后就专职做起了主播，打算先吃几年的青春饭，好好搞钱再重新规划自己。

@ 赵三岁

工龄：2年

曾任职位：游戏公司产品经理

当前职位：某五线城市公务员

转行原因：这几年版权号、政策收缩，游戏行业受到了很大的波及，隔壁的项目线直接被叫停，20多号人当天就被裁，那种恐惧深有体会，几番思考，我觉得既然是打工人，那还是找个稳定一些的工作更加靠谱，每天被裁员的环境而支配，真的不是我想要的，想着考公，家里人也在城里托了些关系，翻年后就回老家当起了公务员，朝九晚五，无KPI考核，每天都能睡好觉，这在以前根本不敢想。

在小摹看来，是蝴蝶总会遇到春天，而机会偏爱有准备的头脑，即使投身新行业，产品经理也并有没因岗位不同而从零开始，反而顺风顺水，扶摇直上。究其原因，无外乎是PM的规划、执行、沟通、管理等核心竞争力适用于绝大多数领域，能够高效帮助企业解决问题，实现自身价值，转行也有足够的底气。所以，产品经理只有不断加强核心竞争力，才能在工作中出类拔萃，获得彼此满意的薪资待遇。

精力管理就好比是计算机的内存清理，你以为关掉一些程序就行了，结果你还是卡成翔。

我的现状

雷猴啊，我是一个临期程序员。打过几年工，被好几个同事问过我为什么精力这么旺盛。

这两年我大多数情况都是早上8点前就到公司*（原本9点上班，后来调成8点半，晚上要是加班就可以多赚半小时了）*，属于工贼类型。

晚上回到家还有精力打游戏、看书、学习。

为什么要提升精力

几年前我还是一只前端程序猿，当时刚从 JQuery 转 Vue 1.0，学完 Vue 1.0 发现公司的新项目开始用 Vue 2.0 ，和外部对接的项目是用 react 。那段时间真的有点疲于奔命的感觉，很累。一天到晚都想睡觉。睡多了又容易头晕。

逛技术论坛时发现有些大佬真的能精通前端三大框架，写出很多原理类的文章。真让人羡慕~~(生气)~~啊。

我开始怀疑是不是我的精力出现了问题。之后尝试过借助外物的帮助，比如每天靠喝咖啡续命，吃维生素提升精力之类的方法。

但这样会进入一个死循环：

喝完咖啡可能睡不着 -> 睡不着可能就会玩手机 -> 玩手机会越玩越晚 -> 导致第二天起不到床 -> 起不到床又怕会扣工资，然后强行起床 -> 上班没精神，然后喝咖啡续命  -> ......

要破掉这个死循环，就要提升自己的精力。

前期准备

世界上是存在拥有 少眠基因 的人，他们每天可能睡4～5个小时就元气满满的。听说只有1%的人拥有这种基因（羡慕了），但我大概率不属于这类人。我的精力是锻炼出来的。

我可是受过专业训练的！

我是一个执行力很弱的人，为了让自己精力旺盛点，我就画真金白银去买课来学。买了不学就亏大了。

这是课程里给出的金字塔模型。完完全全跟着课程去做应该会变得很强。

但实在太难了，即使是第一层我也不能100%按照课程所说的去做（我实在做不到啊啊啊啊）。

举个例子，课程里讲到如果你是右撇子，那早上刷牙的时候就可以用左手刷牙。我试了，左手力量控制不好，出来的结果是一嘴血。

再举个例子，课程里建议早上刷牙的时候试试单脚站着刷牙。我试了，平衡力不好，呛了口牙膏（吞肚子里了）。

由此可见，不是所有方法都适合我。

我的做法

吃了几次亏，我觉得我还是选择性训练算了。如果完完全全跟着课程做能拿100分的话，那我的目标就定在30分好了。

只要大方向没错，我总会有提升的。

大方向是啥？就是课程目录。

• 运动


• 吃


• 睡


• 情绪

在每章中调几项自己能做到的，拿张纸出来列份清单每天跟着做，假以时日～嘿嘿嘿～

运动

运动能带来什么好处我就不啰嗦了（因为我不懂其中的原理）。

先说运动，从最简单的运动做起。

1个俯卧撑

如果你和我说，长跑有很多好处，可以减肥，可以产生内啡肽，获得哔哩吧啦一大堆好处。那我可以坚持1天。

但课程用了一个很巧妙的方式让学员坚持锻炼，就是每天只做1个俯卧撑。

这招真的灵。每天只做1个，这是很容易做到的，完全没有心理负担。

而且，都趴下了，真的只做1个吗？

就这样，我每天都抱着只做1个俯卧撑的心态开启了我的训练。因为没心理负担，所以很容易就坚持下去了，同时每天都给自己带来一个积极的心理暗示：我完成了我承诺的事。

间歇训练

大部分程序员工友的工作应该都是比较忙的，要每天抽一段完整时间出来运动的可能性不大。但如果能在碎片时间里稍微动一动对自己还是有好处的。

举个例子，我在公司开会的时候我不会一直坐着，我主要是站着为主。有时候还会偷偷提纲(就是你理解的那个提纲😎)。我见有些工友还买了电脑升降架，这也是不错的招式。

再来点例子，刚睡醒的时候搓脸、伸懒腰，这些需要动的操作我都归到运动里面。

日常通勤我也改成 公交地铁 + 骑共享单车，早上上班是公交或者地铁，这样不会那么容易出汗，回到公司就不会一身臭汗味。晚上下班我会选择骑共享单车，这肯定算是正式运动了，尤其是早期的共享单车骑起来真的累。

吃

课程介绍到，吃饭不要吃太饱，尽量少吃高油高糖高碳水的食物。

但作为广东人，要我戒口？真的很难！

我做不到天天保持健康饮食，但工作日我还是会尽量克制。尤其是工作日的午餐，会直接影响你下午的状态。

如果中午吃太饱，吃过多高碳水化合物（比如米饭、面条等）下午就很容易困，饭气攻心嘛。

引用课程的内容：

因为高碳水化合物的食物都容易变成糖，让血糖快速升高，从而导致胰岛素快速分泌，引发色氨酸进入大脑。

色氨酸是合成褪黑素的重要原料，褪黑素越多人就越困。

那么，如果我们想快点入睡的话是不是可以在睡前多吃米饭呢？我不建议，这样睡觉太难受了～

回归正题，应该怎么吃，可以从以下几个方面着手：

1. 少吃多餐：不让血糖那么容易大起大落。


2. 多吃低糖高营养食物：首选绿叶蔬菜，然后再到优质蛋白，最后才是高碳水化合物食物。


3. 多喝水。

少吃多餐

第1点的意思两餐之间的间隔时间不要太长，不然血糖容易大起大落，这样更容易累。

除了早中晚三餐，还可以加上午茶和下午茶。

上午茶和下午茶指的不是奶茶，是指可以吃一些坚果、水果（蓝莓草莓之类的水果）。

早餐可以吃一些高纤维高蛋白食物。

午餐建议吃多点蔬菜，肉类尽量选高质量的蛋白质，比如鸡肉鱼肉。

晚餐的话可以吃点碳水化合物，稍微提高一点血糖，促进晚上睡眠。

多吃素菜，少吃碳水化合物

图片来自课程。

睡

高质量睡眠是恢复精力的关键，这里说的并不是要睡很长时间才是高质量睡眠，是要睡得好才行。

怎样才能睡得好呢？什么褪黑素、深睡、浅睡、快速动眼期这些概念我就不介绍了。主要讲讲我的做法。

睡前不要玩手机

睡前不要玩手机。这句话有2个关键点：

1. 睡前


2. 不要玩手机

“睡前”是指多长时间呢？最好是1小时。

我手机的常用软件主要是：微信、企微、微信读书、电话、地图。

我不喜欢玩手游，也不喜欢上微博（连微博都没安装），所以我睡前很容易做到不碰手机。

听说有些工友喜欢睡前在床上打打游戏看看小说，这可能不是好习惯。

如果你实在坚持不了睡前1小时不玩手机，那可以试试睡前半小时不玩，再不行就缩减到10分钟。

还是用回运动篇提到的方法，前期先用最容易实现的标准，坚持一段时间。比如坚持半个月睡前10分钟不碰手机。之后再慢慢加长这个时间。

“不要玩手机”指的是不要在睡前有过多的娱乐项目。比如打游戏、看小说、听激昂音乐等。

冥想

冥想听上去很玄学的感觉。其实我也不知道有没有用，我只是照做了而已。

我所做的冥想仍然是低配版。我上过正念冥想课，确实学到很多冥想的方法，比如如何呼吸、如何思考。

但在睡前我不想搞得那么复杂（怕太复杂自己处理不来，直接睡死过去😄），睡前我只做观察呼吸这件事。

选择一个舒适的姿势躺在床上，合上眼睛，鼻子呼气时心里就想着“呼气”，鼻子吸气时心里就想着“吸气”。

这样做会确实让我平静了很多，不知不觉就睡着了。

我不清楚冥想对我的睡眠有多大帮助，但这样做让我舒服。

情绪

情绪会影响人的健康，同样会影响人的精力。

这里我需要引用一下课程里提到的3条关于情绪的定律：

1. 人的脑子在一个时段只能主要存在一种情绪；


2. 相比正面情绪来说，人脑更容易产生负面情绪；


3. 人可以通过自主的训练来控制情绪。

简单解释一下：

第一条的意思是正常的人在同一时段内，很难开心和惊恐同时存在。

第二条的意思是你赚了100元又失去了100元，其实对于你来说并没什么变化，但你可能会不开心。就是对“损失”比对“获得”更敏感。

第三条的意思好心态是可以训练出来的。

我的做法：

1. 坚持运动。运动能让我变得更积极、更正面。


2. 感恩。每天都想想一直以来遇到过的好事。比如谢谢妈妈带我到这个世上。习惯感恩后，我心态确实变得更平和了，而且也更容易发现别人的优点。


3. 奖励。完成一项任务后给自己小小奖励。

我在“情绪”这个段位不高，能介绍的方法并不多。我的主题是 平和。尽可能朝着这个方向去做。

其他

深呼吸

课程里讲到每天早上起床清醒后可以大喊。

这招我也做不到。在城市生活，放个屁大声点都会被邻居投诉，大叫就更加不可能做到的。

于是我改变了策略：假装自己在大叫。

早上起来这么做确实能更快速清醒，最好在阳台做。

晒太阳

自然光确实比人造光舒服。我的工位比较暗，大白天都要靠灯管照明。工作日午休完我会走去窗边晒晒太阳，让自己清醒一点。

永远年轻，永远发疯。

看到这个知乎问题时，我的思绪纷飞，往事一幕幕闪现在脑海里，等平静下来，内心变得很笃定。

于是，我做了如下的回答：

非常有必要。

1997年，乔布斯刚刚回归苹果不久，在开发者大会上，一名程序员当众质疑乔布斯不懂技术。

乔布斯，你是一个聪明又有影响力的人。但是很遗憾也很明显，很多时候你根本不知道自己在做什么。我希望你能用清楚的语言解释一下 Java 编程语言以及其变种是如何阐述 OpenDoc（开源技文档）内置的一些想法。等你说完以后，你能不能跟我们说一说你自己过去七年都干了些什么？

面对这样犀利的提问，乔布斯平静的喝了一口水，低头沉思了几秒，开口这样回答道：

有时候你能取悦一部分的人，但是当你想要作出改变的时候，最难的是某些事情别人做的是对的。我相信 OpenDoc 肯定有一些功能，没有任何其他东西能做到。我其实也不太懂，我相信你肯定能做一些样品出来，可能是一个小型的 app 来展示它的功能，最难的部分是如何将那些功能塞进更大的愿景里面，例如让你每年一个产品能够卖百八十亿美元。

我经常发现，你得从用户体验出发，倒推用什么技术，你不能从技术出发，然后去想如何才能卖出去。在座的没有人比我犯过更多这样的错误，我也搞到伤痕累累，我知道这就是原因，当我们尝试去为苹果思考战略和愿景，都是从能为用户带来什么巨大利益出发，我们可以给用户带来什么，而不是先找一群工程师，大家坐下来，看看我们有什么吊炸天的技术，然后怎么把它卖出去。

我非常认同乔布斯的话。

程序员有的时候沉迷在自己的世界里，执拗的以为“代码就是全部” 。

但现实并非如此，编码的目的是创造产品或者提供服务，从而在这个商业社会实现更大的价值。

而程序员成长为业务领域专家，能够更加深刻的理解公司的产品或者服务，从而更有优势为公司做出贡献。当个人的贡献上升时，公司的认同和利益也会随之而来。

这个回答一天内得到不少赞同，也是我意想不到的，因为我并不觉得我回答得好，看来很多同学都认可这个观点。

熟悉我的朋友都知道 ，我对技术非常有激情，曾经也认为技术意味着一切。

只是后来，工作中遇到越来越多的挫折，很多好朋友也友善的提醒我，不要太执着于技术，我也越来越认识到自己认知的局限性。

我不断的去读书、听演讲、思考，依稀之间得到一个结论："一个 IT 公司的成功 ，技术固然是重要的一环，而公司的产品、用户人群、经营模式是另一个我很少关注且非常重要的维度"。

偶然间我看了乔布斯的一个视频，视频的两句话让我醍醐灌顶。

• 
  

  我相信你肯定能做一些样品出来，可能是一个小型的 app 来展示它的功能，最难的部分是如何将那些功能塞进更大的愿景里面

  
  


• 
  

  你得从用户体验出发，倒推用什么技术，你不能从技术出发，然后去想如何才能卖出去

  
  

懂业务是一种认知模式，人的能力是多层次的，技术和懂业务并非互斥的关系。

亲爱的程序员朋友，技术是我们的立身之本，但是业务同样重要 , 真诚的希望你做一个既懂技术又懂业务的工程师。

如果我的文章对你有所帮助，还请帮忙点赞、在看、转发一下，你的支持会激励我输出更高质量的文章，非常感谢！

距我被裁已经过去 34 天了，我还没有去找工作，接下来的一个月大概率也不会找工作，而是打算和老公去西藏旅游一趟，我对一周或者两周后的西藏之旅满是期待。至于老东家，我对他没有怨言，在那儿工作期间很愉快，被裁的时候他爽快的给了 N+1 的赔偿，离职的过程中没有发生不愉快的事情。我写这篇文章不是为了缅怀过去或者反思过去，而是记录我的一天，余下的内容没有华丽的词藻，也没有令人深思的道理，只是流水账。

今天我 7 点 20 就醒了，醒来的前一刻还在做梦，我梦到自己睡不着觉，可想而知那不是一个美梦。醒来的那一瞬间，我甚至没有分辨出是现实还是梦境，头昏昏沉沉的赖了一会儿床，在赖床期间我老公起床了，他洗漱结束的时候，我用手机放了一首歌，他走到床边对我巴拉巴拉说了些话，说的都是些大道理，大概是选择呀未来呀思考呀这一套，如果让我将他的话背下来，可真是在难为我。其实他一大早就讲大道理，我特别不想听，但我觉得他的话有些道理，于是赶紧起了床，洗漱完去跑步。

今天温度不高，早上很适合跑步，估摸着跑了 15 分钟，没有记录跑了多少公里，我打算明天记录一下跑步的公里数。跑完步给手机充了一会儿就出门吃早餐，需要坐两站地铁才能到那家包子铺，我住的地方距地铁站大概 1.5 公里，这段路可以坐小区的摆渡车，但我选择了走路。

那家包子铺叫什么名儿？不记得了，更准确的说，我从来没想过要记住它的名字。我买了两个豇豆包，一个卤鸡蛋还有一杯豆浆。为什么要买这些食物呢？不是没有缘由。昨天我只买了两个豇豆包和一杯豆浆，没有吃饱，于是今天加了一个卤鸡蛋。今天买的这些食物，还是没让我吃饱，明天我要再加一个豇豆包。

为什么要买豇豆包呢？因为我喜欢吃酸豇豆，但是这包子里包的不是酸豇豆，而是新鲜的豇豆，所以第一次吃它的时候它与我的预期不符合，尝了之后又发现新鲜的豇豆也好吃，现在我每次都买豇豆包。今天我看见豇豆包里包的不是豇豆，而是四季豆，四季豆也挺好吃。

这家包子店里能喝的食物除了有豆浆还有稀饭，它的稀饭不是很稀，我担心豇豆包就着稀饭吃不好下咽，于是买了豆浆。

吃了早餐我就回家了，到家的第一件事是联系物业师傅来疏通地漏，还让他们处理电动晾衣架不能升降的问题。关于电动晾衣架，我今天学到了一个新知识，有些人可能会认为那是小常识，不值一提，但我还是要写下来——电池放在遥控器里久了会腐蚀铜板，这将导致遥控器通不了电，遥控器就指挥不了晾衣架，我家的晾衣机不能升降就是这个原因的。

今天我写了两篇技术文章去参加掘金推出的金石计划征文活动，这可以瓜分奖金，这是我第 5 次参加金石计划，每一次都瓜分到了最高奖金，这次我瓜分不到最高奖金了，因为写不出 6 篇原创技术文章。

等物业师傅处理好地漏和晾衣架，发布了文章，我就出发去健身房游泳，健身房离我家有 4.8 公里左右，出发前我在想是开车还是走路，最终选了走路。

今后要做什么？在路上我不由得思考。

今年是我工作的第 6 年，6 年来我断断续续的有考研的想法。为什么想考研呢？在路上我想出了一个原因 —— 源自虚荣心。走着走着想上厕所，路过一家花店，进店问老板附近是否有厕所，他说马路对面有，到了马路对面又向烟酒铺的老板询问厕所的具体位置，如愿的上了厕所，一身轻松。

上完厕所路过一家包子铺，肚子饿了，于是进店买了 2 个包子，1 个鸡蛋还有 1 碗粥，其实我想喝带丝汤，但是卖完了，所以没喝成。

吃完午餐继续往健身房走。哦，我想起在包子铺吃午餐的时候看到了一个皮肤特别好的女生。走呀走呀，终于到了健身房，到那儿之后我没有立即去游泳池，而是去休闲区按摩，在按摩椅上躺着的时候，开始思考我是否想继续当程序员，如果当程序员，想做那方面的业务呢？

我喜欢写作。2021 年期间我写了一部小说，超过 10 万个字，2022 年写我的第一本技术书，上个月才交稿，出版社编辑说稿子问题不大，昨天我根据编辑老师的反馈做了修改，并补充了前言，现在稿件已进入 3 审。我还有一个微信公众号，每个月至少发一篇技术文章。

如果继续当程序员，我想做内容创作类的产品。

按摩完就去游泳，游泳池里只有两个人，除了我还有一个小男孩，他挺可爱的。游完 3 圈我离开游泳池去了桑拿室，那儿只有我一个人，当时我突然想到我还想当程序员，不禁眼睛里有了点泪花。

我很爱哭，被裁后我一个人在家哭了好几次。哭，不是因为被裁，因为以前没被裁的时候，我一个人在家也有哭的时候。桑拿室温度很高，泪花流出来就蒸发了。蒸完桑拿洗完澡打算回家，可是外面在下雨，于是又到按摩椅上躺了一会儿，寻思着等雨停了再回家。第二次按完摩，雨没有停的迹象，我决定淋着雨到外面去打车，16 点到的家，在家吃了一包薯片，看了一会莫言的小说《生死疲劳》，17 点的时候到床上睡觉，18 点的时候才醒，然后到小区门口买了做晚餐的蔬菜，今天晚上煮了面。

这篇文章写了 2 个小时。最后我想说今天还有一件想做的事情没有做成——开车到兴隆湖吹风。