軟體開發工作中,絕大多數人都不喜歡突發的緊急任務。因為這樣子的任務,不僅不在預期之內,而且必須完成的時間都很急迫、工作本身通常也都很重要,因此,在處理時,得面臨較大的時間壓力。從技術層面來看,決定問題的解決方案時,必須考量到時間因素來進行取捨。也就是說,即使是技術上較佳的解決方案,倘若無法在限定的緊迫時間內完成時,也必須加以捨棄,並退而求其次,提出能夠在期限內完成的可接受(不見得是最佳的)方案。此外,從心理層面來看,負責緊急工作的人員也必須要能承受時間壓力,同時在這麼大的壓力下,冷靜地思考每一個動作,然後從容地完成任務。

在前文中提到,在接收到一份緊急工作之後,團隊的領導者首先必須確認、協商該任務真正的最後期限,並盡力爭取延長期限,畢竟時間越充裕,工作也才能做得越好。當然,擬定如何完成工作的計畫是必要的,這一份計畫必須決定出在有限的時間內,需要完成哪些工作項目,才能解決問題,而且,該計畫是以能「及時完成」為最高指導原則。

除此之外,最重要的一件事,莫過於挑選適合的人選,組成一支能快速作戰的臨時救火隊。以程式設計這個工作領域來說,究竟誰才是適合救火的人選,是一個有趣的議題,因為並不是每位程式設計者都適合救火的工作。那麼,具有哪些特質的人適合參與救火的行動呢?正如前文中所提,基本上,最好必須具備抗壓、冷靜、技術能力高強、撰寫程式速度快,並且具備良好的應變能力。如果能夠挑選出正確的人選,那麼任務就算完成了一半。

利用加班的短期衝刺力量解決燃眉之急
因為時間緊迫,所以,通常在處理這類突發性工作的時候,額外的加班時間是免不了的。平常盡量不讓團隊成員加班,是因為加班所帶來短期衝刺的力量,就是要用在處理像這樣緊急任務的時刻。不過,加班也就僅僅適合短期衝刺,妥善地利用加班,可以在短暫的時程內順利完成工作,但是,一旦在工作完成後,還是需要提供團隊足夠的休息時間,才能使加班成員的體力以及心理狀態得以恢復正常。

總括來說,在面臨緊急任務時,身為開發團隊領導者最重要的工作,便是擬定一個應變的計畫、組織合適的團隊,同時在這過程中不斷地依據工作的進展以及變化,調整決策以及計畫。最終目標就是要在不可動搖的期限內完成工作。那麼,對於實際執行程式撰寫工作的程式設計者來說,又該如何應對呢?

如果你是程式設計者,當你在某一個周末被團隊的領導者告知:「恭喜你,你被選入本月最佳救火五人組」,心情恐怕不會好到那裡去吧?因為,不僅要犧牲自己的休息時間,而且還得在強大的時間壓力下完成工作,遇上這樣子的事,應該很少人會感到開心。

不過,從正面的角度來想,自己之所以能夠被選入救火隊,代表自己的能力受到肯定。程式設計者的光榮是來自於解決困難的問題,當然,時間很緊迫的工作,通常也都是困難的問題,不如把這樣的工作當做是一場黑客松(Hackathon,意指馬拉松式的黑客活動)吧!這種救火任務通常被我們的團隊以線上遊戲的術語「團練打怪」來比喻。抱持著健康又正面積極的心態來面對挑戰,也算是一種「苦中作樂」……呃,應該說是從解決難題中創造成就感吧!

為了爭取時效,品質必須有所妥協而降低
程式設計者若是需要在很有限的時間內完成程式的撰寫或修改,通常要面臨許多的取捨決策,為了爭取時效,捨棄的往往是程式的其他特性,像是:彈性、可擴充性、可讀性。在有充裕時間的前提下,通常我們會希望所做的設計、所寫下的程式碼具備這些良好的特質,但是,一旦時間成了不可動搖的決定性因子時,如何捨棄這些特質,反而成為重要的關鍵所在。

有時候,你自己心裡也明白,在捨棄可讀性、彈性這些特質的同時,程式碼可能就因此變得比較「骯髒(dirty)」。但是,完備的方案通常需要更多的時間,當時間是一切的主宰時,你必須要準備不那麼完美但是來得及的解決方案。

舉例來說,若是在時間充裕的情況下,你可能會採用某些設計模式,來提供較佳的彈性及未來的擴充性,但是,這會需要用到更多的時間,因此,你可能會決定放棄這麼做,並且選擇寫死(hard-code)的方式,這樣雖然犧牲了程式的彈性及擴充性,但是卻換取到了時間。

一般來說,程式設計者的技巧之所以被認為更上層樓,是因為他們更懂得將彈性、可擴充性、可讀性等良好特質,賦予到其所做的設計以及所撰寫的程式碼。但是,在處理緊急任務的時候,程式設計者反而要試著將自己「降級」。不過,在這種情況下,程式人可以說是在心知肚明的情況下寫出較為dirty的程式碼,因此必須要預先留下後路,等到迫切的危機解除之後,才能利用日後較充裕的時間,進一步調整程式碼。

舉例來說,同一個模組,可以用優雅的方式,也可以用臨時替代性的方式來實作;在時間不夠的情形之下,可以先以臨時替代性的方式來實作,但是,這個模組面對客戶端程式碼的介面部分,卻是在第一時間就制定到位。這意謂著,雖然目前是以臨時替代性的方式來實作這個模組,但是,當緊急工作如期完成之後,有了較為充裕的時間,便可以最完善的方式重新實作這個模組。因為介面即使在重新實作之後也能維持不變,所以這個模組的重新實作不會波及到其他的客戶端程式碼。

在「降級」的過程中,有些設計上原先該避免的情況,你是明知故犯。但是,這種明知故犯是埋有伏筆,也就是預留便於日後再把程式碼「升級」回來的空間。寫下dirty的程式碼是情勢所逼,不得已才這麼做,但是,也不能因為程式已經會動了,就忘了它是dirty的事實,你終究是要還它原本就該有的清新面貌。所以,當你在寫下dirty程式碼的同時,你同時也應該想好了日後的復原計畫。

在面對時間壓力時,你可能會妥協的,不單只是較為dirty的解決方案,也包括了選擇不完整的實作。對於原先該實作完善的功能,選擇僅實作部分,可以縮短開發的時間。有些時候,部份實作是可以被接受的,因為,在緊急的期限內只需要部分的實作,就可以先解燃眉之急。

在實作之前,若能有效地識別出關鍵以及絕對要先實作的部分,並捨棄不必然需要完整實作的部分,就能有效地縮短開發的時間。同樣地,日後一樣必須補足其餘的實作。

趕工的同時,也要想好日後的補強計畫
面對時間短促的緊急工作,所有的步調都必須加速。這中間必須不斷地衡量進度是否符合計畫,若有趕不上的情況,就必須重新調整,決定還需要再捨棄些什麼。通常,趕工的過程就是一連串捨棄的過程,你會不斷地決定是否要捨棄成員的休息時間、程式碼的品質、程式碼實作的功能範圍……等等,以便在期限內達成目標。進行決策時,你必須很冷靜地分辨出哪些可以捨棄、哪些不行、哪些值得捨棄以及哪些不值得。

趕工的過程是一連串的捨棄,而趕工之後的活動,就是一連串的復原工程了。趕工的同時最好準備好復原的計畫及布局,這將有利於救火之後的復原工作。

作者簡介


Advertisement

更多 iThome相關內容