所以，我們不難得出兩點(diǎn)結(jié)論：

1.現(xiàn)有的軟測工程師大多為培訓(xùn)出身；

2.也存在五分之一非培訓(xùn)出身的軟測工程師，排除本身就有基礎(chǔ)的大學(xué)專業(yè)學(xué)習(xí)和從開發(fā)轉(zhuǎn)行的，有不到十分之一的自學(xué)成才的軟測工程師。

那么這樣看來，報班培訓(xùn)還是蠻靠譜的。但是，必須要說清楚的是，報培訓(xùn)班固然靠譜，但并不是報什么培訓(xùn)班都靠譜。

這也好理解，郭德綱說過：“人分三六九等，肉分五花三層”，餓的時候吃東西是靠譜的，但不是吃什么都是靠譜的。同理，培訓(xùn)班也是分檔次的，有好的，有次的，也有那個差不多中不溜的.....

“你們是如何測試軟件的？”

理想情況下，驗(yàn)證代碼質(zhì)量應(yīng)該是單元測試、人工測試以及自動化測試的結(jié)合。

危險信號：“我們都寫不出 bug，哈哈。” → 那些人正是會寫出 bug 的人。

　“你們使用什么樣的版本控制系統(tǒng)？”

版本控制系統(tǒng)對于協(xié)作極其有用，在職業(yè)環(huán)境下沒有理由不使用。

危險信號 #1：“額，版本控制系統(tǒng)？” → 快跑，跑得越遠(yuǎn)越好。

永遠(yuǎn)記得使用版本控制。

危險信號 #2：“<插入不的或者定制的 VCS>” → 這表明他們很有可能沒有跟上時代并且很久沒有升級自己的基礎(chǔ)設(shè)施了。

　　好的行業(yè)代碼

好的行業(yè)代碼有以下屬性，依序是：可讀性，因?yàn)榇a用來讀和維護(hù)的頻次要高于寫。代碼的意圖必須清晰，讓其他開發(fā)者在多年后依然理解。防御性，就是要遵循防御性編碼的實(shí)踐。防御性編碼本身就是一個課題，不過其要義是：你必須確保自己所寫的類和方法的不恰當(dāng)使用不會導(dǎo)致你的代碼搞得軟件都崩潰。優(yōu)化，位列清單的后未知，因?yàn)榇蠖鄶?shù)時候你并不需要真正去擔(dān)心這個。這并不意味著你應(yīng)該編寫糟糕代碼，在存在線性解決方案的情況下以O(shè)(n3)的效率去做某個東西。但開發(fā)者通?？释麌L試并且會在不需要的情況下過度優(yōu)化，卻犧牲了代碼的可讀性和防御性。你永遠(yuǎn)都應(yīng)該能夠證明犧牲了這些屬性的特定優(yōu)化是值得的?，F(xiàn)在你了解了如何去編寫良好的行業(yè)代碼了。好的行業(yè)代碼好的行業(yè)代碼有以下屬性，依序是：可讀性，因?yàn)榇a用來讀和維護(hù)的頻次要高于寫。

　　編碼的工作你不會干太多的

說出來也許有點(diǎn)令人吃驚，但是大多數(shù)時候你都不用寫新代碼，而是相反，要做：調(diào)試讀已有代碼開會或者寫電子郵件研究該怎么做以便不用寫代碼因此編碼以外的技能對你的職業(yè)一樣關(guān)鍵。

調(diào)試和閱讀代碼調(diào)試遠(yuǎn)不僅僅是用打印語句。一切使用廣泛的語言和技術(shù)棧都有各種強(qiáng)大的工具。學(xué)會使用它們，因?yàn)檫@些會讓調(diào)試輕而易舉，節(jié)省你無數(shù)的時間。理解代碼庫。大多數(shù)技術(shù)棧都有某種代碼圖譜生成工具來幫助你理解代碼庫的結(jié)構(gòu)。企業(yè)級的 IDE 通常都內(nèi)置了那種功能。你還可以利用 ReSharper、grep 或者 Sourcegraph 之類的工具來探索代碼。理解產(chǎn)品。你會對居然有這么多開發(fā)者在試圖“修復(fù)”軟件前不知道軟件應(yīng)該是怎么工作的感到驚訝。先看看文檔再說吧。筆記：開會一定要記筆記，要致力于改進(jìn)現(xiàn)有文檔并且建立個人的知識庫。