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.改進：
- 2.問題：
- 1.需要將一個東西的初始化的全部程式碼放在一個程式碼區域。而不是讓初始化邏輯散落在各個地方，然後靠某個id 或者其他東西將不同的地方的資料連線起來。這樣會造成以下問題：
- 1.給後面接手程式碼的人留坑，一不小心就會漏加了某個初始化的邏輯
- 2.這樣的程式碼是低內聚的
- 2.還是要注意對一個資料塊全部生命週期的控制，申請了一塊記憶體就要去找地方釋放它。對於 java 類語言來說就是不引用它了，對於 c/c++ 類語言來說就是手動 delete
- 3.如無必要勿增實體，這句話出自“奧卡姆剃刀”。在寫程式碼上體現的就是：在保證業務邏輯的前提下，儘量定義或使用最簡單的資料結構，資料結構越簡單寫出來的邏輯就越簡單，千萬不要使用無效的中間資料結構
- 4.不要保證臨時程式碼的想法去寫程式碼。 在開始寫程式碼的時候就想好整個結構，比先寫程式碼然後後面去調整結構效率會更高。
來源：https://juejin.im/post/5beb8e206fb9a049c0429329