2010-04-22 22 views
2

當我在開發時,我喜歡在同時做兩件(或多件)事情之間來回跳動,即使這些事情不相關。我能夠讓我的思維非常快速地集中,所以「熱身」時間對我來說不是一個問題。我喜歡在兩個任務之間跳躍的原因是我經常發現我可以以這種方式更快地解決問題。處理多個不相關的任務和代碼評論

這樣做的缺點是我最終同時完成了兩項任務,當Code Review出現時,我發現自己必須向審閱者解釋兩個單獨的想法。此外,每次我要求審覈時,審閱者都必須查看更多的代碼,而不是一次完成一項任務。

對於幫助我保持偏好在任務間跳轉的同時讓審閱者更輕鬆,您是否有任何建議?

我認爲到目前爲止,有些選項:

  1. 使中間檢查插件,即使功能是不完整的。 (tracer bullet code)
  2. 嘗試處理源文件清晰分離的任務,以便代碼可以獨立傳送。

回答

1

我的建議:有兩個代碼單獨簽出副本,雙集成開發環境等

無論你是在你的頭讓他們分開有多好,它破壞了SCM的一些好處,如果你正在做的這樣的:

  • 如果你在一個簽入兩個問題的修復程序(或新功能)檢查,你都使得它更難恢復的問題之一,或者例如,合併修改到另一個分支,而不復制該功能。正如你指出的那樣,你也讓代碼審查變得困難,而且如果由於你的代碼而導致某些事情中斷,它也會使它在未來變得更加困難,因爲現在有人可能不確定那段代碼是哪一個問題相關。
  • 如果您在檢查不完整的功能,可能會破壞構建。這也再一次讓未來追溯更加困難。
  • 即使對源文件進行了清晰的分離,通過一次執行兩個不相關的更改,您可能會引入一些相互依賴的可能性 - 因此,儘管代碼可以同時處理這兩個問題,但如果其中一個或兩個代碼他們自己有變化。
+0

你說得很好。保持來源的2個視圖將緩解我的一些問題。在維護這兩個視圖時會有一些額外的開銷,但它可能是值得的。 – 2010-04-23 12:43:13

+0

另外,我永遠不會考慮檢查破壞構建的代碼。如果我要提供不完整的功能,那麼對於我的團隊中的其他人來說,它必須是非阻塞的。 – 2010-04-23 12:44:20

+1

我經常在自己的倉庫中有不同的開發階段(我們使用git,這使得處理起來更容易),有六個主題分支。 – 2010-04-23 22:26:33

2

你的建議都很好。

我也建議實際測量你的生產力,像這樣跳躍;它可能不會像你想象的那麼好。我準備認爲你可能是對的,但實際上是在測試你的假設。

+0

你認爲我的主張是一個假設。 – 2010-04-23 12:39:15

+0

你沒有說你已經測量過它。如果你有,很好,但如果你沒有,這仍然是一個假設。 「度量,不要假設」優化代碼規則也適用於優化程序員行爲。 – 2010-04-23 22:25:38