吾日內省

11-13

• 1.工做期間打開社交軟件次數過多，須要優化到3次如下，前期尋求軟件層面的控制，後期自制。
• 2.寫代碼前須要作的幾件事情：
  • 1.瞭解代碼的上下文結構
  • 2.瞭解所調用 api 可能會返回的數據類型
  • 3.瞭解業務邏輯
  • 4.處理業務數據須要注意下面這些問題：
    • 1.瞭解數據表示的意義
    • 2.瞭解數據的消費方，以及修改後對消費方的影響。
    • 3.瞭解數據被處理先後的狀態。

11-14

• 1.寫代碼時，使用好 library 是一個很是能提升效率的事情，好比 guava 這個 google 的 java 工具庫的使用：集合功能、參數檢查、區間範圍、字符串操做、緩存、各類工具方法、多線程等等。
• 2.寫代碼就如同搭積木，對每一個方法的入參須要瞭解其傳入的可能性，瞭解了以後就須要使用一些工具對入參進行檢查，若是不對就提前拋出問題，而不是等到後面某個地方拋出 exception。例如Preconditions。
• 3.在想用一個工具代碼的時候，遵循下面的搜索路徑：search jdk ——> search guava—— >search others library ——> write you own

11-15

• 無

11-16

• 1.protobuf 的 message get 的時候返回的不多是 null，集合默認返回空，對象會返回默認對象

11-19

• 1.工做注意力不夠集中，效率不夠高，須要找方法優化：
• 2.23點以後工做學習效率低下，儘可能作一些放鬆的事情好比看閒書看電影：達到要求，娛樂時間目前集中在23點之後
• 3.編程時數據流須要清晰，確認數據處於某種狀態以後(好比不爲null)，就不須要對其進行保護。只有確認爲不肯定的數據才須要保護。
• 4.在寫某個代碼流程的時候(好比 canvas 繪製)，整個流程的開始和結束要由一個 owner(能夠是某個方法，或者類中配對的方法) 來操做。這個規則相似業務邊界限制，可以有效解耦代碼流程。防止代碼流程的狀態混亂。

11-26

• 1.接手他人代碼或進入一個成熟的項目寫代碼就如帶着鐐銬跳舞
  • 1.要遵循原有代碼的設計，除非對代碼很是熟悉，並且很是須要修改，否則不要另起爐竈。
  • 2.對於須要修改的部分，須要從數據結構入手，瞭解了數據結構表明的意義才能開始進行老代碼的修改。
• 2.大項目的開發，性能是很重要的點。可能開發以前運行的好好地，可是由於加的代碼讓性能差了一點，而後由於雪崩效應，就形成了整個 app 的 anr 或者 oom。注意如下事項
  • 1.開發的時候手機不能太好，太好的手機會掩蓋不少問題，而這些問題在低端機型測試的時候就會暴露出來，以後就會形成在性能差的代碼上面加補丁這種現象。結構差、性能差的代碼須要在開始編碼的時候就注意
  • 2.音視頻開發中，除了網絡請求和文件讀取，還會使用到不少耗時長的 api，這些 api 在開發的時候一不注意就會在主線程調用。這也是須要極力避免的事情。

12-19 項目覆盤

• 1.改進
  • 1.在開始需求以前能瞭解到部分需求邊界，這個比以前有進步。
  • 2.git 提交格式有改進
  • 3.不隨意造輪子，能使用現有工具
• 2.問題
  • 1.需求邊界瞭解的不是很完全，正式開始寫代碼以後有些 case 才被發現，這個須要持續改進
  • 2.若是不清楚全部已經被他人依賴了的代碼的調用處的邏輯，那麼就別去修改他，即便這個代碼是有問題的。
  • 3.千萬別在不瞭解業務的狀態下優化代碼，不管是代碼結構仍是代碼性能。
  • 4.對於打日誌，須要根據具體代碼情境打相應級別的日誌，不可一刀切只打 info 或者 debug。
  • 5.在開始寫需求以前必定要花必定的時間肯定代碼的總體設計。這個設計須要能融入現有的代碼體系，不可自起爐竈。
  • 6.若是上線前使用的測試環境的數據有問題，須要以線上環境的數據爲標準，而後輔助以臨時代碼進行修正。千萬別基於測試環境的數據進行代碼的編寫。
  • 7.數據與邏輯須要進行分離，切不可將邏輯與數據進行耦合。只要某個數據產生了，那麼讓邏輯配合數據，而不是數據配合邏輯。
  • 8.開發過程當中，除非實在沒法解決，不然不可臨時寫一個解決方案，而後期待後面解決。由於一旦代碼寫下了，那麼後續就會有代碼依賴，後面解決的成本永遠比如今解決的成本高。
  • 9.時刻注意調用他人的 api時，其 api 須要處於的線程

2019年開始

01-07 項目覆盤

• 1.改進：
  • 1.需求開始前，能完整的整理出需求的流程
  • 2.需求開始前，能寫技術文檔
  • 3.需求開始前，能基本瞭解涉及的代碼的邏輯
  • 4.不隨意造輪子，用上了 guava
  • 5.沒有再隨意改動和優化老的邏輯
  • 6.review 後重寫代碼的量有減小
• 2.問題：
  • 1.除非萬不得已，千萬不要定義一塊在程序的生命週期內永遠也釋放不掉的內存，好比不被置空靜態常量。要儘可能讓內存隨着處理的邏輯走，或者使用弱引用這些可被回收的東西。
  • 2.使用觀察者模式的時候注意要在適當的時候進行註冊和反註冊，以避免在不須要觀察的時候接收到事件。好比 eventbus在 fragment 銷燬以後還在接收事件。須要注意的是handler 的 post 會讓一個事件延後進行，這樣也會形成未知的問題
  • 3.代碼的可閱讀性很是重要，在寫代碼的時候要時常問本身，若是是一個新手過來看代碼他能看得懂嗎？
  • 4.代碼邏輯必定要跟着數據走，數據簡練並且正確，那麼代碼邏輯也就會簡練正確。
  • 5.要時刻注意生命週期這東西，不論是數據的生命週期、仍是需求的生命週期、仍是操做流程的生命週期、仍是 Activity 的生命週期。

01-15 項目覆盤

• 1.改進：
  • 1.無。。。
• 2.問題：
  • 1.須要將一個東西的初始化的所有代碼放在一個代碼區域。而不是讓初始化邏輯散落在各個地方，而後靠某個id 或者其餘東西將不一樣的地方的數據鏈接起來。這樣會形成如下問題：
    • 1.給後面接手代碼的人留坑，一不當心就會漏加了某個初始化的邏輯
    • 2.這樣的代碼是低內聚的
  • 2.仍是要注意對一個數據塊所有生命週期的控制，申請了一塊內存就要去找地方釋放它。對於 java 類語言來講就是不引用它了，對於 c/c++ 類語言來講就是手動 delete
  • 3.如無必要勿增實體，這句話出自「奧卡姆剃刀」。在寫代碼上體現的就是：在保證業務邏輯的前提下，儘可能定義或使用最簡單的數據結構，數據結構越簡單寫出來的邏輯就越簡單，千萬不要使用無效的中間數據結構
  • 4.不要保證臨時代碼的想法去寫代碼。 在開始寫代碼的時候就想好整個結構，比先寫代碼而後後面去調整結構效率會更高。

03-05

• 1.不要把某些事情不當回事，這些事情最終可能演變成大事情。預防比治理方便百倍。
• 2.對外提供的 api，不要包含當前層次不須要作的事情，有些事情應該交給被調用者作。也就是說 api 的內部實現須要對調用者是透明的，調用者不用去搞清楚 api 的內部實現也能夠順利調用。
• 3.presenter 須要數據和 ui 一塊兒拆，presenter 之間不須要太多的數據交互
• 4.不論是寫代碼仍是改 bug 有時候須要找到問題的本質，而不要只要改表面的問題。跳出當前的思惟侷限，就能找到更好的辦法。
• 5.在改代碼的時候必定要跳出原來的思惟，以新的思路想一想
• 6.接手別人未測試的代碼的時候必定要完整的瞭解他們寫的東西，否則坑很大
• 7.儘可能將回答他人的話用實際證實，看代碼的時候路徑這些東西能夠 debug 看，不要懷着心虛去寫代碼