公司技術大咖分享會--後記

公司技術大咖分享會--後記

 

今天下午公司內部召開了個後臺開發人員技術分享會，總共7我的，兵不在多；三個華爲資深大咖給咱們分享了程序員那些事，憑我僅有的記憶如今把它記下，但願對以後的職業生涯有所幫助。

回想當時，分享的內容能夠歸納爲三個大點：

1）關於設計文檔那些事；
2）大咖十幾年開發經驗分享；
3）你們相互交流，提出意見和建議等。

 

關於設計文檔那些事：

一、作軟件開發要接受一個現實，那就是軟件開發就是不個斷髮現錯誤的過程，必定不是完美的，因此設計文檔要速出，由粗到細，常見的問題就是完美主義(尤爲是新手)。

二、設計文檔作到必定程度，它實際上是有套路的，主要組成以下：
架構：數據模型、接口定義；
流程：正常流程、異常場景；設計
交叉影響：配置接口、數據庫、可靠性、性能等。

三、設計文檔中最重要的就是場景(處理過程)：正常場景、異常場景。

四、在設計文檔以前能夠有個可行性探索。

五、設計文檔的好處：
a. 逼迫思考場景(CASE的實質就是場景)，文檔寫得好，編碼不亂；
b. 設計文檔可以指導整個開發流程，包括編碼、接口文檔和測試用例，全部出現的問題均可以追溯到設計文檔中；
c. 出了設計文檔，能夠工程方式編碼(實現就是細節問題)；
d. 提醒本身反覆思考，提高理解，尋求更好的實現方式。

六、設計文檔最怕的就是設計遺漏了場景，及時地把發出來後，可以儘早發現問題，你們看了能夠提出建議，好比本身設計漏了哪些場景。

七、設計文檔是用於指導本身下一步的工做，包括編碼、接口文檔和測試用例的全程指導，而不是寫給領導看的。

八、設計文檔寫得詳細了，讓別人可以看得懂，才能給本身提意見，纔可使得本身作的事更好，設計存在的異常和漏洞就更少。

九、記得在設計文檔裏面列出一個提綱(包括文檔中設計的各大功能點)，由提綱深刻架構。

十、寫設計文檔沒有用嗎？文檔能夠保證你開發點不漏，思路清晰，水平高的人，寫設計文檔水平也高，最高的就是去寫標準，如HTTP、RFC等。

十一、爲何要研究標準呢？好比兩個系統對接出了問題怎麼辦，誰改，改的依據是啥？經過瀏覽協議，發現協議上是這麼定義的，某個字段定義了不能透傳，傳了那你就要改。

十二、寫設計文檔對於寫做的功底仍是有要求的，表達條理清晰，讓本身和他人看得懂，也不要覺得存在錯別字並不重要，影響我的形象只是其一(假如某天你和Boss一塊兒編寫一個設計文檔)。

1三、實際上設計文檔對應着就是一個分解的步驟，再難的事情，均可以分解成一件件小事去完成，對應着正常和異常的場景去設計。

1四、要有機會去寫設計文檔，大膽地發出分享本身的設計文檔，同時再簡單的開發也要先完成設計文檔後編碼。

1五、設計文檔中要配上原型圖(低保真界面圖)，手段不重要，不會畫圖也不是關鍵，有如下幾個方式：
a. 使用原型設計軟件
下載地址：https://www.mockplus.cn/，須要用郵箱註冊我的免費版；
b. 使用Excel表格畫原型圖；
c. 手筆草稿畫圖，手機拍照上傳。

 

經驗分享&意見建議
一、經驗從何而來，一切都順利是不是好事呢？
並不是好事，由於若是一切都很順利，那麼成長值將爲0；若是你老是在作增刪改查，發現本身老是在重複勞動，那麼成長就是零；應該像海綿同樣去吸取相關的附加點，且遇到的問題越多越好。

二、知識技能體系，成長體系？
這些知識體系並不會由於你沒有掌握和注意，該體系就不存在，體系實際是重要的成長目標牽引；好比MySQL這個體系，你也許會安裝和簡單的使用Mysql，可是好比Mysql優化和高級搜索裏面的某些東西你不必定懂，而他確實是存在的，確實也是有開發人員掌握了的，此時本身要想辦法覆蓋這整個體系，完善本身的知識技能樹。

三、問題處理是練兵的利器？
問題單處理流程其實是處理問題的通用流程；問題單處理多了，你天然就會思考，這個問題爲何要這樣子處理，爲什麼是這個流程呢？而後，慢慢的這個東西就會融入了你的血液，成爲你身體的一部分。

四、對於我的成長，當下最重要的是什麼？
最重要的是結合當前本身的工做，填充本身欠缺的知識技能，出色的完成上級安排的任務；由於若是連上班8小時，本職的工做都作很差，還能在其餘的領域有傑出突破貢獻嗎？工做的思考：不要重複工做，對於那些必不得已得重複的工做要搞出花來，好比很快地完成或是搞個工具自帶完成等待；一些優秀的書籍會限制你認識事物的上限；剛剛畢業1~2年的小夥子，最重要的是本身要學會思考，多上上心；開發人員的基本功最爲重要，同時要覆蓋本身的知識技能體系，你的對手永遠都只是你本身。

五、事務分解能力？
包括問題處理和需求開發，再難的任務均可以分解成一件件小事去完成。

六、做爲後臺開發人員，要怎麼解決問題呢？
首先是問題描述，該問題必定是能夠復現的，現象出來後你的定位思路是如何，而後你的定位過程是如何，最終你解決的問題必定是你定位出來的並且是能重現的問題。

開發人員面對問題時有兩種態度：
一、遇到問題直接面對他，解決他；
二、遇到問題繞過去，繞過去就是上面所提到的順不順利的問題，若是繞過去了，就失去了一個成長的機會。

處理問題：
最重要的一點就是要先把問題復現，而後根據它的現象推測，有多是哪些問題，再經過日誌打印判斷大概問題出在哪裏，或是根據消息，查看消息裏面攜帶的參數，看書在哪一步出的問題，正常的流程是怎樣的，異常的又是怎樣的，有多是幾種流程，大膽的猜想驗證。

復現--->定界(先後端問題、哪一個模塊問題)--->推測--->打印、消息、日誌、參數--->99%的問題都是能夠經過Debug(本地Dubug和遠程Debug)和日誌解決。
楊總給個人建議是：性格調整下，多與人溝通交流。