前言

在 JavaScript 中, 通过 new 操作符可以创建一个实例对象，而这个实例对象继承了原对象的属性和方法。因此，new 存在的意义在于它实现了 JavaScript 中的继承，而不仅仅是实例化了一个对象。

new 的作用

我们先通过例子来了解 new 的作用，示例如下：

function Person(name) {

  this.name = name

}

Person.prototype.sayName = function () {

  console.log(this.name)

}

const t = new Person('小明')

console.log(t.name)  // 小明

t.sayName()  // 小明

从上面的例子中我们可以得出以下结论：

• new 通过构造函数 Person 创建出来的实例对象可以访问到构造函数中的属性。

• new 通过构造函数 Person 创建出来的实例可以访问到构造函数原型链中的属性，也就是说通过 new 操作符，实例与构造函数通过原型链连接了起来。

构造函数 Person 并没有显式 return 任何值（默认返回 undefined），如果我们让它返回值会发生什么事情呢？

function Person(name) {

  this.name = name

  return 1

}

const t = new Person('小明')

console.log(t.name)  // 小明

在上述例子中的构造函数中返回了 1，但是这个返回值并没有任何的用处，得到的结果还是和之前的例子完全一样。我们又可以得出一个结论：

构造函数如果返回原始值，那么这个返回值毫无意义。

我们再来试试返回对象会发生什么：

function Person(name) {

  this.name = name

  return {age: 23}

}

const t = new Person('小明')

console.log(t)  // { age: 23 }

console.log(t.name)  // undefined

通过上面这个例子我们可以发现，当返回值为对象时，这个返回值就会被正常的返回出去。我们再次得出了一个结论：

构造函数如果返回值为对象，那么这个返回值会被正常使用。

总结：这两个例子告诉我们，构造函数尽量不要返回值。因为返回原始值不会生效，返回对象会导致 new 操作符没有作用。

实现 new

首先我们要清楚，在使用 new 操作符时，js 做了哪些事情:

1. js 在内部创建了一个对象
2. 这个对象可以访问到构造函数原型上的属性，所以需要将对象与构造函数连接起来
3. 构造函数内部的this被赋值为这个新对象(即this指向新对象)
4. 返回原始值需要忽略，返回对象需要正常处理

知道了步骤后，我们就可以着手来实现 new 的功能了:

function _new(fn, ...args) {

  const newObj = Object.create(fn.prototype);

  const value = fn.apply(newObj, args);

  return value instanceof Object ? value : newObj;

}

测试示例如下：

function Person(name) {

  this.name = name;

}

Person.prototype.sayName = function () {

  console.log(this.name);

};



const t = _new(Person, "小明");

console.log(t.name);  // 小明

t.sayName();  // 小明

以上就是关于 JavaScript 中 new 操作符的作用，以及如何来实现一个 new 操作符。

Promise

背景

JavaScript这种单线程事件循环模型，异步行为是为了优化因计算量大而时间长的操作。在JavaScript中我们可以见到很多异步行为，比如计时器、ui渲染、请求数据等等。

Promise的主要功能，是为异步代码提供了清晰的抽象，支持优雅地定义和组织异步逻辑。可以用Promise表示异步执行的代码块，也可以用Promise表示异步计算的值。

Promise现在主流的翻译为“期约”，在英文里，promise还有承诺的意思，既然是承诺，那就是一种约定，这恰好就符合异步情境的需求：异步的代码不在当前的代码块中调用，而是由外部调用。既然如此，为了获取到异步代码执行的状态，或是为了拿到执行结果，就需要制定一定的规范去获取和维护，Promise A+就是对此指定的规范，Promise类型就是对Promise A+规范的实现。

过去在JavaScript中处理异步，通常会使用一层层的回调嵌套，没有一个规范、清晰的处理逻辑，造成的结果就是阅读困难、调试困难，可维护性差。

Promise A+规范设计的一套逻辑，Promise提供统一的API，可以使我们更有条理的去处理异步操作。

首先，将某个异步任务相关的代码包裹在一个代码块里，也就是Promise执行器函数的函数体中；比如下面的代码：

let p1 = new Promise((resolve, reject) => { // 执行器函数

    const add = (a, b) => a + b;

    resolve(add(1, 2));

    console.log(add(3, 4));

});

同时，针对这段异步代码的执行状态和执行结果，Promise实例内部会进行维护；

此外，Promise类型内部维护一个resolve和reject函数，用于维护状态的更新，以及调用处理程序将异步执行结果传递给用户进行后续处理，这些处理程序由用户自己定义。

Promise类型实现了Thenable接口，用户可以通过Promise的实例方法then来新增处理程序

当用Promise指代异步执行的代码块时，他涉及异步代码执行的三种状态：进行中等待结果的pending、成功执行fulfilled（一般也用resolved）、执行失败或出现异常rejected。当一个Promise实例被初始化时，其对应的异步代码块就进入进行中的状态，也就是说pending是初始状态。

当代码块执行完毕或者出现异常，将得到最终的一个确定状态，resolved或者rejected，和执行结果，并且不能被再次更新。

Promise的基本使用

let p = new Promise((resolve, reject) => {

    const add = (a, b) => a + b;

    resolve(add(1, 2));

    console.log(add(3, 4));

});

p.then(res => {

    console.log(res);

});

简易版Promise

针对Promise的基本使用，可以实现一个简易版的Promise

首先是状态常量的维护，以便于开发和后期维护：

const PENDING = 'pending';

const RESOLVED = 'resolved';

const REJECTED = 'rejected';

然后定义我们自己的MyPromise，维护Promise实例对象的属性

function MyPromise(fn) {

    const that = this;

    that.state = PENDING;

    that.value = null;

    that.resolvedCallbacks = [];

    that.rejectedCallbacks = [];

}

• 首先是state，表示异步代码块执行的状态，初始状态为pending
• value变量用于维护异步代码执行的结果
• resolvedCallbacks用于维护部分的处理程序，处理成功执行的结果
• rejectedCallbacks用于维护另一部分的处理程序，处理的是执行失败的结果

内部使用常量that是因为，代码可能会异步执行，这用于获取正确的this。

接下来定义resolve和reject函数，添加在MyPromise函数体内部

function resolve(value) {

    if (that.state === PENDING) {

        that.state = RESOLVED;

        that.value = value;

        that.resolvedCallbacks.forEach(cb => cb(value));

    }

}



function reject(reason) {

    if (that.state === PENDING) {

        that.state = REJECTED;

        that.value = reason;

        that.rejectedCallbacks.forEach(cb => cb(reason));

    }

}

• 首先这两个函数都得判断当前状态是否为pending，因为状态落定后不允许再次修改
• 如果判断为pending，就更新为对应状态，并且将异步执行结果维护到Promise实例的value属性上
• 最后遍历处理程序，并传入异步结果挨个执行

当然传递给Promise的执行器函数fn也得执行：

try {

    fn(resolve, reject);

} catch (e) {

    reject(e);

}

执行器函数接收两个函数类型的参数，实际传入的就是前面定义的resolve和reject。另外，执行函数的过程中可能会抛出异常，需要捕获并执行reject函数。

最后实现较为复杂的then函数：

MyPromise.prototype.then = function (onResolved, onRejected) {

    const that = this;

    onResolved = typeof onResolved === 'function' ? onResolved: v => v;

    onRejected = typeof onRejected === 'function'

        ? onRejected

        : r => {

            throw r;

        };

    if (that.state === PENDING) {

        that.resolvedCallbacks.push(onResolved);

        that.rejectedCallbacks.push(onRejected);

    }

    if (that.state === RESOLVED) {

        onResolved(that.value);

    }

    if (that.state === REJECTED) {

        onRejected(that.value);

    }

}

• 首先判断两个参数是否为函数类型，因为这两个参数是可选参数。
• 当参数不是函数类型时，就创建一个函数赋值给对应的参数，实现透传
• 然后是状态的判断，当Promise的状态是等待结果pending时，就会将处理程序维护到Promise实例内部的处理程序的数组中，resolvedCallbacks和rejectedCallbacks，如果不是pending，就去执行对应状态的处理程序。

至此就实现了一个简易版本的MyPromise，可以进行测试：

let p = new MyPromise((resolve, reject) => {

    const add = (a, b) => a + b;

    resolve(add(1, 2));

    console.log(add(3, 4));

});

p.then(res => {

    console.log(res);

});

进阶版Promise

根据promise的使用经验，我们知道promise解析异步结果是一个微任务，并且promise的原型方法then会返回一个promise类型的值，这些简易版中都没有实现，为了使我们的MyPromise更符合Promise A+的规范，我们需要对简易版进行改造。

首先是resolve和reject函数，这两个函数中的代码会被推入微任务的队列中等待执行

  function resolve(value) {

        if (value instanceof MyPromise) {

            return value.then(resolve, reject);

        }



        // 调用queueMicrotask，将代码插入微任务的队列

        queueMicrotask(() => {

            if (that.state === PENDING) {

                that.state = RESOLVED;

                that.value = value;

                that.resolvedCallbacks.forEach(cb => cb(value));

            }

        })

    }



    function reject(reason) {

        queueMicrotask(() => {

            if (that.state === PENDING) {

                that.state = REJECTED;

                that.value = reason;

                that.rejectedCallbacks.forEach(cb => cb(reason));

            }

        });

    }

• 对于resolve函数，我们首先需要判断传入的值是否为Promise类型，如果是，则要得到x最终的异步执行结果再继续执行resolve和reject
• 此处使用queueMicrotask方法将代码推入微任务队列

接下来继续改造then函数中的代码

• 首先新增一个变量promise2用于返回，因为每个then函数都需要返回一个新的Promise对象，该变量就用于保存新的返回对象

  let promise2; // then方法必须返回一个promise
  
  

• 然后先改造pending状态的逻辑

  if (that.state === PENDING) {
  
      return promise2 = new MyPromise((resolve, reject) => {
  
          that.resolvedCallbacks.push(() => {
  
              try {
  
                  const x = onResolved(that.value); // 执行原promise的成功处理程序，如果未定义就透传
  
                  // 如果正常得到一个解决值x，即onResolved的返回值，就解决新的promise2，即调用resolutionProcedure函数，这是对[[Resolve]](promise, x)的实现
  
                  // 将新创建的promise2，处理程序返回结果x，以及与promise2关联的resolve和reject函数作为参数传递给 这个函数
  
                  resolutionProcedure(promise2, x, resolve, reject);
  
              } catch(r) { // 如果onResolved程序执行过程中抛出异常，promise2就被标记为失败，执行reject
  
                  reject(r);
  
              }
  
          });
  
          that.rejectedCallbacks.push(() => {
  
              try {
  
                  const x = onRejected(that.value); // 执行原promise的失败处理程序，如果未定义就抛出异常
  
                  resolutionProcedure(promise2, x, resolve, reject); // 解决新的promise2
  
              } catch(r) {
  
                  reject(r);
  
              }
  
          });
  
      })
  
  }
  
  

  整体来看下：

  • 首先创建新的Promise实例，传入执行器函数
  • 大致逻辑还是和之前一样，往回调数组中push处理程序，只是除了onResolved函数之外，还做了一些额外操作
  • 首先在onResolved和onRejected函数调用的时候包裹了一层try/catch用于处理异常，如果出现异常，promise2就被标记为失败，执行其关联的reject函数
  • 如果onResolved和onRejected正常执行，就调用resolutionProcedure函数去解决promise2

• 继续改造resolved状态的逻辑

  if (that.state === RESOLVED) {
  
      return promise2 = new MyPromise((resolve, reject) => {
  
          queueMicrotask(() => {
  
              try {
  
                  const x = onResolved(that.value);
  
                  resolutionProcedure(promise2, x, resolve, reject);
  
              } catch (r) {
  
                  reject(r);
  
              }
  
          });
  
      })
  
  }
  
  

  • 这段代码和pending的逻辑基本一致，不同之处在于，这里直接将处理程序插入微任务队列，而不是push进回调数组
  • rejected状态的逻辑基本也类似

最后就是实现上述代码中所调用的resolutionProcedure函数，用于解决promise2

function resolutionProcedure(promise2, x, resolve, reject) {}

• 首先规范规定了x不能与promise2相等，否则会发生循环引用的问题

  if (promise2 === x) { // 如果x和promise2相等，以 TypeError 为拒因 拒绝执行 promise2
  
      return reject(new TypeError('Error'));
  
  }
  
  

• 接着判断x的类型是否为promise

  if (x instanceof MyPromise) { // 如果x为Promise类型，则使 promise2 接受 x 的状态
  
      x.then(function (value) {
  
          // 等到x状态落定后，再去解决promise2，也就是递归调用resolutionProcedure这个函数
  
          resolutionProcedure(promise2, value, resolve, reject);
  
      }, reject/*如果x落定为拒绝状态，就用同样的拒因拒绝promise2*/);
  
  }
  
  

• 处理x的类型不是promise的情况

  首先创建一个变量called用于标识是否调用过函数

  let called = false;
  
  if (x !== null && (typeof x === 'object' || typeof x === 'function')) { // 如果x为对象或函数类型
  
      try {
  
          let then = x.then; // 取出x上的then属性
  
          if (typeof then === 'function') { // 判断then的类型是否为函数，进行调用
  
              // 根据规范可知，在then调用时，要将this指向x，所以这里使用call对then函数进行调用
  
              // then接收两个函数类型的参数，第一个参数叫做resolvePromise，第二个参数叫做rejectPromise
  
              // 如果resolvePromise被执行，则去解决promise2，如果rejectPromise被调用，则promise2被认为失败，会调用其关联的reject函数
  
              then.call(
  
                  x, // 将this指向x
  
                  y => { // 第一个参数叫做resolvePromise
  
                      if (called) return;
  
                      called = true;
  
                      resolutionProcedure(promise2, y, resolve, reject);
  
                  },
  
                  r => { // 第二个参数叫做rejectPromise
  
                      if (called) return;
  
                      called = true;
  
                      reject(r);
  
                  }
  
              )
  
          } else { // 如果then不是函数，就将x传递给resolve，执行promise2的resolve函数
  
              resolve(x);
  
          }
  
      } catch (e) { // 如果上述代码抛出异常，则认为promise2失败，执行其关联的reject函数
  
          if (called) return;
  
          called = true;
  
          reject(e);
  
      }
  
  } else { // 如果x不是对象或函数，就将x传递给promise2关联的resolve并执行
  
      resolve(x);
  
  }
  
  

至此resolutionProcedure函数就完成了，最终会执行promise2关联的resolve或者reject函数。之所以说关联，是因为这两个函数中有对实例的引用。

到这为止，进阶版的promise就基本完成了，可以来试用一下：

let p = new MyPromise((resolve, reject) => {

    const add = (a, b) => a + b;

    resolve(add(1, 2));

    console.log(add(3, 4));

});

p.then(res => {

    console.log(res);

    return res;

}).then(res => {

    console.log(res);

});

p.then(res => {

    return {

        name: 'x',

        then: function (resolvePromise, rejectPromise) {

            resolvePromise(this.name + res);

        }

    }

}).then(res => {

    console.log(res);

})

前端吐槽：后端从不自测接口，等到前后端联调时，这个接口获取不到，那个接口提交不了，把前端当成自己的接口测试员，耽误前端的开发进度。

听到这个吐槽，仿佛看到曾经羞愧的自己。这个毛病以前我也有啊，有些接口，尤其是大表单提交接口，表单特别大，字段很多，有时候就偷懒了，直接编译过了，就发到测试环境了。前端同时联调的时候一调接口，异常了。

好在后来改了，毕竟让人发现自己接口写的有问题，也是一件丢脸的事儿。

但是我还真见过后端的同学，写完接口一个都不测，直接发测试环境的。

我就碰到过厉害的，编译都不过，就直接提代码。以前，有个新来的同事，分了任务就默默的干着，啥也不问，然后他做的功能测试就各种发现问题。说过之后，就改一下，但是基本上还是不测试，本想再给他机会的，所以后来他每次提代码，我都review一下。直到有一天，我发现忍不了了，他把一段全局配置给注释了，然后把代码提了，我过去问他是不是本地调试，忘了取消注释了。他的回答直接让我震惊了，他说：不是的，是因为不注释那段代码，我本地跑步起来，所以肯定是那段代码有问题，所以就注释了。

然后，当晚，他就离职了。

解决方式

对于这种大表单类似的问题，应该怎么处理呢？

好像没有别的方法，只能克服自己的懒惰，为自己写的代码负责。就想着，万一接口有问题，别人可能会怀疑你水平不行，你水平不行，就是你不行啊，程序员怎么能不行呢。

你可以找那么在线 Java Bean转 JSON的功能，直接帮你生成请求参数，或者现在更可以借助 ChatGPT ，帮你生成请求参数，而且生成的参数可能比你自己瞎填的看上去更合理。

或者，如果是小团队，不拘一格的话，可以让前端的同事把代码提了，你本地跑着自测一下，让前端同事先做别的功能，穿插进行也可以。

前端吐槽：后端修改了字段或返回结构不通知前端

这个就有点不讲武德了。

正常情况下，返回结构和字段都是事先约定好的，一般都是先写接口，做一些 Mock 数据，然后再实现真实的逻辑。

除了约定好返回字段和结构外，还包括接口地址、请求方法、头信息等等，而且一个项目都会有项目接口规范，同一类接口的返回字段可能有很多相同的部分。

后端如果改接口，必须要及时通知前端，这其实应该是正常的开发流程。后端改了接口，不告诉前端，到时候测试出问题了，一般都会先找前端，这不相当于让前端背锅了吗，确实不地道啊。

后端的同学们，谨记啊。

前端吐槽：为了获取一个信息，要先调用好几个接口，可能参数还是相同的

假设在一个详情页面，以前端的角度就是，我获取详情信息，就调用详情接口好了，为什么调用详情接口之前，要调用3、4个其他的接口，你详情里需要啥参数，我直接给你传过去不就好了吗。

在后端看来可能是这样的，我这几个接口之前就写好了，前端拿过去就能用，只不过就是多调几次罢了，没什么大不了的吧。

有些时候，可能确实是必须这么做的，比如页面内容太多，有的部分查询逻辑复杂，比较耗时，这时候需要异步加载，这样搞确实比较好。

但是更多时候其实就是后端犯懒了，不想再写个新接口。除了涉及到性能的问题，大多数逻辑都应该在后端处理，能用一个接口处理完，就不应该让前端多调用第二个接口。

有前端的朋友曾经问过我，他说，他们现在做的系统中有些接口是根据用户身份来展示数据的，但是前端调用登录接口登录系统后，在调用其他接口的时候，除了在 Header 中加入 token 外，还有传很多关于用户信息的很多参数，这样做是不是不合理的。

这肯定不合理，token 本来就是根据用户身份产生的，后端拿到 token 就能获取用户信息，这是常识问题，让前端在接口中再传一遍，既不合理也不安全。

类似的问题还有，比如后端接口返回一堆数据，然后有的部分有用、有的部分没有，有的部分还涉及到逻辑，不借助文档根本就看不明白怎么用，这其实并不合理。

接口应该尽量只包含有用的部分，并且尽可能结构清晰，配合简单的字段说明就能让人明白是怎么回事，是最好的效果。

如果前后端都感觉形势不对了，后端一个接口处理性能跟不上了，前端处理又太麻烦了。这时候就要向上看了，产品设计上可能需要改一改了。

后端的同学可以学一点前端，前端的同学也可以学一点后端，当你都懂一些的时候，就能两方面考虑了，这样做出来的东西可能会更好用一点。总之，前后端相互理解，毕竟都是为了生活嘛。

前言

小王，你的页面白屏了，赶快修复一下。小王排查后发现是服务端传回来的数据格式不对导致，无数据时传回来不是 [] 而是 null, 从而导致 forEach 方法报错导致白屏，于是告诉测试，这是服务端的错误导致，要让服务端来修改，结果测试来了一句：“服务端返回数据格式错误也不能白屏！！” “好吧，千错万错都是前端的错。” 小王抱怨着把白屏修复了。

刚过不久，老李喊道：“小王，你的组件又渲染不出来了。” 小王不耐烦地过来去看了一下，“你这个属性data 格式不对，要数组，你传个对象干嘛呢。”老李反驳： “ 就算 data 格式传错，也不应该整个组件渲染不出来，至少展示暂无数据吧！” “行，你说什么就是什么吧。” 小王又抱怨着把问题修复了。

类似场景，小王时不时都要经历一次，久而久之，大家都觉得小王的技术太菜了。小王听到后，倍感委屈：“这都是别人的错误，反倒成为我的错了！”

等到小王离职后，我去看了一下他的代码，的确够烂的，不堪一击！太烂了！下面来吐槽一下。

一、变量解构一解就报错

优化前：

const App = (props) => {

  const { data } = props;

  const { name, age } = data

}

如果你觉得以上代码没问题，我只能说你对你变量的解构赋值掌握的不扎实。

解构赋值的规则是，只要等号右边的值不是对象或数组，就先将其转为对象。由于 undefined 、null无法转为对象，所以对它们进行解构赋值时都会报错。

所以当 data 为 undefined 、null 时候，上述代码就会报错。

优化后：

const App = (props) => {

  const { data } = props || {};

  const { name, age } = data || {};

}

二、不靠谱的默认值

估计有些同学，看到上小节的代码，感觉还可以再优化一下。

再优化一下：

const App = (props = {}) => {

  const { data = {} } = props;

  const { name, age } = data ;

}

我看了摇摇头，只能说你对ES6默认值的掌握不扎实。

ES6 内部使用严格相等运算符（===）判断一个变量是否有值。所以，如果一个对象的属性值不严格等于 undefined ，默认值是不会生效的。

所以当 props.data 为 null，那么 const { name, age } = null 就会报错！

三、数组的方法只能用真数组调用

优化前：

const App = (props) => {

  const { data } = props || {};

  const nameList = (data || []).map(item => item.name);

}

那么问题来了，当 data 为 123 , data || [] 的结果是 123，123 作为一个 number 是没有 map 方法的，就会报错。

数组的方法只能用真数组调用，哪怕是类数组也不行。如何判断 data 是真数组，Array.isArray 是最靠谱的。

优化后：

const App = (props) => {

  const { data } = props || {};

  let nameList = [];

  if (Array.isArray(data)) {

    nameList = data.map(item => item.name);

  }

}

四、数组中每项不一定都是对象

优化前：

const App = (props) => {

  const { data } = props || {};

  let infoList = [];

  if (Array.isArray(data)) {

    infoList = data.map(item => `我的名字是${item.name},今年${item.age}岁了`);

  }

}

一旦 data 数组中某项值是 undefined 或 null，那么 item.name 必定报错，可能又白屏了。

优化后：

const App = (props) => {

  const { data } = props || {};

  let infoList = [];

  if (Array.isArray(data)) {

    infoList = data.map(item => `我的名字是${item?.name},今年${item?.age}岁了`);

  }

}

? 可选链操作符，虽然好用，但也不能滥用。item?.name 会被编译成 item === null || item === void 0 ? void 0 : item.name，滥用会导致编辑后的代码大小增大。

二次优化后：

const App = (props) => {

  const { data } = props || {};

  let infoList = [];

  if (Array.isArray(data)) {

    infoList = data.map(item => {

      const { name, age } = item || {};

      return `我的名字是${name},今年${age}岁了`;

    });

  }

}

五、对象的方法谁能调用

优化前：

const App = (props) => {

  const { data } = props || {};

  const nameList = Object.keys(data || {});

}

只要变量能被转成对象，就可以使用对象的方法，但是 undefined 和 null 无法转换成对象。对其使用对象方法时就会报错。

优化后：

const _toString = Object.prototype.toString;

const isPlainObject = (obj) => {

  return _toString.call(obj) === '[object Object]';

}

const App = (props) => {

  const { data } = props || {};

  const nameList = [];

  if (isPlainObject(data)) {

    nameList = Object.keys(data);

  }

}

六、async/await 错误捕获

优化前：

import React, { useState } from 'react';



const App = () => {

  const [loading, setLoading] = useState(false);

  const getData = async () => {

    setLoading(true);

    const res = await queryData();

    setLoading(false);

  }

}

如果 queryData() 执行报错，那是不是页面一直在转圈圈。

优化后：

import React, { useState } from 'react';



const App = () => {

  const [loading, setLoading] = useState(false);

  const getData = async () => {

    setLoading(true);

    try {

      const res = await queryData();

      setLoading(false);

    } catch (error) {

      setLoading(false);

    }

  }

}

如果使用 trycatch 来捕获 await 的错误感觉不太优雅，可以使用 await-to-js 来优雅地捕获。

二次优化后：

import React, { useState } from 'react';

import to from 'await-to-js';



const App = () => {

  const [loading, setLoading] = useState(false);

  const getData = async () => {

    setLoading(true);

    const [err, res] = await to(queryData());

    setLoading(false);

  }

}

七、不是什么都能用来JSON.parse

优化前：

const App = (props) => {

  const { data } = props || {};

  const dataObj = JSON.parse(data);

}

JSON.parse() 方法将一个有效的 JSON 字符串转换为 JavaScript 对象。这里没必要去判断一个字符串是否为有效的 JSON 字符串。只要利用 trycatch 来捕获错误即可。

优化后：

const App = (props) => {

  const { data } = props || {};

  let dataObj = {};

  try {

    dataObj = JSON.parse(data);

  } catch (error) {

    console.error('data不是一个有效的JSON字符串')

  }

}

八、被修改的引用类型数据

优化前：

const App = (props) => {

  const { data } = props || {};

  if (Array.isArray(data)) {

    data.forEach(item => {

      if (item) item.age = 12;

    })

  }

}

如果谁用 App 这个函数后，他会搞不懂为啥 data 中 age 的值为啥一直为 12，在他的代码中找不到任何修改 data中 age 值的地方。只因为 data 是引用类型数据。在公共函数中为了防止处理引用类型数据时不小心修改了数据，建议先使用 lodash.clonedeep 克隆一下。

优化后：

import cloneDeep from 'lodash.clonedeep';



const App = (props) => {

  const { data } = props || {};

  const dataCopy = cloneDeep(data);

  if (Array.isArray(dataCopy)) {

    dataCopy.forEach(item => {

      if (item) item.age = 12;

    })

  }

}

九、并发异步执行赋值操作

优化前：

const App = (props) => {

  const { data } = props || {};

  let urlList = [];

  if (Array.isArray(data)) {

    data.forEach(item => {

      const { id = '' } = item || {};

      getUrl(id).then(res => {

        if (res) urlList.push(res);

      });

    });

    console.log(urlList);

  }

}

上述代码中 console.log(urlList) 是无法打印出 urlList 的最终结果。因为 getUrl 是异步函数，执行完才给 urlList 添加一个值，而 data.forEach 循环是同步执行的，当 data.forEach 执行完成后，getUrl 可能还没执行完成，从而会导致 console.log(urlList) 打印出来的 urlList 不是最终结果。

所以我们要使用队列形式让异步函数并发执行，再用 Promise.all 监听所有异步函数执行完毕后，再打印 urlList 的值。

优化后：

const App = async (props) => {

  const { data } = props || {};

  let urlList = [];

  if (Array.isArray(data)) {

    const jobs = data.map(async item => {

      const { id = '' } = item || {};

      const res = await getUrl(id);

      if (res) urlList.push(res);

      return res;

    });

    await Promise.all(jobs);

    console.log(urlList);

  }

}

十、过度防御

优化前：

const App = (props) => {

  const { data } = props || {};

  let infoList = [];

  if (Array.isArray(data)) {

    infoList = data.map(item => {

      const { name, age } = item || {};

      return `我的名字是${name},今年${age}岁了`;

    });

  }

  const info = infoList?.join('，');

}

infoList 后面为什么要跟 ?，数组的 map 方法返回的一定是个数组。

优化后：

const App = (props) => {

  const { data } = props || {};

  let infoList = [];

  if (Array.isArray(data)) {

    infoList = data.map(item => {

      const { name, age } = item || {};

      return `我的名字是${name},今年${age}岁了`;

    });

  }

  const info = infoList.join('，');

}

后续

以上对小王代码的吐槽，最后我只想说一下，以上的错误都是一些 JS 基础知识，跟任何框架没有任何关系。如果你工作了几年还是犯这些错误，真的可以考虑转行。

1. 背景介绍

公司日常开发基于自建的Maven服务器，不对外开放，公司内开发的SDK都传到私服，经过这么多年的迭代已经有上百个包，前段时间有其他公司需要依赖内部某个SDK，而这个SDK有依赖了公司好多SDK，但是公司内网权限无法对外开放，所以无法使用Maven方式对外提供依赖，如果基于AAR方式，对外提供十几个AAR不仅不友好，而且内部也不好维护迭代。

2. 解决思路及办法

市面上有一套开源的合并AAR的方案，合并AAR主要的步骤：

• AndroidManifest合并
• Classes合并
• Jar合并
• Res合并
• Assets合并
• Jni合并
• R.txt合并
• R.class合并
• DataBinding合并
• Proguard合并
• Kotlin module合并

这些都有对应Gradle task，具体方案可以看对应源码：adwiv/android-fat-aar目前已不再维护，gradle不支持高版本，kezong/fat-aar-android虽然也不在维护，但是已经适配了AGP 3.0 - 7.1.0，Gradle 4.9 - 7.3。

3. 遇到问题

3.1 资源冲突

如果library和module中含有同名的资源(比如 string/app_name)，编译将会报duplication resources的相关错误，有两种方法可以解决这个问题：

• 将library以及module中的资源都加一个前缀来避免资源冲突（不是所有历史版本的SDK都遵循这个规范）；
• 在gradle.properties中添加android.disableResourceValidation=true可以忽略资源冲突的编译错误，程序会采用第一个找到的同名资源作为实际资源（资源覆盖可能会导致某些错误）

3.2 动态库冲突

在application中动态库冲突可以使用pickFirst指定第一个，但是这个无法适用于library中。

关于packagingOptions常见的设置项有exclude、pickFirst、doNotStrip、merge。

1. exclude，过滤掉某些文件或者目录不添加到APK中，作用于APK，不能过滤aar和jar中的内容。

比如：

packagingOptions {

    exclude 'META-INF/**'

    exclude 'lib/arm64-v8a/libopus.so'

}

2. pickFirst，匹配到多个相同文件，只提取第一个。只作用于APK，不能过滤aar和jar中的文件。

比如：

 packagingOptions {

    pickFirst "lib/armeabi-v7a/libopus.so"

    pickFirst "lib/armeabi-v7a/libopus.so" 

 }

3. doNotStrip，可以设置某些动态库不被优化压缩。

比如：

 packagingOptions{

    doNotStrip "*/armeabi/*.so"

    doNotStrip "*/armeabi-v7a/*.so"

 }

4. merge，将匹配的文件都添加到APK中，和pickFirst有些相反，会合并所有文件。

比如：

packagingOptions {

    merge '**/LICENSE.txt'

    merge '**/NOTICE.txt'

}

最后针对包含冲突动态库的SDK，单独对外依赖，在application中pickfirst，暂时没有特别好的方法。

3.3 外部依赖库

SDK中有些依赖的是外部公共仓库，比如OKHTTP等，如果都合并到同一的AAR，会导致外部依赖不够灵活，我们的思路是合并的时候不合并外部SDK，只打包公司内部SDK,并打印外部依赖的SDK，提供给外部手动依赖：

1. 先定义内部SDK规则方法：

static boolean isInnerDep(RenderableDependency dep) {

    return (dep.name.contains("com.xxx")

        || dep.name.contains("com.xxxxx")

        || dep.name.contains("com.xxxxxxx")

        || dep.name.contains("com.xxxxxxxx"))

}

2. 定义三个集合：

//所有的内部库依赖

Map<String, String> allInnerDeps = new HashMap<>()

//所有的非内部依赖：公共平台库

Map<String, String> allCommonDeps = new HashMap<>()

//库的类型，jar 或者 aar，依赖方式不同

Map<String, String> depType = new HashMap<>()

3. 分析依赖，放到不同集合打印、合并：

void collectDependencies(Map<String, String> commonDependencies, Map<String, String> innerDependencies, RenderableDependency result) {

    String depName = result.name.substring(0, result.name.lastIndexOf(":"))

//    println "denName = " + depName

    String version = result.name.substring(result.name.lastIndexOf(":") + 1, result.name.length())



    if (result.getChildren() != null && result.getChildren().size() > 0) {

        if (isInnerDep(result) && !isExcludeDep(result)) {

            tryToAdd(innerDependencies, depName, version)

            result.getChildren().each {

                res ->

                    collectDependencies(commonDependencies, innerDependencies, res)

            }

        } else {

            tryToAdd(commonDependencies, depName, version)

        }

    } else {

        if (isInnerDep(result) && !isExcludeDep(result)) {

            tryToAdd(innerDependencies, depName, version)

        } else {

            tryToAdd(commonDependencies, depName, version)

        }

    }

}



configurations.findAll { conf ->

    return conf.name == "implementation" || conf.name == "api"

}.each {

    conf ->

//        println "--------------"+conf.name

        def copyConf = conf.copy()

        copyConf.setCanBeResolved(true)

        copyConf.each {

            file ->

                String s = file.name.substring(0, file.name.lastIndexOf("."))

                String key

                if (s.contains("-SNAPSHOT")) {

                    String t = (s.substring(0, s.lastIndexOf("-SNAPSHOT")))

                    key = t.substring(0, t.lastIndexOf("-"))

                } else {

                    key = s.substring(0, s.lastIndexOf("-"))

                }

                String value = file.name.substring(file.name.lastIndexOf("."), file.name.length())

                depType.put(key, value)

        }

        ResolutionResult result = copyConf.getIncoming().getResolutionResult()

        RenderableDependency depRoot = new RenderableModuleResult(result.getRoot())

        depRoot.getChildren().each {

            d ->

                collectDependencies(allCommonDeps, allInnerDeps, d)

        }



}

println("==================内部依赖====================")



allInnerDeps.each {

    dep ->

        println dep.key + ":" + dep.value



        dependencies {

            String key = dep.key.substring(dep.key.lastIndexOf(":") + 1, dep.key.length())

            String type = depType.get(key)

            if (type == ".aar") {

                embed(dep.key + ":" + dep.value + "@aar")

            } else {

                embed(dep.key + ":" + dep.value)

            }

        }

}



println "=====================正确使用 sdk，需要添加如下依赖========================"

allCommonDeps.each {

    dep ->

        println "api " + """ + dep.key + ":" + dep.value + """

}

3.4 对外提供多个业务SDK

我们提供一个同一AAR后，另一个业务也要对外提供SDK，这样有公共依赖的就会有冲突问题，如果都合并成一个，某一方改动，势必会引起另一方回归测试，最后抽取公共的sdk合并成一个aar，各自业务合并各自的AAR。

4. 参考资料

使用fat-aar编译打包多个aar库 - 简书

fat-aar实践及原理分享 - 简书

github.com/kezong/fat-…

GitHub - adwiv/android-fat-aar: Gradle script that allows you to merge and embed dependencies in generted aar file

5. 总结

本文介绍了Android对外输出AAR和不依赖maven，通过合并多个AAR的方式减少依赖方成本，并介绍了实际使用过程中遇到的问题和解决方案。

写kotlin越来越久，很多代码虽然能看懂，并且能去改，但是不知道他用了啥，里面的原理是什么，举个例子？大家一起学习一下吧

内联函数

顾名思义，但是在项目中我遇到得很少，他比较适用于一些包装方法的写法，比如下面这个

inline fun measureTimeMillis(block: () -> Unit): Long {

    val startTime = System.currentTimeMillis()

    block()

    return System.currentTimeMillis() - startTime

}



val time = measureTimeMillis {

    // code to be measured here

}

println("Time taken: $time ms")

这样的函数，以后如果想要测一段代码的运行时间，只需要将measureTimeMillis包着他就行

类型别名

一个很神奇的东西，允许为现有类型定义新名称

data class Person(val name: String, val age: Int)

typealias People = List<Person>



val people: People = listOf(

    Person("Alice", 25),

    Person("Bob", 30),

    Person("Charlie", 35)

)



fun findOlderThan(people: People, age: Int): People {

    return people.filter { it.age > age }

}



fun main() {

    val olderPeople = findOlderThan(people, 30)

    println(olderPeople)

}

其中People就是一个别名，如果使用typealias替代直接定义list，项目中就会少很多后缀为list的列表，少了类似于personlist这种变量，在搜索，全局替换，修改时也会更加直观看到person和people的区分场景

typealias可以被大量使用在list, map乃至于函数中，因为这些命名可能会比较长，替换后可以提高可读性

高阶函数

一个一开始很难理解，理解后又真香的函数，我愿称理解的那一刻为程序员进阶闪耀时，当一个老程序员回首往事时，他不会因为虚度年华而悔恨，但是一定会因为不懂高阶函数而羞耻

尤其是在项目中发现这种函数，又看不懂时，是万万不敢问同事的，所以，请现在就了解清楚吧

fun calculate(x: Int, y: Int, operation: (Int, Int) -> Int): Int {

    return operation(x, y)

}



fun main() {

    val sum = calculate(10, 5) { x, y -> x + y }

    println("Sum is $sum")



    val difference = calculate(10, 5) { x, y -> x - y }

    println("Difference is $difference")

}

可以看到，calculate其实并没有做什么，只是执行了传入进来的operation,这，就是高阶函数，所谓领导也是如此，优秀的下属，往往将方案随着问题传入进来，领导只要批示一下执行operation即可

配合上lambda原则，最后一个参数可以提出到括号外面，也就是讲operation提出到外面的{}中，交给调用方自己执行，就形成了这样的写法

    val sum = calculate(10, 5) { x, y -> x + y }

理解这一点后，一下子就清晰了很多，calculate看起来什么都没做，他却成为了世界上功能最强大，最灵活，bug最少的计算两个数运算结果的函数

深入

了解上面分析，已经足够我们在kotlin项目中进阶了，现在，我们来看下高阶函数反编译后的java代码

public final class TestKt {

   public static final int calculate(int x, int y, @NotNull Function2 operation) {

      Intrinsics.checkNotNullParameter(operation, "operation");

      return ((Number)operation.invoke(x, y)).intValue();

   }



   public static final void main() {

      int sum = calculate(10, 5, (Function2)null.INSTANCE);

      String var1 = "Sum is " + sum;

      System.out.println(var1);

      int difference = calculate(10, 5, (Function2)null.INSTANCE);

      String var2 = "Difference is " + difference;

      System.out.println(var2);

   }



   // $FF: synthetic method

   public static void main(String[] var0) {

      main();

   }

}

虽然java的实现太不优雅，但是我们可以看出，高阶函数，本质上传入的函数是一个名为Function2的对象，

public interface Function2<in P1, in P2, out R> : Function<R> {

    /** Invokes the function with the specified arguments. */

    public operator fun invoke(p1: P1, p2: P2): R

}

他是kotlin包自带的函数，看起来可以用来在反编译中替换匿名lambda表达式，将其逻辑移动到自身的invoke中，然后生成一个Function2对象，这样实现kotlin反编译为java时的lambda替换

这也是高阶函数得以实现的根本原因

1. 背景

• Gson 作为 json 解析最有名的库，我们也在多处使用或借鉴其实现。但是 json解析本就存在很多问题，并且这些问题轻则导致数据丢失，重则直接崩溃，我们应该对他引起重视。在项目更新kotlin之后，更由于gson库是基于java设计的，进而引出了我们今天遇到的问题。

2. 问题

• 当通过 kotlin 调用 Gson.fromJson(“json”, Class<T>) 解析 json，并且对象通过 kotlin 创建时，有可能在非空的字段解析出 null，例如使用下列 json 和 class 进行解析。

data class LowGsonData(

  @SerializedName("name") var name: String,

  @SerializedName("age") var age: Int,

  @SerializedName("address") var address: String

)



data class LowGsonData(

  @SerializedName("name") var name: String = "",

  @SerializedName("age") var age?: Int = 0,

  @SerializedName("address") var address: String = ""

)



class TestGson {

  @Test

  fun test() {

    val json = "{\"name\":\"cong\",\"age\":11}"

		// val json2 = "{\"name\":,\"age\":11}"

    val testData = Gson().fromJson(json, LowGsonData::class.java)

    println("testData: name = ${testData.name} age = ${testData.age} address = ${testData.address}")

  }

}

• 在我们使用上述两个LowGsonData对json进行解析时，我们关注一下 testData.address 会被解析为什么？

address 不是非空的吗？为什么这里address是空？这样在业务代码很容易因为kotlin的空安全检测，导致空指针问题！

3. 寻找原因

1.把kotlin data转为java

• 因为 kotlin 最终都是转化成 java 字节码运行在虚拟机上的，所以我们先把这个类转为 java 代码方便我们看清这个对象的本质

public final class TestGsonData {

   @SerializedName("name")

   @NotNull

   private String name;

   @SerializedName("age")

   private int age;

   @SerializedName("address")

   @NotNull

   private String address;

   

   public TestGsonData(@NotNull String name, int age, @NotNull String address) {

       Intrinsics.checkNotNullParameter(name, "name");

       Intrinsics.checkNotNullParameter(address, "address");

       super();

       this.name = name;

       this.age = age;

       this.address = address;

   }

}

• 看着好像没啥问题，调用这个构造函数依然能保证数据非空。那我们就需要继续分析gson是怎么构造出对象的？

2.分析Gson是如何构造对象的

• Gson 的逻辑，一般都是根据读取到的类型，然后找对应的 TypeAdapter 处理，本例为普通自定义对象，所以会最终走到 ReflectiveTypeAdapterFactory.create 返回相应的 TypeAdapter。其中包含构造对象的方法 3 个：

（1）newDefaultConstructor ：我们大部分对象都是通过这个地方创建的，获取无参的构造函数，如果能够找到，则通过 newInstance反射的方式构建对象。

private <T> ObjectConstructor<T> newDefaultConstructor(Class<? super T> rawType) {

    try {

      final Constructor<? super T> constructor = rawType.getDeclaredConstructor();

      if (!constructor.isAccessible()) {

        constructor.setAccessible(true);

      }

      return new ObjectConstructor<T>() {

        @SuppressWarnings("unchecked") // T is the same raw type as is requested

        @Override public T construct() {

            Object[] args = null;

            return (T) constructor.newInstance(args);

            

            // 省略了一些异常处理

      };

    } catch (NoSuchMethodException e) {

      return null;

    }

  }

（2）newDefaultImplementationConstructor：都是一些集合类相关对象的逻辑。

（3）newUnsafeAllocator：通过 sun.misc.Unsafe 构造了一个对象，是用来访问 hidden API，以及获取一定的操作内存的能力。

public static UnsafeAllocator create() {

	// try JVM

	// public class Unsafe {

	//   public Object allocateInstance(Class<?> type);

	// }

	try {

	  Class<?> unsafeClass = Class.forName("sun.misc.Unsafe");

	  Field f = unsafeClass.getDeclaredField("theUnsafe");

	  f.setAccessible(true);

	  final Object unsafe = f.get(null);

	  final Method allocateInstance = unsafeClass.getMethod("allocateInstance", Class.class);

	  return new UnsafeAllocator() {

	    @Override

	    @SuppressWarnings("unchecked")

	    public <T> T newInstance(Class<T> c) throws Exception {

	      assertInstantiable(c);

	      return (T) allocateInstance.invoke(unsafe, c);

	    }

	  };

	} catch (Exception ignored) {

	}

  

	// try dalvikvm, post-gingerbread use ObjectStreamClass

	// try dalvikvm, pre-gingerbread , ObjectInputStream



}

• 现在我们已经知道了，当这个对象没有无参构造函数时，第一个方法不成立，最终会通过 unSafe 方式构建对象。虽然 gson 自身的设计，通过三种方式来保证对象创建成功很棒，但是这恰好在Unsafe构造中绕过了 kotlin 的空安全检查。

• 所以 Unsafe 为啥没能符合空安全呢？

  因为 UnSafe 是直接获取内存中的值， String 对象在没有赋值时正好是 null，并且 json 里没有对应值，最后将不会覆盖他。

• 好的真相大白了，那有什么改进方法吗？有，尽量满足第一个条件。

• kotlin 的 data calss 只要有一个属性没有给初始值就不会生成无参构造方法。所以要想保证 gson 解析场景的非空性，我们应该给所有非可空属性附初始值。或者一开始就设置可空，并在业务代码中判空。

data class FullGsonData(

  @SerializedName("name") var name: String = "",

  @SerializedName("age") var age: Int = 0,

  @SerializedName("address") var address: String = ""

)

• 但是全都这么写吗？毕竟有些对象在业务中需要构造方法传入一些必传的值。那我就比较贪心，我既要又要还要。

• 我的想法： 在聊天 elem 的场景，结合业务，封装一个工厂供业务构造对象。并在 data class 中继续保持非空构造。

• 有没有其他好的想法？

  • 通过 kotlin 插件规避

4. 如何规避该问题：

经过调研我认为比较好的方式有：

1.引入noarg和allopen自动生成无参构造函数。

• http://www.kotlincn.net/docs/refere…
• juejin.cn/post/689303…

2.尝试对现有项目中使用的json解析库进行升级改造

如moshi，同时适配属性缺失、属性异常等在生产中可能会遇到的问题。

• juejin.cn/post/684490…
• juejin.cn/post/720957…

5. 参考：

• blog.csdn.net/lmj62356579…
• blog.csdn.net/java_cpp_/a…
• http://www.kotlincn.net/docs/refere…

背景

前菜

什么样的代码是整洁的？

衡量代码质量的唯一标准，是别人阅读你代码时的感受。所谓整洁代码，即可读性高、易于理解的代码。

不整洁的代码，阅读体验是这样的:

1. 乱(组织乱、职责乱、名称乱起)
2. 逻辑不清晰(if-else太多)
3. 绕弯子(简单的事写的很复杂)
4. 看不懂(只有写的人能理解)
5. 难修改(耦合严重，各种写死)

整洁的代码，阅读体验是这样的:

1. 清晰(是什么，做了什么，一眼看得出来)
2. 简单(职责少，代码少，逻辑少)
3. 干净(没有多余的逻辑)
4. 好拓展(依赖的比较少，修改不会影响很多)

为什么需要编写整洁的代码？

1. 保持代码整洁是程序员专业性的重要体现。 写软件就像是盖房子，很难想象一个地板不平、门窗关不严实的房子能称为一个大师制作。代码整洁可以体现一个人的专业水平和追求专业性的态度。

2. 读代码的时间远远大于写代码。 根据《整洁代码之道》作者在书中小数据量统计，读代码与写代码的时间比可能达到10:1，实际项目中虽然达不到这个比例，但是需要阅读其他同学代码的场景并不少见。让代码容易阅读和理解，可以优化阅读代码的时间成本和沟通成本。

3. 不整洁的代码带来诸多坏处。

   1. 每一笔不整洁的代码都是一笔技术债，迟早需要偿还，且随着时间的推移，偿还成本可能会越来越大。
   2. 烂代码难以理解，不敢改动，容易按住葫芦浮起瓢，修完一个bug又引入了另一个bug。
   3. 阅读不好的代码，会让人心情烦躁，充满负能量，是一种精神折磨。
   4. 容易引起破窗效应。当代码开始有一些bad smell，因为破窗效应，可能会导致代码越来越烂，不断积累形成“屎山”。

让代码变得整洁

命名

名副其实

在新建变量、函数或类的时候，给一个语义化的命名，不要因为害怕花时间取名字就先随手写一个想着以后再改（个人经验以后大概率是不会再改，或者想改的时候忘记要改哪里了）。如果名称需要注释来补充，那就不算是名副其实。

避免误导

起名字时，避免别人将这个名字误读成其他的含义。有以下几条准则可以使用：

• 避免使用和本意相悖的词。

e.g.表达一组账号的变量：

• 如果不是一个List类型，不要使用accountList。
• 建议使用accountGroup。

• 避免有歧义的命名。

e.g. 表达过滤后剩下的数据

• 不要使用filteredUsers，filter具有二义性，不清楚到底是被过滤的，还是过滤后剩下的。
• 建议使用removedUsers、remainedUsers来分别表示被过滤的和过滤后剩下的。

• 避免使用外形相似度高的名称。

e.g.简单和单选：

• 不要使用simple和single，外形相似，容易混淆。
• 建议使用easy和single。

• 避免使用不常见的缩写。

避免使用没有区分性的命名

• 避免使用一些很宽泛的词： 比如Product类和ProductInfo或者ProductData类名称虽然不同，但其实意思是一样的。应该使用更有区分性的命名。再比如，getSize可能返回一个数据结构的长度、所占空间等，改成getLength或getMemoryBytes则更合适一些。
• 避免tmp之类的名字： 除非真的是显而易见且无关紧要的变量，否则不要使用tmpXxx来命名。
• 修改 IDE 自动生成的 变量名 ： IDE自动生成变量名字，有些时候是没有语义的，为了易于理解，在生成代码后，顺便修改变量名字。

/// BAD: element表示的语义是啥？需要结合前面的selectedOptions来推断element的语义

List<String> get selectedKeys {

  return selectedOptions.map((element) => element.key).toList();

}



/// GOOD: 阅读代码即可知道获取的是已选选项的key

List<String> get selectedKeys {

  return selectedOptions.map((option) => option.key).toList();

}

给变量名带上重要的细节

• 表示度量的 变量名 带上单位： 如果变量是一个度量（长度、字节数），最好在名字中带上它的单位。比如：startMs、delaySecs、sizeMb等。
• 附带其他属性： 比如未处理的变量前面加上raw。

不使用魔法数字

遇到常量时，避免直接将魔法数字编写到代码中。这种方式有诸多坏处：

• 没有语义，需要思考这个魔法数字代表什么意思。进而导致这个代码只有写的人敢改。
• 如果该魔法数出现多次，之后修改时需要覆盖到每个使用之处，一旦有一处没改，就会有风险。
• 不便于搜索。

建议改为表达意图的常量，或使用枚举。

/// BAD: 需要耗费注意力寻找2的意义

if (status == 2) {

  retry();

}



/// GOOD: 改为表达意图的命名变量

const int timeOut = 2;

if (status == timeOut) {

  retry();

}

避免拼写错误

AndroidStudio有自带的拼写检查，平时在写代码的时候可以注意一下拼写错误提示。

注意变量名的长度

变量名不能太长，也不能太短。 太长的名字读起来太费劲，太短的名字读不懂是什么意思。那变量名长度到底多少最合适呢？这个问题没有定论，但是在决策变量名长度时，有一些准则可以使用：

• 在小的作用域里可以使用短的名字： 作用域小的标识符不用带上太多信息。
• 丢掉没用的词： 有时候名字中的某些单词可以拿掉且不会损失任何信息。例如：convertToString可以替换为toString。
• 使用常见的缩写降低变量长度： 例如，pre代替previous、eval代替evaluation、doc代替document、tmp代替temporary、str代替string。

e.g. 在方法里，使用tempMap命名，只需要理解它是用于临时存储，最后作为返回值；但是如果tempMap是在一个类中，那么看到这个变量可能就会比较费解了。

static Map<String, dynamic> toMap(List<Pair> valuePairs) {

  Map<String, dynamic> tempMap = {};

  for (final pair in valuePairs) {

    tempMap[pair.first] = pair.second;

  }

  return tempMap;

}

附：一些常用 命名规范 。

变量

删除没有价值的临时变量

当某个临时变量满足以下条件时，可以删除这个临时变量：

• 没有拆分任何复杂的表达式。
• 没有做更多的澄清，即表达式本身就已经比较容易理解了。
• 只用过一次，并没有压缩任何冗余代码。

/// BAD: 使用临时变量now

final now = datetime.datetime.now();

rootMessage.lastVisitTime = now;



/// GOOD: 去除临时变量now

rootMessage.lastVisitTime = datetime.datetime.now();

缩小变量的作用域

1. 谨慎使用全局变量。 因为很难跟踪这些全局变量在哪里以及如何使用他们，并且过多的全局变量可能会导致与局部变量命名冲突，进而使得代码会意外地改变全局变量的值。所以在定义全局变量时，问自己一个问题，它一定要被定义成全局变量吗？

2. 让你的变量对尽可能少的代码可见。 因为这样有效地减少了读者需要同时考虑的变量个数，如果能把所有的变量作用于都减半，则意味着同时需要思考的变量个数平均来说是原来的一半。比如：

   1. 当类中的成员变量太多时，可以将大的类拆分成小的类，让某些变量成为小类中的私有变量。
   2. 定义类的成员变量或方法时，如果不希望外界使用，将它定义成私有的。

3. 把定义下移。 把变量的定义放在紧贴着它使用的地方。不要在函数或语句块的顶端直接放上所有需要使用的变量的定义，这会让读者在还没开始阅读代码的时候强迫考虑这几个变量的意义，并在接下来的阅读中，不断地索引是哪个变量。

函数

1. 避免长函数

• 函数要短小！函数要短小！函数要短小！（重要的事情说三遍）
• 每个函数只做一件事。

如果发现一个函数太长，一般都是一个函数里干了太多事情，可以使用Extract Method(提取函数) 重构技巧，将函数拆分成若干个子功能，放到若干个子函数中，并给每个子函数一个语义化的命名（必要时可以添加注释）。这样既提高了函数的可读性，同时短小、单一功能的函数也方便复用。

避免太重的分支逻辑

if-else语句、switch语句、try-catch语句中，如果某个分支过于复杂，可以将该分支的内容提炼成独立的函数。这样不但能保持函数短小，而且因为块内调用的函数拥有较具说明性的名称，从而增加了文档上的价值。

/// BAD: if-else中语句多且繁杂

if (date.before(summerStart) || date.after(summerEnd)) {

  charge = quantity * winterRate + winterServiceCharge;

} else {

  charge = quantity * summerRate;

}



/// GOOD: 分别提炼函数

if (notSummer(date)) {

  charge = winterCharge(quantity);

} else {

  charge = summerCharge(quantity);

}

使用具有语义化的描述性名称给函数命名

1. 函数名称应具有描述性，别害怕长的名称。长而具有描述性的名称，要比短而令人费解的名称好。
2. 别害怕花时间取名字。

降低参数个数

1. 参数个数越少，理解起来越容易。同时也意味着单测需要覆盖的参数组合少，有利于写单测。

2. 当输入参数中有bool值时，建议使用Dart中的命名参数。

      /// BAD: bool类型取值只有true和false，无法理解在这个场景下取值的意义，必须得点到方法的声明里
   
      search(true);
   
   
   
      /// GOOD: 通过命名函数可以了解到取值的意义
   
      search(forceSearch : true);
   
   

3. 当输入参数过多时，建议将其中一些参数封装成类。不然后续每每增加一个参数，就得修改函数的声明。

      /// BAD: 函数参数中放置多个离散的数据项
   
      void initUser({
   
        required String key, 
   
        required String name,
   
        required int age,
   
        required String sex,
   
      }) {
   
        ...
   
      }
   
   
   
      /// GOOD: 将紧密相连的数据项聚合到一个类中
   
      class UserInfo {
   
        String key;
   
        String name;
   
        String sex;
   
        int age;
   
      }
   
   
   
      void initStore({required UserInfo user}) {
   
        ...
   
      }
   
   

分隔指令和查询

函数要么做什么事，要么回答什么事，二者不可得兼。函数应该修改某对象的状态，或是返回该对象的有关信息。两样都干常会导致逻辑混乱。

注释

真正好的注释只有一种，那就是通过其他方式不写注释。

1. 如果你发现自己需要写注释，再想想看能否用更清晰的代码来表达。
2. 为什么要贬低注释的价值？注释存在的时间越久，就离所描述的代码越远，变得越来越错误，因为程序员不能坚持维护注释。
3. 这个目标也并非铁律，项目中经常会存在一些千奇百怪背景的代码，指望全部靠代码表达是不可能的。

坏的注释

1. 臃肿的、不清楚的、令人费解的注释。 如果不确定注释写的是否合适，让你旁边的同学看下能不能看懂。
2. 简单的代码，复杂的注释。 阅读注释比代码本身更费时。
3. 有误导的注释。 随着业务迭代，在改代码的时候并没有更改对应的注释，导致代码逻辑与注释不匹配，引起误解，这对其他开发人员是致命的。
4. 显而易见的东西，没必要写注释。
5. 注释不需要的代码。 不需要的代码不要通过注释的方式保存，直接删掉就好。不然别人可能也不敢删除这段代码，会觉得放在那里是有原因的。
6. 注释不应该用于粉饰不好的设计。 比如给函数或变量随便取了个名字，然后花一大段注释来解释。应该想办法取个更易懂的名字。

好的注释

以下场景值得加上注释：

1. 代码中含有复杂的业务逻辑，或需要一定的上下文才能理解的代码。 如果希望阅读者对代码背景或代码设计有个全局的了解，可以附上相关的文档链接。
2. 用输入输出举例，来说明特别的情况。 相较于大段注释来说，一个精心挑选的输入、输出例子更有效。
3. 将一些晦涩的参数和返回值翻译成可读的东西。

assertTrue(a.compareTo(a) == 0);  // a == a

assertTrue(a.compareTo(b) != 0);  // a != b

4. 代码中的警告、强调，避免其他人调用代码时踩坑。 在写注释的时候问问自己：“这段代码有什么出人意料的地方？会不会被误用？”预料到其他人使用你的代码时可能会遇到的问题，再针对问题写注释。
5. 对代码的想法。 TODO（待办）、FIXME（有问题的代码）、HACK（对一个问题不得不采用的比较粗糙的解决方案）或一些自定义的注释（REFACTOR、WARNING）。
6. 在文件、类的级别上，使用“全局观”的注释来解释所有的部分是如何工作的。 用注释来总结代码块，使读者不至于迷失在细节中。
7. 代码注释应该仅回答代码不能回答的问题。 例如，方法注释应当应该写的是“为什么存在这个方法” 和 “方法做了什么”，而不是“方法是如何实现的”。如果方法注释过于关注方法“如何”工作，那么随着代码的不断变化，它很快就会过时。当开发人员依赖过时的注释来理解方法的工作原理时，这可能会导致混淆和错误。

格式

限制单个文件的代码行数

上图统计了Java中一些知名项目的每个文件的代码行数。可以看到都是由很多行数比较小的文件构成，没有超过500行的单独文件，大多数都少于200行。

小文件通常比大文件更加容易理解。 虽然这不是一个硬性规定，但一般一个文件不应该超过200行，且上限为500行。

dart中，可以通过part字段，对长文件进行拆分。

2. 限制代码的长度

眼睛在阅读高而窄的文本时会更舒服，这正是报纸文章看起来是这样的原因：避免编写太长的代码行是一个很好的做法。另外，短行代码在使用三栏方式解冲突的时候，不需要横向滚动，更容易发现冲突的内容。

/// BAD: 参数放在一行展示

Future navigateToXxxPage({required BuildContext context, required Map<String, dynamic> queryParams, Object? arguments,});



/// GOOD: 每个参数一行展示，更清晰

Future navigateToXxxPage({

  required BuildContext context, 

  required Map<String, dynamic> queryParams, 

  Object? arguments,

});

合理使用代码中的空行

源代码中的空行可以很好的区分不同的概念。反之，内容相关的代码不应该空行，应该紧贴在一起。

变量、函数声明

1. 变量的声明应尽可能接近它使用的地方。 类的成员变量的声明应该出现在类的顶部。局部使用的变量应该声明在它使用之处附近。
2. Dart函数中参数的声明，required标记的参数尽量归在一起。
3. 如果有一堆变量要声明（类的成员变量、函数的参数），可以从重要的到不重要的进行排序。
4. 如果一个函数调用另一个函数，它们应该在垂直上靠近，并且如果可能的话，调用者应该在被调用者之上。 在一般情况下，我们希望函数调用依赖关系指向向下的方向。也就是说，一个被调用的函数应该在一个执行调用的函数下面。像在看报纸一样，我们期待最重要的概念最先出现，低层次的细节出现在最后。

简化控制流、表达式

如果代码中没有条件判断、循环或者任何其他的控制流语句，那么它的可读性会很好。而跳转和分支等部分则会很快地让代码变得混乱。

调整条件语句中参数的顺序

比较的左值为变量，右值为常量。这种方式更符合自然语言的顺序。

/// BAD: 

if (10 <= length)



/// GOOD:

if (length >= 10)

调整if-else语句块的顺序

在写if-else语句的时候：

• 首先处理正逻辑而不是负逻辑的情况。例如，用if(debug)而不是if(!debug)。
• 先处理掉简单的情况。这种方式可能还会使得if和else在屏幕之内都可见。
• 先处理有趣的或者是可疑的情况。

合并相同返回值

当有一系列的条件测试返回同样的结果时，可以将这些测试合并成一个条件表达式，并将这个条件表达式提炼成一个独立函数。/// BAD: 多个条件分开写，但是返回了同一个值。

int test() {

  final bool case1 = ...;

  final bool case2 = ...;

  final bool case3 = ...;

  if (case1) {

    return 0;

  }

  if (case2) {

    return 0;

  }

  if (case3) {

    return 0;

  }

  return 1;

}



/// GOOD：将统一返回值对应的条件合并。

int test() {

  if (shouldReturnZero()) {

    return 0;

  }

  return 1;

}



bool shouldReturnZero() {

  final bool case1 = ...;

  final bool case2 = ...;

  final bool case3 = ...;

  return case1 || case2 || case3;

}

不要追求降低代码行数而写出难理解的表达式

三目运算符可以写出紧凑的代码，但是不要为了将所有代码都挤到一行里而使用三目运算符。三目运算符应该是从两个简单的值中做选择，如果逻辑复杂，使用if-else更好。

/// BAD: 

return exponent >= 0 ? mantissa * (1 << exponent): mantissa/(1<<-exponent);



/// GOOD:

if (exponent >= 0) {

  return mantissa * (1 << exponent);

} else {

  return mantissa / (1 << -exponent);

}

避免嵌套过深

条件表达式通常有两种表现形式：

• 所有分支都属于正常行为（使用if-else形式）。
• 只有一种是正常行为，其他都是不常见的情况（if-if-if...-正常情况）。

嵌套过多深使代码更难读取和跟踪，可以尽量将代码转为以上两种标准的if形式。

/// BAD: if-else嵌套太深，难以理解逻辑。

void test() {

  if (case1) {

    return a;

  } else {

    if (case2) {

      return b;

    } else {

      if (case3) {

        return c;

      } else {

        return d;

      }

    }

  }

}



/// GOOD: 先处理非正常情况，直接退出，再处理正常情况，降低理解成本

void test() {

  if (case1) return a;

  if (case2) return b;

  if (case3) return c;

  return d;

}

不要使用if-else代替switch

一般使用switch的场景，都是某个变量有可枚举的取值，比如枚举类型，不要使用if-else来代替枚举值的判断：

enum State {success, failed, loading}



/// BAD: 对于现在的流程是没问题，但是万一新增了一个State，忘记修改这里，就会出现风险;

/// 况且switch本身就适合在这种场景下使用。

void fun() {

  if (state == State.success) {

    // do something when success

  } else if (state == State.failed) {

    // do something when failed

  } else {

    // do something when loading

  }

}



/// GOOD: 当State新增了一个枚举值时，这里会报错，必须修改这里才能编译通过

void fun () {

  switch (state) {

    case State.success:

      // do something when success

      break;

    case State.failed:

      // do something when failed

      break;

    case State.loading:

      // do something when loading

      break;

  }

}

让表达式更易读

日常写代码时，最常见的一个现象就是if语句的条件中，包含了大量的与或非表达式，如果表达式的逻辑简单还好，一旦表达式开始嵌套或多个与或非并列，那么对于理解代码的人来说将是一个灾难。遇到这种情况，可以使用以下的技巧，逐步优化代码：

1. 提取解释变量。 引入额外的变量，来表示一个小一点的子表达式。

   /// BAD: 阅读代码的人需要理解line.split(":")[0].trim()代表什么，当没有注释时往往纯靠猜测
   
   if (line.split(":")[0].trim() == "root") {
   
     // xxx
   
   }
   
   /// GOOD: 快速理解line.split(":")[0].trim()的语义，便于理解if条件表达式
   
   final userName = line.split(":")[0].trim();
   
   if (userName == "root") {
   
     // xxx
   
   }
   
   
   
   /// BAD: 理解这个表达式需要花多久？
   
   if (line.split(":")[0].trim() == "root" || line.split(":")[1].trim() == "admin") {
   
     // xxx
   
   }
   
   /// GOOD: 还是这个更容易理解？
   
   final isRootUser = line.split(":")[0].trim() == "root";
   
   final isAdminUser = line.split(":")[1].trim() == "admin";
   
   if (isRootUser || isAdminUser) {
   
     // xxx
   
   }
   
   

2. 使用总结变量。 当if语句的条件比较复杂时，将整个条件表达式使用一个总结变量代替。

   /// BAD: 阅读代码的人需要理解什么情况下能进入if语句，代表什么语义
   
   if (newSelect != null && preSelect != null && newSelect != preSelect) {
   
     // xxx
   
   }
   
   /// GOOD: 快速理解if语句的语义，如果关注细节，再看表达式的构成
   
   final selectionChanged = newSelect != null && preSelect != null && newSelect != preSelect;
   
   if (selectionChanged) {
   
     // xxx
   
   }
   
   

3. 减少非逻辑嵌套。 对于一个bool表达式，有一下两种等价写法，大家可以自行判断哪个更加可读。

   /// BAD: 阅读代码的人需要理解什么情况下能进入if语句，代表什么语义
   
   if (!(fileExists && !isProtected)) {
   
     // xxx
   
   }
   
   /// GOOD: 快速理解if语句的语义，如果关注细节，再看表达式的构成
   
   if (!fileExists || isProtected) {
   
     // xxx
   
   }
   
   

类

类应该短小

与函数一样，在设计类时，首要规则就是尽可能短小。对于函数，评价的指标是代码行数；对于类，评价指标则为职责，即如果无法为某个类取个精准的名称，那就表明这个类太长了。

那么，如何让类保持短小呢？这里需要先介绍一条原则：

单一职责原则：即类或模块应有且只有一条加以修改的理由，即一个类只负责一项职责。

使用单一职责，将大类拆分为若干内聚性高的小类，即可实现类应该短小的规则。

• 所谓内聚，即类应该只有少量实体变量，类中的每个方法都应该操作一个或多个这种变量。通常而言，方法操作的变量越多，则内聚性越高。
• 让代码能运行和保持代码整洁，是截然不同的两项工作。大多数人往往把精力花在了前者，这是没问题的。问题在于，当代码能运行后，不是马上转向实现下一个功能，而是回头将臃肿的类切分成只有单一职责的去耦合单元。
• 许多开发者可能会觉得使用单一职责会导致类的数量变多，但其实这种方式会让复杂系统中的检索和修改变得更加清晰简单。

为修改而组织

编写代码时，需要考虑以后的修改是否方便，降低修改代码的风险。

开放封闭原则 ：类应当对扩展开放，对修改关闭。

单元测试

• 软件界旷世之架：测试驱动开发（TDD）之争
• 测试篇——测试驱动开发(TDD)

测试驱动开发(Test-Driven Development, TDD)，要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。 这有助于编写简洁可用和高质量的代码，并加速开发过程。

虽然在日常开发中，我们并不是按照这种方式开发，但是这种思想对于提高代码能力大有裨益。也许你会好奇，这种测试先行的方法与测试后行的方法有什么区别？总结下来就是：

• 假如你首先编写 测试用例 ，那么你将可以更早发现缺陷，同时也更容易修正它们。 当你聚焦在一个方法时，将会更容易发现这个方法的边界case，而我们代码中大部分的缺陷都是由于一些边界case疏漏导致的。
• 在编写代码之前先编写 测试用例 ，能更早地把需求上的问题暴露出来。 在写业务代码前，先思考测试用例有哪些，一些边界问题自然就会浮出水面，迫使你去解决。
• 首先编写 测试用例 ，将迫使你在开始写代码之前至少思考一下需求和设计，而这往往会催生更高质量的代码。 写测试，你就会站在代码用户的角度来思考，而不仅仅是一个单纯的实现者，因为你自己要使用它们，所以能设计一个更有用，更一致的接口。另外为了保证代码的可测性，也迫使你会将不同的逻辑解耦，降低测试需要的上下文。

保持测试整洁

• 如果没有测试代码，程序员会不敢动他的业务代码。 这点在改表单、计算引擎逻辑时深有体会，经常按下葫芦浮起瓢。

• 修改业务代码的同时，相应的测试代码也需要修改。 如果单测不能跑，那单测就毫无意义，写单测并不是为了应付，而是保证代码的正确性，所以不要因为懒得修改导致破窗效应。

• 如何让测试代码整洁？ 可读性！可读性！可读性！单元测试中的可读性比生产代码中更加重要。测试代码中，相同的代码应抽象在一起，遵循 Build-Operate-Check 原则，即每一个测试应该清晰的由以下这三个部分组成：

  • Build： 构建测试数据。
  • Operation： 操作测试数据。
  • Check： 检验操作是否得到期望结果。

• 每个 测试用例 只做一件事。 不要写出超长的测试函数。如果想要测试3个功能，就是拆成3个测试用例。

整洁测试规则(F.I.R.S.T)

• 快速(Fast) ：测试代码需要执行得很快。测试运行慢→不想频繁运行测试代码→不能尽早发现生产代码的问题→代码腐坏。
• 独立(Independent)：测试代码不应该相互依赖，某个测试不应该成为下一个测试的设定条件。测试代码都应该可以独立运行，以及按任何顺序运行。当测试互相依赖时，会导致问题难以定位。
• 可重复(Repeatable)：测试代码应该在任何环境下都可以重复执行。
• 自足验证(Self-Validating) ：测试需要有一个bool类型的输出。不能通过看log判断测试是否通过，而应该通过断言。
• 及时(Timely)：测试代码需要及时更新，在编写业务代码之前先写测试代码。如果程序员先写业务代码，很有可能造成写测试代码不方便的问题。

我对敏捷开发是源于10多年前看了一本关于迭代开发的书，从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的公司，被迫式的接触了许多“敏捷开发”，随着项目经历越来越多，慢慢的就开始有了更新的认识和想法。

但是在接触敏捷开发这个体系之前，自己有机会做一个项目，那个时候我开始将自己认为更有利于项目的管理工作做了一些应用，那个阶段我的主要做法是：

1、项目中开始划分更短的制品交互周期，而不是以前那样等待产品开发完毕后发布各种测试版本。
2、更充分与市场人员交流，在市场人员进行需求交底时，让更多的甚至全体成员参与会议，了解产品的原始业务及需求。并且在过程中有问题也及时的解答及沟通。
3、加强沟通力度，开发测试都在一起每天都会开个小会，通报每日的工作成果，将自己的问题说出来。
4、不同以往的发布频率，测试从项目开始便要切入到产品生产过程，而不是等到最后所有功能都完成后。从而大大减少变动对计划的影响。

在做这些工作的时候我并不知道敏捷开发这个东西，直到在2010年进入一个公司非常提倡敏捷开发，已经有了迭代周期、backlog、站立会议、周例会等等，在这个团队中对开发过程有各种规章要求，完全是制度化的，这在我加入的初期非常的不适应。事实上回头想想，那种方式已经变的不敏捷了，完全是一种教条式的应用。

后来自己有机会回到了老东家，开始自己带团队，很巧老东家被收购后开始推广敏捷开发，只不过因为不是总部，所以这次没有范本，完全由我自己来组织及控制。很高兴这个小团队几个月下来，个人觉得比较成功，当然后面也得到了公司的认可。

下面就敏捷开发分享一些应该着重注意的点，解决这些问题我想对任何开发团队都会有很大的帮助。

需求在开发中的重要性

大量的开发过程告诉我，需求在软件开发过程中是极其重要的。传统的开发强调初期的需求调研及需要分析，这个过程对于一些正规的团队会产生大量的文档，而后交由开发展开产品生产。

然而，事实却不是想象这么简单，无数的例子说明了一点，仅仅在需求调研过程中了解到的需求是无法保证的。数不清的例子告诉我们，需求是会变的，变的原因很多。在极端的情况下，有些客户签字的需求在开发完后，有需要变更也很正常。

所以需求是影响软件开发的第一重要因素，需求来源于业务，我们开发的产品不就是因为这些业务才去做的吗？如何需求都无法把握好，还谈什么开发出好用的产品？

然而如何做好需求呢？我想首先要确立需求的地位，然后只有通过不断的沟通、尝试、反馈向真实需求迈进。

强调人与人的交流

不管怎么样开发过程中主要还是靠人的，而且软件开发是个复杂的团体工程，一个小些的产品也会涉及到各类人：客户、业务分析、管理人员、程序员、测试员等等。这么多人在一起做事情，有一方没有处理好结果肯定就会有问题。

有这样一个例子：客户提出了一个会员管理功能需求，需求人员了解后组织了解决方案，于是交付了开发实现。而经过二个月无尽的黑夜之后交付，需求一看有个模块做的有偏差，但是已经来不及修改了。交给客户看后，发现这不是他们要的会员管理功能相差较大，另外在功能开发的这一段时间，客户又有了新想法，要对原先需求做调整。

这种例子可能大家经常经历吧？

这种问题在敏捷开发方法中提出了解决方法，就是通过不断的交付可用的制品。看起来很抽象，其实很简单。同样是上面的例子：
Ø 客户提出会员管理功能需求
Ø 需求人员在了解需求后与开发负责人商量，确定一个快迭代的开发计划，每二周向客户演示一次，并将这个计划与客户确认
Ø 确认后需求人员向全体成员讲解需求背景故事
Ø 开发负责人组织并确定迭代计划内容，明确每个迭代提交的产品目标、开发任务安排、测试跟踪计划
Ø 每个迭代过程中都由需求及测试进行确认每个任务的实现结果是否跑偏
Ø 后面就是每二周向客户演示一次产品，并获得客户的反馈
Ø 根据客户的反馈调整下个迭代计划，并继续下一个迭代
Ø 直到产品交付

通过上面的步骤，就不至于在开发完成后才知道用户的真实想法，因为很多用户对软件开发是没有概念的，他只知道自己有某种需求，但最开始是没有一个完整的概念的。所以就要通过不断的让用户看到产品的模型，这个过程用户才会逐步的对产品产生概念。同样的在过程中客户的提出需求变更也是在一定的可控制范围之内，这样一来可以大大的减少软件返工的情况，自然就不会拖延计划了。

而这个过程中，需求已经完成了一个真正的过渡，不再是一头重的情况了。他让需求从客户那快速的反馈到开发团队中。同样的，在开发不断的交付制品时，需求也更加及时的了解到产品的进度，把握开发人员开发的功能是否符合需求。
当然这并不是一个标准做法，不同的团队可以有不同的处理方式。这里只是想强调需求需要更多的投入到开发过程中去，及时的与客户沟通交流，了解到客户的真实想法。

强调文档的作用

我觉得很多对敏捷开发的一个误解就是不需要文档，敏捷开发并未抛弃文档。只是更强调更有效的方式使用文档。在很多传统开发方法中，特别是很多很正规的开发团队对文档的要求非常苛刻。然而事实是文档不易管理，最痛苦的是不好维护，文档需要随着变化而变化，比如需求调整、技术架构升级、产品维护等等。如果要保证文档的一致性，太难了。特别是对于一些无法进行有效管理的开发团队就更加明显，经常是软件已经几个版本了，文档却是两年前的。

但敏捷真的不需要文档吗？我想不是的，如何把文档做到好维护我想才是最重要的。文档到底指的指的什么？什么样的算文档？

提出上面两个问题，我们先想想经常说的文档的作用是什么？不就是一个传播工具吗？可以用作记录、给他人看、用于以后查看。有很多方法可就解决了这个问题，比如wiki系统。维护一个wiki系统，可以随时写，随时维护，可以方便的查找。嗯，多方便。

另外一个问题就是什么样的工作需要形成文档呢？

记得在前一家公司，维护一个10多年的老系统修改一个公式计算的BUG，但是怎么也不知道这个复杂的公式是什么意思，问过了公司大部分的人也无人可解。这时想，如果当初有那么一份文档，谢天谢地。

像这种关键的内容有份文档还是很重要的，否则随着时间推移，谁也不能保证能记得住当时为什么会这么干。

记得多年前一次记笔记的经历，我看了一篇文章了解了DELPHI实现单实例模式的方法，这种方法很酷。于是整理成了笔记写在了wiki上，第二天就得到了回复，帮助到了别外产品开发组的同事。

嗯，文档就是这样他具有传播性，你不可能跑去跟所有人说出你的想法，但是文档却更容易达成。他也有传承性，有些文档也许10多年后又起了重要作用。

团队协作

1、减少对开发人员的干扰

曾经接手一个产品的开发，最初遇到一个很头痛的问题，原先写好的迭代计划，而且工作量也较大，大家都在忙着。即便在这样的状态下，客服人员却经常跑来找某个程序员A维护各种系统问题，程序员A在一次维护中竟然导致了系统数据出现大面积错误。程序员A心理上承受着巨大的压力，而每天的这些问题又不得不解决，加之新版本又有很重的开发任务无法完成，最终导致整个开发计划变更。

我无法再忍受，找到了需求及客服的负责人，沟通后发现这些问题很多都是重复性的，主要是因为原先系统的不足。于是回去组织人员做了几个后台临时功能，并交付给了客服人员，之后就没有再来找过这位程序员A。后续我又找到了客服负责人，要求不能直接找开发人员解决这类问题，并与负责人约定了处理过程。

这是个例子，在实际情况中还有很多这种事情，甚至有很多开发人员要直接面对客户。我想对于职能型团队来说，开发团队最好是减少这些方面的干忧。当然对于一个人包干的情况就不讨论了。

大部分的人都不是超人，在一个时间段内处理超出自己负荷的工作是很难做好保质保量的。所以对于开发管理人员一定要考虑到这点，尽量让开发人员有比较好的工作进度环境，通过外界的方式来解决一些开发团队的干扰。

成功的前端工程师很会善用工具，这些年低代码概念开始流行，像国外的Mendix，国内的JNPF，这种新型的开发方式，图形化的拖拉拽配置界面，并兼容了自定义的组件、代码扩展，确实在B端后台管理类网站建设中很大程度上的提升了效率。

开源地址：http://www.yinmaisoft.com/?from=jueji…

任何信息化项目都可以基于 JNPF 开发出 ERP、OA、CRM、EHR 等各类管理系统。

这边强烈建议试试它，你会发现不一样的惊喜！心情舒畅还是很重要的，记得有一次迭代总结时，有个程序员总结说：发现心情舒畅自己的工作效率很高。呵呵。我想你也有同感吧。

2、不要忽略测试人员在开发阶段的作用

曾经多少次在项目发布前加班到深夜2点的情景还历历在目，那种感觉即快乐又痛苦。由于和客户签定的合同的交付日期就要到了，产品却迟迟未集成完成，测试只能干等着上网聊QQ。就在下班前的一刻发布了，测试开始了紧张的测试，在屏幕闪动中，一个个的BUG提交，直到流程都无法都走不下去，测试无奈了。第二天就要发布，实施人员就等着制品第二天出差。只有不断的改，再发布，无尽的循环。直到大家都憔悴的看着老大，终于老大说：还剩下的这几个问题无关紧要，大家回去吧。

几个月的开发过去后在总结会上，只能抱怨测试资源不足，时间太短，需求更改太多，需求更改后测试不知道。无数的问题一次一次的出现在同样的总结会议上。

上面的这个例子很多人应该经历过，真的测试只有最后一刻才能体现价值吗？我想不是的。

在后面的项目中我总结了这个问题的，针对每个开发任务要求进行测试验证。而测试如何验证呢？他需要知道这个开发任务的需求是如何，提前做好测试计划及测试用例，在接到开发制品后测试并提交BUG，这个工作是可以开发过程中就能不断的进行的。保证每一个任务的质量，可以大大减少后期集成的错误量。

另外根据敏捷开发的思想，测试团队在开发过程中也需要加强与开发团队的交流，甚至有必要组成虚拟团队，位置调整到一起，这样可以及时快速的交流，参加开发团队的站立会议同样可以及时了解到开发的实际情况及进度，反过来把握测试计划及测试内容。

特别是测试从另一个角度来审视需求，这样也可以一定程度上发现或者改善需求上的不足。

3、发挥团队人员的潜力

敏捷开发比较提倡开发任务由开发自己评估并认领工作任务，这样可以激发开发的潜在动力。

之前在做一个新产品时，需要使用java，而我们团队是使用C#的，面临转型问题。而有一位同事很感兴趣，于是我就让他负责前期的框架探索与搭建。结果就是这位小伙工作效率很高，我最初给他的目标全部都完成了。最有意思的是后面产品开始研发时，这位小伙已经成为了团队的大牛，大家有问题都找他解决。也正是因为这个过程，这位小伙被全面激活，也在大家面前展示了能力。甚至在小伙离职时也被领导给予大幅涨薪来挽留。只不过谁又能想象到这位小伙进入我团队之前是因为被定为裁员的目标而调剂过来的呢!

所以充分发挥好每个人员的特点，让人能够在自己感兴趣的工作中，效果会很多。减少指派方式的任务的分配，充分发挥个人的主动性，这个团队精神面貌也会好很多。

4、管理者不要离团队太远

作为团队的Leader要参与到团队的工作中去，比如一个开发主管一定要写写代码，参与架构等对项目有关的事情，而不是在那里分分任务。这样团队成员才会觉得这个Leader很亲近感。

特别是有些开发主管在带队后离团队越来越远，有时对于开发进度不如意时就说：“这么个简单功能怎么会搞了这么久？”，其实每天都在加班的同事心里想着：“有本事你来？”，即使这个小组长有这个能力，但对于团队来说也不是一件好事，因为大家都抱有怨恨之心，还谈什么好好工作呢？这个小组长就是失职的。所以这种情况下应该主动去了解进度滞后的原因，并且自己要加入到解决问题的工作中去，而不是在边上抱怨别人。

5、小组织不要搞太多的官

中国几千年的文化，官本位一直影响着我们，大家都想坐在那指挥，自己啥事也不用干，想想都惬意。在我们这个行业是不是发现也很类似？大家都想着干几年当个小组长，然后升个部门经理，当上CTO迎娶白富美。

团队的管理基本是事与人的管理，非常的伤脑和心。如果一个组织内，特别是小组织内“官”太多，协调就会非常的难，大家就会经常性的扯皮。

结束

与敏捷开发结缘也有几年，从开始的抵触到后面的认可经历了许多，这个过程并不是一蹴而就的，需要花时间花精力，特别是要去实践、总结。

还有我觉得是不能太教条，很多事情都要有怀疑的心，然后去实践总结，找到合适自己团队的方式方法。

注：此文章为原创，欢迎转载，请在文章页面明显位置给出此文链接！ 若您觉得这篇文章还不错请点击下右下角的推荐，非常感谢！

导读

程序员痛恨遇到质量低劣的代码，但在高压环境下，我们常为了最快解决当下需求而忽略代码规范，在无意识中堆积大量债务。我们还观察到许多开发者被迫加班的罪魁祸首便是写低效代码、不重视代码优化。编程路上，欲速则不达。 接下来，我将为各位列举9种我个人工作中高频遇到的不整洁代码行为，并提出针对性优化建议。继续阅读~

目录

1 代码风格和可读性

2 注释

3 错误处理和异常处理

4 代码复用和模块化

5 硬编码

6 测试和调试

7 性能优化

8 代码安全性

9 版本控制和协作

10 总结

01、代码风格和可读性

• 错误习惯

1.1 变量命名不规范

在编程中，变量命名是非常重要的，良好的变量命名能够提高代码的可读性和可维护性。不规范的命名会增加理解难度，以下是一个不规范命名的例子：

int a, b, c; // 不具有描述性的变量名

float f; // 不清楚变量表示的含义

这样的变量命名不仅会降低代码的可读性，还可能会导致变量混淆，增加代码维护的难度。正确的做法应该使用有意义的名称来命名变量。例如：

int num1, num2, result; // 具有描述性的变量名

float price; // 清晰明了的变量名

1.2 长函数和复杂逻辑

长函数和复杂逻辑是另一个常见的错误和坏习惯。长函数难以理解和维护，而复杂逻辑可能导致错误和难以调试。以下是一个长函数和复杂逻辑的案例：

def count_grade(score):

    if score >= 90:

        grade = 'A'

    elif score >= 80:

        grade = 'B'

    elif score >= 70:

        grade = 'C'

    elif score >= 60:

        grade = 'D'

    else:

        grade = 'F'

    

    if grade == 'A' or grade == 'B':

        result = 'Pass'

    else:

        result = 'Fail'

    return result

在这个例子中，函数 count_grade 包含了较长的逻辑和多个嵌套的条件语句，使得代码难以理解和维护。正确的做法是将逻辑拆分为多个小函数，每个函数只负责一个简单的任务，例如：

def count_grade(score):

    grade = get_grade(score)

    result = pass_or_fail(grade)

    return result

def get_grade(score):

    if score >= 90:

        return 'A'

    elif score >= 80:

        return 'B'

    elif score >= 70:

        return 'C'

    elif score >= 60:

        return 'D'

    else:

        return 'F'

def pass_or_fail(grade):

    if grade == 'A' or grade == 'B':

        return 'Pass'

    else:

        return 'Fail'

通过拆分函数，我们使得代码更加可读和可维护。

1.3 过长的行

代码行过长，会导致代码难以阅读和理解，增加了维护和调试的难度。例如：

def f(x):

    if x>0:return 'positive' elif x<0:return 'negative'else:return 'zero'

这段代码的问题在于，它没有正确地使用空格和换行，使得代码看起来混乱，难以阅读。正确的方法是，我们应该遵循一定的代码规范和风格，使得代码清晰、易读。下面是按照 PEP 8规范改写的代码

def check_number(x):

    if x > 0:

        return 'positive'

    elif x < 0:

        return 'negative'

    else:

        return 'zero'

这段代码使用了正确的空格和换行，使得代码清晰、易读。

02、注释

• 错误习惯

• 错误的注释

注释是非常重要的，良好的注释可以提高代码的可读性和可维护性。以下是一个不规范的例子：

int num1, num2; // 定义两个变量

上述代码中，注释并没有提供有用的信息，反而增加了代码的复杂度。

03、错误处理和异常处理

• 错误的习惯

3.1 忽略错误

我们往往会遇到各种错误和异常。如果我们忽视了错误处理，那么当错误发生时，程序可能会崩溃，或者出现不可预知的行为。例如：

def divide(x, y):

    return x / y

这段代码的问题在于，当 y 为0时，它会抛出 ZeroDivisionError 异常，但是这段代码没有处理这个异常。下面是改进的代码：

def divide(x, y):

    try:

        return x / y

    except ZeroDivisionError:

        return 'Cannot divide by zero!'

3.2 过度使用异常处理

我们可能会使用异常处理来替代条件判断，这是不合适的。异常处理应该用于处理异常情况，而不是正常的控制流程。例如：

def divide(a, b):

    try:

        result = a / b

    except ZeroDivisionError:

        result = float('inf')

    return result

在这个示例中，我们使用异常处理来处理除以零的情况。正确做法：

def divide(a, b):

    if b == 0:

        result = float('inf')

    else:

        result = a / b

    return result

在这个示例中，我们使用条件判断来处理除以零的情况，而不是使用异常处理。

3.3 捕获过于宽泛的异常

捕获过于宽泛的异常可能导致程序崩溃或隐藏潜在的问题。以下是一个案例：

try {

    // 执行一些可能抛出异常的代码

} catch (Exception e) {

    // 捕获所有异常，并忽略错误}

在这个例子中，异常被捕获后，没有进行任何处理或记录，导致程序无法正确处理异常情况。正确的做法是根据具体情况，选择合适的异常处理方式，例如：

try {

    // 执行一些可能抛出异常的代码

} catch (FileNotFoundException e) {

    // 处理文件未找到异常

    logger.error("File not found", e);

} catch (IOException e) {

    // 处理IO异常

    logger.error("IO error", e);

} catch (Exception e) {

    // 处理其他异常

    logger.error("Unexpected error", e);}

通过合理的异常处理，我们可以更好地处理异常情况，增加程序的稳定性和可靠性。

04、错误处理和异常处理

• 错误的习惯

4.1 缺乏复用性

代码重复是一种非常常见的错误。当我们需要实现某个功能时，可能会复制粘贴之前的代码来实现，这样可能会导致代码重复，增加代码维护的难度。例如：

   def calculate_area_of_rectangle(length, width):

       return length * width



   def calculate_volume_of_cuboid(length, width, height):

       return length * width * height



   def calculate_area_of_triangle(base, height):

       return 0.5 * base * height



   def calculate_volume_of_cone(radius, height):

       return (1/3) * 3.14 * radius * radius * height

上述代码中，计算逻辑存在重复，这样的代码重复会影响代码的可维护性。为了避免代码重复，我们可以将相同的代码复用，封装成一个函数或者方法。例如：

   def calculate_area_of_rectangle(length, width):

       return length * width



   def calculate_volume(length, width, height):

       return calculate_area_of_rectangle(length, width) * height



   def calculate_area_of_triangle(base, height):

       return 0.5 * base * height



   def calculate_volume_of_cone(radius, height):

       return (1/3) * 3.14 * radius * radius * height

这样，我们就可以避免代码重复，提高代码的可维护性。

4.2 缺乏模块化

缺乏模块化是一种常见的错误，这样容易造成冗余，降低代码的可维护性，例如：

   class User:

       def __init__(self, name):

           self.name = name



       def save(self):

           # 保存用户到数据库的逻辑



       def send_email(self, content):

           # 发送邮件的逻辑



   class Order:

       def __init__(self, user, product):

           self.user = user

           self.product = product



       def save(self):

           # 保存订单到数据库的逻辑



       def send_email(self, content):

           # 发送邮件的逻辑

   ```

此例中，User 和 Order 类都包含了保存和发送邮件的逻辑，导致代码重复，耦合度高。我们可以通过将发送邮件的逻辑提取为一个独立的类，例如：

   class User:

       def __init__(self, name):

           self.name = name



       def save(self):

           # 保存用户到数据库的逻辑



   class Order:

       def __init__(self, user, product):

           self.user = user

           self.product = product



       def save(self):

           # 保存订单到数据库的逻辑



   class EmailSender:

       def send_email(self, content):

           # 发送邮件的逻辑

通过把发送邮件单独提取出来，实现了模块化。现在 User 和 Order 类只负责自己的核心功能，而发送邮件的逻辑由 EmailSender 类负责。这样一来，代码更加清晰，耦合度降低，易于重构和测试。

05、硬编码

• 错误的习惯

5.1 常量

在编程中，我们经常需要使用一些常量，如数字、字符串等。然而，直接在代码中硬编码这些常量是一个不好的习惯，因为它们可能会在未来发生变化，导致维护困难。例如：

def calculate_score(score):

    if (score > 60) {

    // do something}

这里的60就是一个硬编码的常量，导致后续维护困难，正确的做法应该使用常量或者枚举来表示。例如：

PASS_SCORE = 60;

def calculate_score(score):

    if (score > PASS_SCORE) {

        // do something    }

这样，我们就可以避免硬编码，提高代码的可维护性。

5.2 全局变量

过度使用全局变量在全局范围内都可以访问和修改。因此，过度使用全局变量可能会导致程序的状态难以跟踪，增加了程序出错的可能性。例如：

counter = 0

def increment():

    global counter

    counter += 1

这段代码的问题在于，它使用了全局变量 counter，使得程序的状态难以跟踪。我们应该尽量减少全局变量的使用，而是使用函数参数和返回值来传递数据。例如：

def increment(counter):

    return counter + 1

这段代码没有使用全局变量，而是使用函数参数和返回值来传递数据，使得程序的状态更易于跟踪。

06、测试和调试

• 错误的习惯

6.1 单元测试

单元测试是验证代码中最小可测试单元的方法，下面是不添加单元测试的案例：

def add_number(a, b):

    return a + b

在这个示例中，我们没有进行单元测试来验证函数 add_number 的正确性。正确示例：

import unittest



def add_number(a, b):

    return a + b



class TestAdd(unittest.TestCase):

    def add_number(self):

        self.assertEqual(add(2, 3), 5)



if __name__ == '__main__':    unittest.main()

在这个示例中，我们使用了 unittest 模块进行单元测试，确保函数 add 的正确性。

6.2 边界测试

边界测试是针对输入的边界条件进行测试，以验证代码在边界情况下的行为下面是错误示例：

def is_even(n):

    return n % 2 == 0

在这个示例中，我们没有进行边界测试来验证函数 is_even 在边界情况下的行为。正确示例：

import unittest



def is_even(n):

    return n % 2 == 0



class TestIsEven(unittest.TestCase):

    def test_even(self):

        self.assertTrue(is_even(2))

        self.assertFalse(is_even(3))



if __name__ == '__main__':    unittest.main()

在这个示例中，我们使用了 unittest 模块进行边界测试，验证函数 is_even 在边界情况下的行为。

6.3 可测试性

代码的可测试性我们需要编写测试来验证代码的正确性。如果我们忽视了代码的可测试性，那么编写测试将会变得困难，甚至无法编写测试。例如：

def get_current_time():

    return datetime.datetime.now()

这段代码的问题在于，它依赖于当前的时间，这使得我们无法编写确定性的测试。我们应该尽量减少代码的依赖，使得代码更易于测试。例如：

def get_time(now):

    return now

这段代码不再依赖于当前的时间，而是通过参数传入时间，这使得我们可以编写确定性的测试。

07、性能优化

• 错误的习惯

7.1 过度优化

我们往往会试图优化代码，使其运行得更快。然而，过度优化可能会导致代码难以理解和维护，甚至可能会引入新的错误。例如：

def sum(numbers):

    return functools.reduce(operator.add, numbers)

这段代码的问题在于，它使用了 functools.reduce 和 operator.add 来计算列表的和，虽然这样做可以提高一点点性能，但是这使得代码难以理解。我们应该在保持代码清晰和易读的前提下，进行适度的优化。例如：

def sum(numbers):

    return sum(numbers)

这段代码使用了内置的 sum 函数来计算列表的和，虽然它可能比上面的代码慢一点，但是它更清晰、易读。

7.2 没有使用合适的数据结构

选择合适的数据结构可以提高代码的性能。使用不合适的数据结构可能导致代码执行缓慢或占用过多的内存。例如：

def find_duplicate(numbers):

    duplicates = []

    for i in range(len(numbers)):

        if numbers[i] in numbers[i+1:]:

            duplicates.append(numbers[i])

    return duplicates

在这个示例中，我们使用了列表来查找重复元素，但这种方法的时间复杂度较高。我们可以使用集合来查找元素。例如：

def find_duplicate(numbers):

    duplicates = set()

    seen = set()

    for num in numbers:

        if num in seen:

            duplicates.add(num)

        else:

            seen.add(num)

    return list(duplicates)

我们使用了集合来查找重复元素，这种方法的时间复杂度较低。

08、代码安全性

• 错误的习惯

8.1 输入验证

没有对用户输入进行充分验证和过滤可能导致恶意用户执行恶意代码或获取敏感信息。例如：

import sqlite3

def get_user(username):

    conn = sqlite3.connect('database.db')

    cursor = conn.cursor()

    query = f"SELECT * FROM users WHERE username = '{username}'"

    cursor.execute(query)

    user = cursor.fetchone()

    conn.close()

    return user

在这个示例中，我们没有对用户输入的 username 参数进行验证和过滤，可能导致 SQL 注入攻击。正确示例：

import sqlite3



def get_user(username):

    conn = sqlite3.connect('database.db')

    cursor = conn.cursor()

    query = "SELECT * FROM users WHERE username = ?"

    cursor.execute(query, (username,))

    user = cursor.fetchone()

    conn.close()

    return user

在这个示例中，我们使用参数化查询来过滤用户输入，避免了 SQL 注入攻击。

8.2 不正确的密码存储

将明文密码存储在数据库或文件中，或使用不安全的哈希算法存储密码都是不安全的做法。错误示例：

import hashlib



def store_password(password):

    hashed_password = hashlib.md5(password.encode()).hexdigest()

    # 存储 hashed_password 到数据库或文件中

在这个示例中，我们使用了不安全的哈希算法 MD5 来存储密码。正确示例：

import hashlib

import bcrypt



def store_password(password):

    hashed_password = bcrypt.hashpw(password.encode(), bcrypt.gensalt())

    # 存储 hashed_password 到数据库或文件中

在这个示例中，我们使用了更安全的哈希算法 bcrypt 来存储密码。

8.3 不正确的权限控制

没有正确验证用户的身份和权限可能导致安全漏洞。错误示例：

def delete_user(user_id):

    if current_user.is_admin:

        # 执行删除用户的操作

    else:

        raise PermissionError("You don't have permission to delete users.")

在这个示例中，我们只检查了当前用户是否为管理员，但没有进行足够的身份验证和权限验证。正确示例：

def delete_user(user_id):

    if current_user.is_authenticated and current_user.is_admin:

        # 执行删除用户的操作

    else:

        raise PermissionError("You don't have permission to delete users.")

在这个示例中，我们不仅检查了当前用户是否为管理员，还检查了当前用户是否已经通过身份验证。

09、版本控制和协作

• 错误的习惯

9.1 版本提交信息

不合理的版本提交信息可能导致代码丢失、开发人员难以理解等问题。错误示例：

git commit -m "Fixed a bug"

在这个例子中，提交信息没有提供足够的上下文和详细信息，导致其他开发人员难以理解和追踪代码的变化。正确的做法是提供有意义的提交信息，例如：

$ git commit -m "Fixed a bug in calculate function, which caused grade calculation for scores below 60"

通过提供有意义的提交信息，我们可以更好地追踪代码的变化，帮助其他开发人员理解和维护代码。

9.2 忽略版本控制和备份

忽略使用版本控制工具进行代码管理和备份是一个常见的错误。错误示例：

$ mv important_code.py important_code_backup.py

$ rm important_code.py

在这个示例中，开发者没有使用版本控制工具，只是简单地对文件进行重命名和删除，没有进行适当的备份和记录。正确示例：

$ git clone project.git

$ cp important_code.py important_code_backup.py

$ git add .

$ git commit -m "Created backup of important code"

$ git push origin master

$ rm important_code.py

在这个示例中，开发者使用了版本控制工具进行代码管理，并在删除之前创建了备份，确保了代码的安全性和可追溯性。

10、总结

好的代码应该如同一首好文，让人爱不释手。优雅的代码，不仅是功能完善，更要做好每一个细节。

最后，引用韩磊老师在《代码整洁之道》写到的一句话送给大家：

“

细节之中自有天地，整洁成就卓越代码。

以上是本文全部内容，欢迎分享。

-End-