编程注意

1. 不是简单的复制，该放在fragment里面的放在fragment里面。
   不怪我，我当时的能力差，根本没有编排代码的能力。也不熟悉，给我的时间也少。我以后会努力做到不是完成任务，而是把事情做好。

2. .接口用来回调。

3. 一个activity 将会很庞大。（提取出来吧，不可能搬砖一样吧）

4. Bundle bundle = getIntent().getExtras();

1.NAVI_INDEX_ACCOUNT
2.mFragmentList.get(position)

这种明显的会崩溃的代码不要有。

3. ((OnlineFragment)getCurFragment()).goBackAndExit();
   4.onKeyDown 抽象一个basefragment
   写非空判断是一种习惯

Base里面可以放一下跟界面什么无关的一些逻辑，让fragment什么的看起来代码少一点。

除了编程之外的东西：

1. 做事情要主动。
2. 积极吸取别人的经验。已经有的bug，当你遇到的时候，你就。。。。
3. 挑战自己的脑子。必须提出一个问题。而且当时我是第一个。
4. 你要对你写的代码负责任
5. 其实一件事情没有你想象中的那么难，和浪费时间
6. 围绕是什么为什么怎么做
7. 画图 讲细节 讲包和类
8. 集思广益
9. 周报不是让你回报的多清楚，而是培养你明天要干什么，对明天的规划
10. 做事情，简 繁 简
11. Bug是有日期的，多久之前是要解决完的。

12.由一个变量，找到那里用到了，然后。。。。一点一点的解决bug。
夜间模式这个问题，本来是一个小问题，但是我用了一上午加差不多一下午才解决。我把功夫放到了没用的东西上，一堆变量，然后呢，没什么用。不就是点击之后做了什么，这里做了，那里没有做。再说，用脑子想想，肯定在bookshelfFragment那里有这一块的代码。因为功能在那里有啊。。。自己瞎调试，调试了那么久。。都不知道关键。

12. traceView trace文件
13. 调试布局就加背景色。
14. 没有事情做了，提前给他说。。。。哎。身份卑微。。。心宽，这都不算事。
15. 维护代码，找代码，一定要顺藤摸瓜，不能抱着侥幸心理去瞎找。代码太多了。
16. 类的继承关系一定要搞清楚。看一个类第一眼看的就是继承关系！
17. 维护代码要认真，不能以改动少为目标，而是以以后扩展。
18. 主动，至少每天问一遍进度。
19. 目标，有自己的计划和目标。熟悉代码的某一个模块，等等。
20. Utils分为两类，一类是通用的commonUtils，第二个是这这个app内的，apputils
21. 写代码要分层。第一层就是通用的，第二层是封装了一下，供某个具体业务用的。
22. 以后他妈的测试什么，都写清楚，能不能用6.0的手机测试等等。别他妈的别人说你这是什么啊，打不开，你又跟人家解释。好吗？我不喜欢丢人。
23. 提测要自测通过了，再提测。不然别人烦，到时候你也没面子。
24. 永远要不要其烦的点。因为！因为你觉得是系统的方法，他妈的，他就是重写了，而且关键逻辑就在这里。
25. 可以根据一个变量，解决一个bug。 登录退出都是那个变量，findUseage。Token为空了，那么在哪里为空了？
26. 弄个记事本，我也有今天，事情多的忙的处理不过来，但是不能忘，也记住。没完成一个就删了它。现在我才知道，嗯，很管用。
27. 排除法解决bug,，这一块代码我已经弄了半天，各种都认真的试验过了，那么就说明不是这一块的问题，去想其他的地方，虽然可能你都不知道是哪一块在影响她。
28. 主动，主动去推进。我就不怕你觉得我烦，没关系，我一天问你一次进度。我终于知道，产权部那个人做事情的，有一天，你会感谢我，进度没有延期。
29. 压力不要太大，你做不到的事情，老员工会处理的。不要怕，学会求助。
30. 你写的代码一定会执行吗？不一定，所以，这种代码一定不要有。你写在广播里面，但是你并没有。
31. 看代码：
32. 看到一个类，先看继承关系
33. 然后看里面，也就两个，成员变量（全局作用的东西），方法。
34. 做事情，重要的不是做，而是先想出来怎么做。不乱，不错。怎么做比做更重要。

32．面向接口编程， 面向对象编程。我开始读源码，Android源码。还有设计模式。
这些真的太重要了，它比写代码重要。
可维护性，扩展性，更健壮、更稳定，通俗易懂。
面向过程编程。。。。
真的是，负责一个模块，真的是，比改bug有意思多了。设计师，架构师。其实，实现功能没什么。

32. 一次次的机会，怎么可以就浪费了。长见识的什么的。
33. 解决问题的时候，不要大意，一定不要自己生成bug,比如空指针。
34. 呼呼，对人就是不一样，那个哥哥的叫的亲。
35. 做事情要有时间意识
    主动推进事情，然后你是leader
    要想着怎么样为公司盈利，你为公司创造了一亿的财富，那么你年薪一千万都没问题
    做事情要有原型图，否则后面随便做出来没效果，然后重新做？
36. 今日总结抄送你同事，一块做项目的同事。
37. 自己做的事情，就把事情做好，不要让同事给你擦屁股。反正我是不想这样，不想自己的事情别人帮我做，不喜欢本来不用麻烦别人的给别人造成麻烦。
38. 不知道的事情，就要问。不然难死你你也不知道，没有什么捷径。别人做的项目，多问。问测试，问技术，问服务端。自己不是贴别厉害的情况下， 唯一的优势就是要问。就像福尔摩斯一样，只有你掌握一些东西，才能做事情。

结构 互动 怎么样做到的，通过接口
怎么样调用了他的什么什么。 怎么实现的这个功能

主动
才能脱颖而出 ，鹤立鸡群，才有机会，人本性确实是安逸。
效率
做事情要有效率。
突然发现，自己虽然看了很多书，但是，真正作用在自己身上的，好少，好少，除非那种看了两遍以上的书，比如人性的弱点。

不能停留在只为了功能
具体说明：不能只为了实现某一块功能，趁热对整个模块的业务逻辑都弄清楚

如果可以分享章节，就好了。一篇好文章，我想分享，只能分享一本书？

新添加的代码呢，不能随便return。就像上报阅读进度，书籍退步出来的问题，finish不掉。你随便return了会影响到原来的功能。

记住，代码那一块，你已经看了三遍，确定不是这一块的问题，那么就想想，他肯定会走那一块？finish？

开发有一个例子数据不就好了吗

以后写代码我不能只为了功能，完全不考虑稳定性。逻辑不能混乱。
这么b货，写个代码，那么多如果。狗日的。但是，就需要这样啊。

和厂商打交道，主动去问，是对的。
然后不要上去给别人说这个是sdk,你去更新一下。要把改了什么，为什么要更新，在群里，让大家都知道。不然就会出现，一堆人问你为什么要改？哈哈。