-
不是简单的复制，该放在fragment里面的放在fragment里面。
不怪我，我当时的能力差，根本没有编排代码的能力。也不熟悉，给我的时间也少。我以后会努力做到不是完成任务，而是把事情做好。 -
.接口用来回调。
-
一个activity 将会很庞大。（提取出来吧，不可能搬砖一样吧）
-
Bundle bundle = getIntent().getExtras();
1.NAVI_INDEX_ACCOUNT
2.mFragmentList.get(position)
这种明显的会崩溃的代码不要有。
- ((OnlineFragment)getCurFragment()).goBackAndExit();
4.onKeyDown 抽象一个basefragment
写非空判断是一种习惯
Base里面可以放一下跟界面什么无关的一些逻辑，让fragment什么的看起来代码少一点。
除了编程之外的东西：
- 做事情要主动。
- 积极吸取别人的经验。已经有的bug，当你遇到的时候，你就。。。。
- 挑战自己的脑子。必须提出一个问题。而且当时我是第一个。
- 你要对你写的代码负责任
- 其实一件事情没有你想象中的那么难，和浪费时间
- 围绕是什么为什么怎么做
- 画图 讲细节 讲包和类
- 集思广益
- 周报不是让你回报的多清楚，而是培养你明天要干什么，对明天的规划
- 做事情，简 繁 简
- Bug是有日期的，多久之前是要解决完的。
12.由一个变量，找到那里用到了，然后。。。。一点一点的解决bug。
夜间模式这个问题，本来是一个小问题，但是我用了一上午加差不多一下午才解决。我把功夫放到了没用的东西上，一堆变量，然后呢，没什么用。不就是点击之后做了什么，这里做了，那里没有做。再说，用脑子想想，肯定在bookshelfFragment那里有这一块的代码。因为功能在那里有啊。。。自己瞎调试，调试了那么久。。都不知道关键。
- traceView trace文件
- 调试布局就加背景色。
- 没有事情做了，提前给他说。。。。哎。身份卑微。。。心宽，这都不算事。
- 维护代码，找代码，一定要顺藤摸瓜，不能抱着侥幸心理去瞎找。代码太多了。
- 类的继承关系一定要搞清楚。看一个类第一眼看的就是继承关系！
- 维护代码要认真，不能以改动少为目标，而是以以后扩展。
- 主动，至少每天问一遍进度。
- 目标，有自己的计划和目标。熟悉代码的某一个模块，等等。
- Utils分为两类，一类是通用的commonUtils，第二个是这这个app内的，apputils
- 写代码要分层。第一层就是通用的，第二层是封装了一下，供某个具体业务用的。
- 以后他妈的测试什么，都写清楚，能不能用6.0的手机测试等等。别他妈的别人说你这是什么啊，打不开，你又跟人家解释。好吗？我不喜欢丢人。
- 提测要自测通过了，再提测。不然别人烦，到时候你也没面子。
- 永远要不要其烦的点。因为！因为你觉得是系统的方法，他妈的，他就是重写了，而且关键逻辑就在这里。
- 可以根据一个变量，解决一个bug。 登录退出都是那个变量，findUseage。Token为空了，那么在哪里为空了？
- 弄个记事本，我也有今天，事情多的忙的处理不过来，但是不能忘，也记住。没完成一个就删了它。现在我才知道，嗯，很管用。
- 排除法解决bug,，这一块代码我已经弄了半天，各种都认真的试验过了，那么就说明不是这一块的问题，去想其他的地方，虽然可能你都不知道是哪一块在影响她。
- 主动，主动去推进。我就不怕你觉得我烦，没关系，我一天问你一次进度。我终于知道，产权部那个人做事情的，有一天，你会感谢我，进度没有延期。
- 压力不要太大，你做不到的事情，老员工会处理的。不要怕，学会求助。
- 你写的代码一定会执行吗？不一定，所以，这种代码一定不要有。你写在广播里面，但是你并没有。
- 看代码：
- 看到一个类，先看继承关系
- 然后看里面，也就两个，成员变量（全局作用的东西），方法。
- 做事情，重要的不是做，而是先想出来怎么做。不乱，不错。怎么做比做更重要。
32．面向接口编程， 面向对象编程。我开始读源码，Android源码。还有设计模式。
这些真的太重要了，它比写代码重要。
可维护性，扩展性，更健壮、更稳定，通俗易懂。
面向过程编程。。。。
真的是，负责一个模块，真的是，比改bug有意思多了。设计师，架构师。其实，实现功能没什么。
- 一次次的机会，怎么可以就浪费了。长见识的什么的。
- 解决问题的时候，不要大意，一定不要自己生成bug,比如空指针。
- 呼呼，对人就是不一样，那个哥哥的叫的亲。
- 做事情要有时间意识
主动推进事情，然后你是leader
要想着怎么样为公司盈利，你为公司创造了一亿的财富，那么你年薪一千万都没问题
做事情要有原型图，否则后面随便做出来没效果，然后重新做？ - 今日总结抄送你同事，一块做项目的同事。
- 自己做的事情，就把事情做好，不要让同事给你擦屁股。反正我是不想这样，不想自己的事情别人帮我做，不喜欢本来不用麻烦别人的给别人造成麻烦。
- 不知道的事情，就要问。不然难死你你也不知道，没有什么捷径。别人做的项目，多问。问测试，问技术，问服务端。自己不是贴别厉害的情况下， 唯一的优势就是要问。就像福尔摩斯一样，只有你掌握一些东西，才能做事情。
结构 互动 怎么样做到的，通过接口
怎么样调用了他的什么什么。 怎么实现的这个功能
主动
才能脱颖而出 ，鹤立鸡群，才有机会，人本性确实是安逸。
效率
做事情要有效率。
突然发现，自己虽然看了很多书，但是，真正作用在自己身上的，好少，好少，除非那种看了两遍以上的书，比如人性的弱点。
不能停留在只为了功能
具体说明：不能只为了实现某一块功能，趁热对整个模块的业务逻辑都弄清楚
如果可以分享章节，就好了。一篇好文章，我想分享，只能分享一本书？
新添加的代码呢，不能随便return。就像上报阅读进度，书籍退步出来的问题，finish不掉。你随便return了会影响到原来的功能。
记住，代码那一块，你已经看了三遍，确定不是这一块的问题，那么就想想，他肯定会走那一块？finish？
开发有一个例子数据不就好了吗
以后写代码我不能只为了功能，完全不考虑稳定性。逻辑不能混乱。
这么b货，写个代码，那么多如果。狗日的。但是，就需要这样啊。
和厂商打交道，主动去问，是对的。
然后不要上去给别人说这个是sdk,你去更新一下。要把改了什么，为什么要更新，在群里，让大家都知道。不然就会出现，一堆人问你为什么要改？哈哈。
网友评论