公司技術大咖分享會--後記
今天下午公司內部召開了個後臺開發人員技術分享會，總共7個人，兵不在多；三個華為資深大咖給我們分享了程式設計師那些事，憑我僅有的記憶現在把它記下，希望對之後的職業生涯有所幫助。
回想當時，分享的內容可以概括為三個大點：
1）關於設計文件那些事；
2）大咖十幾年開發經驗分享；
3）大家相互交流，提出意見和建議等。
關於設計文件那些事：
1、做軟體開發要接受一個現實，那就是軟體開發就是不個斷髮現錯誤的過程，一定不是完美的，所以設計文件要速出，由粗到細，常見的問題就是完美主義(尤其是新手)。
2、設計文件做到一定程度，它其實是有套路的，主要組成如下：
架構：資料模型、介面定義；
流程：正常流程、異常場景；設計
交叉影響：配置介面、資料庫、可靠性、效能等。
3、設計文件中最重要的就是場景(處理過程)：正常場景、異常場景。
4、在設計文件之前可以有個可行性探索。
5、設計文件的好處：
a. 逼迫思考場景(CASE的實質就是場景)，文件寫得好，編碼不亂；
b. 設計文件能夠指導整個開發流程，包括編碼、介面文件和測試用例，所有出現的問題都可以追溯到設計文件中；
c. 出了設計文件，可以工程方式編碼(實現就是細節問題)；
d. 提醒自己反覆思考，提升理解，尋求更好的實現方式。
6、設計文件最怕的就是設計遺漏了場景，及時地把發出來後，能夠儘早發現問題，大家看了可以提出建議，比如自己設計漏了哪些場景。
7、設計文件是用於指導自己下一步的工作，包括編碼、介面文件和測試用例的全程指導，而不是寫給領導看的。
8、設計文件寫得詳細了，讓別人能夠看得懂，才能給自己提意見，才可以使得自己做的事更好，設計存在的異常和漏洞就更少。
9、記得在設計文件裡面列出一個提綱(包括文件中設計的各大功能點)，由提綱深入架構。
10、寫設計文件沒有用嗎？文件可以保證你開發點不漏，思路清晰，水平高的人，寫設計文件水平也高，最高的就是去寫標準，如HTTP、RFC等。
11、為什麼要研究標準呢？比如兩個系統對接出了問題怎麼辦，誰改，改的依據是啥？通過瀏覽協議，發現協議上是這麼定義的，某個欄位定義了不能透傳，傳了那你就要改。
12、寫設計文件對於寫作的功底還是有要求的，表達條理清晰，讓自己和他人看得懂，也不要以為存在錯別字並不重要，影響個人形象只是其一(假如某天你和Boss一起編寫一個設計文件)。
13、實際上設計文件對應著就是一個分解的步驟，再難的事情，都可以分解成一件件小事去完成，對應著正常和異常的場景去設計。
14、要有機會去寫設計文件，大膽地發出分享自己的設計文件，同時再簡單的開發也要先完成設計文件後編碼。
15、設計文件中要配上原型圖(低保真介面圖)，手段不重要，不會畫圖也不是關鍵，有以下幾個方式：
a. 使用原型設計軟體
下載地址：https://www.mockplus.cn/，需要用郵箱註冊個人免費版；
b. 使用Excel表格畫原型圖；
c. 手筆草稿畫圖，手機拍照上傳。
經驗分享&意見建議
1、經驗從何而來，一切都順利是否是好事呢？
並非好事，因為如果一切都很順利，那麼成長值將為0；如果你總是在做增刪改查，發現自己總是在重複勞動，那麼成長就是零；應該像海綿一樣去吸收相關的附加點，且遇到的問題越多越好。
2、知識技能體系，成長體系？
這些知識體系並不會因為你沒有掌握和注意，該體系就不存在，體系實際是重要的成長目標牽引；比如MySQL這個體系，你也許會安裝和簡單的使用Mysql，但是比如Mysql優化和高階搜尋裡面的某些東西你不一定懂，而他確實是存在的，確實也是有開發人員掌握了的，此時自己要想辦法覆蓋這整個體系，完善自己的知識技能樹。
3、問題處理是練兵的利器？
問題單處理流程實際上是處理問題的通用流程；問題單處理多了，你自然就會思考，這個問題為什麼要這樣子處理，為何是這個流程呢？然後，慢慢的這個東西就會融入了你的血液，成為你身體的一部分。
4、對於個人成長，當下最重要的是什麼？
最重要的是結合當前自己的工作，填充自己欠缺的知識技能，出色的完成上級安排的任務；因為如果連上班8小時，本職的工作都做不好，還能在其他的領域有傑出突破貢獻嗎？工作的思考：不要重複工作，對於那些必不得已得重複的工作要搞出花來，比如很快地完成或是搞個工具自帶完成等待；一些優秀的書籍會限制你認識事物的上限；剛剛畢業1~2年的小夥子，最重要的是自己要學會思考，多上上心；開發人員的基本功最為重要，同時要覆蓋自己的知識技能體系，你的對手永遠都只是你自己。
5、事務分解能力？
包括問題處理和需求開發，再難的任務都可以分解成一件件小事去完成。
6、作為後臺開發人員，要怎麼解決問題呢？
首先是問題描述，該問題一定是可以復現的，現象出來後你的定位思路是如何，然後你的定位過程是如何，最終你解決的問題一定是你定位出來的而且是能重現的問題。
開發人員面對問題時有兩種態度：
1、遇到問題直接面對他，解決他；
2、遇到問題繞過去，繞過去就是上面所提到的順不順利的問題，如果繞過去了，就失去了一個成長的機會。
處理問題：
最重要的一點就是要先把問題復現，然後根據它的現象推測，有可能是哪些問題，再通過日誌列印判斷大概問題出在哪裡，或是根據訊息，檢視訊息裡面攜帶的引數，看書在哪一步出的問題，正常的流程是怎樣的，異常的又是怎樣的，有可能是幾種流程，大膽的猜測驗證。
復現--->定界(前後端問題、哪個模組問題)--->推測--->列印、訊息、日誌、引數--->99%的問題都是可以通過Debug(本地Dubug和遠端Debug)和日誌解決。
楊總給我的建議是：性格調整下，多與人溝通交流。