軟件集成策略故事連載----對項目的不利影響竟然這么大

2．對項目的不利影響竟然這么大

周一早上。老劉先是說了些感謝的話，感謝曉川的辛苦工作。曉川聽了很欣慰。接著，老劉用筆記本給曉川展示了一張巨大的圖，跟他說，這是項目的任務計劃圖。好復雜啊，曉川看得一愣一愣的。老劉見狀，轉向白板，在白板上給曉川畫了張簡單的圖。如圖 1所示。

“曉川，我想讓你了解，你的工作對于這個項目有多重要。看這張圖，這是一個典型的例子。開發任務 B、C、D要想開始，必須在開發任務 A完成之后。類似這樣一個一個任務串在一起，就決定了項目至少需要多久才能完成。這個你能理解吧？”

“能。 ”

“但是現在 A任務完成后， B、C、D任務不能立即開始。即便是 B、C、D任務的人手已經到位了也不行。你知道細節。 ”

“嗯，A任務完成后，要等到下一輪集成時才能去集成。而集成本身也需要時間，要等集成結束， A任務對應的改動進了基線才行。這時候大家才能看到 A任務的成果， B任務才能開始。”曉川很熟悉。

“現在要等多久？”老劉問。

“嗯，那要看我這邊集成需要多久。剛結束的一次是整整一周。哦，不止是集成的時間。還要算上等待集成的時間。如果剛好是周一上午完成的，那幾乎不用等。如果不巧是周二完成的，或者就晚了一步，是周一下午完成的，那就要先等上兩個星期。也就是說，平均要先用一個星期等待進入集成環節，再用一個星期等待完成集成。 ”

曉川說完，陷入沉思。以前只是覺得自己的工作很辛苦，沒想到，整個項目都在看著我，指望我快些、再快些……

“我知道你很辛苦，曉川，”老劉說，“現在你也知道我多么期待你把工作做得更好。你有什么好主意嗎？”

曉川：“我覺得關鍵是開發人員提交代碼的質量。如果他們在提交前保證代碼是可以編譯通過的，那集成的時候就不會有構建問題了。現在昀費時間的就是集成的時候反復構建。 ”

老劉：“你是說，大部分時間是用在反復構建上，而不是在這之前的版本合并上？”

曉川：“對，是這樣。比如這次集成，星期一下午一點開始處理大家的提交。您知道，大家的代碼改動，都在各自的任務分支上。所謂提交，就是告訴我，等到集成時，要把他的分支合并到集成分支。在我合并的過程中，可能會遇到版本合并沖突，我就要協調，誰提交的，就找誰解決。快下班的時候我給所有的還有提交沒有處理的程序員發了郵件，讓他們待命，準備解決沖突。這樣，到晚上九點的時候，所有的版本合并沖突都解決完了。而后面的時間，就都費在反復構建上了。”

老劉：“好。那看來反復構建昀費時間。然后你的思路是，如果程序員提交的版本都是能構建的，你這里就不需要反復構建了？”

“對。這樣的話，說不定周二早上，任務 B、C、D就可以開始了。 ”曉川很有信心。

“如果程序員的提交都沒問題，你確定你構建的時候就肯定沒問題么？”老劉降低了語速，一個字一個字地說。

“那當然，但是……”曉川意識到了什么，好像這里的邏輯看似簡單明確，其實并不是嚴格的推理。

“這樣吧，我看到你有一些想法，這很好。你再想一想。多調查調查，看看現在究竟是什么原因需要反復構建。也跟大家聊聊。總之，請你幫忙想想辦法，縮短從任務 A完成到任務 B可以啟動這中間的時間。 ”

本文節選自《軟件集成策略》一書

董越 著.
電子工業出版社出版。