關於程序員的職場心得
欄目:
心得體會 /
發佈於: /
人氣:1.53W
今天本站小編為大家傾情整理了一篇關於《一個程序員的職場心得》，都是乾貨，快來看看吧！![關於程序員的職場心得]( "關於程序員的職場心得")
軟件開發
作為程序員，接觸最多的當然是軟件開發了，以下是 7 條心得：
1、若無必要，勿增實體。
這是奧卡姆剃刀的定義，所謂剃刀就是法則，是奧卡姆這個英國學者提出來的。這個剃刀核心的點在於不要浪費較多東西去做，用較少的東西同樣可以做好的事情。放在軟件領域，就是不要過度設計，添加當前不需要的功能，也不要一開始就做的非常複雜，難以維護。
不需要用設計模式，就不用硬套。不需要用額外功能，就不要寫擴展。用設計模式和寫功能擴展，必須要有不得不這麼做的理由。
無論是新創建的軟件系統，還是添加功能到現有系統中，都應該從一個最簡單的版本開始，這個最簡版本甚至幾乎沒有可用功能。然後，再一步步迭代與重構，擴展它的功能，完善它的設計。簡單的系統自然而然會演變成複雜的系統，而不是人工注入複雜，影響它的正常進化。
2、日誌記錄，錯誤處理。
開發新系統必須要做的一件事就是搭建日誌記錄和錯誤處理能力，系統上增加功能也要接入日誌記錄和錯誤處理。雖然這不會影響正常場景的功能，但是非常重要。
日誌和錯誤可以告訴我們程序運行的時候發生了什麼，程序有沒有按照預期工作，通過日誌和錯誤我們可以基本知道程序運行的路徑，也可以用來做監控，統計和預警。
3、每行新代碼都要能被執行到。
新寫一個功能，一定要保證你的新代碼都能被執行到，也就是你的測試用例能夠覆蓋到代碼的每一行。有些特別的分支可能很難走到，但你要想辦法走到，比如構造符合該分支的請求入參，再比如異常分支可以使用 mock 工具 mock 異常出來做觸發。
4、一次只改一個地方。
這是種變量思維。在你開發時，發現程序掛了，如果你只改一個地方，很容易定位到問題所在，因為就一個變量，不可能是別的原因了，但如果你改了好幾個地方，之前也沒有測試，找出原因就會花費你大量的時間和精力。
所以，要小迭代，每迭代一個點確保功能符合預期，再進入下一個迭代，如此重複，而不是一股腦改掉所有的內容。
5、集成測試前要單元測試。
你負責一個單元，你的同事負責另外一個單元，入口側集成了這兩個單元，入口有專門的測試同學來測，以驗證整體功能的正確性。如果單元測試充分，就能使測試同學只關注各個單元之間協調的正確性，從而節省整體的時間和複雜度。
6、開發時間往往比預期長。
有時候，你可能會把事情想簡單，真正寫代碼的時候才會發現評估有遺漏，工期會比預期長。
有時候，代碼寫的非常順利，測試的時候可能就會被某個不符合預期的場景卡主，需要花很長的時間解決。
有時候，你依賴的下游未能按期向你交付服務，你的開發工作就要延期。
寫代碼容易，讓代碼正常無誤的跑起來，就比較費勁了，所以評估工作量要給自己留點 buffer（緩衝），以應對一些特殊情況。
7、讀代碼並且跑代碼。
對於一段代碼，想要理解它做了什麼事情。一種方法是閲讀它，憑藉自己的大腦去得出代碼運行的邏輯。
但這種方式並不可靠，畢竟人往往是靠不住的，不過系統是可以靠得住的。
那我們就可以跑這段代碼，去分析真實系統環境運行的結果。
職場協作
作為職場人，我的工作除了寫代碼，還有就是和各個角色的協作，像產品經理，項目經理，其他開發，測試，以下是職場協作方面的 7 條心得：
1.選擇適當的溝通方式。
就溝通效率而言，當面>視頻>電話>聊天軟件>郵件。
打擾強度和正式程度是反方向。
緊急的問題就當面或視頻或電話，搶奪對方的注意力，儘快解決。
重要的結論一定要落在聊天軟件或郵件裏。畢竟電話沒有存檔，出了問題沒法追溯。
但如果你什麼小事都要發郵件，那也太浪費自己時間了，什麼事情都要給人打電話，那也容易讓別人厭煩。
所以大多數場景，還是聊天軟件，你留言，對方看到了再回復，不必把雙方的溝通綁定在同一時間段。
2.藉助身邊人的力量。
有些時候，你做事情可能會卡主，這非常困擾你，而你也毫無頭緒。
這個時候你就可以藉助下身邊人的力量了。
比如一件事你在三個方案裏面糾結，你就可以整理好自己的思路，分析各個方案的優劣，然後帶着這些信息和同事或老闆溝通，尋求他們的建議。
有時候，你在向他們表達的時候，可能就意識到自己的方向了。當然，你也可以得到不同視角的建議，這對你方案的完善是很有幫助的。
所謂：好風憑藉力，送我上青雲。
3.善於提問。
很多事情自己是可以搞定，比如讀代碼和運行代碼可以理解這一塊邏輯，但這要花很多時間。如果你直接問作者，幾分鐘內你就可以拿到這些信息。
信息是可以換能量的。所以多提問，多獲取信息，你可以少做很多無謂的工作，從而把精力投身到重要的事情上。
4.不輕易承諾。
承諾並能順利完成事情，是值得佩服的。
但過分過早承諾不適合自己做的事情，對自己無疑是一個負擔。如果你本身帶團隊，對團隊也是個負擔。
承諾要慎重，如果還不明朗，就帶回去再評估考慮下。對外部團隊如此，對團隊同事也應該如此。
不要給了對方期待，又給對方失望，弄得自己信用也不佳。
5.分享利益。
一件事，如果有他人的貢獻，我們要感激這個人，也要分享利益給他。
比如你寫的專利裏某個人幫助了你，作者中一定要加入他的名字。
比如你在向領導彙報你主導的項目的時候，一定要提到其他參與者的名字。
之前看周杰倫演唱會錄影帶的時候，有一段是杰倫專門介紹場上樂隊各個成員的名字，當時看這段挺動容的，怪不得像方文山，楊瑞代這些人能和杰倫合作 20 多年。
6.清楚自己的角色，做角色份內的事情。
一張地圖上，首先要有定位，然後要有目標，才能去看走什麼樣的路徑。
角色就是這樣的定位。你把自己的角色定位成純開發，一般來講專注技術就好了。
但如果你想和產品經理更好的溝通，最好還是培養一些產品思維。這樣有個好處，就是一些技術類需求，你可以自己判定和定義了，此時你的角色就轉換成產品經理了。
如果需求比較多，不能馬上都做，需要排下期，週期長的項目還要管理下項目節奏，此時也沒有專職的項目經理介入，那你就可以嘗試做項目經理的角色。
你技術一路發展，對自己負責的領域瞭如指掌，你開始接觸了一些架構設計和決策的工作，那此時已經有新角色了，就是架構師的角色。
所以一個人是可以有多種角色的，角色決定了職責，因此一件事情中，要清楚自己的角色，做好角色份內的事情，不要越界，也不要失職。
7.讓子彈飛一會兒。
如果一件事存在爭議，你並不是爭議雙方的領頭人，只是這件事可能會涉及到你落地。那麼不要急着去介入具體方案和落地，讓他們再爭會兒，很可能最終的結論是你啥也不用做。
認知成長
作為終身學習者，職場工作的同時，也關心着自己的成長，以上更多是技能方面的，以下是認知成長方面的 7 條心得：
1.技術是工具，也可以是資產，還可以是商品。
技術有三個階段：技術支撐業務，技術驅動業務，技術創造商業價值。這三個階段技術是分別作為工具，資產以及商品存在的。
我們看到的一個個互聯網產品，背後都是由技術搭起來的，技術只是工具。
隨着業務發展，逐步沉澱面向某個問題的解決方案，有些以專利的形式體現，技術就成為了資產。
把通用的技術提煉出產品能力，像阿里雲的很多服務那樣，技術就變成了商品。
2.提升效率。
什麼叫效率？
效率就是你完成了多少事，除以你開始了多少事。你開始了一百件，只完成了一件，你的效率就是 1%。
所以提高效率的辦法，一個是你多完成事，第二個是你少開始事。
3.打造自己的知識系統。
人的大腦天生喜歡記憶結構化系統化的知識。零碎的知識點太多，也只是隱藏在大腦的某個角落，經常被忽視。
關鍵是建立體系化的知識結構，去幫助生活和工作上的決策。
4.機會留給主動的人。
主動向項目組同步進展，主動向領導彙報，主動把事情推向正確的方向。你會發現自己的運氣在變好。
5.凡事需要平衡。
一個算法要想獲得更快的時間，勢必要犧牲更多的空間。
同樣，無論項目方案還是架構設計，都沒有對和錯，要權衡當下更重視什麼，可以容忍什麼，做出適當的選擇即可，後邊可以再調節。
6.任何事都是一個 IPO。
I 是 Input，P 是 Process，O 是 Output，凡事都可以歸為 輸入-處理-輸出 的路徑，想好依賴方，處理方式以及交付物，事情就可以變得簡單。
7.公司是你的放大器也是你的限制器。
公司是一種組織，組織能輔助個人做成一些事，比如個人在組織中做項目得到成長，能得到優秀同事的幫助，能享受公司發展的紅利，能獲得公司的學習資源和其他福利。
但個人做事往往會受組織的限制，比如制度約束，工作時長，發展方向等等。
需要好好利用放大器，同時也要評估限制器是否超出了自己的容忍度。
人人簡歷網
