[譯] 做爲初級開發人員，我學會放下的 7 項真理

• 原文地址：7 absolute truths I unlearned as junior developer
• 原文做者：Monica Lent
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：cyz980908
• 校對者：Ultrasteve, portandbridge

做爲初級開發人員，我學會放下的 7 項真理

明年就是我正式受僱以編程爲業的第 10 個年頭了。十年了！除了實際工做以外，在我生命的近三分之二的時間裏，我一直在開發網站相關的東西。我幾乎不記清在個人生活中什麼時候我不知道 HTML，這樣的確想是有點奇怪。有些孩子學習演奏樂器或跳芭蕾，而我卻在我童年的臥室裏用代碼創造了一個神奇的世界。

這是我往終端裏打打奇怪文字就能按期伸手拿錢的頭一個十年；回想這段時光，我打算花些時間和各位分享下做爲開發者，在此間個人一些想法的轉變。

對如今的初級開發人員來講：也許你會在這裏找到一些你如今相信的東西，並從中獲得啓發，去了解更多關於它的知識，以及爲何這個話題如此多元化。 或許你會發現這篇文章很鼓舞人心，由於你已經遠遠超過了我在你這個階段的水平。

對如今的高級開發人員來講：也許你能夠講述一些有趣（或不起眼）的故事來分享你在初級開發人員的人生經歷。

我澄清一下，我認爲初級開發人員是很棒的，由於僅僅是學習就須要很大的勇氣。而這篇文章是關於我本身的經歷和學習，並非要歸納全部初級開發者的想法或行爲。

我但願你喜歡這篇文章而且能夠產生一些共鳴。😄

感謝 Artem 和 Sara 對這篇文章的反饋！

做爲初級開發人員，我學會放下的真理

1. 我是一個高級開發人員

當我申請第一份技術工做時，我才 19 歲。我申請的職位是「學生網站管理員」。這是一個很是棒的職位，由於你能夠同時被視爲學生和大師（英文裏學生網站管理員這個單詞能夠拆成學生和大師，這裏是做者的冷笑話）。如今每一個人都想成爲一名工程師，由於工程師聽起來更高級，但若是你問我，「大師」是作什麼的。這麼說吧，個人工做是編寫 PHP 和 MySQL，維護咱們的 Drupal 網站以及構建一些內部工具。

由於我在臥室裏編碼已經有幾年了，因此我十分確定我是有「多年的開發經驗」的。因此當我被問及我有多少寫 PHP 的經驗時，我自信地回答，「3 或 4 年！」。

我覺得我對 SQL 瞭解不少，由於我能夠作外鏈接。 😎

當我谷歌搜索它時，3-4 年的經驗意味着我應該可以賺錢。 💰

快進到我最近的工做，這是我在 5 年的學生和工做經驗「結合」後獲得的工做（我認爲這和正常的工做經歷是同樣的）。 然而在那個時候，我基本上歷來沒有審查過個人代碼。 我經過 ssh 部署到服務器並運行 git pull 指令。我很肯定我歷來沒有打開過 Pull Request。別誤會，我在前兩份工做中學到了不少很棒的東西,可是我歷來沒有真正和同一個代碼庫中的其餘開發人員一塊兒工做過。可是, 我申請了一個「高級前端工程師」的職位，獲得了一份工做，並接受了。

在那裏，我是一位成熟的 24 歲高級開發人員。

個人意思是，要不是我有豐富的經驗，他們怎麼會給我這個職銜呢，對吧？固然，是我使人印象深入的經歷讓我走到了這一步，人們應該聽個人！我已是處在技術生涯的巔峯，我也是辦公室裏最年輕的開發者。

像老大同樣。 💅

我最終學到的

並不是全部的經驗生來平等。 我在臥室編碼、學生時代的工做、計算機科學研究領域的工做以及在一家成長中的初創企業工做的經歷都是頗有價值的經歷。但它們並不都同樣。在你職業生涯的初期，你在支援到位的團隊工做一年所能學到的東西，要比你一我的（或是隻有少許反饋的狀況下）編程五年多十倍。若是你的代碼從未被其餘開發人員審查過，你將沒法以最快的速度學習 —— 這是一個巨大的因素。

這就是爲何導師如此重要。 和你一塊兒工做的團隊比你薪水中的幾塊錢更有價值。若是你能控制住本身的話，不要接受你將獨自工做的初級職位！不要僅僅由於薪水就接受你的第一個角色（或者老實說，任何角色）。團隊纔是真正的價值所在。

我還了解到職位頭銜不會給你「帶來」任何東西。 這有點像，5 人團隊的首席技術官不一樣於 50 人或 500 人團隊的首席技術官。即便頭銜相同，所需的工做和技能徹底不一樣。因此，僅僅由於我有一個「高級」職位頭銜，也不能讓我成爲一名高級工程師。此外，等級頭銜自己就有缺陷，很難跨公司比較。我認識到不要盯着職位頭銜，或者說很重要的的是把它們做爲一種外部驗證的形式是。

2. 每一個人都寫測試

在我職業生涯的前半段，我從事研究工做。具體來講，我在一個公共資助的項目上工做了大約 3 年半，而後在一所大學擔任 NLP 主席一年半。我能夠告訴你的是：學術研究中的編程與作工程和業務中的編程是徹底不一樣。

大多數狀況下，你不是在構建應用程序。你是在研究算法或解析數據集。或者，若是你正在構建一個應用程序，那麼你的工做極可能是由公共資助的，這意味着其餘人能夠無償使用，並且一般是開源的。某樣東西是免費的話，這意味着，在很大程度上，你沒有責任確保它老是徹底可用。

由於，嗯，這是免費的。

你也沒有責任賺錢或產生結果，但這是一個徹底不一樣內容的博客文章，講述的是如何成爲學術界的一名開發人員。 ✨

長話短說，我帶着不少指望離開了學術界.

而那都是些有關業界運做的想法。我以爲該有自動部署、拉請求和代碼審查。這些都是極好的！終於實現了我求之不得的 代碼質量！但我堅信，除了使用適當的標準和最佳實踐編寫高質量代碼以外，軟件行業的每一個人都要寫測試。

呃哼。

因此想象一下，當我在一家初創公司上班的第一天，卻發現沒有任何測試時，我有多麼的驚訝。前端沒有測試。後端沒有測試。總之就是不作測試。

沒！有！測！試！

這裏不只沒有測試，並且彷佛沒有人認爲缺少測試有問題！我有點天真地猜測，不作測試，是由於你們人們不知道如何爲 AngularJS 編寫測試。若是我教他們怎麼作，一切都會好的，咱們會開始測試。錯了！長話短說，多年之後，咱們會在向代碼中添加自動化測試方面取得巨大的進步，但這並不像我想象的那樣簡單。

但這並非由於人們不知道如何編寫測試。

他們要麼從未感覺過沒有測試的痛苦，要麼感覺過有過期測試的痛苦。雖然兩件事我也從未親身經歷過。

我最終學到的

大量的公司和創業公司不多或根本沒有測試。 在努力尋找適合產品市場的產品或者在爲生存而戰時，不少公司都忽略了早期的測試。即便是那些看起來很複雜、有贊助會議或開源代碼的公司，它們中的不少仍然是一個龐大的、粗糙的、有着不多的測試的總體，它們須要你的幫助來改進。詢問那些不打算招募你的開發人員，讓他們告訴你代碼庫的狀態。

沒有一家公司有完美的技術設置。 每一個公司都有問題，每一個公司都有技術債務。問題是他們在作什麼。咱們求職時不該該有不切實際的想法，以爲是有工做要作的 —— 不然他們不會僱傭你 😉

對你缺少現實生活經驗的話題過於執拗己見是至關傲慢的。 我給人的印象是這樣一個無所不知的人，堅持認爲必定有測試，但幾乎沒有任何實際經驗。不要像我同樣。有原則很重要，但也要開放，真正有興趣理解他人的經歷和觀點。

3. 咱們遠遠落後於其餘人（也就是「技術錯失恐懼症」）

這個與單元測試的主題密切相關。儘管個人公司沒有不少單元測試，但其餘公司確定都作了，對吧？

我讀了不少博客帖子。我在 YouTube 上觀看了一些會議討論。我一直在關注「橙色網站」。好像每一個人寫的程序都功能精妙、質量一流、性能出色，並且動畫精美，而我只是在這裏修補一些東西，試圖讓它在個人最後期限以前及時工做。

我幾乎崇拜我正在關注的全部其餘公司，而且對我本身的公司和項目如此落後感到失望。

我最終學到的

許多會議討論的是概念的證實，而不是現實世界的場景。 僅僅由於你看到一個關於特定技術的會議，這並不意味着公司在平常工做中使用了該技術，或者他們全部的代碼都處於完美狀態。一般，作會議演講的人展現的是玩具應用程序，而不是真實的案例研究，區分這二者很重要。

處理遺留問題是徹底正常的。 可是說真的， 咱們很容易會以爲有的公司沒有遺留問題要處理。但在花時間參加會議，與頂尖科技公司的工做人員交談以後，我發現，咱們都是同病相憐。哪一個公司沒有他們試圖徹底把控（或在某個時候不得不徹底把控）的龐雜的（堆積如山的）麻煩代碼？有遺留的代碼是正常的，學習如何處理遺留代碼經常比從頭構建應用程序教會你更多的東西，由於你將更多地接觸到你還不理解的概念。

4. 代碼質量最重要

早些時候，代碼審查這事，我作起來是能夠很不留情的。

至少，我對編碼風格很是挑剔。個人編碼風格，剛好是 Airbnb JavaScript 風格指南的修改版本，但符合我我的的品味。當時我最不想看到的，就是別人的編碼風格和我不同，好比縮進、格式化、命名。要是想在我不留一條註釋的狀況下經過我負責的代碼審查，不只要用上讀心術，還要有中彩票的運氣。

想象一下在你 PR 下的 50 多條關於全部遺漏的分號評論！

由於個人眼睛像老鷹，這隻老鷹想要那些高質量的分號。 🦅

（幸運的是，在盯着電腦看了不少年後，我再也不有鷹眼了，因此大家都倖免於難 —— #開玩笑）

我最終學到的

足夠好就是足夠好。 當談到代碼須要有多「好」時，收益會有必定程度的減小。代碼不須要寫得很是細緻完美，也能夠作到既完成工做任務，又不會在維護的時候出現大麻煩。一般，有些重複或冗長的代碼更容易被其餘人理解。另外，「好代碼」不一樣於「看起來是我寫的代碼」。

架構比吹毛求疵更重要。 雖然能夠改進一小段代碼，但日後引起更大問題的，一般是體系層面的東西。我應該更關注應用程序的結構，而不是早期的一小段代碼。

代碼質量很重要。 別誤會我。可是代碼質量並非我想象的那樣，好比語言分析和格式化，或者在我最近讀到的博客文章中提倡的任何風格。 🙈

5. 一切都必須記錄在案！

當我進入個人第一家公司，老實說，這是我第一次大量使用別人寫的代碼。固然，在個人第一份工做中，我已經作了一點，可是我歷來沒有真正進入一個現有的代碼庫，並弄清楚到底發生了什麼。由於那一次遇到這種問題的時候，我重寫了全部代碼，而不是試圖弄清楚它是如何工做的。

無論怎樣。

這都無濟於事，由於它是由 Ruby 開發人員編寫的 AngularJS 代碼，或者說我是一個不知道本身仍是個萌新的萌新開發者。 🕵🏻‍♀️

那麼，我如何處理這 300 行讓我感受本身快要淹死的不熟悉的代碼的呢？

JSDoc。無處不在。

我開始註釋一切只是爲了試圖理解它。對我能夠接觸到的全部函數做註釋。

我學習了全部那些奇特的專用於 Angular 的 JSDoc 語法。因而個人代碼老是通常的代碼兩倍長，由於裏面有許多註解和註釋。 👌

我最終學到的

文件有時是謊話。 咱們很容易認爲文檔是萬靈藥。「咱們須要文檔！」 我雖然沒有得出結論，認爲「僅僅由於文檔工做很辛苦，並不意味着它不值得作」，但也明白到，你必須用正確的方式記錄正確的事情。過多地記錄錯誤的事情每每會致使停滯不前，這對於那些試圖解決問題的人來講一樣使人困惑。

在適當的時候更關注自動化而不是文檔。 測試或其餘形式的自動化不太可能不一樣步。所以，我嘗試將重點放在用清晰的語言編寫好的測試上，這樣開發人員在編寫代碼時就可以看到項目如何使用工做代碼工做。另外一個例子是用一些註釋自動安裝應用程序，而不是一個冗長而詳細的安裝指南。

6. 技術債務是壞的

若是你看完剛纔那點就以爲我很神經質的話，別急，這點我還沒說呢！在我職業生涯的一段時間裏，我認爲任何我認爲「混亂」的代碼實際上都是技術債務。技術債務是一個有趣的術語，由於若是你讓人們給你舉一個例子來講明它是什麼，可能會獲得許多不一樣的解釋。

所以，做爲一個把任何一種雜亂的代碼都視爲技術債務的人，我當即試圖以最嚴格的方式消除它！

絕不誇張地說，我曾經花了一個週末手工修復了 800 個語言分析錯誤。

這就是我有多神經質。

（免責聲明：這是在自動修復成爲一件事以前）

我最終學到的

雜亂無章的代碼並不等同於技術債。 僅僅由於感受很差並不意味着這是技術債。技術債實際上在某種程度上減緩了你的速度，或者使某些變化變得困難或者容易出錯。若是代碼僅僅是有點亂，那就有點亂吧。整理它可能不值得我花時間。

持有一些技術債是健康的。 有時候咱們走捷徑是由於咱們須要借時間，爲此，咱們放棄了將來的速度。擁有一些真正的「技術債」的代碼是能夠的，只要你意識到你可能須要償還這些債。若是你認爲你的代碼庫沒有技術債務，那麼你極可能過度強調完美而不是交付。嗚嗚嗚，說的就是我！

7. 資歷高意味着最擅長編程

我從很小就開始編碼，大概已經精通 for 循環 15 年多了。編程自己對我來講就像呼吸同樣。當一個解決方案顯而易見時，我能夠直接輸入，而後代碼就會隨之而來。這就像寫博客或電子郵件同樣。我能夠比其餘人更快地編寫解決方案，而且一般本身承擔更復雜的項目。

很長一段時間，我覺得成爲高級開發人員就是這麼一回事。

難道不是嗎？職位名稱是高級開發人員，而不是「高級溝通者」或「高級項目經理」。我是真的搞不懂，要成爲一名真正的資深開發者，還得學些什麼其餘技能。

我最終學到的

除了編程，高級工程師還必須發展許多技能。 與我所擁有的技能相比，我必須培養的技能數量簡直是天文數字。從溝通和依賴管理到共享上下文、項目管理、評估，以及與非開發人員的成功協做。這些技能很難量化，須要大量的嘗試和錯誤來糾正。

不是每一個人都會在職業生涯中成爲「高級」。 資歷高是多年積累經驗的結果。然而，多年的經驗是資歷高的必要條件，但不是充分條件。它還必須是一種正確的經驗，在這種經驗中，你內化了正確的教訓，併成功地將這些學習到的應用到將來。有時候，更大的教訓可能須要一年或更長時間才能徹底被發現 —— 這就是爲何多年的經驗仍然重要，即便你是一個很是好的程序員。

在某些領域，咱們都還年輕。 不管你有多少經驗，仍然有你知道的很少的地方。認可你所不知道的是填補這個空白並從更有經驗的人那裏得到幫助的第一步。

---

意外收穫 — 我真的很喜歡這篇文章 關於成爲一名高級工程師 。 若是你正在努力解決你職業生涯中的什麼問題，而且發現本身在想「高級意味着什麼？」，這將是一本很棒的讀物。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。