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

時(shí)間估計(jì)錯(cuò)誤

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

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

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

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

代碼評(píng)估標(biāo)準(zhǔn)

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

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

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

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

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

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

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

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

對(duì)臨時(shí)解決方案說不

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

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

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

招聘好的團(tuán)隊(duì)球員

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

在我們看來，軍隊(duì)中有一個(gè)很好的標(biāo)準(zhǔn)，用這個(gè)標(biāo)準(zhǔn)來區(qū)分好士兵和壞士兵并不難。你可以想象這樣一句話:“我不會(huì)和他一起去探險(xiǎn)的”。

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

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

1. 你會(huì)同意在一個(gè)他是團(tuán)隊(duì)領(lǐng)導(dǎo)的項(xiàng)目里工作嗎?

2. 你能把你負(fù)責(zé)的任務(wù)托付給他嗎?

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