[[234990]]

如果您是團隊領(lǐng)導(dǎo)者、項目經(jīng)理或開發(fā)人員，您可能會遇到以下問題。以下是我們解決這些問題的方法方法。

時間估計錯誤

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

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

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

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

[[234991]]

代碼評估標準

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

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

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

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

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

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

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

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

對臨時解決方案說不

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

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

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

招聘好的團隊球員

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

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

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

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

你會同意在一個他是團隊領(lǐng)導(dǎo)的項目里工作嗎?

你能把你負責的任務(wù)托付給他嗎?

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