2009-10-02 36 views
4

我的團隊負責人建議所有開發人員使用ReSharper,但他並未「執行」此建議。因此,每當我打開一些代碼時,它立即跳到我身上,無論編寫它的開發人員是否使用ReSharper。告示牌是不必要的嵌套,冗餘類型聲明和通用參數的使用,符號名稱中的拼寫錯誤(因爲它們將難以修復它們)等。使用Resharper - 它真的是一個「個人決定」嗎?

未明確的假設似乎是用戶ReSharper是一個「個人決定」,不會影響其他任何人。但這是真的嗎?在這個問題上什麼水平的「執法」是理想的?

+1

您使用的是最新版本還是一年以上的版本? – JoelFan 2009-10-02 19:00:19

+0

你有沒有動力不足的機器(特別是RAM)> – JoelFan 2009-10-02 19:00:57

回答

11

如果你在一個組中工作,那麼沒有任何影響你的代碼是純粹的個人決定。

1

現在使用R#超過2年後,我同情你。我發現我的代碼基本上更清晰,更清晰,更具可讀性。而我的標準,對於我自己的代碼以及我不得不從其他人審查/維護的代碼,已經取得了飛躍性的飛躍。然而,政治的fundemental規則(人性真的)是大多數人抵制變革......並迫使它後,他們似乎永遠不會降低該阻力,所以勸說始終是一個更好的辦法...

+2

你知道物理學中的量子實際上是一個非常小的東西,所以量子的飛躍幾乎沒有? :-)(抱歉,無法抗拒) – 2009-10-02 20:42:24

6
<Opinion>

我認爲像ReSharper這樣的工具的使用應該按照風格約定的實現方式來確定。每個人都這樣做。或者沒有人這樣做。

作爲一名開發人員,開發人員有數百個來自其他開發人員的警告,他們只是沒有像其他人一樣編寫相同的標準,這真的很煩人。

</Opinion>
+0

當你說警告 - 你的意思是編譯器警告,或者這是一個ReSharper建議修改其他人的代碼? – 2009-10-02 18:52:06

+0

顯然他意味着ReSharper的建議。 – Alex 2009-10-02 19:13:08

+0

是的,我的意思是ReSharper的建議。我說警告因爲我有這個確切的問題,但我的團隊成員不在日食中使用FindBugs。 – 2009-10-02 19:34:01

2

你應該寫一個符合你的團隊同意的編碼標準代碼(類似於this就足夠了)。你選擇的VS插件,鍵盤綁定,字體顏色和大小應該是你自己的。

我不會過分關注minutae,比如「冗餘類型聲明」。更重要的是讓人們加入SOLID原則。

0

就個人而言,我認爲如果一個團隊的標準具有可執行性並且可以通過工具強制執行,那麼他們的工作標準最好。 Resharper做得很好(只要你設置了相同的規則)就格式化差異的文件發出警告。規則只有在有強制執行這些規則的工具時才重要 - 無論這是Resharper的警告還是其他事情都不重要。

我目前的團隊大約有一半。我使用R#,和其他一些成員一樣,但我們的一些團隊只是在沒有它的情況下使用VS。然而,我們確實遵守了StyleCop提供的標準 - 因此R#用戶很高興(假設我們已經安裝了Resharper的StyleCop),並且非Resharper用戶可以正常工作。

1

我認爲整個團隊都應該使用這些工具纔能有效。

話雖如此,你遇到的「問題」似乎是代碼質量問題,並且與R#無關。 您描述的錯誤可以使用或不使用R#創建,並且可以通過執行代碼評論或結對編程來避免。 R#幫助快速編寫好的代碼,我想不出一個不想提高他的工作效率的開發人員 - 所以如果你希望你的團隊中的每個人都能從R#中受益,請說服他們,他們會使用它更有成效。再次配對編程是一種演示新工具優點的方法。

0

最好在整個團隊/項目中使用一套一致的規則,無論他們是如何執行的(通過CA工具或代碼審查等)。

由於缺乏給定點的明確標準,您需要放鬆您的規則(或resharper's)以接受其他程序員所做的事情,即使這些規則不適合您的個人風格。事實上,程序員都是個人,你永遠不會發現兩個這樣的人完全相同 - 總是需要一些靈活性。

CA工具經常會造成浪費時間的建議(根據我的經驗,大部分建議都非常垃圾)。我的意思是,如果你的團隊中的所有成員都可以有效地閱讀,理解和維護一段代碼,那麼通常很少重構代碼 - 當改變時要小心浪費時間來滿足Resharper您正在製作的代碼不會對可讀性,可維護性,健壯性,可移植性或效率產生任何影響。關掉這些警告,而不是浪費時間重構代碼。

說了這麼多,你應該明確宣傳和推廣CA到你的團隊和你的經理。團隊/項目將受益,並且每個人都將從使用CA工具中受益。

0

對我來說,使用代碼重構工具是一件容易的事。想一想 - 你不是爲自己編寫代碼,而是爲其他人編寫代碼:)建築師必須使他們的計劃精確,可讀,易於理解,因爲他們知道有其他人正在背後。他們有幫助他們做到這一點的工具。那麼,爲什麼程序員不這樣做?我們抱怨這是「太多的工作」或「爲什麼要解決什麼問題?」事實是,不重構歸結爲純粹的懶惰。

+0

執行手續是不容易的嗎? Au反對......如果每個人都爲*其他人*寫作,但事實證明那個類別的人羣是零,那麼它確實是沒有人編碼的。參見Emporer的新衣服並且不存在(薩特) – micahhoover 2017-05-16 14:45:08

相關問題