程式設計師和開發人員通常可以互換使用,但它們之間有一個重要的區別:開發人員的更廣泛的視角和關注點不僅僅是程式碼。在本文中,我們將從編碼中退一步,重點介紹定義成功開發人員應具備的技能。
大多數人都知道這兩個術語是同義詞,而且確實是同義詞。但是,如果您在 Google 上搜尋,您會發現其中存在差異。差別不在於他們如何處理程式碼,而是他們對工作和軟體開發的看法。
| |程式設計師|開發商|
|----------------|--------------------|----------- - ---------|
|關注|實施 |解決問題 |
|建立|程式碼|解決方案 |
|參與|開發與測試|完整的 DevOps 生命週期 |
|與 | 一起工作程式碼|程式碼和人|
|承擔責任|程式碼 |產品|
上表顯示了程式設計師和成熟的開發人員可以擁有的不同觀點。程式設計師的視野很狹窄,專注於程式碼及其直接環境:使用適當的架構編寫乾淨的程式碼,對其進行徹底測試,然後將其交付給下一個部門或直接投入生產。
然而,軟體開發人員對開發有更廣泛的看法。這不僅僅是編寫程式碼;這是關於協作建構解決客戶問題的產品。這很少涉及單一團隊,而是整個 DevOps 生命週期中的許多團隊,從規劃階段一直到監控已部署的產品。
開發營運生命週期
這並不一定意味著開發人員正在整個 DevOps 鏈上運作。重要的是開發人員了解並參與整個生命週期,並積極嘗試改進和優化流程。它還可以在其他團隊需要幫助時提供幫助,以便整個組織可以提供優質的產品。
查看整個產品解決方案至關重要
讓我們從軟體開發人員需要具備的最明顯的技能開始—即使是程式設計師也應該具備的技能:架構。儘管這似乎是顯而易見的,但由於其重要性以及許多人忽視它的事實,值得強調。
軟體開發中常見的角色是架構師。一個容易犯的錯誤是認為團隊架構師獨自負責團隊擁有的所有應用程式的架構,但這根本不是事實。每個開發人員都應該為改進程式碼架構做出貢獻,因此必須了解並實踐它。雖然架構師在更高、更廣泛的層面上工作,但所有開發人員都有責任保持程式碼整潔。
所有語言和框架都有最佳實踐和反模式。它們有所不同,並隨著時間的推移而變化。例如,我去年關於React 中該做和不該做的文章仍然高度相關,但隨著 React 19 中的新編譯器,這 17 條規則中的某些規則將變得過時。
重要的是要記住,在開始使用新語言或框架時,始終要研究最佳實踐和反模式。這些小時的閱讀可以節省大量時間,否則這些時間將花在除錯和重構上。在極端情況下,我們談論的是節省數月甚至數年的開發時間。
設計模式在架構中扮演重要角色。好程式碼和壞程式碼的區別通常在於設計模式的使用。大多數設計模式與語言無關,這意味著無論您使用什麼語言或框架,都可以使用它們。此外,每個框架都有自己的一套設計模式,並且建立在消費者應該遵循的模式之上。
最著名的通用設計模式之一是 SOLID。它是一種適用於大多數框架的通用設計模式。一些框架已經基於它,這些框架的用戶將自動遵循該模式。其他框架可以從中受益,儘管如何適應它並不總是顯而易見的。例如,React 不會自動遵循 SOLID 原則,但如果您了解 SOLID 原則如何運作,您也可以將它們應用到 React 中。
React 也是特定於框架的設計模式的一個很好的例子,其中有渲染道具、自訂鉤子模式和高階元件等模式。
關鍵點有兩個:花時間學習一般的設計模式,並確保在開始使用新框架時找到特定框架的設計模式。
一般來說,設計模式使程式碼更加:
可讀的
可測試的
模組化的
強壯的
DRY(不要重複自己)
這些方面對於編寫可重複使用程式碼和與同事協作是必要的。設計模式也有助於防止錯誤。
設計模式不完全防錯
作為開發人員,您最常建立更大系統的一部分。如果沒有與其他團隊進行適當的溝通來確保您的軟體與系統的其他部分相容,您的部分就會變得毫無用處。如果您自己的團隊內部沒有溝通,您甚至無法按時完成元件。
溝通在每個專案中都至關重要。不幸的是,這非常具有挑戰性。我可以寫很多關於溝通困難以及如何有效溝通的文章,但這不是我今天的重點。
現在,請記住,溝通是開發人員工作的重要組成部分,它與精通編碼一樣重要。如果您想了解更多訊息,我確實提供了有關如何在大型組織中進行有效溝通的其他技巧。
{% 嵌入 https://dev.to/perssondennis/the-art-of-code-review-and-why-you-need-it-4b9m %}
在我早期,當我與某些個人和團隊溝通時遇到困難時,我的第一個反應通常是提供超級清晰的指示並密切跟踪流程以確保其他人完成任務。當這不起作用時,我最終會放棄並自己完成工作以完成它。
就在那時我意識到最好的溝通方式是在根本不需要的時候。如果沒有什麼需要溝通的,就不會有任何溝通問題。
這裡有一個重要的細節:我並不是建議你應該跳過溝通而自己做別人的工作。相反,我是說工作應該以最小化溝通需求的方式劃分為不同的領域。
在建立團隊時,人們通常會談論跨職能團隊,即擁有開發、部署和監控產品所需的所有能力且不依賴其他團隊的團隊。
跨職能團隊通常指的是擁有自組織的知識和技能,這意味著他們擁有管理其依賴關係所需的所有專業知識。
再說一遍,本文要介紹的內容很多,因此我不會深入探討這個主題。如果您有興趣,可以在我的另一篇文章中閱讀有關消除依賴性的更多訊息,其中也涵蓋了團隊協作和溝通的類似技巧。
溝通的一個重要部分是知道什麼時候不溝通
團隊建立這個詞最常與有趣的活動和偶爾的下班後聚會聯繫在一起。雖然這些絕對是團隊建立的重要方面,但它們遠非全部。
你的團隊有共同的目標嗎?你們同意如何處理程式碼審查嗎?您知道為什麼您的團隊從不在團隊的 Slack 頻道中回答問題嗎?如果這些問題的答案是否定的,那麼您還沒有完全建立一個團隊。
團隊建立應該是討論想法、解決衝突和分歧,並找到整個團隊都同意的共同工作方式。這是關於分享知識和經驗,以便所有隊友都能輕鬆地與團隊合作並面對即將推出的功能和錯誤。這是為了幫助團隊成員獨立和協作地工作。
實現這一目標的方法通常涉及會議。這些不一定是有嚴格議程的正式會議,但必須有團隊聚集在一起溝通的場合。有些討論可能需要整整一個小時,而其他主題可以在小型同步會議期間解決。
例如,討論對程式碼審查的期望的好時機是在實際程式碼審查期間!不要只討論如何更改程式碼,而要確保討論您認為需要更改的原因。為什麼你認為這很重要?
最後一點-團隊建立是針對整個團隊的。雖然 Scrum Master 和團隊領導等某些角色肩負著建立團隊的責任,但他們並不是唯一應該努力改進團隊的人。建立團隊是團隊合作,而不是一個人的任務。
即使是超級英雄也需要團隊
你是否曾被某個問題困擾過?您曾尋求幫助但沒有人有時間提供協助嗎?你是否覺得沒有人聽你說的話,儘管後來證明你是對的?為什麼會出現這種情況?
人們通常很忙,不可能總是考慮每個人的意見。你需要做的就是讓別人聽到你的聲音。通常,這樣做的方法是大聲並自信地聲明您的解決方案或問題是需要考慮的。
然而,並不是每個人都願意這麼做。幸運的是,還有另一種方法可以讓別人聽到你的聲音——找一個即使在你低聲說話時也能聽你說話的人。
當你需要幫助時,誰是最有可能幫助你的人?這是家人、朋友和熟人。人們很少會幫助陌生人,尤其是當這意味著要承擔額外的工作時。
透過建立人脈並結交朋友,您會發現自己可以更頻繁、更快地獲得幫助。人們優先考慮幫助朋友,既因為這是他們喜歡的人,也因為拒絕朋友更困難。
交朋友的難易度因人而異,但每個人都有機會。只需在排隊喝咖啡時向某人發表簡短的評論或提出問題,或與設計師討論您在 Figma 設計中想知道的事情,而不是猜測或發送 Slack 訊息。無論你做什麼,都不要要求其他人替你與某人交談,否則你就錯過了一個新朋友。
最後,你不需要和每個人都成為最好的朋友,他們才能幫助你。只需與某人交談五分鐘就足以讓他們將您視為他們認識的人以及他們想要尊重和禮貌的人。
越多越好
每個人都知道著名的「某人」。一旦事情沒有解決,總是「某人」的錯。 「有人」應該處理這件事。
但這人是誰?不幸的是,通常很難辨識它們,這就是為什麼需要討論責任以及誰應該做這項工作。有趣的是,通常情況下,負責人應該做這項工作。
負責任的真正意義是什麼?負責其實並不意味著你必須自己完成工作,而是意味著對你的期望是完成工作。您完全可以將整個任務委託給其他人,讓他們承擔責任。
真正的責任涉及確保成功的承諾,但也要求鼓勵其他人為這一目標做出貢獻。科技公司的執行長有很多責任,但最終,這將是一個由開發人員、經理和其他實際工作來開發產品的人員組成的整個組織。
同樣,團隊中的架構師負責確保團隊在編寫程式碼時擁有並遵循架構指南。然而,這並不意味著架構師的工作是編寫所有程式碼,甚至定義架構的每個面向。整個開發團隊應該協作提高程式碼品質並遵守商定的模式和實踐。
關於責任的一個有趣的事情是,它通常可以委託給其他人。然而,一旦這樣做,責任通常由委派責任的人承擔;只是處理轉移的工作的責任。這意味著,如果出現問題,專案失敗或延遲,那麼責任人就必須承擔責任。
有時候,這其實是每個人的責任
不是每個人都喜歡工作中那個能令人驚奇地為每個人解決所有問題的人嗎?嗯,我也這樣做,但我知道這不是最佳行為。
承擔別人的工作只會造成人們依賴他人來完成任務的循環。當優秀員工辭職的那一天,整個團隊甚至多個團隊都會發現自己陷入了困境。
不要為別人做這些工作,而是花時間指導他們如何自己處理。儘管最初可能需要更長的時間,但一旦它們能夠自給自足,您將節省大量時間和精力。
雖然您不應該為他人做工作,但這並不意味著您應該避免直接職責以外的任務。請記住,工作不應該僅僅落在負責人的身上,該人可以委派任務,以便每個人都可以為完成任務做出貢獻。
然而,任務有不同類型。如果你負責某件事,那麼工作量很可能比一個人單獨完成的還要多。在這種情況下,委派至關重要,但決定委派什麼取決於任務的性質。如果這是一項小型的一次性任務,請避免將其委託給其他人,因為解釋可能比自己完成它需要更長的時間。
對於耗時或重複的任務,請將其視為委派的候選人。在這裡,您應該權衡委派的含義:如果一項任務很關鍵,您可能會選擇親自處理它,即使分配它會節省大量時間。
偶爾徵求許可並仔細檢查你所做的事情是否受到讚賞是很好的做法,這樣你就不會花一個月的時間做一些完全不必要的事情。但每天都要戒掉它。
正如團隊應該是自組織的一樣,作為開發人員,您也必須能夠照顧好自己。你不可能有一個經理或團隊領導總是告訴你今天應該做什麼或如何解決每個問題。
你應該做的是自己弄清楚這一點。這並不意味著您不能與任何人交談。請記住,溝通是發展的重要組成部分。如果您不確定或正在處理更大的任務,請與您的開發團隊討論以了解他們的想法。確保清楚描述問題並提出一些您想到的潛在解決方案。
你看到這裡的差異了嗎?不同之處在於您是與您的開發團隊一起工作;你們共同負責開發你們的產品。如果你是一個八人團隊,那麼你就有八個大腦,可以幫助你做出正確的決定。如果你去找團隊領導詢問該怎麼做,那麼你基本上就忽略了自己做決定的意願,並將所有責任都推到了一個人的身上。這不是解決問題的好方法。
當然,你會犯錯。忍受這一點。這就是生命長大的路。這不只是一句「殺不死你的會讓你變得更強大」的話。
如果您閱讀了我在交流章節中連結的文章,您應該已經看到了學習金字塔。然後您可能會注意到,您在教別人時學到的內容的保留率高達 90%,而您閱讀的內容的保留率僅為 10%。
根據學習金字塔,你教別人的內容你記住了 90%
令人驚訝的是,這個金字塔告訴您,當您的目的是教導別人時,您是學得最多的人。接下來,你將透過練習做些什麼學到最多的東西。
請注意這與我們在此討論的其他主題如何一致,即參與解決問題、建立團隊以及停止向他人詢問該怎麼做。所有這些的基礎是採取行動並積極致力於改進團隊並提出問題的解決方案。這些行動涉及小組討論、練習解決問題和教導他人,所有這些都位於學習金字塔的底部。
相反,如果你只接受別人的命令,只聽他們說的話,閱讀他們如何解決問題或編寫他們告訴你寫的程式碼,那麼你純粹是在金字塔的頂端工作,這意味著你透過閱讀、聆聽和觀看演示來學習的效率非常低。
作為教導他人的好處,你將面臨最棘手的問題。當你不知道別人問你的問題的答案時,你可能會抓狂或感到尷尬,但幾年後,你將成為知道這一切的人。
{% 嵌入 https://dev.to/perssondennis/ Three-simple-rules-to-solve-unsolvable-organizational-problems-3o3n %}
我們現在討論了開發人員需要的一些技術技能,以及一些如何處理溝通和與他人互動的軟技能——這些技能對於如何與他人互動非常重要。
我們還沒討論的是你是誰──你的個人特質決定了你是誰。這些可能很難更改,但您可能不需要這樣做。正如我們將看到的,最重要的部分是在需要調整它們時學習。
當談論個性時,特質是個性的特徵。有許多模型試圖模擬人類性格,其中 DISC、MBTI(邁爾斯-布里格斯類型指標)和大五模型是最著名的模型。
DISC模型是一個非常簡單的模型,它將人分為四種不同的性格,我們不會在本文中深入探討。
DISC人格模型
MBTI 更進一步,將人們分成 16 組。這是一個非常流行且經過研究的人格模型,但它並沒有被科學所接受。
MBTI人格模型
科學界普遍更喜歡大五理論。大五與MBTI類似,它包括外向與內向以及其他四個特徵。
大五人格模型
MBTI和大五是兩個相當相似的模型,大五之所以被科學地接受,並不是因為大五有更好的特質;而是因為大五有更好的特質。這是因為它在一定程度上定義了人。
大五人格並沒有對人進行分類,它聲稱人類比 16 種人格更複雜,並且每個特徵都有一個等級。這意味著一個人不一定是外向或內向;他們可能介於兩者之間,這被稱為中間性格。
大五代表了規模上的個人特徵
如果我們遵循為人類的每個特徵建立一個量表的想法,我們就可以開始判斷特定特徵是好還是壞。讓我們以完美主義為例。
完美主義者有很多種類型:自我導向的、他人導向的、社會規定的等等。聽起來不太吸引人,不是嗎?
就我個人而言,我看到完美主義存在著許多問題。坦白說,我自己也曾是這樣的人,但我努力擺脫它。儘管如此,我不能說這是一件應該避免的壞事。事實上,有時它是非常有益的;例如,當作為一個擁有數百或數千開發人員的大公司的高級架構師時,那麼有必要成為完美主義者。
這裡的問題是,沒有一致的好或壞特徵。每個特徵都有其自身的優點和缺點。一個特質的好壞取決於你所處的情況。
比如說,以建築師為例。我聲稱完美主義對於大公司的高級架構師來說是一個很好的品質。然而,在一家新創公司中,真正的完美主義者是不可取的。新創公司最注重的是速度和敏捷性。您需要快速與客戶進行迭代,以找出他們的需求,並且您需要比競爭對手更快、在資金用完之前做到這一點。
根據您的角色,您可能需要專注於品質或速度
一般來說,在任何領域成為極端分子都很少有好處。無論是外向或內向、宗教信仰或政治觀點,處於任何範圍的遠端都會帶來挑戰。讓事情變得複雜一點的是,嚴格平均也沒有好處。獨特的技能通常對於完成生活中的事情至關重要。
事實是,理想的人不能用固定的標準來確定。相反,它們有能力存在於沿線的任何地方。這樣的人完全了解自己的行為,並且能根據當前情況進行調整。這種適應性不僅取決於任務,還取決於與之互動的人的特徵 - 請記住,與他人的有效溝通至關重要。
即使在同一角色中,您也可能需要根據任務採取不同的行動
想想彼得·帕克。你會如何形容他的性格?你會用描述蜘蛛人的方式來描述它嗎?
有時你必須成為其他人(是的,那應該是彼得·帕克)
{% 嵌入 https://dev.to/perssondennis %}