Java 開發人員在項目中的典型任務

Java 開發人員的典型職責是什麼？畢竟，您需要了解自己正在從事什麼以及最終會做什麼，對嗎？今天我想談談 Java 開發人員執行的十項重要任務。 但首先，讓我們熟悉一個名為 Jira 的工具。或者刷新您對它的記憶，如果您已經熟悉它的話。 吉拉是一種組織人際互動的工具，儘管在某些情況下它也用於項目管理。換句話說，一個項目被分解成這個工具中描述的小任務。這些任務分配給負責實施的開發人員。例如，任務可以是添加一些功能。在執行任務時，開發人員和其他專家會添加關於誰做了什麼以及他們花費了多少時間的評論。這樣做是為了時間跟踪目的——了解在哪些任務上花費了多少時間。理想情況下，每天完成一次：在晚上離開辦公桌之前，指出您在 8 個工作小時中花費了多少時間在各種任務上。Jira 的功能比上面描述的要多得多，但這足以初步了解。

1. 設計新的解決方案

在創建和實施某些東西之前，您需要將其概念化，對嗎？正如我之前所說，這可能只是 Jira 中分配給您的一項任務，因此您要努力設計一個新的解決方案，在 Jira 中記錄您花費了多少時間以及在哪些方面。這項工作也可以在團隊電話會議的討論中進行：每個人都可以發表意見並提出他們認為最好的方法。在這裡我想指出幾點。首先，軟件開發是一個非常有創造力的職業，因為你需要使用標準工具來想出解決問題的新方法。一項任務往往可以有許多不同的解決方案。因此，一切都取決於開發人員的創造力，這在很大程度上受到他們積累的知識和經驗的影響。你可以在這裡展示你所有的創造力和天才，但重要的是不要過度。如果這樣做，代碼將變得過於復雜且難以閱讀。結果，在你離開之後，沒有人會完全理解你編碼的內容以及它是如何工作的。他們將不得不從頭開始重寫所有內容。他們可能會想起你。不止一次。而且不太可能會說出溫暖、友善的話。你需要那個嗎？其次，開發人員必須保持心理靈活性，即您不應該堅持單一的解決方案並對其他解決方案變得封閉。好像你只能用一種方式做某事，沒有其他選擇。你可能會因為各種原因掉入這個陷阱。例如，假設你想證明你的觀點是正確的。或者您可能已經設計並實施了自己熟悉的解決方案——當然，你不想承認它不是最好的。這些情況會讓你相當失明。事實上，你需要能夠承認自己的錯誤並始終保持開放的心態，即使你不得不刪除你引以為豪並且已經編碼了一個多星期的功能。我記得一位同事如何通過在 Jira 中留下這條時間跟踪評論來讓每個人的一天都變得愉快： “我去除了死產的特徵。並哀悼。”

2.編寫新功能

這一步——實現新功能——在邏輯上跟在前一步之後。項目中涉及的所有工作都在 Jira 中劃分為任務，然後根據開發人員的工作量將其分配給開發人員。此過程有不同的方法，稱為“方法論”，您可以在CodeGym 上的這篇文章中閱讀更多詳細信息。通常，任務有一個估計，這是完成它們所需的預測時間。它可以由您（開發人員）在收到任務時設置，也可以由團隊負責人設置，也可以在計劃期間由開發團隊共同設置。這次猜測很少準確，因為影響軟件開發的因素太多了。例如，程序員對相關技術的熟悉程度、不熟悉程度、整體經驗、各種不可預見的陷阱等。這些只是一般估計。也就是說，並非所有項目都需要時間估算。就我個人而言，我發現沒有它生活得更輕鬆，尤其是當 PM 沒有每天多次問我“你的時間估計在哪裡？”的問題時。所以，你接到一個任務，Ready for review ” 在 Jira 中，並祈禱您的代碼更改不會連同評論一起返回進行修訂。

3. 編寫測試

審閱者，即檢查您代碼的人，喜歡您實現的功能，但她有一個問題要問您：相關測試在哪裡？所以她把任務發回給你修改。測試是任何 Java 應用程序的重要組成部分。通過運行測試，您可以立即識別應用程序無法正常工作的地方。例如，開發人員在系統的一部分進行了一些更改，導致另一部分的行為發生了變化，但他在編碼時沒有註意到這一點。通過運行測試，他將能夠看到某些測試失敗了，這意味著它們沒有產生預期的結果。這告訴他系統中的其他地方出現了問題。知道這一點後，他不會將重大更改提交給服務器，而是繼續調試他的代碼。是的，很少有開發人員喜歡編寫測試，但不可否認它們給軟件開髮帶來的好處。客戶自己通常會指明他們想要保持的測試覆蓋率水平（例如，80%）。這意味著你需要知道各種類型的測試，並能夠編寫它們。Java 開發人員主要編寫單元測試和集成測試，而更廣泛的（端到端）測試由 QA 和測試自動化專家處理。

4. 查找和修復錯誤

對於 Java 開發人員來說，這也是一項非常常見、頻繁的任務。QA 和測試自動化專家的主要工作是捕捉錯誤。換句話說，他們尋找程序行為不正確的地方，然後他們在 Jira 中創建任務並將它們分配給某人。例如，對於團隊負責人，團隊負責人又決定將他們分配給哪些開發人員，具體取決於他們的工作量和對系統相關部分的熟悉程度。之後，指定的開發人員會在調試器中花費數小時來尋找錯誤的根本原因，使用 QA 專家提供的錯誤描述來重現錯誤發生的情況。一旦開發人員發現錯誤並修復它，他就會將修復程序發送給審查。有時開發人員無法重現錯誤，因此他將任務連同解釋性評論一起發回給 QA 專家。查找和修復錯誤似乎不會花很長時間，但還是有一些細微差別。這一切主要取決於開發人員對這部分代碼的熟悉程度，以及他的經驗和理論知識。有時一個bug可以在20分鐘內找到並修復，有時則需要三天時間。這意味著此類任務特別難以提前估計，除非開發人員在閱讀描述後立即了解錯誤的內容、位置和方式。在這種情況下，

5.代碼審查

如上所述，一旦完成任務，就應該將其送審。如果通過審核，則進入主分支。如果沒有，它將連同需要解決的評論一起返回給開發人員。當然，你明白你的代碼都是由其他開發人員檢查的，而不是由一些高權力者檢查的。也就是說，並不是每個人都可以執行代碼審查——只有經過現實世界實踐磨練的最有經驗的開發人員才能分辨好代碼和壞代碼之間的區別。代碼審查通常使用輔助工具（例如Crucible ）執行. 審閱者檢查代碼，並在必要時對某些行留下評論。可以有各種評論。例如，有些是關鍵的。如果它們沒有得到解決，那麼審閱者將不允許提交代碼。例如，其他評論只是對所選方法的簡單評論。開發人員可以聽取、注意或忽略這些內容。團隊可以創建自己的代碼審查規則和程序，就哪些值得關注、哪些不值得關注、完成代碼審查應分配的時間範圍等達成一致。僅憑經驗不足以進行審查：您仍然需要大大提高您的技術技能並閱讀各種書籍（例如，“Clean Code”）。

6.代碼分析

由於多個想法不同的人同時為項目編寫代碼，因此他們的代碼和方法會有所不同。隨著時間的推移，一切都逐漸變得一團糟。為了改進代碼，有時會創建任務來分析某個模塊或整個應用程序，發現並記錄缺點，然後根據此分析創建重構任務。在開發開始時，團隊看不到一些更簡單、更簡潔的解決方案但他們現在看到了的情況下，此類分析也有幫助。例如，邏輯經常在某些方法中重複。因此，它可以被提取到一個單獨的方法中，然後可以多次重複使用。或者一個類可能變得過於臃腫，或者一些代碼變得難以維護或過時，或者...... 分析任務有助於提高代碼和應用程序的質量。也就是說，對我來說，分析大量代碼可能很無聊。

7.重構代碼

代碼分析的下一部分是重構。代碼可能已經過時、過時、寫得不好、難以閱讀等等。您應該始終力求完美（儘管它不存在）和最新的代碼，刪除任何多餘的東西，因為多餘的東西只會導致混亂並干擾查看代碼功能的能力。不用說，您不太可能在項目開始時看到這些任務：您會在開發的後期階段遇到它們，當應用程序被打磨和完善時。在這裡，與同事商量他們會做什麼以及他們看到的陷阱可能是合適的。從本質上講，這些任務類似於開發新功能。例如，假設您收到一項任務，要在不更改其行為的情況下編輯某些功能。為此，您刪除舊代碼，編寫自己的代碼並檢查測試。如果您做的一切都正確，那麼在不對測試進行任何更改的情況下，它們應該都像以前一樣通過。在代碼中的所有內容都符合預期後，我們將其送去審核，然後去喝杯咖啡 :)

8. 編寫文檔

想像一下，您是某個長期軟件開發項目的新開發人員。您需要熟悉代碼庫或執行某些特定任務，例如診斷錯誤。您將如何瀏覽該項目？每五分鐘糾纏你的隊友？如果他們很忙或者是周末怎麼辦？這正是我們擁有文檔的原因 — 以便不熟悉代碼的人可以進來，找到相關頁面，并快速弄清楚應用程序中她感興趣的部分發生了什麼。但是必須有人創建文檔，哈哈。如果一個項目有開發人員必須支持的文檔，那麼當他們實現新功能時，他們會描述它並更新文檔以及任何代碼更改或重構。您還可以僱用一名單獨的員工（技術作家）來編寫、維護和監督文檔。如果有這樣的專家，普通開發人員的生活就會輕鬆一些。

9、各種會議

開發人員的大量時間花在了各種會議、談判和計劃上。最簡單的例子就是每日站會，你需要匯報昨天做了什麼，今天要做什麼。此外，您需要與測試人員進行一對一的電話通話，以便他們可以演示/解釋重現錯誤的細微差別，或者與業務分析師討論微妙之處和要求，或者討論組織問題與下午。這意味著儘管開發人員可能是一個喜歡獨處的內向者，但她仍然需要能夠找到與其他人的共同點（嗯，至少是一點點）。 開發人員的級別越高，她需要花在溝通上的時間就越多，寫代碼的時間就越少。開發負責人可以將一半甚至更多的工作時間花在單獨的對話和會議上，並且編寫代碼的頻率可能會降低（可能會導致他失去一點編碼能力）。但如果你只是喜歡說話，你可以作為一個團隊領導，過渡到管理，完全忘記編寫代碼，而是整天與各種團隊、客戶和其他經理溝通。

10. 進行/通過面試

如果你在外包或外包公司工作，你將經常需要通過外部面試，在那裡你需要將自己“推銷”給客戶（你可能會被為客戶工作的人面試），以及內部面試那些在公司內部晉升的人。我會稱這是一個很好的成長機會，因為頻繁的面試會迫使你保持知識的敏銳：你不會生鏽和軟弱。畢竟IT軟了，完全可以掉出這個領域。當您成為更有經驗的開發人員時，您將能夠發現自己在桌子的另一邊，進行面試而不是通過面試。相信我，當你從這個角度看時，你會非常驚訝，因為問面試問題比回答問題更可怕。您需要有自己的面試策略、問題列表以及在一小時內針對所有必要主題提出問題的時間。之後，您有責任提供反饋，這將影響招聘決定以及候選人是否會收到期待已久的工作機會或晉升。或者，您可能會允許一個明顯較弱的候選人獲得她不合格的職位，然後您可能會被問到，“您怎麼能允許她以這種知識水平被錄用”？所以，當你在面試中處於困境時，請記住，你面前的人也面臨著挑戰​​，並且可能會感到壓力很大。您有責任提供反饋，這將影響招聘決定以及候選人是否收到期待已久的聘用或晉升。或者，您可能會允許一個明顯較弱的候選人獲得她不合格的職位，然後您可能會被問到，“您怎麼能允許她以這種知識水平被錄用”？所以，當你在面試中處於困境時，請記住，你面前的人也面臨著挑戰​​，並且可能會感到壓力很大。您有責任提供反饋，這將影響招聘決定以及候選人是否會收到期待已久的聘用或晉升。或者，您可能會允許一個明顯較弱的候選人獲得她不合格的職位，然後您可能會被問到，“您怎麼能允許她以這種知識水平被錄用”？所以，當你在面試中處於困境時，請記住，你面前的人也面臨著挑戰​​，並且可能會感到壓力很大。 任何面試對候選人和麵試官來說都是有壓力的。 我們可能會在這裡結束。感謝所有閱讀這篇文章的人。留下一個贊並繼續學習 Java :)