package com.cheng.improve151suggest;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.widget.ListView;
import java.util.Arrays;
import com.cheng.highqualitycodestudy.R;
import com.cheng.improve151suggest.adapter.I151SuggestListAdapter;
/**
第12章 思想为源
建议144： 提倡良好的代码风格
建议145： 不要完全依靠单元测试来发现问题
建议146： 让注释正确、清晰、简洁
建议147： 让接口的职责保持单一
建议148： 增强类的可替换性
建议149： 依赖抽象而不是实现
建议150： 抛弃7条不良的编码习惯
建议151： 以技术员自律而不是工人
*/
public class I151SChapter12Activity extends AppCompatActivity {
private static final String TAG = "I151SChapter12Activity";
private ListView mChapterLV;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_i151suggestchapter);
initView();
initData();
}
private void initView() {
this.mChapterLV = (ListView) findViewById(R.id.isi_chapter_lv);
}
private void initData() {
String[] suggests = getResources().getStringArray(R.array.i151schapter12);
I151SuggestListAdapter adapter = new I151SuggestListAdapter(this, Arrays.asList(suggests));
mChapterLV.setAdapter(adapter);
}
/**
* 建议144： 提倡良好的代码风格
*/
private void suggest144() {
/*
来分析以下优秀团队的编码风格应该具有哪些特征
1）整洁
不管代码风格的定义有多优秀，有多适合开发人员，如果代码结构混乱不堪，即使效率再高，也会使维护难
以持续。代码首先是给人看的，然后才是给机器执行的
2）统一
从一个团队中诞生的代码应该具有一致性的风格，要使用下挂式括号就全部使用下挂式括号，要使用tab缩进
就全部使用tab缩进，要使用小驼峰方式命名就全部使用小驼峰方式命名，不要带有个人色彩的风格标识。这
样可以让我们的代码看起来很职业，而不是一帮乌合之众产生的“稻草”式代码
统一的代码风格还要求具有连贯性，我们应该在不同的模块、层级中使用相同的编码风格，而不能在展现层使
用一种编码，在逻辑层又使用另外一种编码风格。一个项目的编码风格不应该因为所处的功能区不同而有所差
异。当然，若使用多种异构语言开发项目，则可以考虑为不同的语音提供不同的规范
3）流行
一种编码格式的流行必然有它存在的理由，完全可以借鉴流行的编码格式，没有必要对这种风格进行重塑，而
且使用流行风格可以让新成员尽快融入项目，避免出现进入一个新环境而出现茫茫无助的状态
不要让你的代码规范标新立异，独树一帜，跟随“风尚”也许是一种省事、省力、省心的最好编码风格
4）便捷
制定出来的编码规范必须有通用开发工具支撑，不能制定出只能由个别开发工具支持的规范，甚至是绑定在某
一个IDE上。在小范围内独乐乐，可以提升代码的友好度，方便使用，但很难大范围内推而广之，特别是很难
上升到工程级别。代码风格是为一个团队准备的，如果团队中就只有一个i额开发人员，基本上代码风格不会
有太大差异，这是习惯和个性使然，但是如果团队中有多个成员，就需要防止给开发人员过渡的自由了，不
符合开发规范的代码要坚决予以重构，以使团队代码风格一致
*/
/**
* 注意
* 现在的项目中源代码逐渐增多，完全依靠人工来做代码走查很难查出问题，可以使用工具来统计代码，这
* 里推荐使用Checkstyle，它可以自定义代码模板，然后根据模板检查代码是否遵循规范
*/
}
/**
* 建议145： 不要完全依靠单元测试来发现问题
*/
private void suggest145() {
/*
单元测试的目的是保证各个独立分割的程序单元的正确性，虽然它能够发现程序中存在的问题（或缺陷，或
错误），但是单元测试只是排查程序错误的一种方式，不能保证代码中的所有错误都能被单元测试挖掘出来，
原因有以下四点
1）单元测试不可能测试所有的场景（路径）
单元测试必须测试的三种数据场景是：正常场景、边界场景、异常场景。正常数据场景，用来测试代码的主
逻辑：边界数据场景，用来测试代码（或数据）在边界的情况下逻辑是否正常；异常数据场景，用来测试出
现异常非故障时能否按照预期运行。在项目中的测试覆盖率不能达到100%的一个主要原因：单元测试的代码
量远大于生产代码。通常在项目中，单元测试覆盖率很难达到60%，因为不能100%覆盖，这就导致了代码测
试的不完整性，隐藏的缺陷也就必然存在了
2）代码整合错误是不可避免的
单元测试只是保证了分割的独立单元的正确性，它不能保证一个功能的完整性。单元测试首先会假设所有的
依赖条件都满足，但真实情况并不是这样的，我们经常会发现虽然所有的单元测试都通过了，但在进行整合
测试时仍然会产生大量的业务错误--很多情况下，此种错误是因为对代码的职责不清晰而引起的，这属于认
知范畴，不能通过单元测试避免
3）部分代码无法（或很难）测试
比如一个JEE应用，一般情况下都是多线程环境，但是我们很少对代码进行多线程测试，原因很简单，测试
很复杂，很难进行全面的多线程测试。而且如果要保证在多线程下测试通过，就必须对代码增加大量的修饰，
这必然会导致代码的可读性和可维护性降低，这也是一般都抛弃多线程测试的原因
在Spring中，默认情况下每个注入的对象都是Singleton的，也就是单例的，每个类在内存中只有一个对象
实例，这也是偶尔出现数据资源不一致现象的元凶：在多线程环境下数据未进行资源保护，特别是在系统压
力较大、响应能力较低的情况下，数据资源出现不一致情况的可能性更大
这只是一种单元测试很难覆盖的情况，还有一种情况是根本不能实施单元测试，比如不确定性算法，什么叫
不确定算法？像我们经常接触的函数f(x)，给定一个确定的x值，就有确定的结果f(x)，在任何时候输入x，
都能获得固定的f(x)，这就是确定性算法，但还有一种算法，比如要计算出明天通过某一个大桥的车辆数量，
必须根据专家经验、天气、交通情况、是否是节庆日、是否有大型体育比赛、并行道路通行的情况等来进行
计算，这些条件很多都是非确定的依据，所推导出的也是一个非确定结论的数据--明天通过大桥的车辆数量，
想想看，这怎么进行单元测试，不确定算法只能无限接近而不能达到，单元测试只能对确定算法进行假设，
不能对不确定算法进行验证
4）单元测试验证的是编码人员的假设
代码的意图只是反映了编码者的理解，而单元测试只是验证了这种假设。想想看，如果编码者从一开始就误解
了需求意图，此时的单元测试就充当了帮凶：验证了一个错误的假设
*/
/**
* 注意
* 指出单元测试的缺陷，并不是为了说明单元测试不必要，相反，单元测试在项目中是必须的，而且是非常
* 重要的，特别敏捷开发中提倡的TDD（Test-Driven Development）测试驱动开发：单元测试先行，而
* 后才会编写生产代码，这可以大幅度地提升代码质量，加快项目开发的进度
*/
}
/**
* 建议146： 让注释正确、清晰、简洁
*/
private void suggest146() {
/*
先来看一些不好的注释习惯
1）废话式注释
2）故事式注释
3）不必要的注释
4）过时的注释
5）大块注释代码
6）流水账式的注释
7）专为JavaDoc编写的注释
建议在注释中只保留<p>、<code>等几个不常用的标签，不要增加<font>、<table>、<div>等标签
好的注释应该是什么样子的呢？
好的注释首先要求正确，注释与代码意图吻合；其次要求清晰，格式统一，文字准确；最后要求简洁，说明
该说明的，惜字如金，拒绝不必要的注释，如下类型的注释就是好的注释：
1）法律版权信息
2）解释意图的注解
3）警示性注释
这类注释使我们经常缺乏的，或者是经常忽视的（即使有了，也常常是与代码版本不匹配），比如可以在注
释中提示此代码的缺陷，或者它在不同操作系统上的表现，或者警告后续人员不要随意修改
4）TODO注释
注释只是代码阅读的辅助信息，如果代码的表达能力足够清晰，根本就不需要注释，注释能够帮助我们更好
地理解代码，但它所重视的是质量而不是数量。如果一段代码写得很糟糕，即使注释写得再漂亮，也不能解
决腐烂代码带来的种种问题
*/
/**
* 注意
* 注释不是美化剂，不能美化你的代码，它只是一副催化剂，可以让优秀的代码更加优秀，让拙劣的代码更
* 加腐朽
*/
}
/**
* 建议147： 让接口的职责保持单一
*/
private void suggest147() {
/*
单一职责原则就是要求我们的接口（或类）尽可能保持单一，它的定义是说“一个类有且仅有一个变化的原因”，
那什么是职责呢？
职责是一个接口（或类）要承担的业务含义，或是接口（或类）表现出的意图。单一职责有以下优点：
1）类的复杂性降低
2）可读性和可维护性提高
3）降低变更风险
下面以电话通信为例子来说明如何实施单一职责原则：
1）分析职责
一次电话通信包含四个过程：拨号、通话、回应、挂机，来思考下该如何划分职责，这四个过程包含了两个职
责：一个是拨号和挂机表示的通信协议的链接和关闭，另外一个是通话和回应所表示的数据交互
我们依靠什么来划分职责呢？依靠变化因素，可以这样考虑该问题：
通信协议的变化会引起数据交换的变化吗？会的！你能在3G网络视频聊天，但你很难在2G网络上实现
数据交互的变化会引起通信协议的变化吗？会的！传输2KB的文件和20GB的文件需要的不可能是同一种网络
2）设计接口
首先不要考虑实现类是如何设计的，首先应该通过两个接口来实现职责。接口的定义如下：
// 通信协议
interface Connection {
// 拨通电话
public void dial();
// 通话完毕、挂电话
public void hangup();
}
// 数据传输
interface Transfer {
// 通话
public void chat();
}
3）合并实现
接口定义了两个职责，难道实现类就一定要分别实现这两个接口吗？这样做确实完全满足了单一职责原则的
要求：每个接口和类职责分明，结构清晰，但是一般在设计的时候肯定不会采用这种方式，因为一个电话类
要把ConnectionManager和DataTransfer的实现类组合起来才能使用。组合是一种强耦合关系，你和我都
有共同的生命期，这样的强耦合关系还不如使用接口实现的方式呢！而且这还增加了类的复杂性，多两个类
通常的做法是一个实现类实现多个职责，也就是实现多个接口，代码如下：
// 电话
class Phone implements Connection, Transfer {
// 实现各个接口
}
这样的设计才是完美的，一个类实现了两个接口，把两个职责融合在一个类中。你会觉得这个Phone有两个
原因引起了变化，是的，但是别忘记了我们是面向接口编程的，我们对外公布的是接口而不是实现类。而且，
如果真要实现类的单一职责，就必须使用上面的组合模式，这会引起类间的耦合过重、类的数量增加等问题，
人为地增加了设计的复杂性
*/
/**
* 注意
* 接口职责一定要单一，实现类职责尽量单一
*/
}
/**
* 建议148： 增强类的可替换性
*/
private void suggest148() {
/*
一个接口可以有多个实现方式，一个父类可以有多个子类，并且可以把不同的实现或子类赋给不同的接口或
父类。多态的好处非常多，其中有一点就是增强了类的可替换性，但是单单一个多态特性，很难保证我们的
类是完全可以替换的，幸好还有一个里氏替换原则来约束
里氏替换原则是说“所有引用基类的地方必须能透明地使用其子类的对象”，通俗点讲，只要父类型能出现的
地方子类型就可以出现，而且将父类型替换为子类型还不会产生任何错误或异常，使用者根本就不需要知道
是父类型还是子类型。但是，反过来就不行了，有子类型出现的地方，父类型未必就能适应
为了增强类的可替换性，就要求在设计类的时候考虑以下三点：
1）子类型必须完全实现父类型的方法
难道还有能不实现父类型的方法？当然有，方法只是对象的行为，子类完全可以覆写，正常情况下覆写只会
增强行为的能力，并不会“曲解”父类型的行为，一旦子类型的目的不是为了增强父类型行为，那替换的可能
性就非常低了
2）前置条件可以被放大
方法中的输入参数称为前置条件，它表达的含义是你要让我执行，就必须满足我的条件。前置条件是允许放
大的，这样可以保证父类型行为逻辑的继承性，比如有这样的代码：
class Base {
public void doStuff(HashMap map) {
}
}
class Sub extends Base {
public void doStuff(Map map) {
}
}
这是Java的重载实现，子类型在实现父类型的同时也具备了自己的个性，可以处理比父类型更宽泛的任务，
而且不会影响父类的任何行为。子类型可以在扩展前置条件的情况下保持类的可替换性
3）后置条件可以被缩小
父类型方法返回值是类型T，子类同名方法（重载或覆写）的返回值为S，那么S可以是T的子集，这里又分为
两种情况：
如果是覆写，父类型和子类型的方法名名称就会相同，输入参数也相同（前置条件相同），这是返回值S是T
类型的子集，子类型替换父类型完全没有问题
若是重载，方法的输入参数类型或数量则不相同（前置条件不同），这使用子类型替换父类型的情况下，子
类型的方法会不被调用到，已经无关返回值类型了，此时子类型依然具备可替换性
*/
/**
* 注意
* 增强类的可替换性，则增强了程序的健壮性，版本升级时可以保持非常好的兼容性。即使增加子类，原有
* 的子类还可以继续运行。在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的
* 子类完成不同的业务逻辑，非常完美
*/
}
/**
* 建议149： 依赖抽象而不是实现
*/
private void suggest149() {
/*
在面向过程开发中，我们考虑的是如何实现，依赖的是每个具体实现，而在OOP中的，则需要依赖每个接口，
而不能依赖具体的实现，比如我们要到北京出差，应该依赖交通工具，而不是依赖的具体飞机或火车，也就
是说我们依赖的是交通工具的运输能力，而不是具体的一架飞机或某一列火车。这样的依赖可以让我们实现
解耦，保持代码间的松耦合，提高代码的复用率，这也是依赖倒置原则提出的要求
依赖倒置原则包含三层含义：
-高层模块不应该依赖低层模块，两者应该依赖其抽象
-抽象不应该依赖细节
-细节应该依赖抽象
高层模块和低层模块容易理解，每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模
块，原子逻辑的再组装就是高层模块。那什么是抽象，什么又是细节呢？在Java语言中，抽象就是指接口或
抽象类，两者都是不能直接被实例化的；而细节就是实现类，实现接口或继承抽象类而产生的类就是细节，
其特点是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。依赖倒置原则在Java语言中的
表现就是：
-模块间的依赖是通过抽象发生的，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的
-接口或抽象类不依赖于实现类
-实现类依赖接口或抽象类
更加精简的定义就是“面向接口编程”，它的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此
独立，互不影响，从而实现模块间的松耦合。那怎么在项目中使用这个规则呢？只要遵循以下的几个规则就
可以：
1）尽量抽象
每个类尽量都有接口后抽象类，或者抽象类和接口两者都具备。接口和抽象类都是属于抽象的，有了抽象才
可能依赖倒置
2）表面类型必须是抽象的
比如定义集合，尽量使用如下这种类型：
List<String> list = new ArrayList<String>();
此时list的表面类型为List，是一个列表的抽象，而实际类型为ArrayList。在可能的情况下，尽量抽象表
面类型，但也存在不必抽象的情况，比如工具类xxxUtils，一般是不需要接口或抽象类的
3）任何类都不应该从具体类派生
如果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝对的，因为人都会犯
错误的，有设计缺陷是在所难免的，因此只要是不超过两层的继承都是可以忍受的。特别是做项目维护时，
基本上可以不考虑这个规则，为什么？维护工作基本上都是做扩展开发的，修复行为通过一个继承关系，覆
写一个方法就可以修正一个很大的Bug，何必再去继承最高的基类？（当然这种情况尽量发生在不甚了解父
类或无法获得父类代码的情况下）
4）尽量不要覆写基类的方法
如果基类是一个抽象类，而且这个方法已经实现了，那么子类尽量不要覆写。类间依赖的是抽象，覆写了抽
象方法，对依赖的稳定性会产生一定的影响
5）抽象不关注细节
接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现
类准确地实现了业务逻辑，同时在适当的时候对父类进行了细化，各司其职才能保证抽象的依赖完美实现
*/
/**
* 注意
* 依赖抽象的优点在小项目中很难体现出来，例如在小于10个人月的项目中，使用简单的SSH架构，基本上
* 不用费太大力气就可以完成，是否采用抽象依赖原则影响不大。但是，在一个大中型项目中，采用抽象依
* 赖可以带来非常多的优点，特别是可以规避一些非技术因素引起的问题。项目越大，需求变化的概率也就
* 越大，通过采用依赖倒置原则设计的接口或抽象对实现类进行约束，可以减少需求变化引起的工作量剧增
* 的情况。人员的变动在大中型项目中也是时常存在的，如果项目设计优良、代码结构清晰，人员变化对项
* 目的影响则基本为零。大中型项目的维护周期一般都很长，采用依赖倒置原则可以让维护人员轻松地扩展
* 和维护
*/
}
/**
* 建议150： 抛弃7条不良的编码习惯
*/
private void suggest150() {
/*
这里列出7条编码者经常会犯的错误
1）自由格式的代码
2）不使用抽象的代码
抽象的意义不在于编码，而是在于对业务的理解，接口是对业务宏观的描述，而不是实现代码
3）彰显个性的代码
“最小惊诧原则”（简称POLS，或者POLA），其意是说要使用最常见的，而不是最新颖的功能。在编码时，应
寻找最常用的方法来实现，比如，同样有两个方法都实现一个算法，选择那个最常用的，而不是那个别人一看
就惊呼“哇哦，算法这么牛”的，让普通人都能看懂的代码才是最简洁的代码
最小惊诧原则也同样适用于UI设计，当操作界面上两个元素冲突或重叠时，首选那个不让用户感到吃惊的元素
4）死代码
可能是忘记删除的代码，也可能是故意保留的类似“到此一游”的签名代码，这些代码按照正常的执行逻辑是
不可能被执行到，但是在某些未知情况下它就是执行了，此时就会产生严重的影响
5）冗余代码
6）拒绝变化的代码
7）自以为是的代码
这是我们编码的最大忌讳，认为自己无所不能，编码不会出现任何错误，于是不编写测试代码，或者测试代码
只是为了应付质量检查人员
自以为是还表现在对产品或工具的选型上，相信自己编写的工具类，而不是开源工具，宁愿自己写序列化工具，
也不选择kryo或protostuff；宁愿自己写日期处理工具，也不选择Joda或date4j；宁愿自己写批处理框架，
也不选择Spring Batch，这样是不行的！--相信天外有天吧，更多更好的工具等待着你去发掘
*/
}
/**
* 建议151： 以技术员自律而不是工人
*/
private void suggest151() {
/*
以下20条建议可以逐步把我们向技术人员方向培养
1）熟悉工具
我们的工具就是Java，我们应该了解它的使用范围，了解它的生态系统，了解它的发展趋势
2）使用IDE
3）坚持编码
没有编码，就等于是无源之水，无本之木，何来灵感和灵性？
4）编码前思考
开始编码之前，必须已经完成设计，最低要求是对开发中遇到的问题有清晰的认识，不要在编码中解决问题
5）坚持重构
不要相信一次就能写出优秀的代码，这是不现实的，任何优秀的代码、算法都是经过多次重构磨练的，坚信
自己的下一个版本或代码更优秀
6）多写文档
写注释、写说明、写报告都是对代码或项目的回顾和总结，不仅仅是为了后续的参与人员，同时也是为了整
理自己头脑中混乱的思维
7）保持程序版本的简单性
一个项目不要保持多个版本，即使有分支也必须定义出项目合并的条件，或者时间约束，或者目标约束，不
可任由版本扩散
8）做好备份
经常把代码拷贝到不同的主机上备份是一个好习惯，如果能自动备份那将是一个非常好的方式
9）做单元测试
10）不要重复发明轮子
在项目中使用已经成熟的工具或框架
11）不要拷贝
不要让打段的代码散落在各处，不要做搬运工，不要做拷贝工，要做技术工
12）让代码充满灵性
为变量、类、方法起个好听的名字是一个不错的主意，为代码增加必要的注释也是很好的办法，“One Line”
能解决一个上百行代码的问题，也是一个优秀的实现
13）测试自动化
不管是性能测试、单元测试，还是功能测试，想尽办法让它自动化，不要唉测试之前手动配置或触发条件，这
不够人性化，同时让代码“汗颜”--本是用来自动执行的，但却被手动设置了条件
14）做压力测试
把业务人员制定的指标扩大3倍，然后再做压力测试
15）“剽窃”不可耻
多看开源代码，学习一下人家是如何编码的，然后经常“剽窃”一下，这也是提高技能的最佳途径
16）坚持向敏捷学习
敏捷中的一些思想是非常优秀的，例如TDD测试驱动开发、交流的重要性、循序渐进开发等
17）重里更重面
18）分享
19）刨根问底
20）横向扩展
Java要运行在JVM、操作系统上，同时还要与硬件、网络、存储交互，另外要遵循诸如FTP、SMTP、HTTP等
协议，还要实现Web Service、RMI、XML-RPC等接口，所以我们必须熟悉相关的知识--扩展知识面，这些
都是必须去学习的
*/
}
}