自從我獲得CS學位并開始我作為軟件開發人員的職業生涯以來已經差不多四年了。 在這篇文章中，我想分享我在此過程中學到的一些經驗教訓。
目錄
-永遠不要假設
-非技術問題是最困難的
-首先考慮，稍后編碼
-你創建的內容比創建它的工具更重要
-每個角色都同樣重要
-結論
永遠不要假設
在開始我的第一份工作后，我的第一個項目是一個長期項目的短期任務。 該項目見過許多沖刺和許多開發人員。 代碼庫龐大，復雜，并且與外部服務有許多集成。
我的第一個任務是修復一些間歇性失敗的單元測試。 正在測試的代碼相對較舊，由高級開發人員編寫。 由于功能從UI工作得很好并且經過QA徹底測試，我假設問題必須與測試本身一致。
我花了近三天時間試圖修復未破壞的測試。 當我向我的團隊負責人解釋為什么修復工作花了這么長時間時，他教我第一堂課。 他告訴我永遠不要認為別人的代碼是正確的，因為它看起來像它。
這可能是我學到的最重要的一課，可以應用于很多情況，而不僅僅是涉及代碼。 以下是一些：
1永遠不要以為某人會因為你的要求而做某事。始終得到明確的協議。還沒有收到你要求檢查某人的回復？發送跟進。如果有重要的事情，重要的是跟進。
2永遠不要假設有人理解你告訴他們的內容，即使他們說他們這樣做了。這是我在職業生涯中取得的成就之后學到的，我幫助指導了更多的初級開發人員。我發現我會通過指令進行步槍攻擊，并在第二天跟進，發現有問題的開發人員雖然說他們完全理解了所需要的內容但沒有取得多大進展。相反，讓這個人給你一個關于討論內容的演練，這樣你就可以確定他們理解了。這不僅適用于指導開發人員，例如向BA / QA等解釋某些內容。
3永遠不要認為對方是錯的。我認為開發人員傾向于責怪其他人，因為他們的代碼不起作用。你對你編寫的代碼保護起來，直到你確信它不會出錯。如果QA告訴你他們遇到了問題，他們有理由這樣做。給他們帶來懷疑的好處不會花費太多，而且他們會比關閉更能體會到它。
非技術問題是最困難的
在大學里，所有的問題都是技術問題。 弄清楚如何使一段代碼工作幾乎總是手頭的問題。 然而，在職業生涯中，我發現這種情況很少發生。
確保在跨多個時區的大型團隊中進行溝通。 確保流程有效，并且清楚地記錄在案。 弄清楚如何幫助船上或指導新的團隊成員。 試圖在開發過程中順利引入新的東西。 當數字在當前推動他們的議程時，說服項目管理專注于長期代碼健康。
這些只是一些示例，顯示了你可以在項目中遇到的各種事情。 在我看來，它們比追蹤那些困擾你的空指針要難得多。
首先考慮，稍后編碼
你發現了一個可以改進的流程。 你立即決定自動化它。 你花費每個空閑時間開發一些會徹底改變團隊工作方式的東西。
聽起來很熟悉吧？ 包括我在內的開發人員喜歡自動化解決方案。
我學到了什么？ 不要馬上去找代碼。 停下來，思考問題，而不是解決方案。 與一系列人交談，而不僅僅是開發人員。 首先確定問題是技術問題還是流程問題。 然后你可以找出解決方案。
當然，使用Docker和好編寫的腳本提出一些復雜的解決方案會很酷，你可能會學到很多東西，但從長遠來看，為非技術問題提出技術解決方案可能無助于團隊。 它可能只是掩蓋了更大的問題。
你創建的內容比創建它的工具更重要
當我畢業時，我喜歡編寫代碼，學習新的語言和框架，以及任何涉及技術元素的東西。
不要誤會我的意思，我仍然這樣做。 但是，我已經意識到，只要我們用作開發人員的工具使我們能夠完成工作，那么這些工具是什么并不重要。 在前端開發中，每隔一天就有一個新的框架。 盡管作為開發人員保持活躍是最重要的，但最終用戶（重要人物）并不關心某些事情是如何發揮作用的。
每個角色都同樣重要
我已經提到了不自動假設每個不是開發人員的人都錯了的重要性。 除此之外，我了解到組成團隊的每個成員（BA，QA，項目經理，其他利益相關者等）與任何開發人員一樣重要。
如果沒有來自每個角色的表示，項目就不起作用，并且如果不在不同資源類型之間平均分配資源，則同樣不起作用。
我了解到，即使是編寫實際代碼的開發人員，也沒有沒有利益相關者的代碼，如果沒有質量保證他們的立場，就沒有利益相關者。
結論
我希望你能從這些課程中學到一些東西。 如果你有一些你已經學過的課程，你想分享，我很樂意在答復中聽到它們。

新聞名稱：作為四年的軟件開發人員，五個重要經驗教訓
新聞來源：http://m.newbst.com/news8/114608.html

網站建設、網絡推廣公司-創新互聯，是專注品牌與效果的網站制作，網絡營銷seo公司；服務項目有軟件開發等

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯