公司技術大咖分享會--后記
今天下午公司內部召開了個后台開發人員技術分享會，總共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)和日志解決。
楊總給我的建議是：性格調整下，多與人溝通交流。