[心得] 進入陌生專案

這些討論實在是太無聊了, 繼續來開不同話題,
討論點有內涵的東西不是比較有意思嗎?

這篇來講講怎麼進入一個陌生專案,所謂的陌生專案有很多種形式,

但不管什麼形式, 這裡的前提都是 source code 還在,
source code 都不見的逆向模式特別複雜, 這裡先不論.

以下我把專案形式概略分為四類:

1. 棄嬰型: 所有以前的開發者已經不可考了, 目前無人主力維護

2. 孤島型: 專案本身跟其他專案連結性不高, 本來就已經有1-2人在主力維護.

3. 協作型: 專案本身有跟其他專案連結, 且各專案(包括當前專案)都有人維護.

4. 跳島型: 專案本身有跟其他專案連結, 但其他專案沒有固定人員維護,
可能就3-4人維護多個專案, 要不斷切換專案.

然後進入專案的身分我們先假設是一個工程師, (主管角度的有機會在寫)

-------------------------------

一個工程師進入專案時, 有以下幾件事情會建議要列表確認:
(這裡的確認不是篩選, 我們假設你就是要做這件事情)
(反過來說如果你是 code manager ,
這些也應該寫成 getting start SOP)

1. 有哪些 repo / 使用的版本控制工具(雖然這年頭應該都是 git)

2. 測試環境的 setup 跟準備, 了解測試環境共用的情況,
自己的行為會對別人產生什麼影響(反之亦然).

3. 有無特殊 commit log 要求或格式

4. 有無特殊的 coding guide , 命名規則/程式碼慣例要求...etc

5. issue 使用什麼方式追蹤紀錄 (issue tracker)

6. 如果對任務有疑問時, 有誰可以解釋需求問題. (requirement manager)

7. 如果對任務有進度時, 應該要跟誰回報/形式為何
(通常跟5有關,但有些地方會有特殊要求, 所以單列一項)

8. 如果對既有的程式邏輯有疑問時, 有誰可以討論慣例 (coding mentor)

9. 團隊習慣的溝通工具, 每個人習慣的溝通頻率(重要).

進入一個專案, 越快越好的抓緊上面的這些事情, 能大幅的增加融入的情況,
這種時候不要怕煩別人, 新人是少數煩別人別人不會靠北你的時期.

--------------------------

底下幾種類型的專案分別論述:

1. 棄嬰型: 所有以前的開發者已經不可考了, 目前無人主力維護

這種類型的專案, 對你來說最重要的 key man 就是 requirement manager.

我們大部分的工作都是在把程式碼跟需求提供者的描述對照,
並且能力範圍內去確保他是有可讀性的.

有時候會碰到出現需求提供者沒講到, 但程式碼有的判斷跟邏輯,
這時候要複述幾次程式邏輯所想表達的意思,
跟需求提供者確認是否有任何一丁點可能是什麼東西.

如果真的找不到原因, 可以反過來確認如果修改他會發生什麼影響,
請需求提供者確認這樣的影響是不是預期的. (損害控管)

如果兩層確認後都非預期, 那就改吧.
一個專案越多不敢改的東西, 控制力就越低.

這種情況通常不用負責處理團隊政治, 話語權也會比較高,
要作的就是謹慎的放手去做, 該大膽就大膽, 但就是確定自己有掌握狀況.

這個狀態時要特別留意文件的撰寫,
因為不會有其他人幫你記得慣例跟程式碼文化.

寫文件是給自己看的.

2. 孤島型: 專案本身跟其他專案連結性不高, 本來就已經有1-2人在主力維護.

這種時候要留意的是原本的主力對需求的掌握程度為何,
是能充分承接跟滿足, 這種時候當然就先觀望, 銜接他們的工作分配.

如果原本的主力就已經是火燒屁股的狀態, 這種時候則應找他們討論,
看是劃定自己的責任區, 大家各自分工, 以利團隊穩定,
還是他們還有餘力帶著自己銜接工作分配.

另外在這種情況, 除非你有劃定自己的責任區,
不然要作程式碼文化或慣例調整時, 必須找到原本的 keyman 說服.

總之, 留意團隊默契, 這種時候其他 1-2 人的話語權相對高很多,

而你只是個新人, 除非真的有足夠的實力,
讓其他人讓位聽你說,不然沒有必要硬坦.

這種時候可以不用太積極寫文件, 因為你寫出來的文件對團隊貢獻度也有限.

3. 協作型: 專案本身有跟其他專案連結, 且各專案(包括當前專案)都有人維護.

基本上是 2 的擴大版, 現實生活中正常軟體公司都處於這個位置居多,

通常跨專案會有 1-2 個人會負責跨專案協調, 這些人是地下(或實質)架構師,
融入體系時要留意這些人跟專案資深成員的關係.

以國內的風土民情通常是關係不會好到哪去,
因為架構師的工作往往是比較惹人嫌的.
(看到他們出面就表示有新的工作了) XD

而且圈內正常合格能作跨組協調的架構師沒那麼多,
這是複雜一點的技術管理工作.

如果關係不好, 那就要把視線放在留意目前專案資深成員在意的點,

通常是當前專案的敏感點, 有些專案都有自己的[強假設],
再跟架構師關係不好的前提下, 這些強假設會特別敏感.

如果跟架構師關係很好的話, 那就把視線放在架構師的指示上.

這種團隊的方針, 因為上面反正橫豎都有人,
自己的工作是消化 task, 直到自己變成能主導夠大責任區的 senior.

文件的處理在這個狀態也相對不重要.

4. 跳島型: 專案本身有跟其他專案連結, 但其他專案沒有固定人員維護,
可能就3-4人維護多個專案, 要不斷切換專案.

這種情況略為棘手一點, 正常這種情況 mentor 會幫你安排,
因為如果 mentor 不特別安排期待的話, 這種專案基本上是新人墳場.

(新人最忌諱的就是沒有穩定專案, 沒有明確需求, 沒有明確範圍)

多數人在這種狀態時, 會急著想找個專案開主堡開始生兵,
但如果是我的話, 我會各專案先理解彼此之間的關係,

看哪些專案是敏感(或不敏感的), 看自己的風險屬性,
決定自己要對哪些專案特別熱情, 慢慢的你就會發現自己往那個專案移動.

但如果這個過程中又出現砸下新的專案的情況,
這種時候請毫不猶豫的離職, 組織一定是出了大問題.

另外, 這種時候也要多 focus 在文件的撰寫,
again, 文件是寫給自己看的.

--------------------------

基本上在專案融入的過程有幾個常見的困難:

1. 聽不懂團隊內術語或行話, 最可怕的不是完全聽不懂,
而是同樣的話聽在你耳裡跟聽在團隊成員是不同意思.

2. 看不清楚權力分配, 導致對所有指令照單全收, 結果作錯.
(如果團隊有人過度熱心/白目時會發生這種慘案)

3. 沒弄懂大家合作的方式跟默契, 導致把其他環境搞爛

4. 寫出跟團隊慣例或程式碼文化不一致的東西或作法.

(要你用 util 挖個碉堡, 自己用土鍬挖了個地下城.
我在別人身上碰過這種情況, 我後來負責收尾......花了很多力氣.)

5. 有時候團隊本來跨 team 分工默契就爛等著在找戰犯,

結果你一去就撞在大家的敏感點上,
變成別人攻擊你團隊的破口或代罪羔羊, 這就有點衰.

-------------------------

這篇寫的東西算是入門時一些要留意的事情,
其實工作時最重要的特色就是不白目, 要白目就得要有足夠武力.

如果有興趣拉深細節, 可以再推文討論, 我們再來根據具體情況追進.

--

I have a dream, it's silly but beautiful.

--

我想起十年前我們還在遊說大家開始使用 svn ，不要使用 zip 的年代。 表面上看起來 svn 是進步，但隔了幾年， 有些人反而卡在 svn 進不了 git 。 有些人當時鼓勵團隊轉 hg ，不過沒幾年 git 大一統 hg 整個淡出，從我的立場是沒什麼標準可言，只有能不能用。

有些地方啦(擦汗)

某專案，聘用新人，新人來覺得原本的人寫的太爛了。 跟主管說要重寫，主管本身偏 pm ， 沒有該技術專業，但同意原本的結構不良。 於是同意他自己重寫，中間沒設 check point ，也沒定期 merge 回來。 旁邊有另一個同事在舊專案開發新的需求進度。 搞到最後三個月過去，新的東西完成度約只有 40%，且完全未經可靠測試驗證。 這段期間已經在舊版新增的功能當然也沒有。 我們面臨一個不穩定舊版，跟一個未完成的新版的選擇。 我後來的處置是整個廢棄完成度過低的新版， 回來把舊版切出模組，分塊重新處理...... 那個去寫新版的工程師跟我槓上， 我們兩邊冷戰了快三個禮拜，我後來調他去做別的專案， 讓他不要再看到這個傷心地。 真要走這麼大的 move， 一開始就該安排 merge 計畫....

超過, 因為還會造成舊專案的同仁適應問題. 而且後續收尾還有一些行政成本.

從他的立場他覺得他只是需要時間. XD 我也算是理解他的感受啦, 後來有好好安排. XD