編程語言的選擇應該是團隊決策還是管理決策？

Question

我剛剛和我的一位員工討論了部門編程語言標準。他認爲編程語言的選擇應該與項目團隊一起駐留。我覺得管理層應該對使用什麼語言做出全面的決定。如果考慮到團隊的願望，兩種語言是否符合項目標準？我很想聽聽大家對此的體驗。

Answer 1

如果他們說「我們想用這種語言」，我認爲團隊士氣會遭受相當可怕的折磨。管理層說「不，你必須改用這種語言。」

它確實需要一個聯合決定，每個人都需要支持他們的推理。

Answer 2

是的。 兩組都應該有輸入。 許多不同的方面也需要被優先考慮，儘管這可能是一個重要的方面。工作市場（僱用新人工作的能力），語言支持，工具等。

Answer 3

你必須考慮到團隊，他們是那些會成功的人。如果他們不會/不能用這種語言工作，那麼它會讓項目變得非常困難。

顯然管理將有最後的發言權，這是管理的目的，但他們必須考慮團隊的偏好/建議。我認爲他們必須有一個真的很好的理由不選擇團隊建議的語言

Answer 4

如果你的程序員比Java更優於Java，那麼使用Java是有意義的，如果其中任何一個將工作。與在該級別的任何決定一樣，管理層可能有理由選擇其中一個。他們應該聽取團隊的意見，但最終的決定應該是他們的。

Answer 5

我覺得開發者確實應該在所選語言中有發言權。總的來說，管理者似乎有一種習慣用「流行語」去做。 （好）程序員希望知道最好的工作語言，這是基於管理層可能缺乏的多年經驗的一種觀點。

Answer 6

請記住，管理層在編程團隊繼續前進時會保留代碼，並且他們還需要聘請新的編碼人員以在將來進行維護。所以，如果團隊想要選擇erlang或haskell，那麼管理層有責任讓公司拒絕。 （對不起，選擇erlang和haskell開發者，但並不是你們中的很多人）。

一般而言，這就是問題所在 - 團隊希望以某種方式使用某些有益於他們的事物，但重點應放在公司代碼的未來，並由公司支付（即您的工資）。他們需要確保將來可以支持。

他們也會爲你的培訓付出代價，所以它的管理很重要。

團隊可以提出建議並嘗試影響決策，我相信除了最糟糕的公司之外，所有公司都會認真聽取團隊的意見，但管理層最終會做出決定。

Answer 7

當然，團隊的投入很重要。如果您對應用程序的主要架構作出決定，並且團隊認爲他們沒有參與其中，那麼您將面臨道德問題。這個決定最終應由管理層（假設管理層是技術性的）和主要建築師和管理層做出。

但是選擇語言時要記住的一點是，當團隊對您的選擇更加熟悉和滿意時，您的成功率會更高。如果你聽他們說什麼，然後以具體的商業和技術理由來找他們，爲什麼你沒有選擇他們，那麼至少他們會聽到他們聽到的謊言，並且是這個過程的一部分。

Answer 8

與生活中的大多數事情一樣，必須在個人（每個團隊成員）或組織（應該成爲管理者的關注點）的好/樂之間達成平衡。

Answer 9

我在工作場所，管理層的經驗與技術團隊進行了討論，技術團隊就編程語言提出了我們熟悉和最好的工作方面的建議。然後管理層決定部門使用的編程語言。 它應該雙向工作，因爲技術團隊必須能夠熟練地使用編程語言（以便能夠按計劃交付），並且對於管理層，他們可以針對業務中的中長期計劃，資源管理和培訓。

Answer 10

球隊 - 毫無疑問，

Answer 11

一個好的項目經理將讓他的資深工程師做出這個決定，做他的工作：管理項目，即從「上位 - 管理 - 屏蔽開發團隊BS」。一位優秀的項目經理還需要他的高級工程師詳細論證爲什麼他們使用特定的編程語言（如果語言的選擇非常重要）。如果他對理由不滿意，我認爲將他們的開發團隊引導到每個人都可以生活和工作的方向是他/她的工作。在開發團隊中強制使用一種語言？不是一個好主意。該項目將註定要失敗。

Answer 12

在我看來，這很大程度上取決於情況。

當然，你應該考慮他們的願望，但要考慮的一件大事就是團隊最具生產力的語言是什麼。另外一個有時看不到的語言是誰將維護項目長遠來看，他們的能力是什麼？

最後一個對我來說是一個很大的問題，一個程序員往往會在一些奇怪的方向上使用一些邊緣案例技術，主要是因爲他/她想要「嘗試」或者因爲它是新的和熱門的。在這些情況下，可維護性往往被人遺忘，一旦程序員不在了，而其他人不得不去維護項目，那麼可維護性往往會被大大地遺忘。

另一方面，如果您的團隊對此感到非常強烈，是否值得引起分歧？

所以，在一天結束時，這取決於你的情況以及它是什麼類型的項目。

Answer 13

我認爲這兩種方法都存在危險。程序員可能傾向於使用酷酷且有趣的即將到來的技術，管理層可能會使用大量銷售或商業化的技術（但不受反微軟開發團隊的歡迎））。

需要有人擔任架構師角色，可以與兩個團隊聯繫，並根據業務目標以及開發人員的關注做出客觀決策。這個人需要了解系統的總體目標，衡量客戶所需的基礎設施，穩健性和技術支持。等等......當然這取決於公司/項目的規模對這些決策的影響。

Answer 14

同意其他海報，它應該是一個聯合決定。但是 - 通常管理層必須從長遠角度考慮，而不僅僅是項目團隊，例如正在進行的維護工作。所以軟件的使用壽命可能是一個因素。如果球隊選擇了一些不是主流的東西，他們總是會在他們手中爭鬥。

此外，最後的說法通常屬於客戶。如果項目是內部的，那麼客戶可能只是本地管理/技術。對於其他客戶，團隊需要一些非常誘人的理由來推翻他們的願望。

Answer 15

真正的問題是什麼是選擇了另一種語言的好處：

• 功能：什麼能得到這份工作 無論是現在還是做得比較好的，並在未來 ？這項技術 決定證明這個項目的未來堅實的決定 和 我是否甚至在乎（當然從一個 管理職位）？

• 費用：我需要爲此 技術選擇購買額外的 硬件或軟件嗎？我想成爲 卡在那個硬件/軟件？ 開發人員是否精通 建議的技術或 我需要僱傭新鮮血液？

• 時間：需要多少時間才能使用 這項技術？我要去 不得不培訓人們使用這個？

問題的實質是管理層應該提出這些問題，發展應該成爲他們的探討者。

Answer 16

對不起 - 但在其他工程分支中，這甚至會成爲一個問題？ 波音的設計師決定使用火箭發動機代替渦扇發動機會更酷？

Answer 17

這實際上是一個變相的「信任」問題。

當管理層信任時，選擇是毫不費力的（讓專家技術人員決定）。

我建議任何團隊都要審視潛在的信任問題，而不是僅僅關注語言問題。

專注於根本原因，結果/症狀會自行解決。

Answer 18

您的首要問題應該是該語言是否能勝任這項工作。馬克吐溫說：「對於一個用錘子的男人來說，一切都看起來像釘子。」所以，僅僅因爲團隊熟悉一種語言，並不意味着它是最好的工具。另一方面，熟悉語言和領域專家的開發人員使用自己的工具可以提高生產力。

第二個問題是開發人員的可用性。當團隊繼續前進時，誰還會支持它？僱用或重新培訓一種晦澀的語言可能代價高昂。該語言也可能是新的，開發者基礎可能無法實現。

第三個問題是該工具的可用性/穩定性。每次語言改變時你都必須不斷重寫（我正在考慮VB/.Net）。另外，誰在支持它？如果供應商放棄它，該語言會發生什麼？

那麼簡短的答案是，如果團隊有偏好，他們應該爲他們的選擇提出強有力的論據;這足以說服老闆說推銷員的回扣不值得花錢。試着理解管理層的推理，如果你不能反駁它，你可以接受這個決定。

Answer 19

項目語言的選擇應包括團隊偏好，而不是覆蓋項目及其環境的正確選擇。

編程團隊應該比管理團隊擁有更多的短名單上的語言經驗，因爲這是他們聘用的，並且應該在技術上更好地判斷哪些技術更適合他們使用。

只有當管理團隊的選擇至少具備資質和經驗時，他們纔會試圖影響團隊的合作選擇，除非選擇對技術業務有非商業影響，並且應該考慮這些影響。

良好的管理讓我們這是員工做他們聘請他們做的事情，並在他們可以的地方進行設計，所以恕我直言，選擇應該委派給編程團隊。

一個快樂的編程團隊將會提高生產力，最終取得更好的結果，如果他們在選擇時遇到困難，不會抱怨。

管理層應該更關心在預算範圍內按時完成最終項目，並取得積極成果，然後使用哪些技術，除非這些選擇具有需要解決的特定業務影響。

編程團隊成員和管理團隊成員都在同一個團隊中，應該考慮每個人的需求，包括編程團隊成員最舒適的使用和思考哪些技術最適合每個項目，恕我直言，這應該是一個首要考慮因素僅僅是業務需求或事實技術考慮。

只是爲了證明有效的商業理由不支持編程團隊的選擇，可能是因爲技術不夠主流，無法讓團隊成員以合理的成本從合理規模的池或簡單接口轉換爲當前或計劃資源。

Answer 20

最終，它必須是管理層的選擇，因爲他們承擔程序員離開後的後果負擔，並且代表公司在選擇中的利益。語言選擇不僅要考慮當前的編程團隊的能力/技能集，還要考慮所有未來的成員和任何支持人員的可銷售技能。如果這意味着你找不到合格的人來支持它，你不想選擇太模糊的語言。此外，如果語言接近流行/支持生活的結束，那麼它就有可能過早地被重寫，而不是被期望。

我做了一個廣泛的假設，即語言選擇類型的可維護性，能力和類型沒有根本不同（即ML與C++）。所有這些說法，如果牢記這些因素，並且語言選擇在平等的基礎上，那麼使用團隊的語言選擇對於士氣是最好的，並且會導致更好的產品而不影響長期長期的應用前景。

Answer 21

考慮語言。如果它是一個易於編程的編程位置（也就是說，如果您可以在一週內僱用某人來填補其中一位程序員的工作 - 他們是否應該離開），那麼請遵循團隊的建議。如果你給他們這樣的話，你不會相信他們會做多少工作。否則，您可能需要填寫多個職位。不要賭注糟糕的經濟，讓軟件開發人員留在他們的座位上。這實際上是一個完美的時間去逛逛。保持他們的快樂，但要確保語言的選擇不是一些晦澀難懂的語言。

Answer 22

我一定會諮詢當時正在開發的團隊。給他們設計文檔並獲得他們的反饋。這至少讓他們覺得自己的決定很重要。

管理人員需要考慮其他事情，例如，所選語言的培訓人員的成本，購買IDE的成本（如果需要），初始開發完成後的代碼庫維護成本。

在經理做出明智決定之後，開發人員應該感覺他們能夠問爲什麼做出特定決定。將決定留給管理層，但是要提高決策的透明度。

Answer 23

這個問題有很多。最後，爲工作付費的人做出選擇。但是：

• 除非管理層比他們僱用的人更聰明，他們應該考慮他們的意見。管理層通常不會向編碼人員解釋，與每種語言選擇相關的費用可能會使其他選擇更加令人滿意。當他們認爲他們的建議被忽略時，這會在編碼員身上滋生怨恨。

• 有相當數量的人有嚴重缺陷的判斷力。他們只知道一種語言，所以他們只推薦一種語言。管理層可能已經做出了決定，並會忽視員工的良好建議。編碼器或管理人員可能是過度的技術人員，即使他們不符合項目的最佳利益，他們也會接受技術解決方案。他們也可能有強烈的意見，情緒成熟度不足以讓其他人不同意。

• 員工也可能故意提出不符合項目所有者最佳利益的事情，因爲他們認爲這符合他們自己的最佳利益。

大多數情況下，我認爲這些選擇是出於情感原因而不是理性選擇。

Answer 24

有趣的是，編程語言的選擇對於管理來說應該是一個如此重要的問題，而依賴於精心製作的開源庫或框架通常會在沒有多少考慮的情況下完成。

從歷史上看，這裏有一些邏輯，因爲改變編程語言意味着改變平臺，但是現在編程語言標準化運行在CLR或JVM平臺上，共享庫和部署環境，多樣化成本使用不同的語言可能會比取決於複雜框架的語言少。例如，如果您的應用程序需要規則引擎，那麼使用JVM版本的prolog可能會更好，而不是依賴於某些模糊的Java規則引擎API。