写了 10 年代码之后,我学到的 7 个绝对真理
明年就是我的開發者生涯的第十個年頭。整整十年!我有三分之二的時間都用在了 Web 開發上。在孩童時代,當其他小孩還在學習樂器或芭蕾舞的時候,我在自己的臥室里用代碼編織了一個神奇的世界。為了給這十年來一個總結,我想分享一下我在過去的十年當中作為一名開發者的心路歷程。
對于現今的初級開發者來說,或許他們會在這篇文章里找到一些能夠引起他們共鳴的東西,或者讓他們深受鼓舞的東西。對于現今的高級開發者來說,或許他們也有一些有趣的故事可以分享,因為他們都是過來人。
1. 我是高級開發者
我在 19 歲的時候開始應聘我的第一份開發工作,當時的那個職位叫作“Student Webmaster”。這個職位很有意思,因為如果你拿到這個職位,就變成了“學生”和“大師”的結合體。不過現在的人更希望成為“工程師”,因為這個頭銜聽起來似乎更有發燒友的味道。我當時的工作是負責 PHP 和 MySQL 方面的開發,維護 Drupal 網站,以及開發一些內部工具。
因為在孩童時代就開始寫代碼,并且我很肯定它們可以作為正式的經驗,所以當被問及我有幾年 PHP 經驗時,我非常自信地回答道:”三到四年“!
我當時覺得我對 SQL 應該懂得挺多了,因為我都會用外連接了。
在當時,三到四年的經驗意味著我可以拿到比較可觀的薪水了。
五年之后,我開始了最近的這份工作。即使是到了這個時候,我的代碼都沒有給別人評審過。在部署代碼的時候,我直接從 Git 上拉取代碼,然后通過 SSH 部署到服務器上。我敢肯定我幾乎沒有提交過 PR。不過不要誤會,其實我在頭兩份工作中學到了很多有用的東西,只是我從來沒有真正地和其他開發者一起開發過同一個代碼庫。我就是這樣去申請了”高級前端開發“的職位,并拿到了 offer。
就這樣,我成了一名 24 歲的高級開發者。
我的意思是,如果我撐不起這個頭銜,他們也不會給我這個職位的,對吧?我很確信的是,我之所以能夠拿到這個職位,是因為我過去的那些令人印象深刻的經歷。我感覺自己達到了職業生涯的巔峰,我是公司里最年輕的開發者。
我最終學到了什么
每個時期的經驗都是不一樣的。孩童時期的編碼經歷、學生時期的編碼經歷、CS 研究員時期的編碼經歷,以及在成長型初創公司時期的編碼經歷,它們對我來說都是無價之寶。但各個時期的經歷都是不一樣的。在職業生涯早期,如果你加入了一個優秀的團隊,那么在一年內學到的東西要比自己獨立工作五年多十倍。如果你的代碼沒有拿給別人評審,就不會成長得那么快。
所以,導師很重要。加入團隊比暫時多賺點錢要重要得多。如果有可能,不要接受那種獨立工作的初級職位。在選擇第一份工作時,不要只為了錢,加入好團隊才是真正有價值的。
職位頭銜什么的其實都是浮云。想象一下 5 人團隊的 CTO 和 50 人團隊或者 500 人團隊的 CTO,雖然頭銜一樣,但它們所要求的工作技能卻是完全不同的。所以,我也不會因為被安了“高級開發者”的頭銜而變成高級工程師。而且頭銜具有“迷惑性”,同樣的職位在不同的公司之間也不具備嚴格的可比性。
2. 每個人都會寫測試代碼
我的職業生涯的前半部分主要從事學術方面的工作。具體地說,有三年半時間花在了一個由公共基金支持的項目上,然后一年半是在大學里。我可以告訴你:學術界的編程與業界的編程其實完全不一樣。
你的大部分時間并不是在開發應用程序,而是在寫算法或者解析數據集。如果湊巧你是在開發應用程序,那么它很可能也只是個公共項目——要么是免費的,要么是開源的。免費的項目意味著你不一定會全力以赴把它做到完美。
畢竟,天下沒有免費的午餐。
后來,我帶著很多期望離開了學術界。
我期望能夠在業界看到我想看到的東西,比如自動化部署、PR 和代碼評審,以及高質量的代碼!我堅信業界的每個開發者都會寫測試代碼。
但是,在我加入第一家初創公司的那一天,居然沒有看到任何測試代碼。前端沒有,后端也沒有,什么測試代碼都沒有。
更糟糕的是,沒有測試代碼也就算了,居然沒有人認為缺少測試代碼是個問題!帶著一點點的天真,我就當是他們不知道如何為 AngularJS 編寫測試代碼吧。如果我教他們怎么寫測試代碼,或許這個問題就解決了吧。但我錯了!幾年之后,我們在添加自動化測試代碼方面有了長足的進步,但與我最初想象的并不一樣!
他們之前不寫測試代碼并不是因為不知道該怎么寫,而是他們體會不到沒有測試代碼的痛苦,或者不堪忍受維護遺留測試代碼給他們帶來的痛苦。
我最終學到了什么
很多公司或者初創企業壓根就沒有測試代碼,即使有,數量也很少。為了讓產品盡快上市,或者為了生存,很多初創公司忽略了早期的測試。即使是那些看起來挺不錯、贊助過開發者大會或開源項目的公司,它們的一些項目也都是只包含少量測試的大單體。
沒有一家公司的技術棧是完美的。每一家公司都有自己的問題,都逃不過技術債務,關鍵在于他們做了哪些事情來解決這些問題。
如果你在某些問題上缺乏實際經驗,但又固執己見,這樣就顯得有點傲慢了。我給人的印象是一個無所不知的人,并堅持一定要寫測試代碼,但我在這方面其實也沒有大量的經驗可言。堅持原則固然重要,但也要試著開放心態,并真正從別人的經驗和角度來看待問題。
3. 我們比別人落后太多
這個與上一個話題有點關系。我們公司沒有人寫單元測試代碼,但是其他公司的人會寫的,對嗎?
我讀過很多博文,在 YouTube 上看過很多大會演講的視頻。好像他們每個人都能做出非常復雜且質量很高的應用程序,不僅性能好,還非常有趣。而我呢,能夠趕在截止日期之前把能用的東西拼湊在一起,并讓它們運行起來就算不錯了。
基本上,我對這些公司充滿了崇拜之情,但同時又對自己的公司和項目落于人后而感到失望。
我最終學到了什么
很多大會演講只涉及概念驗證,并不是真實的案例。如果你在某某技術大會上看到某一項很特別的技術,那并不意味著他們公司一定會在日常開發中使用這項技術。通常,演講者所使用的演示 App 并非真實的案例,所以要注意區分它們。
處理遺留代碼是很正常的事情。通常,人們會理所當然地認為別人的公司不需要處理遺留代碼。但在技術大會上與那些大公司的人交流過之后,我發現,他們和我們的處境是一樣的。有遺留代碼是很正常的,相比從頭開發 App,學會如何處理好遺留代碼將會讓你學到更多的東西,因為你會接觸到更多你之前沒有接觸過的概念。
4. 代碼質量最重要
在以前,我對代碼評審的要求是很嚴格的。
至少,我對代碼風格是十分挑剔的。縮進、格式化、命名——你最好要做得和我一模一樣。代碼評審不留下任何評論的幾率跟中彩票的幾率一樣低。
想象一下,一個 PR 里有我的 50 多個評論,都是因為缺少分號!
因為我有一雙老鷹似的眼睛,不會漏掉任何一個分號!
我最終學到了什么
做到足夠好就可以了。代碼質量“好”到一定程度,它給我們帶來的收益是遞減的。代碼不需要完美,只要維護起來不像是一場災難就可以了。通常情況下,有點啰嗦的代碼讀起來反而更容易理解。而且,“好代碼”與“它看起來就像是我寫出來的代碼”是兩碼事。
看清整體架構比對細節吹毛求疵更重要。少量有問題的代碼可以加以改進,而架構方面的問題會導致更大的問題。我想我在一開始就應該更加關注應用程序的整體結構,而不是代碼的細節。
代碼質量很重要,但請注意,代碼質量并不是指我以前所認為的那些東西,比如 linting、格式化,等等。
5. 所有代碼都需要注釋
在加入第一家公司時,我需要處理大量別人留給我的代碼。我在干第一份工作時有做過一些類似的事情,但后來都沒有真正深入到已有的代碼庫,弄跟無頭蒼蠅一樣到處亂撞。我寧愿重寫所有代碼,也不想一點一點去理清楚老代碼是怎么寫的。
但即使是這樣又能怎樣?一個 Ruby 程序員寫出來的 AngularJS 代碼,或者一個自認為自己很厲害的初級程序員寫出來的代碼,別人照樣看不懂。
所以,我開始在所有可能的地方添加注釋,給所有函數加了注解。
我學會了所有與 Angular 相關的 JSDoc 語法。我的代碼行數因此增加了一倍,因為有太多的注釋。
我最終學到了什么
有時候注釋也會撒謊。有人把注釋當成了萬靈丹。“我們需要注釋!”不要因為寫注釋很難,就認為完全不值得這么去做,我只是認為要用正確的方式給需要注釋的地方加上注釋。錯誤的過度注釋只會給后面修復代碼 bug 的人添加更多的麻煩。
在適當的情況下用自動化代替注釋。自動化測試代碼通常不太會出現不同步的情況。我開始專注于編寫清晰的測試代碼,當其他人在閱讀我的代碼時就可以知道這些代碼是干什么用的。
6. 技術債務是不可容忍的
在很長一段時間里,我認為任何“混亂”的代碼都是技術債務。技術債務這個東西很有意思,如果你讓不同的人例舉技術債務的例子,他們會給出不同的答案。
因此,作為一個將“混亂”代碼視為技術債務的人,我會立即使用最嚴格的方式消除這類代碼!
我曾經花了一整個周末修復了 800 個 linting 錯誤(當然是在出現自動修復工具之前)。
可見我是一個多么神經質的人。
我最終學到了什么
不完美的代碼不一定就是技術債務。一些看起來不是那么好的代碼并不意味著它就是技術債務。技術債務會以某種形式阻礙項目的進展,或者讓你很難對項目做出變更。如果代碼有點美中不足,就放過它們吧,花太多時間清理它們可能不值得。
有點技術債務是正常的。有時候我們不得不走捷徑,因為時間緊迫。有一點技術債務是沒有問題的,只要記得回過頭來把這些債務還掉。如果你想讓你的項目零技術債務,那么你很可能把代碼本身凌駕在交付價值之上。我之前就是這樣的!
7.“高級開發者”就是指編程最厲害的人
因為從小就寫代碼,編程對我來說就像呼吸一樣。寫代碼就像在寫博客或者郵件,通常比別人更快給出解決方案。
在很長一段時間里,我一直在思考這個問題:這就是成為高級開發者要做的事情的嗎?
難道不是這樣嗎?因為頭銜是叫“高級開發者”,又不是叫“高級溝通者”或者“高級項目經理”,不是嗎?我不知道要成為高級開發者,除了編程還需要其他什么技能。
我最終學到了什么
高級工程師除了編程,還需要發展其他技能。與我已經掌握的技能相比,我還欠缺的技能簡直就是一個天文數字。從通信、依賴管理到共享上下文、項目管理、估算,以及與非開發人員合作。這些技能是不太好量化的,所以需要更多的試錯才能獲得。
不是每個人都能成為“高級開發者”。資歷是多年經驗積累的結果,但這也只是必要條件,而非充要條件。而且你的經驗還得是用得上的,你要把它們內化了,并可以用來解決問題。有時候,一些很重要的經驗需要一年甚至更長的時間才能顯化出來。
在某些領域,我們仍然很嫩。不管你的經驗多么豐富,總有很多東西是你不懂的。承認自己的“無知”是第一步,然后向更有經驗的人學習,爭取把中間的差距彌補起來。
原文鏈接:
https://monicalent.com/blog/2019/06/03/absolute-truths-unlearned-as-junior-developer/
創作挑戰賽新人創作獎勵來咯,堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的写了 10 年代码之后,我学到的 7 个绝对真理的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: python中的切片以及注意事项
- 下一篇: python中向类中动态添加新特性及删除