我在 19 歲的時候開始應(yīng)聘我的第一份開發(fā)工作，當(dāng)時的那個職位叫作“Student Webmaster”。這個職位很有意思，因為如果你拿到這個職位，就變成了“學(xué)生”和“大師”的結(jié)合體。不過現(xiàn)在的人更希望成為“工程師”，因為這個頭銜聽起來似乎更有發(fā)燒友的味道。我當(dāng)時的工作是負(fù)責(zé) PHP 和 MySQL 方面的開發(fā)，維護(hù) Drupal 網(wǎng)站，以及開發(fā)一些內(nèi)部工具。

因為在孩童時代就開始寫代碼，并且我很肯定它們可以作為正式的經(jīng)驗，所以當(dāng)被問及我有幾年 PHP 經(jīng)驗時，我非常自信地回答道：”三到四年“！

我當(dāng)時覺得我對 SQL 應(yīng)該懂得挺多了，因為我都會用外連接了。

在當(dāng)時，三到四年的經(jīng)驗意味著我可以拿到比較可觀的薪水了。

五年之后，我開始了最近的這份工作。即使是到了這個時候，我的代碼都沒有給別人評審過。在部署代碼的時候，我直接從 Git 上拉取代碼，然后通過 SSH 部署到服務(wù)器上。我敢肯定我?guī)缀鯖]有提交過 PR。不過不要誤會，其實我在頭兩份工作中學(xué)到了很多有用的東西，只是我從來沒有真正地和其他開發(fā)者一起開發(fā)過同一個代碼庫。我就是這樣去申請了”高級前端開發(fā)“的職位，并拿到了 offer。

就這樣，我成了一名 24 歲的高級開發(fā)者。

我的意思是，如果我撐不起這個頭銜，他們也不會給我這個職位的，對吧？我很確信的是，我之所以能夠拿到這個職位，是因為我過去的那些令人印象深刻的經(jīng)歷。我感覺自己達(dá)到了職業(yè)生涯的巔峰，我是公司里最年輕的開發(fā)者。

每個時期的經(jīng)驗都是不一樣的。孩童時期的編碼經(jīng)歷、學(xué)生時期的編碼經(jīng)歷、CS 研究員時期的編碼經(jīng)歷，以及在成長型初創(chuàng)公司時期的編碼經(jīng)歷，它們對我來說都是無價之寶。但各個時期的經(jīng)歷都是不一樣的。在職業(yè)生涯早期，如果你加入了一個優(yōu)秀的團(tuán)隊，那么在一年內(nèi)學(xué)到的東西要比自己獨立工作五年多十倍。如果你的代碼沒有拿給別人評審，就不會成長得那么快。

所以，導(dǎo)師很重要。加入團(tuán)隊比暫時多賺點錢要重要得多。如果有可能，不要接受那種獨立工作的初級職位。在選擇第一份工作時，不要只為了錢，加入好團(tuán)隊才是真正有價值的。

職位頭銜什么的其實都是浮云。想象一下 5 人團(tuán)隊的 CTO 和 50 人團(tuán)隊或者 500 人團(tuán)隊的 CTO，雖然頭銜一樣，但它們所要求的工作技能卻是完全不同的。所以，我也不會因為被安了“高級開發(fā)者”的頭銜而變成高級工程師。而且頭銜具有“迷惑性”，同樣的職位在不同的公司之間也不具備嚴(yán)格的可比性。

我的職業(yè)生涯的前半部分主要從事學(xué)術(shù)方面的工作。具體地說，有三年半時間花在了一個由公共基金支持的項目上，然后一年半是在大學(xué)里。我可以告訴你：學(xué)術(shù)界的編程與業(yè)界的編程其實完全不一樣。

你的大部分時間并不是在開發(fā)應(yīng)用程序，而是在寫算法或者解析數(shù)據(jù)集。如果湊巧你是在開發(fā)應(yīng)用程序，那么它很可能也只是個公共項目——要么是免費的，要么是開源的。免費的項目意味著你不一定會全力以赴把它做到完美。

畢竟，天下沒有免費的午餐。

后來，我?guī)е芏嗥谕x開了學(xué)術(shù)界。

我期望能夠在業(yè)界看到我想看到的東西，比如自動化部署、PR 和代碼評審，以及高質(zhì)量的代碼！我堅信業(yè)界的每個開發(fā)者都會寫測試代碼。

但是，在我加入第一家初創(chuàng)公司的那一天，居然沒有看到任何測試代碼。前端沒有，后端也沒有，什么測試代碼都沒有。

更糟糕的是，沒有測試代碼也就算了，居然沒有人認(rèn)為缺少測試代碼是個問題！帶著一點點的天真，我就當(dāng)是他們不知道如何為 AngularJS 編寫測試代碼吧。如果我教他們怎么寫測試代碼，或許這個問題就解決了吧。但我錯了！幾年之后，我們在添加自動化測試代碼方面有了長足的進(jìn)步，但與我最初想象的并不一樣！

他們之前不寫測試代碼并不是因為不知道該怎么寫，而是他們體會不到?jīng)]有測試代碼的痛苦，或者不堪忍受維護(hù)遺留測試代碼給他們帶來的痛苦。

很多公司或者初創(chuàng)企業(yè)壓根就沒有測試代碼，即使有，數(shù)量也很少。為了讓產(chǎn)品盡快上市，或者為了生存，很多初創(chuàng)公司忽略了早期的測試。即使是那些看起來挺不錯、贊助過開發(fā)者大會或開源項目的公司，它們的一些項目也都是只包含少量測試的大單體。

沒有一家公司的技術(shù)棧是完美的。每一家公司都有自己的問題，都逃不過技術(shù)債務(wù)，關(guān)鍵在于他們做了哪些事情來解決這些問題。

如果你在某些問題上缺乏實際經(jīng)驗，但又固執(zhí)己見，這樣就顯得有點傲慢了。我給人的印象是一個無所不知的人，并堅持一定要寫測試代碼，但我在這方面其實也沒有大量的經(jīng)驗可言。堅持原則固然重要，但也要試著開放心態(tài)，并真正從別人的經(jīng)驗和角度來看待問題。

這個與上一個話題有點關(guān)系。我們公司沒有人寫單元測試代碼，但是其他公司的人會寫的，對嗎？

我讀過很多博文，在 YouTube 上看過很多大會演講的視頻。好像他們每個人都能做出非常復(fù)雜且質(zhì)量很高的應(yīng)用程序，不僅性能好，還非常有趣。而我呢，能夠趕在截止日期之前把能用的東西拼湊在一起，并讓它們運行起來就算不錯了。

基本上，我對這些公司充滿了崇拜之情，但同時又對自己的公司和項目落于人后而感到失望。

很多大會演講只涉及概念驗證，并不是真實的案例。如果你在某某技術(shù)大會上看到某一項很特別的技術(shù)，那并不意味著他們公司一定會在日常開發(fā)中使用這項技術(shù)。通常，演講者所使用的演示 App 并非真實的案例，所以要注意區(qū)分它們。

處理遺留代碼是很正常的事情。通常，人們會理所當(dāng)然地認(rèn)為別人的公司不需要處理遺留代碼。但在技術(shù)大會上與那些大公司的人交流過之后，我發(fā)現(xiàn)，他們和我們的處境是一樣的。有遺留代碼是很正常的，相比從頭開發(fā) App，學(xué)會如何處理好遺留代碼將會讓你學(xué)到更多的東西，因為你會接觸到更多你之前沒有接觸過的概念。

在以前，我對代碼評審的要求是很嚴(yán)格的。

至少，我對代碼風(fēng)格是十分挑剔的。縮進(jìn)、格式化、命名——你最好要做得和我一模一樣。代碼評審不留下任何評論的幾率跟中彩票的幾率一樣低。

想象一下，一個 PR 里有我的 50 多個評論，都是因為缺少分號！

因為我有一雙老鷹似的眼睛，不會漏掉任何一個分號！

做到足夠好就可以了。代碼質(zhì)量“好”到一定程度，它給我們帶來的收益是遞減的。代碼不需要完美，只要維護(hù)起來不像是一場災(zāi)難就可以了。通常情況下，有點啰嗦的代碼讀起來反而更容易理解。而且，“好代碼”與“它看起來就像是我寫出來的代碼”是兩碼事。

看清整體架構(gòu)比對細(xì)節(jié)吹毛求疵更重要。少量有問題的代碼可以加以改進(jìn)，而架構(gòu)方面的問題會導(dǎo)致更大的問題。我想我在一開始就應(yīng)該更加關(guān)注應(yīng)用程序的整體結(jié)構(gòu)，而不是代碼的細(xì)節(jié)。

代碼質(zhì)量很重要，但請注意，代碼質(zhì)量并不是指我以前所認(rèn)為的那些東西，比如 linting、格式化，等等。

在加入第一家公司時，我需要處理大量別人留給我的代碼。我在干第一份工作時有做過一些類似的事情，但后來都沒有真正深入到已有的代碼庫，弄跟無頭蒼蠅一樣到處亂撞。我寧愿重寫所有代碼，也不想一點一點去理清楚老代碼是怎么寫的。

但即使是這樣又能怎樣？一個 Ruby 程序員寫出來的 AngularJS 代碼，或者一個自認(rèn)為自己很厲害的初級程序員寫出來的代碼，別人照樣看不懂。

所以，我開始在所有可能的地方添加注釋，給所有函數(shù)加了注解。

我學(xué)會了所有與 Angular 相關(guān)的 JSDoc 語法。我的代碼行數(shù)因此增加了一倍，因為有太多的注釋。

有時候注釋也會撒謊。有人把注釋當(dāng)成了萬靈丹?！拔覀冃枰⑨?！”不要因為寫注釋很難，就認(rèn)為完全不值得這么去做，我只是認(rèn)為要用正確的方式給需要注釋的地方加上注釋。錯誤的過度注釋只會給后面修復(fù)代碼 bug 的人添加更多的麻煩。

在適當(dāng)?shù)那闆r下用自動化代替注釋。自動化測試代碼通常不太會出現(xiàn)不同步的情況。我開始專注于編寫清晰的測試代碼，當(dāng)其他人在閱讀我的代碼時就可以知道這些代碼是干什么用的。

在很長一段時間里，我認(rèn)為任何“混亂”的代碼都是技術(shù)債務(wù)。技術(shù)債務(wù)這個東西很有意思，如果你讓不同的人例舉技術(shù)債務(wù)的例子，他們會給出不同的答案。

因此，作為一個將“混亂”代碼視為技術(shù)債務(wù)的人，我會立即使用最嚴(yán)格的方式消除這類代碼！

我曾經(jīng)花了一整個周末修復(fù)了 800 個 linting 錯誤（當(dāng)然是在出現(xiàn)自動修復(fù)工具之前）。

可見我是一個多么神經(jīng)質(zhì)的人。

不完美的代碼不一定就是技術(shù)債務(wù)。一些看起來不是那么好的代碼并不意味著它就是技術(shù)債務(wù)。技術(shù)債務(wù)會以某種形式阻礙項目的進(jìn)展，或者讓你很難對項目做出變更。如果代碼有點美中不足，就放過它們吧，花太多時間清理它們可能不值得。

有點技術(shù)債務(wù)是正常的。有時候我們不得不走捷徑，因為時間緊迫。有一點技術(shù)債務(wù)是沒有問題的，只要記得回過頭來把這些債務(wù)還掉。如果你想讓你的項目零技術(shù)債務(wù)，那么你很可能把代碼本身凌駕在交付價值之上。我之前就是這樣的！

因為從小就寫代碼，編程對我來說就像呼吸一樣。寫代碼就像在寫博客或者郵件，通常比別人更快給出解決方案。

在很長一段時間里，我一直在思考這個問題：這就是成為高級開發(fā)者要做的事情的嗎？

難道不是這樣嗎？因為頭銜是叫“高級開發(fā)者”，又不是叫“高級溝通者”或者“高級項目經(jīng)理”，不是嗎？我不知道要成為高級開發(fā)者，除了編程還需要其他什么技能。

高級工程師除了編程，還需要發(fā)展其他技能。與我已經(jīng)掌握的技能相比，我還欠缺的技能簡直就是一個天文數(shù)字。從通信、依賴管理到共享上下文、項目管理、估算，以及與非開發(fā)人員合作。這些技能是不太好量化的，所以需要更多的試錯才能獲得。

不是每個人都能成為“高級開發(fā)者”。資歷是多年經(jīng)驗積累的結(jié)果，但這也只是必要條件，而非充要條件。而且你的經(jīng)驗還得是用得上的，你要把它們內(nèi)化了，并可以用來解決問題。有時候，一些很重要的經(jīng)驗需要一年甚至更長的時間才能顯化出來。

在某些領(lǐng)域，我們?nèi)匀缓苣?/strong>。不管你的經(jīng)驗多么豐富，總有很多東西是你不懂的。承認(rèn)自己的“無知”是第一步，然后向更有經(jīng)驗的人學(xué)習(xí)，爭取把中間的差距彌補起來。

原文鏈接：

https:///blog/2019/06/03/absolute-truths-unlearned-as-junior-developer/

你也「在看」嗎？??