[[234990]]

如果您是團隊領導者、項目經理或開發人員，您可能會遇到以下問題。以下是我們解決這些問題的方法方法。

時間估計錯誤

在軟件開發中最常見的困難之一是任務估計。我們可以找到許多原因，但是，在我們看來，主要的原因是每個人都在說謊。不管它聽起來多么荒謬。開發人員將估計值(在他們看來是真實的)乘以3。然后經理們將其加倍。之后，他們的領導將會增加三倍的估計，同時老板也懷疑這樣是否能在最后期限前完成任務。

有很多人試圖將這一過程正式化，排除人為因素，但總的來說，沒有什么好的辦法，僅僅通過跟開發者直接打交道的有經驗的人自行判斷。目前最有效的方案使用條件度量單位，也稱為故事點(story point)。

但即使在這種方法中也存在缺陷——相互欺騙也在繼續。老前輩們告訴新來者的第一件事是，他們的假定的計量鸚鵡(或一個故事點)包含了大約5個小時的開發，你應該這樣評估——通過將時間估計除以5。這就是謊言的開始。

每個人都在頭腦中按小時對任務進行評估，然后通過簡單的數學運算，把它變成故事點。在那之后，每個人都聚精會神地盯著同事們，心里想，到底是計量鸚鵡的數量太少了(還是反過來說，太大了)。然后改變它以滿足同事和經理的期望。一遍一遍這樣的重復。

[[234991]]

代碼評估標準

您對團隊中的代碼審查有什么感覺?您是否支持定期的代碼評審，或者只是走走形式就可以了?總結軟件開發中的最佳實踐，我們注意到人們都非常關注代碼的清潔度。但是如何理解這個程序是否足夠好呢?

在日常的開發過程中，確定當前正在編寫的代碼有多好成為一個巨大的挑戰。這并不是因為開發人員不夠聰明。簡單的事實是，可想而知，當前開發人員創建的代碼已經是最好的代碼，否則他不會這樣編寫。通常，他們會這樣狡辯，“代碼中可能有一些不太漂亮的部分，但是當時沒有別的辦法”，我們都很熟悉的這樣爭論的后果。

有一種自檢代碼的技術，在這種技術中，仍然不可能檢測到您的代碼中的所有缺陷，但是，可以將它們中的大多數都捕獲。它們是一組“石蕊試紙”(如果你愿意的話，可以是認作是“觸發器”)，在編寫代碼時，你應該記住它們。以下是其中的一些:

是否能容易的測試你的代碼?如果在編寫測試時遇到問題，那么這里的某些東西就像是糟糕的代碼。

這段代碼容易縱向擴展嗎?我們不是要同時運行幾個應用程序，而是要將實體添加到上面的級別。像“company_id”或其他。

很容易為某個方法或變量想出一個名字嗎?如果命名有困難，要經過深思熟慮，那么很可能它的代碼也不是很清晰。

你需要重新定義多少種方法?有很多邊界條件需要處理嗎?或者，在一般情況下:規則是怎樣的，你的功能是建立在什么基礎上的，你有多少例外的規則?這里講的不是有太多的業務邏輯，而是一個正確選擇的體系結構和代碼結構。如果在系統中發現了一個bug，并且您可以通過添加一個有條件的分支來修復它，那么這個bug并不是從頭開始出現的，而是從組織不正確的代碼結構中出現的。

有很多這樣的標準，但有些不能像這樣公式化，而且在每個特定的項目中，要求可能會有所不同。此外，一個優秀的開發人員在他的潛意識中已經有了一套這樣的標準，并通過它們能精確地嗅一段有異味的代碼。試著在工作中為自己制定這些標準，并不斷完善它。除了能夠要準確的歸納爛代碼特征外，我們還需要一個很棒的自測試工具，因為在編寫代碼6個月之后，您的代碼就會開始腐敗，而新標準和規則能夠發現這些問題。

對臨時解決方案說不

由于不同的原因，當前有一些解決方案可能比正確的方案更可取:所需的時間更少、代碼更簡單、設計更簡化等等。有些開發人員傾向于使用這樣的技巧來搞定特定的任務完成實現或趕上最后期限。但是，這種臨時解決方案可能會使用很多年，不需要更改，它會與應用程序的其他部分緊密地交織在一起，因此很難替換它。事實證明，這種臨時方案是推遲了一個不確定的未來的任務，而最終忘記了它。這種債務的數量隨著時間的增加而增加。

當然，有時妥協是必要的，我們也一直都這樣做，但不要認為這樣的解決方案是暫時的，就可以暫時放棄你的原則。

記住:不存在臨時代碼。當檢查并添加部分代碼到應用程序中，要想到它將永遠留在那里。堅守這個底線，你會發現臨時代碼的數量會驟然減少，這將使您的代碼對其他團隊成員來說更加清晰易懂。

招聘好的團隊球員

當你召集一個團隊在一個項目上共同工作時，你應該確定一個人是否是一個好的團隊成員，他的技能和個人素質是否適合于開發工作。知道如何從候選人中挑出一個不合適的人，這對你的項目管理成功至關重要。每個公司的人力資源都有自己的方法和技巧來實現這個目標，但是有沒有統一的算法來避免在招聘員工時出錯呢?

在我們看來，軍隊中有一個很好的標準，用這個標準來區分好士兵和壞士兵并不難。你可以想象這樣一句話:“我不會和他一起去探險的”。

實際上，當被問及戰斗伙伴如何組隊時，標準可能會有很大的不同，而這些標準的不同取決于所獲得的優勢和經驗。對某些人來說，重要的是他的搭檔是否是好的射手，跑得快。而另一些人要的是尋找一個沉默寡言，烹飪美味的人。還有人是需要一個不怕蛇并且能夠控制戰斗直升機的人。我們試圖創建一個通用的戰士所需品質和屬性列表，但很快就落入了一些RPG的特性俗套，比如“Fallout”或“Skyrim”。事實上，要區分一個好的戰士和一個壞的戰士是極其困難的。

但是，使用下面的一些判斷方法，可以很容易的判斷一個個javascript開發人員是好還是不好。問自己兩個問題:

你會同意在一個他是團隊領導的項目里工作嗎?

你能把你負責的任務托付給他嗎?

如果兩個答案都是“不”，那么這樣的士兵就需要緊急送往建筑營，遠離戰場。