• 很少有人從頭開始構(gòu)建代碼
• 對領(lǐng)域的認知比會寫代碼更重要!
• 文檔編寫沒有得到足夠重視
• 代碼是次要的，商業(yè)價值才是第一的
• 你需要和不稱職的人打交道
• 大部分時間都在與不確定性打交道
• 假設(shè)所有東西都有bug
• 這不是一份理想的工作
• 美學(xué)是教不來的
• 即使你不想給出估算，但還是會有人問你
• 并非所有的會議都是無用的
• 結(jié)論

按照慣例，首先聲明，以下內(nèi)容皆為個人觀點。但，無論你是經(jīng)驗豐富的專業(yè)人士還是剛剛?cè)胄械男“祝枷Ｍ旅孢@些見解能夠給你帶來一些幫助。

我從2023年年中就想寫這篇文章了，但很多觀點我一時無法全部記住。所以在過去的一年里，我一直在收集想法并把它們記錄下來，現(xiàn)在我有了足夠的觀點，下面來分享給大家。

很少有人從頭開始構(gòu)建代碼

在大學(xué)，他們會教你如何編寫一個400行的程序，從頭到尾地解決一個問題。你手頭有一個白板，你需要展示一些花哨的算法，以證明你具有可以找到走出迷宮的知識和能力。最后，你找到了完美解決方案去解決那個超簡單的問題。

這看起來很像真實的世界，對吧？但現(xiàn)實并非如此。在現(xiàn)實世界中，你有一個幾十萬行的代碼，當你試圖弄清楚你的同事在寫這部分代碼時到底在抽什么風，你需要在文檔和更了解代碼的人之間來回切換。當一周快結(jié)束時，你寫了10行代碼來修復(fù)某個bug，然后循環(huán)往復(fù)，直到人們找到你，向你解釋他當時為什么要這樣寫。

代表開發(fā)者的日常生活

專業(yè)的軟件開發(fā)人員在團隊中工作，一般只處理大型軟件代碼庫的一小部分，并且通常只是修復(fù)一些東西，而不是從頭開始構(gòu)建。它并不像培訓(xùn)機構(gòu)所描述的那樣迷人，而且修復(fù)所付出的開銷要比寫代碼多得多。

對領(lǐng)域的認知比會寫代碼更重要!

我驚訝地發(fā)現(xiàn)，當你理解了它是如何（更重要的是為什么）工作，以及工作的基本原理后，編寫代碼會變得容易得多。

在構(gòu)建銀行移動端APP的時候，你可以更好地理解交易是如何運行的，貨幣結(jié)算是如何運作的，賬本是如何工作的等。

在為餐廳構(gòu)建銷售系統(tǒng)時，你最好弄清楚服務(wù)員是如何工作的，在烹飪清單中如何做庫存管理，以及信用卡授權(quán)是如何工作的。基本上，這就是你的軟件運行域的內(nèi)部和外部。

構(gòu)建醫(yī)療、物流和記賬方面的軟件也是如此。

如果不了解這些，個體是很難做出有意義的貢獻的，對雇主來說也就沒有價值了。例如，如果你有銀行APP的經(jīng)驗，那么你很容易在金融領(lǐng)域再找到一份新的工作，因為你已經(jīng)熟悉該領(lǐng)域。

文檔編寫沒有得到足夠重視

大學(xué)經(jīng)常為學(xué)生提供軟件開發(fā)職業(yè)所需的基本技術(shù)技能，如算法和數(shù)據(jù)結(jié)構(gòu)。然而，他們通常不會優(yōu)先考慮編寫整潔、文檔良好和可維護的代碼。

圖片

通常，開發(fā)人員只有在處理別人編寫的代碼并經(jīng)歷了試圖理解和修改它的挑戰(zhàn)之后，才會意識到編寫可維護代碼的價值。可想而知，當我看到正確的文檔時，我是多么高興。然而，這些都不是在課堂上學(xué)到的，而是通過實踐經(jīng)驗總結(jié)的。通過編寫文檔和易于理解的代碼可以節(jié)省大量時間和精力。

代碼是次要的，商業(yè)價值才是第一的

沒有人會過來對你說：“哇，這行代碼寫的真棒！”相反，他們會說：“用戶對你寫的功能相當滿意”，或者“你的代碼把整個網(wǎng)站都搞垮了”。

雖然這聽起來可能令人驚訝，但軟件工程師的主要工作重點不是編寫代碼，而是通過使用已編寫的軟件來創(chuàng)造價值。代碼只是實現(xiàn)這一目標的工具。代碼->軟件->價值。

你寫的東西需要滿足世界上的一些需求——一些用戶使用的工具，一些降低成本的自動化，一些人們愿意付出（付出他們的時間、金錢或注意力）的東西。我們可以簡化它。如果你用糟糕的技術(shù)構(gòu)建了一些為用戶提供巨大價值的東西——恭喜你，你已經(jīng)完成了作為軟件工程師的目標。但，如果你用優(yōu)秀的技術(shù)構(gòu)建了一些東西，但卻為用戶提供了糟糕的價值——那么很遺憾，你并沒有達到目標。

優(yōu)雅的代碼，最佳實踐，智能解決方案，設(shè)計模型——這些都是為了你的軟件工程師同事，他們將在你之后處理這些代碼庫，而不是幫助你實現(xiàn)帶來價值的目的。（請注意，帶來價值也可以意味著構(gòu)建一個不會崩潰的可伸縮的解決方案，這要求代碼寫的至少像點樣。）

你需要和不稱職的人打交道

大多數(shù)工作環(huán)境中都會有不稱職的人。不是指他們就是你的經(jīng)理，他們可以是提供API的合作伙伴公司的經(jīng)理，也可以是客戶的某些高管。和不稱職的人協(xié)作是非常令人沮喪和疲勞的。他們創(chuàng)造了一種有害和低效的工作環(huán)境。他們花了太多時間來做決定，或者做出了糟糕的決定，從而給團隊和項目帶來了負面影響。這導(dǎo)致了持續(xù)的延遲和返工，浪費了寶貴的時間和資源。

我花了相當多的時間來尋找有效的方法來處理這些事情，同時又不會成為一個混蛋。我認為大學(xué)應(yīng)該傳授此技能。

圖片

我發(fā)現(xiàn)了一種有效的方法就是不管別人怎樣，都要專注于高效。我試圖尋找其他可能更有效的解決方案，以及避免無效的人參與。比如，記錄一切也是很有幫助的。這可以提供具體的證據(jù)，證明他們的不稱職對項目進程的影響。

最終，應(yīng)對不稱職的最好方法是積極主動，找到繞過他們局限性的方法。這可能涉及：

1. 尋求額外的資源或支持。
2. 想辦法把任務(wù)委派給更有能力的人。
3. 實現(xiàn)故障保護和回退機制，這樣事情不會卡在你這邊。
4. 以面對面的方式告訴對方，他們阻礙了這個進程。
5. 再說一遍，沒必要當混蛋。

大部分時間都在與不確定性打交道

與人打交道很難。處理不確定性也很難。與不確定的人打交道更難。這就是你作為一個軟件開發(fā)人員要做的。

人們并不總是知道他們想要什么，有時他們沒有意識到一個簡單的改變可能是非常復(fù)雜的——“哦，你的意思是我們不能僅僅是變更支付供應(yīng)商？而是整個信用卡付款流程的改變，對吧？”

他們在大學(xué)里對你說的一個大謊言是，你的項目經(jīng)理會給你適當?shù)摹⒔Y(jié)構(gòu)化的、簡單的指令，告訴你需要做什么，然后你編寫代碼。“畫一個曼德勃羅特集”或“渲染一個環(huán)境遮蔽的Rabbit mesh”。在一天結(jié)束的時候，你有了一個解決方案，你和你的經(jīng)理擊掌，然后微笑著回家。

實際上會發(fā)生的是，你的產(chǎn)品經(jīng)理會給你一個任務(wù)的粗略輪廓，“我們需要一些東西來把我們從A點帶到B點，但我們還沒有任何設(shè)計，第三方集成也不會立馬交付，除非我們告訴他們我們想要什么，X老板希望它是紅色的，Y老板希望它是綠色的。”這就是軟件工程師的“真正工作”開始的地方——收集需求，弄清楚需要做什么。

需求收集在編程中可不是簡簡單單的。這沒有寫代碼那么有趣。但作為程序員，這需要你花費大量的時間，因為它需要與人而不是機器合作——打電話給提供第三方集成的機構(gòu)，并與他們的開發(fā)人員交談，以了解什么是可行的，什么是不可行的。與利益相關(guān)方坐下來，告訴他們，他們的想法沒有意義，我們可以這樣做，不能那樣做。

編寫第一行代碼可能需要數(shù)周時間。你需要弄清楚需求，然后弄清楚它需要放在哪里，然后弄清楚它需要如何構(gòu)建，然后弄清楚它可能會在哪里出錯，然后才真正開始編寫第一行代碼。

假設(shè)所有東西都有bug

這是很多開發(fā)人員對于信任的一個普遍誤解：

• 你很少充分信任你的代碼，因為你知道你也是人，也會犯錯誤。
• 你使用的第三方庫可能會有bug，但它們是由比你更有能力的人編寫的，對吧？
• 標準操作系統(tǒng)庫不應(yīng)該有任何bug，對吧？它們是由更聰明的人寫的。
• CPU/硬件應(yīng)該永遠不會出錯，對吧？他們花了好幾年研發(fā)這個東西；它不應(yīng)該壞。
• 供電是不應(yīng)該中斷的啊。哎。

但事實是——我們永遠不能完全相信我們的代碼、庫甚至硬件不會在某些時候中斷；相反，我們需要假設(shè)它會。即使是聰明人也會犯糊涂。

圖片

如果你查看任何流行庫（操作系統(tǒng)或應(yīng)用程序級別）的GitHub issue，你會看到大量未定義的操作等待被修復(fù)。天啊，我的Linux機器有多少次因為分段故障崩潰了？這太瘋狂了。

通過假設(shè)一切都可能發(fā)生故障或有bug，我們可以采取措施來預(yù)防或減輕潛在的問題，這最終有助于確保系統(tǒng)的可靠性和穩(wěn)定性。

這不是一份理想的工作

你的大學(xué)或培訓(xùn)機構(gòu)都會告訴你，一旦你開始工作，你將擁有的美好生活是什么。但那都只是一個空洞的承諾。

圖片

• 這是一項艱苦的工作。你一天大部分時間都坐在電腦后面。
• 工作和生活很難平衡。一般其他職業(yè)是，一天的工作在18:00結(jié)束，然后就可以完全忘記工作。但在這不是的。你很可能一直在線并查看代碼，即使是在深夜。
• 你很少會有時間做自己喜歡的事情。而且通常情況下，這是一項需要完成的乏味工作。
• 職業(yè)發(fā)展機會有限。即使你是一名優(yōu)秀的員工，在公司里也可能沒有提升的空間。
• 壓力的環(huán)境。最后期限、bug和滿足客戶期望的壓力都會導(dǎo)致壓力倍增。
• 遠程工作可能導(dǎo)致孤立。根據(jù)公司和團隊結(jié)構(gòu)的不同，軟件工程師可能會長時間獨處（不包括視頻通話），導(dǎo)致缺乏真正的社交互動。
• 工作保障有限。隨著技術(shù)的不斷發(fā)展，軟件工程師可能會面臨被更新、更高效的技術(shù)取代的風險。

美學(xué)是教不來的

大學(xué)課程教會了我們做出優(yōu)秀代碼的基礎(chǔ)知識，但是軟件開發(fā)中的真正美學(xué)是無法在課堂上教授的。

軟件開發(fā)中的美學(xué)是指代碼的整體外觀和感覺。關(guān)鍵在于它是否易于閱讀、理解和維護。美觀的代碼是干凈、有組織并遵循邏輯模式的代碼。這是一種讓你在看到它的時候感覺優(yōu)雅的代碼。或者在糟糕的時候讓你畏縮。

不幸的是，美學(xué)不能在一個學(xué)期的課程中教授。它是通過經(jīng)驗、閱讀大量好代碼和維護壞代碼獲得的。

經(jīng)理們都喜歡數(shù)字、估算，以及用寫在餐巾上的想法來要求估算。這就是現(xiàn)實世界的運作方式——企業(yè)有一些利潤目標，但在批準立項之前，他們需要了解成本。

在大學(xué)里很難傳授這一點，因為準確性高度取決于你構(gòu)建系統(tǒng)的經(jīng)驗。你多年來解決的問題越多，就越容易估計未來的工作。

圖片

我不打算討論做估算的最佳方法；有很多方法可以做到。但我要說的是，估算是企業(yè)唯一能理解的東西。如果你開始談?wù)摗拔覀冇虚L期計劃，但我不知道我們什么時候能完成”，那么在這種前提下，公司很難生存。

在Mindnow，我們通常會粗略地估算整個項目，以估算需要分配多少預(yù)算——這是長期的優(yōu)先事項。然后，我們開始基于沖刺的計劃，整個團隊討論、確定優(yōu)先級并提交到短期可交付成果中，使我們更接近長期優(yōu)先級。

即使你不想給出估算，但還是會有人問你

經(jīng)理們都喜歡數(shù)字、估算，以及用寫在餐巾上的想法來要求估算。這就是現(xiàn)實世界的運作方式——企業(yè)有一些利潤目標，但在批準立項之前，他們需要了解成本。在大學(xué)里很難傳授這一點，因為準確性高度取決于你構(gòu)建系統(tǒng)的經(jīng)驗。你多年來解決的問題越多，就越容易估計未來的工作。

圖片

我不打算討論做估算的最佳方法；有很多方法可以做到。但我要說的是，估算是企業(yè)唯一能理解的東西。如果你開始談?wù)摗拔覀冇虚L期計劃，但我不知道我們什么時候能完成”，那么在這種前提下，公司很難生存。在Mindnow，我們通常會粗略地估算整個項目，以估算需要分配多少預(yù)算——這是長期的優(yōu)先事項。然后，我們開始基于沖刺的計劃，整個團隊討論、確定優(yōu)先級并提交到短期可交付成果中，使我們更接近長期優(yōu)先級。

并非所有的會議都是無用的

既然，軟件工程師的工作并不是花大量時間寫代碼，那時間都去哪了呢？答案——會議。

會議的目的是確保一切進展順利，按時進行。他們讓人們圍繞一個共同的目標保持一致，并讓每個人都走上正軌。市場營銷部門知道有些東西正在開發(fā)中，他們可以為功能的最終發(fā)布做準備。項目經(jīng)理了解開發(fā)人員的工作方向，并在需要時進行微小的修正。客戶支持帶來了最終用戶的反饋。質(zhì)量保證部門分享他們發(fā)現(xiàn)的問題。管理層分享利益相關(guān)方的最新情況。

圖片

所有這些都是相互關(guān)聯(lián)的，而會議是信息共享的場所。作為一名軟件工程師，需要對這種信息共享的一部分負有責任，因此阻礙它是不負責任的。雖然你可能不喜歡這樣，但是必須共享信息以保持系統(tǒng)的效率。

結(jié)論

如果你正在考慮從事軟件工程師的職業(yè)，請準備好面對這些事實并擁抱這成長的機會。你不太可能給世界帶來多么有意義的改變，但說到底，這只是一份工作，你可以通過其他方式做出有意義的貢獻。

最重要的是——不忘初心，享受工作。