一些项目代码经验

数据单位转换，很多时候数据会涉及到单位转换，比如浮点数据转换给用户看时是整型的，但在程序内部，数据层等一般用浮点等精确的形式进行处理，只是在最后到给用户展示的时候才转换成int等简略的方式，不要在程序内部用int等粗略型的方式处理数据，除非保证它一直是int。

跟着上面一条的，除了用户输入的，以及显示层本身的数据，不要从显示层拿数据来用，或者把它当做存储数据的位置。数据应该在逻辑层或者数据层保存，并在后面使用。因为显示层的数据是会变化的，很可能会做处理，格式不一样了。比如有的代码把一个数值转换成String，显示到TextView里面，后面服务器传来新数据，再从TextView里面获取String转换成数值，用这个数值与新数值比较一不一样，来判断是不是该做进一步的处理，这样的代码总觉不那么可靠。

知乎上的一句话

“编程语言大多是共通的，如果熟悉C、Java，转向Python并不需要花很多的学习精力，仅仅需要一个适应的过程而已。相对编程语言本身，我认为算法能力、数据结构、建模能力、设计模式、编程艺术、代码规范更重要”

编程语言应该是将一门尽量精通(熟悉），然后再转向其它的很容易。建模能力、设计模式、编程艺术还不太会。所以，有一两年工作经验、项目经验什么的，面试的时候可不止是要基本的语法知识，更会涉及到编程的思想、方法了呢，一个行业技术做到深处都是“艺术”了啊。

代码整齐的好处，一般来说，整齐的总是好的，不止是代码，在其它领域一样讲究整齐，比如做清洁，房子里面的东西就常说要将他们摆放整齐，码头的货物是放到集装箱里面然后摆放整齐的。整齐包括空间位置上的整齐，还有就是内容规格的统一，整齐之后就便于查看，便于处理。

/**
* 轮胎的ID在UI层的代表序号
*/
public static final int UI_FRONT_LEFT_TIRE  = 1;
public static final int UI_FRONT_RIGHT_TIRE = 2;
public static final int UI_BACK_LEFT_TIRE   = 3;
public static final int UI_BACK_RIGHT_TIRE  = 4;

// for mPrivateFlags:
/** {@hide} */
static final int PFLAG_WANTS_FOCUS                 = 0x00000001;
/** {@hide} */
static final int PFLAG_FOCUSED                     = 0x00000002;
/** {@hide} */
static final int PFLAG_SELECTED                    = 0x00000004;
/** {@hide} */
static final int PFLAG_IS_ROOT_NAMESPACE           = 0x00000008;
/** {@hide} */
static final int PFLAG_HAS_BOUNDS                  = 0x00000010;
/** {@hide} */
static final int PFLAG_DRAWN                       = 0x00000020;

向上面一样，把同一功能点的变量放到一个起，并且整齐排列，由于变量名长短不一导致的不整齐也用空格填补；

类的中成员排列的顺序统一，静态常量，静态，变量，功能相近的方法等一般的Java规范里面的顺序；

命名的规范和统一；

等等

整齐的代码能给人一种愉快的观感，提升自己写代码的舒适度。

便于阅读，比如上面的常量定义，常量的值放到一列上面，很容易就看到有哪些值，相同功能点的变量或方法有哪些。

便于查错，因为放到一起，比如上面的可能LEFT打成了RIGHT，因为放到一起，并且命名和排列规则，上下一对比，很容易就会发现问题。

便于更改，如果想要增加一个，直接到这个地方，按照格式添加一个即可，简单方便不易出问题。

命名相关：

1、常量定义：很基础的，标识符定义唯一化原则，一般某种东西分为好几个，然后要对每个进行区分，其标识符应该统一定义和使用而不是每个地方定义一个。比如自己遇到的一个胎压监测，为了标识汽车的四个轮子，在一个界面用四个标识符标识，在另一个界面又用另外四个来标识，Intent传递标识符进行界面跳转时还要转换一遍，何必了，直接定义在一个地方，在不同地方访问就行了。（写出这样的代码，很可能是不熟练，以及对语言掌握不深导致的）。

2、使用”完全体”命名:自己命名的话最好能完全说明该实体(方法、变量、或者类)的作用，然后再追求简洁，这样代码具有自解释性，可读性高很多。虽然这会让代码长不少，但在现带IDE的提示下，输入起来也很容易的。并且通常同一个会有好几个实体是在同一个模块下，所以他们的名字会比较整齐，比如, 比起使用不规范的缩写更易于进行各种处理等。比如想要知道这个Activity里面有多少个Fragment，直接输入输入Fragment，从代码提示里面就能看出有多少个Fragment了。

private FragmentTireDetail mFragmentFrontLeft  = null;
private FragmentTireDetail mFragmentFrontRight = null;
private FragmentTireDetail mFragmentBackLeft   = null;
private FragmentTireDetail mFragmentBackRight  = null;

private TextView mTvFrontLeft;
private TextView mTvFrontRight;
private TextView mTvBackLeft;
private TextView mTvBackRight;

IDE的警告应该尽量全部消除，不合适的警告修改IDE的配置，因为IDE给出警告的地方很可能产生错误，甚至是严重的错误.

// 临时记的

在Android Studio中使用Text运行Java 代码

操作集中化：

有些比较关键的操作，如果需要特别注意的，可以集中起来，放到一个方法里面。即使只有一行代码，也写到方法里面，所有需要此操作的都必须经过这个方法。这样以后出问题的时候就便于处理，比如加断点，打Log，而不用在各个地方去找使用的代码，然后在处理。

写文档的时候一开始不要处理格式（除非用于索引的标题等），先把需要输入的材料输入完了，最后润色的时候在处理。

针对数据特征优化算法，在设计算法的过程中，有一种思想就是根据数据的特征设计算法，很多在教科书上的经典的算法，都是通用的，对随机数据处理的算法。而当处理某一类问题时，通常可以根据数据的特征进行改造，优化算法，让其时间空间效率得到很大的提升。比API接口中提供的算法好很多。不要以为API中提供的算法就是一定是最好的，API要兼顾通用性，特殊情况下，可以自己写出更好的。比如排序，如果存在排序的数的值的范围很小，或者存在部分有序。

防御式编程与契约式编程

写代码过程中，如果有一个提供给外部调用的函数，此函数会传入参数进行处理（或者反之，调用其它模块的api），通常需要对参数（或者返回值）进行各种检查，判空，判类，判数值范围，判数组长度等等。我们倾向于认为所有与外部交互的数据（传入的或者获取到的，甚至交互）都是不可靠的，会出异常的，要对这些数据进行判别以及处理。这就是防御式编程。

契约式编程，就是与外部交互的数据都是按照约定标准来的，不会出现不规范的数据（交互）。因此模块内部不需要做判断及
db5b
处理等等。

这两种编程风格各有一定的优缺点：

防御式编程会造成代码的臃肿，充满各种判断，降低可读性，还会妨碍部分问题的暴怒（不跑抛出的话），但程序不容易出错，崩溃等。

而契约式编程则反之，代码简洁，可读性好。但是容易出现错误，崩溃等。

目前基本上还是防御式编程为，需要对程序传入的数据进行各种判断。因为确实要让外部调用数据完全符合契约规范是比较难的，外部环境以及调用者会多种多样，很难保证外部输入一定会完全地按照标准来：如果是用户输入，不能去要求用户；有些异常即使外部模块遵守了契约也会漏下来，因为出错时不能完全防止的；有些异常是调用者疏忽，没检查的，这也是无法避免；有些异常是模块自己没说清楚的，调用者也不知道。一般采取的方法根据情况是绝大多数异常都会采用防御式方法做判断，并且处理，很少数的实在不应该防御的异常以及显然应该遵守的，必须在模块接口中写为锲约规范。写模块的时候还是要考虑到所有可能的异常，不防守处理或者不写为契约规范，都会导致问题。

学习一个新的语言、框架等的API时，太过细节而又不是核心的东西不要去记，记了哪些反而把该记住的核心忘了，并且就算记了，用得不多，过段时间还是忘了。这些API不用知道或者大概知道一点点就行了，以后用的时候上网查，推测，再把它找出来用就是。自己以前学习的时候就是出现了这个问题，很多时候可劲去背那些没必要的API，浪费精力，适得其反。还有一种心态，故意去钻那个又难又偏的点，以此来挑战自己，验证自己的能力什么的，不用这样，要挑战去挑战主线上的难点知识，主线上面你不会的难点多的很。

常用的日志：

美团点评文章中提到的日志：

作为基础日志库，Logan目前已经接入了集团众多日志系统：

CAT端到端日志

埋点日志

用户行为日志

代码级日志

网络内部日志

Push日志

Crash崩溃日志

现在，Logan已经接入美团、大众点评、美团外卖、猫眼等众多App，日志种类也更加丰富。

常用/通用功能会基础库化

如果在一个比较大的公司，也比较多的业务的话，很多东西都会平台化，集成成为一个sdk，基础库等等，这是常用的模式。比如上面的日志获取上传，就形成了一个基础库。自己在一开始开发软件应该对此有一定的准备，比如常用到的工具型的方法，就按类型放到不同的工具类中，以后可能独立出去，作为基础库的一部分。

算法的重要性：

MIT教授Erik Demaine则更为直接：

If you want to become a good programmer, you can spend 10 years programming, or spend 2 years programming and learning algorithms.

如果你想做一个比一般人好的，优秀的开发者的话，这句话就是应当遵守的，对于自己，不要忘了以及使用上算法。

开发中有很多值得讲究和学习的细节，即使是注释，看下面的注释，自己以前都写得很随意，没有去关注里面的东西，实际上不对，看到JDK里面的源码，注释里面的规则都是严格遵守的，比如

分段，自己以前虽然相当分段，但是没做好的，分段在要在代码里面分出来，同时用HTML标签分出来，一般在段首加上
标签，不过看到项目经理的写法，在段末加上两个

<br/><br/>

,感觉更好，加在段首有点影响阅读。

使用@link， 使用 {@link …} 要在前后加上空格，就想写代码一样，那样看起来才对。

类标出来， 注释中用到的类等信息，没必要用@link 表示出来的，一般用

<tt> </tt>

表示出来，这样的英文字体与普通英文字体不一样

任何一项技能都有很多的细节需要掌握的，要善于观察、发现、思考这些细节，这些东西很多是资料，甚至别人教的东西里面都没有的，或者教了你也没发现。而人与人之间巨大的差距相当部分就是由这些细节引出来的，这些要靠自己尽量的去掌握。

/**
* 五角星形状的check动画，可以放到布局中直接使用, 会显示出一个五角星，选中显示实心，不选中显示空心，
* 由未选中到选中过程的执行五角星缩放，小圆点散开并消失等动画<br/><br/>
*
* 可以通过xml，或者相应的设置项设置颜色，动画持续时间，是否选中，内部视图比例等属性，详见
* attrs属性文件，{@link R.styleable#FiveStarAnimation } 等<br/><br/>
*
* 内部的执行的方式是：
* 这个动画内部分两种动画，一种是五角星的缩放动画，另一种是一圈小圆点的发散动画，通过控制两个View
* {@link FiveStarsView} 和 {@link DiffusePointView} 的缩放实现这两个动画过程，{@link
* FiveStarAnimation } 是一个 <tt>FrameLayout</tt>，<tt>测试的</tt>内部装入了这两个View
* 具体计算方式见动画执行过程 {@link FiveStarAnimation#initAnimation()}
*/

在编程中，2的幂在编程中是一个很好的数，Java的HashMap使用它各种位运算加速HashMap的操作。JDK 8的一个resize中通过位运算优化重新hash的操作是一开始也没想到的，后面发现的。

小技巧：

将调试语句用注释注掉，需要的时候再加上，而不是直接删除。