公司技術大咖分享會 後記

2022-07-03 05:15:08 字數 2590 閱讀 6803

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

今天下午公司內部召開了個後台開發人員技術分享會,總共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、要有機會去寫設計文件,大膽地發出分享自己的設計文件,同時再簡單的開發也要先完成設計文件後編碼。

經驗分享&意見建議

1、經驗從何而來,一切都順利是否是好事呢?

並非好事,因為如果一切都很順利,那麼成長值將為0;如果你總是在做增刪改查,發現自己總是在重複勞動,那麼成長就是零;應該像海綿一樣去吸收相關的附加點,且遇到的問題越多越好。

2、知識技能體系,成長體系?

這些知識體系並不會因為你沒有掌握和注意,該體系就不存在,體系實際是重要的成長目標牽引;比如mysql這個體系,你也許會安裝和簡單的使用mysql,但是比如mysql優化和高階搜尋裡面的某些東西你不一定懂,而他確實是存在的,確實也是有開發人員掌握了的,此時自己要想辦法覆蓋這整個體系,完善自己的知識技能樹。

3、問題處理是練兵的利器?

問題單處理流程實際上是處理問題的通用流程;問題單處理多了,你自然就會思考,這個問題為什麼要這樣子處理,為何是這個流程呢?然後,慢慢的這個東西就會融入了你的血液,成為你身體的一部分。

4、對於個人成長,當下最重要的是什麼?

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

5、事務分解能力?

包括問題處理和需求開發,再難的任務都可以分解成一件件小事去完成。

6、作為後台開發人員,要怎麼解決問題呢?

首先是問題描述,該問題一定是可以復現的,現象出來後你的定位思路是如何,然後你的定位過程是如何,最終你解決的問題一定是你定位出來的而且是能重現的問題。

開發人員面對問題時有兩種態度:

1、遇到問題直接面對他,解決他;

2、遇到問題繞過去,繞過去就是上面所提到的順不順利的問題,如果繞過去了,就失去了乙個成長的機會。

處理問題:

最重要的一點就是要先把問題復現,然後根據它的現象推測,有可能是哪些問題,再通過日誌列印判斷大概問題出在**,或是根據訊息,檢視訊息裡面攜帶的引數,看書在哪一步出的問題,正常的流程是怎樣的,異常的又是怎樣的,有可能是幾種流程,大膽的猜測驗證。

復現--->定界(前後端問題、哪個模組問題)--->推測--->列印、訊息、日誌、引數--->99%的問題都是可以通過debug(本地dubug和遠端debug)和日誌解決。

楊總給我的建議是:性格調整下,多與人溝通交流。

SK7 大咖分享隨記

到了一周中最放鬆的時刻,老梁回到家,家人往往都睡了。老梁就找點吃的喝的,今天喝了大半罐rio強爽8 c白桃酒,有點暈暈乎乎的。老梁坐在沙發上抱著電腦跟大夥聊聊天,今天聊點啥呢?前些天公司請了頭部公司研究員大咖來分享,大領導口乾舌燥費了好大勁請來的。大咖抽出寶貴的時間來分享,聽的人不少,聽進去的不多,...

大咖分享 百度語義技術及應用全解

本報告提綱分為以下3個部分 語義表示 語義匹配 未來重點工作 計算機理解語言是乙個具有很大挑戰的問題。人類在理解語言的過程中,除了語言符號本身的識別,還包含符號背後的語義和知識。舉個例子,當人看到 計算機 這個符號時,腦子裡能迅速浮現出計算機的畫面以及和計算機相關的知識和概念,但是這對於計算機就比較...

技術分享會 談談公司內部的技術分享

這段時間,為了促進程式同事間技術氛圍,在公司內部組織開展技術分享會。形式很簡單,每週進行一次技術分享 分享人由組員順序安排 題材不限,可以是自己熟悉的技術,比如說服務端的開發者,分享後端定時器,訊息佇列等等,前端的開發者分享載入的模式,mvc模式等等,可以是一些通用的技術,比如資料結構,演算法,風格...