2011年11月1日 星期二

程式碼全部寫完,但工作還沒結束(轉載)

這一篇文章是我在整理Email 時,被我翻出來的。

當初朋友寄給我時,大概認為我是搞系統韌體出身的,想聽聽我的意見吧。

這種事情本來我就一直強調:寫程式根本不能一開始,就大家劈里啪啦

分頭上機寫程式...但實際上,這一種事情在我眼中分成兩種結論,

就看您是在大公司裡寫程式的?!還是在小公司或小團隊裡寫程式的!?

看看我當初回答,與我看完賈伯斯傳裡感想,那些搞Apple II 或是NeXT 的作業系統的人,

都是絕頂聰明,都只是小貓兩三隻就撐起整個程式架構的維護與發展。

所以難怪賈伯斯一直強調:他是比較相信天才,也不喜歡跟笨蛋共事,

也是有其道理的啦。--- 所以,如果您的程式功力真的經日積月累之後,

最好還是把自己當天才用吧!如果不行~那就把自己當作白癡,換個工作吧。

因為人家的經驗法則已經跟您說了:要成功非得要這一種有自信的天才。

(PS : 其實在蘋果與微軟之間的系統爭議中,就是封閉與開放兩種觀念,

蓋茲認為封閉系統唯有在像Jobs 這種人身上,才有成功的機會。

但是以開放系統來說:如果沒有很好的系統規劃或是核心架構的維護,

其系統也是很容易發散不易收斂...也比較難在短時間內完成完整的產品雛形。

----這一點Jobs 利用蘋果很明確的證明給大家看,如何在短時間可以超越微軟。

Jobs 傳裡也有深刻的描述他們之間的系統觀念之爭---沒有絕對的對與錯。

但是針對Jobs 在iTunes 裡整合硬體、軟體與音樂等之間成功,他本身有對於

SONY 有明確的點出,大公司有時喜歡拆解組織,看似專業分工,但實際上對於

公司整合核心技術反而容易產生門戶觀念,結果反而做不了事...所以,

Jobs 說:蘋果再大也不會隨便拆解公司,這一點跟國內有些公司的作法不同。) 

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

以下是我當初的回答內容:

關於寫程式會有疊層架屋的問題,據說:連微軟的作業系統也有同樣的歷史包袱,

大家都說Womdow 7 都有Windos XP 的影子,而Windows XP 也有Windows 2000 的影子...
這個比喻呢?就跟我們人一樣...人老了,身上就會有日積月累的老毛病,
不管是生理或心理的...所以,這一種事情都沒啥好意外的。
 
        所以,以前我們在賣單晶片MCU 時,我們就必須有個產品業務觀念:您說:
賣 1K ROM Size 的MCU比較容易出貨呢?!還是賣8 K 甚至 16K ROM Size MCU 容易出貨呢?!
答案當然就是越小容量的MCU 比較容易出貨...因為程式一下子寫完,也比較不容易出現文章中的問題。
 
         一樣的觀念:從去年夯到今年的iPhone (iPad)給我們做產品或系統設計的最大啟發就是:
"簡單"......您只要留意就知道,在iPhone或iPad 上要玩他的應用軟體,一定要先把目前所使用的
軟體關閉才可以,一次只執行一個應用軟體,不像微軟的作業系統---多工。
所以,蘋果的這些產品的硬體規格真的都很簡單...所以,我們未來的生活還是以簡單為目標。
 
---
        至於文章所指的產品系統開發有著團隊共業的宿命...文章所指的還沒指出這個團隊包含多少人,
涵蓋多少地區的工程師...現在台灣很多東西都號稱結合兩岸三地...甚至全球佈局的工程團隊...
呵~呵...一旦出現文中的情況時,Project Leader 包您三天兩頭就得當空中飛人了...這一點 Joe 應該比我們更清楚吧!
 
我早已經看破紅塵了...這些程式開發的鳥事對我這種年紀的工程師來說:
我寧願日子簡單一點,不要再承受這一種背負團隊共業的折磨
引用文中結論的一句話:
"這些都有可能透過專案管理、軟體工程、設計技巧來加以改善,降低專案收尾的難度。"
對啊...以我們這一種寫程式的資歷,本來就可以做到這一點,只不過,因為要承受團隊的共業
所以,還是要把這個共業放出來讓大家承擔,這樣子才會像當長官的樣子。
所以,在大公司是要反向操作的啦,明明簡單的東西就是要把他搞得煞有一回事的,
這樣子才會像在大公司做事的規模與樣子啊。
 
---所以,結論:很簡單,這一篇文章就是給年輕不懂事的工程師看的...讓他懂得在大公司的做事方法。
如果要我再到大公司做事,我一定是朝這個方向努力的啦...讓這些工程開發的事,沒完沒了...
這樣子才可以長長久久的永保安康...做得越久,領得越久...不是嗎?!哈~哈~
這是共業,絕對不會是長官來背黑鍋的啦! 是不是呢?!
 
---只是啊...我是很有正義感的啦,而且我也上了年紀,已經不適合去飛來飛去的啦。
哈~哈~

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

程式碼全部寫完,但工作還沒結束
/王建興 (清華資工所博士班研究生) 2011-01-13

專案為何難以收尾 3回個別的模組程式都開發好了,然而要收拾善後、面對過程中的錯誤,還有很多工程要進行,例如要滿足後續追加或異動的需求,以及解決先前設計不良的問題

    需求無法收歛、整合工作不如預期簡單、不如預期快速,都是影響到專案難以收尾的關鍵原因。

而且,我們會對專案有「難以收尾」的印象,往往是因為我們太低估這件事情的難度及複雜度。

攤開許多專案的專案時程表,時常可以看到整合階段及測試階段所需的時間,還有資源,

事實上都遠遠被低估。例如,時程表上可能為整合階段安排了兩個月,

事實上,最後可能卻花掉了四個月;

而測試階段或許安排了一個月,最後卻也花掉了四個月。 這種預期和現實之間的落差,

又怎麼能不叫專案經理、團隊成員、甚至是客戶,打從心裡覺得這專案「怎麼如此難以收尾」呀。

低估收尾所需工作及時間的習慣和心態,正是專案難以收尾的重要原因之一,有時我們可以說,

不是難以收尾,而是根本就估錯了收尾所需的工作及時間,自然會覺得收尾很難。

 有些人總是認為,個別的模組程式都開發好了,距離專案完成,也就只差一小步了吧?

只要把它們整合在一塊、然後花時間測一測,不就可以大功告成了?如此期待當然十分美麗,

然而現實總是格外殘酷,劇情也不會單純地依照想像上演。

畢竟,軟體專案不同於總是讓王子與公主從此過著幸福快樂日子的童話故事,專案的成員必須

用如臨大敵的角度來看待收尾的工作,千萬不要以為程式碼都寫得差不多了,

專案就幾乎到了完成狀態,事實上,還有很多的工作等待處理。

局部需求的異動,往往又影響到更多環節 在專案規畫上,

必須接受需求難免會有改變、增加情況,進而做出適當的安排。

到了專案尾聲,一旦牽扯到需求的改變,影響層面便可能很廣。

因為一旦需求有所擴充或調整時,往往不僅只是需要改寫程式碼,

甚至有可能會衝擊到設計。

倘若改變波及到主架構、或核心模組的設計,那麼由於主架構和核心模組

都是系統中被高度相依的,所造成的影響便格外的深遠。

主要設計若被需求變更所擊中,那麼相對應的各種設計,

也可能需要進行配套的調整,接著再重新改寫必要的程式碼、

然後重新進行單元測試,接著再行整合,最後再重新進行整合測試。

由於軟體程式碼天生的複雜特性,有時往往是牽一髮而動全身。

每次的修改都有可能引發完全無法預料的副作用,接著就必須花費極多的時間,

才有辦法找到問題然後加以修正。

既然需求的變動是難以避免的,那麼,在設計上考慮需求有可能變動,

提前做出因應,甚至採取能適應變動的設計,那麼便有能力在需求發生變動時,

降低因為改變而造成的影響、同時縮小影響的範圍。

有些人在從事設計時並不會考慮到可能會有的變動,雖然他們的設計能夠滿足當下的需求,

但是,當需求有所改變時,想要擴充、調整他們原先的設計,代價就會十分高昂。

所以,好的設計技巧其實有助於縮短專案的收尾階段。當設計者能在一些好的設計原則之下,

運用好的設計技巧,使得所做出來的設計能夠達到更佳的擴充性、彈性,而且在面對需求改變,

也能將改變限制在較小的局部範圍內、同時降低所做修改引起副作用的可能性時,

那麼,在收尾階段遭遇到可能的需求變更時,便可以花費更少的時間及力氣。

面臨程式碼結構不夠理想的困境 專案收尾階段,能讓團隊設計能力的優劣高下立判。

相同的,團隊的程式碼結構是好是壞,到了專案收尾階段,通常也能顯現得一清二楚。

軟體專案的進行,本來就是一個不斷評估現況、不斷針對現況和目標的差距進行修正的過程。

在過程中,團隊可能會發現各種和計畫不同的項目,例如所認知的需求和客戶不同、

所做的設計其實無法滿足需求、或者像程式碼的實作錯誤等等。到了專案後期,

其實整個專案可以說是累積了一路上各種修正的產物。有時候,在有期限壓力下,

人們難免被迫要做一些抉擇,在時間上求快及完備的解決方案之間,

選擇了快、但不那麼「乾淨」的作法。

這些作法隨著專案進行一路累積,往往就讓程式碼結構逐漸走向了敗壞的道路,

不是變成了疊床架屋的奇怪建築,就是成了面貌可憎的大怪獸。 同樣的,到了收尾的階段,

這個疊床架屋的奇怪建築,可能會遭受到各種考驗。

例如,需求只要一改,最後自然會演變成程式碼的更動,

或者,在經過各種測試之後,發現了程式碼的問題,進而必須進行修正時。

而在面對充滿各種疊床架屋作法的程式碼,想要做一些改動時,

我想大多數的程式設計者的心情,都是十分無奈、不知從何改起的。

結構敗壞的程式碼或許可以運作,但是,一旦你要去更動它時,就會顯得險阻重重。

例如,它的問題可能出在相依性極高,想要修改一個小地方,

可能得要修改到為數不少的其他部份,而且,更可怕的是,

你可能不知道自己是否修改到所有需要修改的地方,因為需要修改的東西散落在程式碼四處。

好比利用「複製、貼上」手法將某一段程式碼「重覆運用」在各地的方式,

就很容易造成這種情況。一旦發現最先被拿來複製的那段原始程式碼,

必須要修改(不論是因為需求改變或內有臭蟲),所有基於這段程式碼的「分身」,

都必須跟著「本尊」一起同步改變。倘若有八萬六千個分身,

那麼就得徹底找出它們,然後把它們變得和新本尊一樣才行。

一旦有所疏漏,那麼修改就不完全,問題也不能真正根除。

有一些軟體專案之所以在收尾的時候,問題層出不窮,

便是因為程式碼結構日積月累各種快速「dirty」解決方案,

使得專案到了後期,面臨需求變更或測試修改的考驗時,付出了極為沉重的代價。

 如同電影《無間道》有云:「出來跑的,遲早要還」。而在專案前,中期抄捷徑,

通常就是在專案後期償還更多,而且還要加上利息。

程式碼結構愈糟,在這一個階段要經歷的折磨就愈痛苦,想要看到專案收尾完成的難度就愈高。

開發過程中沒有妥善解決的問題,都有可能在收尾時爆發

所以說,到了專案後期的各種不可預料的事情,實在太多,

有客戶拼命增加、修改需求,好不容易個別的模組看起來都寫好了,整合起來卻是問題百出。

最糟的是,竟然發現需要變更主要的核心設計,而這個設計一變,

一大堆設計都被波及,而大量的修改,導致程式碼品質低落,

測試好像沒有終止的一天。這都是很多專案在收尾時可以觀察到的現象。

收尾絕對不是一件簡單的事,會這麼的困難,

其實是因為那時所要處理的是,整個專案執行過程中,一路下來所累積的所有錯誤。

偏偏,許多人都沒有意識到,自己在這個階段即將面對的,其實是如此艱困的環境,

然後低估了收尾的困難度。 我們這次談到了幾個可能造成難以收尾的原因,

這些都有可能透過專案管理、軟體工程、設計技巧來加以改善,降低專案收尾的難度。

只要能重視這些問題,其實是可以透過各種方式來處理,但如果只是抱持著輕視的態度,

那麼難以收尾的情境,可能就會一而再、再而三地重演了。

1 則留言:

  1. 543ok.tw錄音卡片DIY2011年11月4日 上午8:23

    太贊同了
    局部需求的異動,往往又影響到更多環節
    「出來跑的,遲早要還」。
     
    現實是,客戶說個標題後,就是要樣品,功能是問一說一,,看完樣品後,又是一堆Good Idea,,
    無止境的動code,,擔憂的不是做不完修改跟測試,
    煩憂的是1個月後,IC出來,上線生產後的未爆彈.

    回覆刪除