扯淡

好的代码 更多的也是为了后期维护，哪怕后期不需要你来维护 ，清晰干爽的代码也会为作者留下好的印象

并且 在工作团队中 可以施加影响力

用主干逻辑 消灭长代码

业务场景

假期到了，想来场说走就走的旅行，输入目的地,出发

虽然是说走就走，也不能什么都不想开车就出发
因为：

如果忘记带钱包，可能只能走到油耗尽的地方
如果忘记带 身份证，驾驶证 行车证 路上遇见交警查车 ...
如果出发前未检查车厢里面的油 ......
如果汽车半路爆胎......
如果距离下个服务区或高速出口还有100km，此时的你三急
如果 如果 如果 太多的如果

代码实现之瀑布流

      void journeyWithoutPlan(User user,Car car){

              if(user.haveMoney()){
                      throws TravelFailureException("未带money");
              }

              if(user.haveIdCard()){
                      throws TravelFailureException("未带身份证");
              }

              if(car.tireBlowout()){
                      throws TravelFailureException("汽车爆胎");
              }

              if(user.urgentBathroom()){
                     throws TravelFailureException("三急异常");
              }

              if(...){

              }
              
              //是否可以继续行走的判定
              while(goOn()){
                  //是否到达目的地
                 if(arrived()){
                      break;
                 }
                 try{
                     user.drive(car);
                  }catch(TravelFailureException e){
                      if(e.code ==Code.IntValue("汽车爆胎")){
                            //修车
                       }
                       if(e.code ==Code.IntValue("三急异常")){
                           //紧急车道停车  开双闪  路边解决
                       }
                   }
              }
              happyEnding(user,car);
      }

      经历各种异常的洗礼，终于到达目的地
      但接下来的游玩中的各种异常正在悄悄逼近
      回头看下代码 逻辑挺清晰的 各种问题都想到了 满意的嘴角微微上扬
      但已经忘记自己是谁了 要干嘛了      

代码实现之主干逻辑

  该业务的目的是 说走就走的旅行
  假如一切顺利的话  就仅仅是  user.drive(car);
  旅行过程中遇到问题提前初始化到预案中,人的预案，车的预案
  过程中：
             人出现问题 ---->人的预案----> 下一步行动
             车出现问题 ---->车的预案----> 下一步行动
  生活场景中：
             车爆胎(车异常)   ---->  人判断异常(识别异常)  ----> 响应的预案
            
  
  user.initializeJourneyException();
  car.initializeJourneyException();

  void journeyWithoutPlan(User user,Car car){     
          //我要做的就是开车到目的地
           while(!arrived()){
                user.drive(car);
           }
          happyEnding(user,car);
  }

  class User{
        List<UserJourneyException>exceptions;
        public void initializeJourneyException(List<JourneyException> exces){
                   this.exceptions=exces;
        }

       void drive(Car car){
            try{
                   ......
              }catch(CarJourneyException e){
                  //旅行过程中车预案处理
                  CarJourneyGenericPlan.hand(e,this,car);
              }catch(UserJourneyException ex){
                  //旅行过程中人预案处理
                  UserJourneyGenericPlan.hand(e,this);
              }
      }
  }

比较

第一种风格是 自低向上的编程风格 尝试解决所有的子问题 (接地气) --------------->更高层次的组件(用了我的组件 出行全搞定)

第二种风格是 自顶向下的编程风格 任务模块清晰 可读 （战略清晰)--------------->计划清晰易读 模块清晰(读我的计划 出行目标清晰可见)

不鼓吹那种风格更好，其实大部分编码都包含两者的组合 看如何平衡

不过既然在商业公司里面做开发，我们玩的就是软件工程

既然是工程 需要将大问题拆分成小问题 然后再把这些问题的解决办法组合去解决这个大问题 而非靠一人之力,一个方法之力，一个组件之力 去解决所有问题

赌博在 “一” 的结果是 成也风云败也风云

总结

每个业务模块 每个方法 都有自己的最终目的，编写代码时需清晰的认识到下一行代码是否是最终目的里必不可少的一环,剔除非主干逻辑代码

具有领导者思维 安排各个模块 各个方法各司其职

认清工作 软件工程 还是 计算机科学

长期维护的系统 代码最终还是要 可读的 可读的 可读的