一份軟體工程行業生存指南

mindwind發表於2019-02-28

如今越來越多的人進入軟體工程行業,偶遇一份國外同學寫的行業生存指南,讀來感覺頗值得參考,簡單翻譯過來,分享一下。也許生存指南能更好得讓你在這個行業生存下來,並快速獲得成長與發展。


我遭遇了作為一名軟體工程師的現實:我必須去掌握當時還不知道,但我將會需要的許多技能。回首過往,如果早知道我現在知道的這些事情,肯定要好很多。

因此,我寫了篇指南,它源自早年我作為專業人士去輔導程式設計師的經驗,以及我本人和我一些同事的經驗來幫助其他人。

包括以下內容:

  1. 如何充分利用好面試;
  2. 如何在軟體工程師的工作中存活下來並茁壯成長;
  3. 以及在考慮持續改進時需要哪些資源。

1. 面試

當你開始你的軟體工程職業生涯時,你將不得不面對一個不爭的事實。面試糟透了。

對每一個牽涉其中的人來說都是可怕的。作為一名面試官和一名應聘者,我可以證明面試是一個很大的時間無底洞,它包含極度的壓力,並且是一個非常糟糕的未來工作表現的指標。然而,它們是必要的邪惡,以至於你和你的簡歷都最好為此做好準備。

1.1 準備戰鬥

如果你正在考慮從事軟體工程,一定要學習一些最常見的程式設計面試問題,比如 “FizzBuzz”:

編寫一個將數字從 1 列印到 100 的程式。對於 3 的倍數就列印 ‘Fizz’ 而不是數字,對於 5 的倍數 就列印 ‘Buzz’。對於既是 3 又是 5 的倍數,就列印 ‘FizzBuzz’。

聽起來足夠簡單,對吧?

好吧,絕大多數應聘者都沒有通過這個簡單的測試,更不用說其更復雜的變體了。

我個人見過許多高階職位的候選人在可以完全上網的情況下都沒能通過這道測試。因此,如果你在簡歷中列出了一種程式語言,那麼你至少要知道如何使用它編寫 'FizzBuzz' 程式。否則,你就是在浪費所有人的時間,包括你的時間。

當然,你需要知道的應不止於 'FizzBuzz',才能在面試中倖存下來。你還需要確保你知道:

  • 基本資料結構和演算法:例如連結串列、陣列、樹和排序;
  • 你選擇的語言中,公共的 “常識” 問題”:例如字串是否可變,記憶體是如何管理的;
  • 物件導向的程式設計概念,比如類和物件,以及繼承。

在你的職業生涯之初,你將需要在這些問題上表現出色,大放異彩,因為你還沒有足夠的經驗來證明你會很勝任這份工作。

1.2 給自己額外的優勢

有幾件事你可以做,這會給你一些額外的東西。

首先,學會交流你的經歷。你應該有一個 “電梯演講”(在乘坐電梯的短時間內的推薦演講)來把你的簡歷總結成一個連貫且吸引人的敘述。

另外,瞭解你自己的簡歷!這聽起來很傻,但我看到很多應聘者在艱難解釋簡歷上的某一特定專案。你應該能夠回答你在簡歷上列出的任何經歷相關的問題,並解釋它如何使你成為更好的候選人。

接下來,在 GitHub (或其他公共程式碼庫)上擁有程式碼示例。

眼見為實,面試官能夠看到你的程式碼可是會產生奇蹟的。此外,它還展示了你對程式碼版本控制系統的理解。

程式碼示例不必太複雜,但它們確實需要乾淨,並展示良好的編碼實踐。這是你的機會,在一個沒有時間壓力的編碼面試中展示你會如何編碼。

完成上述所有工作之後,就應該考慮參加一個開源專案了。顯示你可以在現有的程式碼庫中工作,並與其他程式設計師協作。

這將是你身處工業程式設計環境之外,最接近工業程式設計環境的方法了。這也是迄今為止最困難和耗時的方法,所以先把它留到最後,直到你把前面那些 “低垂的果實” 都摘了。

1.3 面試你的面試官

在求職的匆忙和壓力下,許多應聘者忘記了面試是雙向的。當公司試圖發現你是否適合這份工作的時候,你也應該弄清楚公司是否適合你。

確保你可以問下面的一些問題,即使是在後續的電子郵件中。

下面是一些你可以問的問題:

問題 #1
“對於我來說,一個典型的工作日會是什麼樣子?”

重要的是要明確對某個特定職位的期望,因為軟體工程的不同崗位差異很大。例如,你可能需要維護伺服器或與客戶直接交談。

紅燈警示:“我不確定。” → 這裡的意思是面試你的人不是招聘你的團隊中的人,或者他們還沒有一個清晰的認識為什麼要僱用你。

問題 #2
“你們是如何測試軟體的?”

理想情況下,應該使用單元測試、手動測試和自動化測試的組合來驗證程式碼的質量。

紅燈警示:“我們通常不寫 bug,哈哈。” → 這樣說的傢伙正是寫 bug 的人。

問題 #3
“你們使用什麼版本控制系統?”

版本控制系統對於協作非常有用,沒有任何理由在專業環境中不使用版本控制系統。

紅燈警示 #1:“啊,版本控制系統?” → (若他們不知道)趕快逃跑,跑得遠遠的。

紅燈警示 #2:一些模糊或自定義的 VCS 系統 → 表明他們很可能跟不上時代,很長時間沒有更新他們的基礎設施了。

問題 #4
“你們是否進行同行評審?”

同行評審,或讓其他人在你提交到程式碼庫前檢視你的程式碼,是發現愚蠢錯誤的極好方法,也是開始職業生涯時的一個重要的培訓機會。

紅燈警示:“我們相互信任!” → 這種情況很可能是高階開發人員對他們的程式碼具有自利的保護性,而不是很樂意收到反饋。

問題 #5
“你們有什麼繼續教育的計劃?”

作為一名軟體工程師意味著不斷地學習,因為技術以眼花繚亂的速度出現、成熟和過時。因此,許多公司都有一個培訓預算,用於支付大學和線上課程、專業會議或內部講座的費用。

紅燈警示:“你是說在空閒時間上網閱讀東西嗎?” → 這暗示公司要麼現金緊缺,要麼認為開發者是可替代的,而不會長期投資。

問題 #6
“你們使用的軟體開發流程是什麼?”

無論實際細節如何,流程對於軟體工程都是至關重要的。關於什麼是最優流程的具體問題,需要進行激烈的辯論,但只要有一種商定的專案工作方式存在,就會盡量減少混亂,並確保大家達成共識,保持一致。

紅燈警示:“我們的過程是受自由形式的爵士樂啟發。” → 表明很可能整個部門都處於消防模式,從緊急情況跳到緊急情況,缺乏任何明確的目標。

問題 #7
“你們如何處理技術債?”

技術債是程式碼庫中的一種過時技術和快但髒的解決方案的累積。解決這個問題對於程式碼的長期健康是很重要的,並且應該持續地進行。

紅燈警示:“我們只關注新特性。” → 他們的程式碼庫可能一團糟,或者它就快變得一團糟了。

問題 #8
“你的公司文化是怎樣的?”

公司文化可能是一個非常模糊的概念,但即使是像開放式辦公室和隔間這樣的小事情,也會在很大程度上改變你與同事的日常互動。這裡沒有通常意義上的 “紅燈告警”,但要確保他們的答案可以讓你每週忍耐 40+ 小時,並持續數年。

2. 作為軟體工程師而工作

在這個階段,如果你在面試中表現出色,並且喜歡面試官對你問題的回答,那你很可能會被錄用。

恭喜,你已正式成為一名軟體工程師了!

現在該談什麼了?是時候重新學習關於編碼和工作的很多事情了。既然我們是程式設計師,就讓我們從討論程式碼開始吧。

2.1 好的工業級程式碼

好的工業級程式碼具有以下屬性,按順序排列:

  • 可讀性,因為程式碼被讀取和維護的頻率比編寫要高。在你編寫程式碼多年之後,其他開發人員必須清楚程式碼的意圖。

  • 防禦性,遵循防禦性編碼的最佳實踐。防禦性編碼本身就是一個主題,但它的主旨是:你必須確保你編寫的類和方法被不當使用時不會導致軟體崩潰。

  • 優化的,這條在最後是因為大部分時間,你不會真得需要擔心它。但這並不意味著,當存線上性解決方案時,你應該寫些執行效率為 O(n³) 的爛程式碼。但在有些不必要的時候,開發人員會渴望嘗試和過度優化程式碼,這通常會損害程式碼的可讀性和可防禦性。你應該總是能證明做出某種優化而犧牲的可讀與防禦屬性是合理的。

現在你已經知道如何編寫良好的工業級程式碼了。

2.2 你不會編寫太多程式碼

這可能令人驚訝,但大多數情況下,你不會編寫新程式碼,而是:

  • 除錯
  • 讀已存在的程式碼
  • 開會或者寫郵件
  • 研究該做什麼,這樣就不用編寫程式碼了

因此,編碼以外的其他技能對你的職業生涯也同樣重要。

2.3 除錯和閱讀程式碼

您需要的不僅僅是用 print 語句進行除錯。所有廣泛使用的語言和技術棧都有各種強大的工具,學會使用它們,因為它們會使除錯變得輕而易舉,併為你節省無數的時間。

理解程式碼庫。大多數技術棧都有一些程式碼圖形生成工具,可以幫助你理解程式碼庫的結構。企業級 IDE 通常內建這樣的功能。

理解產品。你將會驚訝的,在嘗試 “修復” 軟體之前,有多少開發人員不知道軟體應該如何工作。

2.4 整理思緒

由於你的大部分時間將花在溝通、調研和多工處理上,你需要一些工具來使得一切有序。

TODO List / 任務列表:你的公司應該已經有某種任務處理軟體了,但是擁有一個針對個人的軟體也是有幫助的。

注意事項:在會議上做筆記,努力改進現有文件,建立個人知識庫。使用 Evernote、OneNote 或紙質筆記本,就像以往的舊時光一樣。這看起來可能有點過火了,但一年後,當你重新檢視那個花了你 3 天的時間才想出來的費解的設計過程時,你會感謝自己的。我從未見過一個優秀的軟體工程師,他不做大量的筆記。

圖表/視覺化:人是視覺動物,建立流程和體系結構圖表將幫助你和其他人理解複雜的主題。在與非技術同事交流時,圖表特別有用。

2.5 知道何時使用庫

簡短答案:幾乎總是使用。

長篇大論:99% 的時間裡,你不應該重新發明輪子。在大多數軟體工程職位中,實現特定型別的排序完全是浪費時間。這並不意味著你不應該知道所用的演算法和資料結構是如何工作的,因為這將幫助你決定使用什麼以及何時使用。

為了成為一名高效的軟體工程師,你需要了解可供你使用的庫。大多數流行語言的標準庫非常有用,比你預期的要大。此外,程式碼庫還可能利用了額外的專門庫。閱讀他們的文件,並知道什麼時候使用它們。

如果額外的庫可以節省時間,那麼你也不應憚於建議使用它們。但是,你需要確保選擇了一個良好的庫供工業級使用。一個好的庫是:

  • 開源,這樣你就可以自己驗證程式碼的質量,並可能修復對你的應用至關重要的 bug。
  • 寬容的許可證,例如 MIT 和 BSD,使用它們你的公司不會遇到任何問題。小心 GPL,以免意外開源了你的程式碼庫。
  • 成熟的,即它已經推出了一段時間,並有一套豐富的功能。
  • 在維護的,新版本經常釋出。
  • 被用於其他公司或專案,這是一種批准可用的標記,並確保它有行業支援,並持續維護。

3. 持續進步

除了學習能讓你在日常工作中做得更好的技能之外,你還需要不斷地改進你的技能,學習新的技能,以便為自己創造新的職業機會。

學習的機會很多,其中多數都是負擔得起的。

線上課程:不應錯過以靈活的形式向該領域最好的老師學習的機會。

線上碩士學位:最近在名列前茅的大學中,線上碩士學位是一種靈活的方式來繼續你的正規教育,它們通常也比較便宜。(譯註:國內不知道有沒有了,學位有時是個門檻)

部落格:部落格是開發人員社群的重要組成部分(這並不奇怪,因為你現在正在閱讀部落格)。有時,部落格能給你一些關於軟體工程師做什麼以及不做什麼的好想法。

會議:放在最後,但並非最不重要。會議是一個驚人的學習機會,你一定要利用你公司的培訓預算去參加。

...

最後,希望這篇文章能讓你對作為一名軟體工程師的職業生涯的起步階段有所瞭解,併為你提供了在這一令人興奮的旅程中表現出色的工具。


作者:Valeri Alexiev 日期:2018-10-29 原文:A Software Engineering survival guide


寫點文字,畫點畫兒,記錄成長瞬間。 微信公眾號「瞬息之間」,既然遇見,不如同行。

一份軟體工程行業生存指南

相關文章