不是簡單的復制，該放在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,你去更新一下。要把改了什么，為什么要更新，在群里，讓大家都知道。不然就會出現，一堆人問你為什么要改？哈哈。
