雕虫晓技之编码

1、功能优先 程序员主要工做是写代码，最终目标则是产品，而产品的核心是其中的功能，若是功能没有完成，代码写得再漂亮也没用，因此第一点是功能优先。

因为每一个人接触到的知识是很是有限的，不可能像搜索引擎同样什么都知道，因此在面对具体的功能开发时，要优先从本身现有的知识库里面寻找最可靠有效的解决方案，先利用已有的知识设计出大体的框架，而后在不考虑编码复杂度的状况下先完成第一个版本功能的开发，把功能作出来以后，再进行迭代优化，使其逐渐接近完美。

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

2、适当测试 测试有黑盒测试和白盒测试，黑盒测试就是把本身当成用户来体验这些功能，看功能是否正常，而白盒测试在Android中一般是指单元测试。

虽然公司有专业的测试人员，可是本身写的代码仍是本身最清楚哪里可能出现问题，因此建议在交付给专业测试以前本身先简单的测试一遍，避免一些常见的漏洞。

在这里说明一下有关单元测试的问题，你们都知道单元测试是好的，可是据我观察，有不少程序员基本不写单元测试，那么单元测试究竟是不是必须的呢？

我的以为，是否进行单元测试要依照具体状况而定，不是全部的方法都须要单元测试，例如：读取数据库操做，获取网络数据，这些自己就不包含什么复杂逻辑的内容是不须要测试的，假如数据出现了问题，十有八九是其余地方写入了错误数据，而不是由于读取才出现的，所以这些也就没有必要进行测试了。具体的业务逻辑也不须要单元测试，不然产品一旦修改需求，测试代码也要跟着大动干戈，岂不是自找麻烦。

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

3、代码风格 相信每一个人都有本身的编码风格，我的但愿在保持本身风格的同时，也可以让别人更容易看懂本身的代码，因此设计了一个固定的结构，即适合编码，又适合阅读。

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

下面是本身使用的规范，一个大体的例子：

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(){
    System.out.println("LALA");
}

//--- 对外方法或接口 ---

// 对外方法，均为 public
public void sayHaha(){
    System.out.println("HAHA");
}
复制代码

} 这样的编码风格也是我调整了若干次后总结的，规则很简单，也没有太大的束缚，但很实用。

一个类写完以后它的内部逻辑可能很长时间都不会改变，而调用者也不关心它的内部逻辑，因此就将内部逻辑放在中间位置，公开常量放在开头，接口放在结尾，相比于中间，开头和结尾更容易定位，这样在使用的时候最容易寻找。

例如：我以前写了一个类，我知道它的具体做用，但很长以前没有使用了，忘了怎么使用，我就能够打开这个类，直接跳到末尾看一下调用接口就知道怎么使用了，而不用再去看它的具体实现逻辑。

也有人习惯将公开常量和调用接口所有放在最开始的部分，这个就看我的的编码习惯了，只要不是把公开的方法接口混杂到具体内部逻辑中就好。

4、技术选型 最后一个话题是技术选型，有句俗话叫”条条大路通罗马”，在技术上尤为如此，对于同一个业务来讲，不一样的人进行开发可能会选择不一样的技术方案，使用不一样的思路。那么具体到咱们开发时，应该如何选择方案呢？

我的以为应该有如下几条原则：

1. 首选本身实践过的

若是是本身实践过的内容，会对这套流程比较熟悉，能快速上手开发，也踩过里面常见的坑，知道如何规避。因此这套是首选方案，能够快速稳定的实现业务。

2. 次选官方推荐或者你们都在用的

若是本身自己对这方面不熟悉，则建议选择官方推荐方案，或者用的人比较多的方案。对于官方推荐来讲，有后台撑腰，文档清晰明确，使用起来会少走弯路。而使用人数较多的则说明有不少前人帮忙踩坑，不少坑在没遇到的时候就被填平了，即使遇到了，基本也能找到轻松绕过去的方案。

3. 慎选热门新技术

其实这一点有悖程序员文化，程序员都喜欢新潮的，酷酷的技术，并且使用新技术能够为未来的简历添加上浓墨重彩的一笔，因此不少程序员都喜欢使用新技术。

我的以为，喜欢新技术没错，任何新技术的兴起，必然是由于它拥有着旧技术所没有的特色，才会受到人们的追捧，但也不要盲目的去使用新技术。对于新技术的出现，咱们能够去学习，研究分析它的优缺点，但不要当即在商业项目中使用，由于任何技术都须要必定时间的沉淀才能逐渐完善，一项新技术的出现可能会解决某一方面的痛点，但同时也可能引入其余麻烦，若是使用新技术出现了麻烦，将没有任何能够参考的东西，只能去看源码分析，这将会大大的拖慢项目进度。

对于新技术的出现，我的的观点是，默默学习，持续观望，等沉淀几个月以后再尝试将这项技术应用到实际的项目中。

4. 不选冷门技术

若是不是无可奈何，不要去选择没什么人用的技术方案，这些方案没人使用必定是由于有更好的替代方案，或者是这项技术自己存在缺陷。固然，对于这些缺陷，做者通常不会明确的告诉咱们。这些技术方案可能一开始使用起来没问题，但若是遇到问题，就会让人很是头疼，在某些状况下，修复这个问题所花费的时间甚至会超过本身从头再写一遍。因此使用冷门技术以前请先祈祷一下本身不会踩到坑。