下面这些事情，如果没有做，项目也可以摇摇晃晃的往前走，但是我们应该追求业界所说的高效程序员，一个高效的程序员，绝对不是随心而欲的完成一个项目，一定有一些自己经历过各种项目历练而熟记于心的准则。
我相信，高效程序员的效率可能是普通程序员的20倍，可能差别就在下面这些地方

单元测试

功能未写，测试先行

最理想的情况是在写一个功能的时候，先写一个fail的单元测试，功能完成的标准是看单元测试是否可以由fail变为pass。平时在做项目时，在项目紧张的时候一直坚持做到这一点实属不易，但我们至少可以在功能完成后，review一下哪个方法需要单元测试，经过单元测试的功能，我们会更有信心的交付这个功能

不仅仅是测试

单元测试可以迫使我们的代码接口更加清晰

易于测试的代码一般也是接口清晰的代码

完善单元测试

初次单元测试是目标是一些基础功能，当这个模块单元测试ok后仍然有bug，我们需要审视一下我们是否需要完善当前的单元测试，之后可以通过单元测试来验证该bug，而不是通过测试人员和最终用户

自动化

所有单元测试应该在每次功能交付之前自动的运行一次，比如Maven打包的时候会运行test目录下面的所以单元测试，有一个fail则打包失败

框架

测试框架可以提供Assert函数和Mock对象，方便统一运行测试和测试case的管理，常见的测试框架如下：

• Junit for Java
• gtest for C++

Code Review

没人可以review

平时在做项目时，一个功能模块可能就一个人写，完成后没有相关的人可以review，或者可以review，但是review的质量不高。review的目的其实是保证代码的质量，反过来想，开发中哪个行为最容易破坏代码的质量呢？

不熟悉这个模块的人的代码提交没有被review

Code Owner

引入Code Owner机制，每个模块需要至少有一个Owner，对这个模块的代码负责，Owner自己提交的代码，如果有条件，可以找对应的人review一下（比如两个Owner的时候，互相review），其他开发人员如果有需求需要改这个模块的代码，必须向Owner提供review申请

reivew方式

Android通过repo和gerrit来管理代码，gerrit是一个代码审核服务器的概念，可以确保所有人都要向Owner发起reivew进程，但大多数git实现，比如gitlab和github，都没有代码审核服务器，所以尽量每个模块单独建立一个仓库，而不是所有模块共享一个仓库，这样太多人有master权限了

应该单独建立一个仓库，每个仓库只有Owner才有master权限

其他人想修改该模块的代码必须向master发起push request来review，所有仓库可以通过repo管理

原型开发

一口气不能吃成胖子

对于一个产品，一定有很多模块组成，每个模块一次开发好都开发好再进行集成一般时间耗时比较长，原型开发就是每个模块先实现基本功能，集成后马上可以进行产品演示，这样有两个好处：

• 验证技术实现的可行性，评估性能，能对技术方案进行及时的调整
• 对产品会有一个直观的感受，请其他人体验，给出更好的产品建议，同时给领导这个项目正在一步一步向前走的感觉

模块化

依赖抽象而不是过程

任何一本软件开发的书都会强调模块化的重要性，平时在做项目时，每个“模块”以功能来划分很容易做到，当发现一个“模块”比较臃肿的时候，拆分成两个“模块”也花不了多少时间，但这些“模块”可能不是真正的模块，模块与模块之间依赖过程，而不是依赖抽象，要真正做到模块化应该有两点：

• 模块与模块之间是通过接口交互
• 每个模块是一个单独的编译单元

做到这两点，每个模块都可以通过简单的一行命令独立出来提供单一的服务

持续模块化

项目紧张的时候，为了快速搭建原型可以先牺牲一下模块化，在原型验证通过后，开发正式代码时，模块化是第一步，项目开发过程中要有持续模块化的心态，如果开始没有做好模块化，抱着功能测试通过后再重构代码的心态，结果往往是模块化永远不会被执行，因为测试通过的代码有了一个附加值，开发人员这个时候重构的话，代码可能需要重新测试一遍，所以臃肿的代码就一直保留下来

当发现解决一个bug的时候，需要改很多地方代码，那么就是你需要立刻做模块化的信号

配置模块化

除了代码层面做好模块化，在打工程里面有很多配置文件，哪些配置文件需要放到模块里面，哪些需要放到根目录的，都需要仔细思量，最终达到的效果就是当要更换一个模块或者模块单独抽出来做服务的时候，花的成本最少

跨平台

操作系统原生语言

设想一下你想在Android、IOS、OSX、Windows、Linux上面写一个文件读写的工具库，你们会选择哪种语言来做，第一反应应该是Java，Java最大特征就是跨平台，但是很抱歉，除了Android和Linux上面你可以很好产品化（因为有Java环境支持），其他平台都需要用户先装好java环境，这一点是无法做到的。

所以真正的跨平台语言应该是和操作系统相关的原生语言，该语言的输出是不需要用户额外安装其他的虚拟环境，那么答案应该只有一个：C语言

平时在做项目时，当你准备实现一个功能的时候，除了定义良好的接口，也要先考虑一下，这个功能是否有跨平台的需求，是否该用C来实现
不是所有功能都可以通过C来实现跨平台，比如移动端的一些UI组件操作，我们需要保证的是可以做到尽量跨平台

跨平台技术

一个功能跨平台的实现主要考虑的是两方面：

• 代码级别的跨平台
• 编译级别的跨平台

C语言在不同的平台上面有不同的API，需要在代码中根据宏来控制
编译级别的跨平台主要需求时一个编译脚本，各个平台上面可以完成编译，GYP是由Python实现的跨平台编译脚本，可以很好满足需要

可配置

测试人员的可配置

当交互的产品需要切换一下线上、线下功能，或者开启debug模式，是否需要开发人员重现build一个版本，很不幸，这个在开发中很常见，我们应该在产品测试前考虑好哪些功能是可以给测试人员配置的，如果移动平台，比如IOS上面，配置文件比较麻烦，我们也应该提供一种后门，通过PC端的命令来控制IOS的表现，达到可配置的效果

最终用户的可配置

开发给最终用户的配置选项一般是产品经理来定的，开发人员需要注意的是安全性问题，防止用户通过配置选项来破坏后台服务