Bb8670747cf73456c7f4286ba8f42f45
雕虫晓技(二) 编码

前言

对于编程,一般需要先设计,再编码,即针对某一项功能进行详细的分析后,得出具体的技术方案,然后编码进行实现,这是最理想的状态,但是现实不可能这么理想。

在公司的项目中,一般不会有太充裕的时间,专一用来琢磨技术方案,再加上个人能力有限,前期分析很难具体到每一个细节中,那么在这种情况下应该如何编程呢?下面就分享几个自己使用的准则。

一、功能优先

程序员主要工作是写代码,最终目标则是产品,而产品的核心是其中的功能,如果功能没有完成,代码写得再漂亮也没用,所以第一点是功能优先。

由于每个人接触到的知识是非常有限的,不可能像搜索引擎一样什么都知道,所以在面对具体的功能开发时,要优先从自己现有的知识库里面寻找最可靠有效的解决方案,先利用已有的知识设计出大致的框架,然后在不考虑编码复杂度的情况下先完成第一个版本功能的开发,把功能做出来之后,再进行迭代优化,使其逐渐接近完美。

对于功能开发来说,也要注意偏重,用户需要的是内容,而不是一个应用,在初期阶段要注意将内容展示做好,至于其中的一些动画效果和细节处理,在这一阶段都属于次要内容,具体的细节可以等功能基本完善之后慢慢调整。

二、适当测试

测试有黑盒测试和白盒测试,黑盒测试就是把自己当成用户来体验这些功能,看功能是否正常,而白盒测试在Android中通常是指单元测试。

虽然公司有专业的测试人员,但是自己写的代码还是自己最清楚哪里可能出现问题,所以建议在交付给专业测试之前自己先简单的测试一遍,避免一些常见的漏洞。

在这里说明一下有关单元测试的问题,大家都知道单元测试是好的,但是据我观察,有很多程序员基本不写单元测试,那么单元测试到底是不是必须的呢?

个人觉得,是否进行单元测试要依照具体情况而定,不是所有的方法都需要单元测试,例如:读取数据库操作,获取网络数据,这些本身就不包含什么复杂逻辑的内容是不需要测试的,假如数据出现了问题,十有八九是其他地方写入了错误数据,而不是因为读取才出现的,因此这些也就没有必要进行测试了。具体的业务逻辑也不需要单元测试,否则产品一旦修改需求,测试代码也要跟着大动干戈,岂不是自找麻烦。

真正需要测试的是那些基础函数,尤其是具有分支判断的函数,这些函数才是最容易出现问题的地方,写测试代码的时候,重点要进行边界数值测试,以及特殊情况的测试,当然,如果是一些通用的基础组件,个人更喜欢写一个 Demo,在测试的同时就把用法示例也写出来了。

三、代码风格

相信每个人都有自己的编码风格,个人希望在保持自己风格的同时,也能够让别人更容易看懂自己的代码,所以设计了一个固定的结构,即适合编码,又适合阅读。

个人习惯将常量和变量放在最上面,然后是生命周期和应用的核心方法,依次进行排列,最后是外部调用的接口。这样做主要是为了后期查看方便,什么方法在什么位置很容易就能找到,避免了上下来回滚动去寻找一个方法的麻烦。

下面是自己使用的规范,一个大致的例子:

```
public class GcsSloop {
// 对外常量
public static final String HAHA = "haha";
// 对内常量
private static final int mVal = -1;
// 全局变量
private int mVar;

//--- 构造函数(生命周期)与核心功能 ---

public GcsSloop() {        
    this(-1);
}    
public GcsSloop(int var) {        
    this.mVar = var;
}    

// 核心方法,一般均为 private
private void doSomthing(){
top Created with Sketch.