背景
記錄在工作中需要分析和思考到的點。
過程如果需求不合理，就得委婉表達這個需求無法做。換一種實現方式。
如果需求要修改系統原有設計，就得表明需求無法做。換一種實現方式，因為重新設計一套系統，費時費力。
如果需求要動一些框架的**，比如使用activiti做加籤操作，則也是乙個非常難的需求。即使不修改框架**，也需要花費大量的時間理解到activiti是怎樣工作的，才有可能寫出來。
根據時間週期和專案已有設計，適當調整一下需求，不要非常教條，需求是怎樣就一定要做成怎樣，可以適當調整一下。
只要結果正確，過程合理，即使不是嚴格的實現，變通的解決方案，也是可行的。
如果系統原有設計已經是這樣了，那麼就應該思考，如何在已有設計的基礎上，更好的實現需求。
每乙個需求，都應該問問：為什麼要做這個需求？
每乙個需求，都需要理解這個需求的使用場景。
是否花費了足夠時間去理解原型，並且與產品進行溝通？
做的功能設計是否及時與web client, ios, android溝通?
完成的功能需求，是否能夠應對需求的改變？如何設計才能應對需求的改變呢？大膽的設計，不要拘泥於現有系統的設計，打破它。
如果需求有問題，需要積極組織會議討論。
如果需求過於難，花費幾天也沒有找到思路，需要積極向上反饋。
寫的**邏輯，是擴充套件還是修改？會不會影響原有的邏輯過程？
功能邏輯的實現的影響範圍有多大？
功能能夠相容原來的移動端邏輯嗎？因為ios發布版本也是乙個漫長的過程，完成功能需要考慮到，盡可能少修改ios的**。
知道有哪些具體的任務。每個任務實現細節是怎麼樣的。哪些是底層的通用功能設計？哪些是上層的變化需求？
對乙個專案底層業務邏輯非常熟悉，那麼就應該花費時間去做功能設計。比如工作流引擎業務相關的設計，把這些設計做成更加通用的功能，而把上層變化的需求分配給同事。
任務分配：自己需要做哪些？為什麼自己要做這些？哪些是需要分配出去的？為什麼要分配這些？
能夠批量插入資料庫的就不要一條一條插入。
區分功能方法和業務方法。功能方法就需要設計得更加通用一些，誰都可以呼叫這樣的功能方法。切記：功能方法不能耦合業務邏輯。
在**的抽象層上。比如乙個list寫判斷。這個list是null的時候應該怎麼處理？size為1的時候又怎麼處理？像這樣的抽象層一般考慮兩種情況空和非空。也就是說把size為1的情況寫到多的情況中。
固有**邏輯：找到需要截斷的業務邏輯，採用return截斷。
每乙個介面都需要考慮：重複提交怎麼辦？事務怎麼處理？併發怎麼處理？日誌記錄了嗎？是否需要使用分布式鎖？是否需要使用分布式事務？
使用list的時候，如果能夠確定容量大小，一開始就需要給定。
立即看日誌記錄。尋找問題原因。
積極詢問產生問題的全過程，看能否在測試環境復現。
定位問題，分析問題，找到問題原因，解決問題。一定是這樣的步驟。如果是涉及oom之類的，先解決問題比如加大一下堆上記憶體。其次就是線上使用arthas工具分析，哪些物件建立了，未**。
如果是棧溢位了，則加大棧的記憶體大小，先解決問題。其次，找到是呼叫了哪個方法導致這樣的bug發生，分析為什麼會發生。 小結
通過一次又一次的總結，力求做更好的功能設計，把**寫的更好。
思考：如何去溝通需求？分析需求？做更加好的需求功能設計？
思考：如何才能非常完備地把**寫好？
2018 6 2019 6實習總結與感悟
在為期一年的實習過程中，我的工作內容是使用人工智慧方法解決廠區生產計畫 的任務。實際上就是使用深度學習方法 cnn lstm attention 模型結構解決時間序列 的任務。通過實習的工作經歷。我認為對乙個演算法工程師或者說乙個初級的演算法工程師來說，將發明乙個里程碑式的新演算法作為工作內容是不現...
資料分析總結與感悟
小生今年研二，從事軟體資料分析與挖掘不到兩年。兩年裡小生忙忙碌碌，從來沒有總結過自己的工作，今天暫停住忙碌的腳步，隨意書寫幾行文字，權當忙裡偷閒總結這兩年資料分析與研究的經歷與體悟。大家共勉！分析資料其實說難也難說簡單也是簡單的。分析的難點在於初始分析某個專業領域的資料是 無從下手 的，資料量之大，...
順序結構程式設計知識總結與感悟
首先了解了計算機系統的組成和程式的基本結構並開始初步編譯程式。進而學習順序結構程式設計，並開始解決問題 a解決問題基本步驟 a 了解問題 b 考慮解決方案 c 程式語句描述方案 d 除錯執行 b語句的學習 cout語句 實現輸出功能的語句 cin語句 實現輸入功能的語句 賦值語句 注意 單等號賦值，...