《I. M. Wright's "Hard Code"》第一章閱讀札記

12/31/2008
I. M. Wright's "Hard Code"》一書的內容係來自作者 Eric Brechner 原先發表於雜誌上的專欄文章,其筆調輕鬆詼諧,有時亦頗辛辣,挺適合躺在床上看。本書還有個特色,就是每篇文章都有附一張作者「玉照」,且每一張都有不同的搞怪表情或動作。不妨到作者的部落格看看,上面的文章也延續了這種搞笑風格。

這本書有簡體中文版,書名是《代碼之道》。台北天龍簡體書局可以買到,價格 180 NTD,還蠻划算,便買了一本。雖然很少讀簡體書,但讀起來並沒感覺特別困難。看了第 1 章,聯想到自己陷入參與的專案,便順手寫下一些感想。

第 1 章的標題是「專案的不當管理」(Project Mismanagement),其中有一篇名為「2001-06-01:開發時程、飛天豬、和其他幻想」的文章,裡頭提到:

我心裡從來沒有特定功能的交付日期,而只有一系列的「專案日期」--里程碑、測試版、正式版發行等等。一個好的開發時程應該只簡單列出每個里程碑所要完成的功能。第一個里程碑要完成的通常都是那些「必須有」(must have)的功能,至於要放哪些、放多少,則須以開發人員的數量和功能的「困難/適中/容易」三種難易度來考量。那些「最好有」(like to have)的功能可放在第二個里程碑,「希望有」(wish)的功能則放在第三個里程碑,其餘功能皆不予考慮。(註1)

[原文]:In my mind, there are no dates for features on a dev schedule beyond the project dates—milestones, betas, and release. A good dev schedule works differently. A good dev schedule simply lists the features to be implemented in each milestone. The "must-have" features go in the first milestone and usually fill it. Fill is based on the number of devs and the "hard/medium/easy" scale. The "like-to-have" features go in the second milestone. The "wish" features go in the third milestone. Everything else gets cut.

第一個念頭是聯想到目前正在纏鬥的專案。這個專案從開標完成、動工開始算,預計整個完工時間大約三年(這是非常樂觀的時程吧 @_@),開發人員粗略估計約 20~30 人--其中包括 PM、SA、PG、測試員、以及其他打雜、跑龍套的人(我算其一)。不過,開發期間人員來來去去,而我並非 PM,所以這些數字只是根據自己觀察所推估的,不見得準。

勉強來說,這個專案也有訂里程碑,稱為一期、二期、三期。以三年分三期來看,這樣的里程碑週期肯定是太長了,作者的建議是每個里程碑應為期 6 至 12 週。但比較奇妙的地方在於,這個專案並沒有明顯區分甚麼 must-have、like-to-have、wish 功能,大概講起來就只有一種,就是:no-matter-what-I-just-want-to-have 功能。回想起來確實挺「隨性」的,專案需要哪些功能,以及各項功能的重要性、急迫性似乎沒有經過審慎評估,而是只要 user 想得到的,通通都放進去,然後再依子系統粗略切割時程和實作的順序。如此隨性的後果,便是有些規劃在初期要先完成的功能,卻因為其他基本功能尚未實作而卡在那裡(沒有先找出功能相依的順序);要不然就是東西寫好了卻沒什麼人用,平白浪費開發人員的時間。

談到做專案總是容易流於發牢騷,寫到這裡就好。

註1:前面摘錄的段落是自己根據原文翻譯,並非取自簡體中文版。我也發現自己翻譯的結果跟簡體版的譯文有些差異(非簡繁術語差異,而是對原文意思的解讀不同)。不過,此差異應屬末節,無關宏旨;抑或是我誤解了原文的意思,也有可能。大體而言,簡體中文讀起來挺順的,比讀原文要快多了(原文挺多俚語之類的,看起來似乎不好翻譯),可以省下不少時間,這要感謝譯者陸其明先生的用心。

2008-12-31 更新:

由於有提到不同譯法的意見,我在發文後便一併到譯者陸先生的部落格留下本文的網址,而陸先生也迅速做出了回應,將翻譯的修正更新到《代碼之道》的勘誤表。對其認真態度表示敬佩與感謝!

撰寫使用案例規格(情節描述)的一些問題與建議

12/27/2008
在 review 一些高抽象層次的系統分析文件時,我發覺經常出現的問題其實跟懂不懂 OO 沒有太大關係,反而跟一些基本的分析技巧以及文件撰寫技巧有關。

先解釋一下,這裡的高抽象層次的系統分析文件,指的是在跟使用者訪談會議結束後,根據使用者描述的需求,以使用者目標為出發點所撰寫的初步分析文件。其中應包含使用者的角色定義、主要的事流程、情節描述等等。為了表達這些內容,我們傾向使用 UML 的使用案例圖(use case diagram)和使用案例規格(use case specification)來描述,以求表達方式的一致性。喔,對了,還有活動圖,而且是比較高階的活動圖,主要用來捕捉事務流程。

在撰寫高階的系統分析文件(或者說初步的系統分析產出)時,我所碰過的一些常見問題包括:
  • 虛應故事的心態。沒有弄清楚使用案例圖和使用案例規格(use case specification)的真正用途,而只是交差了事(有做文件就好);或者實際上進行系統設計時根本不以目前撰寫的系統分析文件為基礎,而是在系統分析時一邊用自己慣用的規格書格式來撰寫,因為將來實際使用的是這份文件(真是浪費時間啊!)。
  • 沒有想清楚抽象層次,分析文件的內容不是太粗就是太細(太快描述太多實作細節)。
  • 文字表達能力不足,無法清楚描述使用者的意圖和操作流程。
前兩個問題彼此互有關聯:如果撰寫使用案例規格(或者說情節描述)只是為了應付驗收,文件內容的抽象層次不太可能拿捏得當(適當的抽象層次不會憑空出現,你得時刻想著這個問題,直到它成為習慣)。如果不了解寫這份文件的目的為何,恐怕也很難分得清楚內容要寫多細。

何謂適當的抽象層次?

文件內容的抽象層次該多細並沒有甚麼明確的標準,要看 SA 對系統的了解程度而定。剛開始,SA 從使用者那邊得到一些線索,此時記錄下來的東西可能是非常粗略的。隨著 SA 對欲設計的系統有更多瞭解,文件內容也會越來越細。而當細到某種程度,SA 認為可以開始進行更細部的設計時(例如:需要開始思考資料庫欄位的設計、類別的設計與關聯),此時大概可界定為進入系統設計的階段(儘管這個兩個階段中間的界線仍不十分明顯)。

舉例來說,在初步的分析文件中把使用案例和將來要實作的系統功能選單項目做一對一的對應,這種描述方式就明顯不當。對一個複雜系統來說,剛開始應該要描述使用者的意圖,以及如何達成這些目標,而不是直接就設想好將來操作介面的選單會有哪些功能項目。畢竟,使用者都還沒確認你寫的東西對不對,還不知道你是否真正了解她要什麼,怎麼能一下子就完成「功能分解」呢?太快做功能分解也會導致使用案例的粒度切得不恰當,當然寫出來的使用案例規格也就很難抓到重點。

雛型畫面到底要不要先做?

曾聽過一些建議,說在進行 OOA 時不要先想到資料庫欄位和操作畫面(UI ),個人認同前者。UI 的部分我覺得可以先做一些簡略的畫面雛型,以便和 end users 確認。

完成初步的系統分析文件之後,我們通常會拿去跟 end users 討論。也許有些人會質疑:「user 怎麼可能看得懂你那些橢圓形圖案和活動圖?他們也不可能有時間去看那一堆情節描述吧?」

不見得。但確實有許多使用者沒辦法逐一細看你寫的分析文件,而且使用者大都比較喜歡看圖說故事,因為總是要看到實際的畫面才比較有感覺。如果光看文字描述,一方面比較花時間、一方面也比較累。

因此我贊成在完成初步的分析文件時,也先製作粗略的 UI 雛型,方便讓 end users 了解我們所知道的東西,以及我們打算要怎麼來設計系統以完成他們的需求(功能、作業流程等)。可是,這樣不就會開始出現前面提到的「功能選單」和「資料庫欄位」了嗎?這不要緊,當它們需要出現在畫面中時就讓它們出現吧。我的意思是,我們是為了要讓細節逐漸浮現而表達這些東西--就像讓冰山在水面下隱藏的部分逐漸顯現出來--而不是連主要的 use cases 都還沒抓出來就直接去想功能選單長甚麼樣子。此外,UI 雛型上面的輸入欄位也不見得就是對應到資料庫欄位;它們還是有差別,而且你也不用在設計 UI 雛型時把全部可能需要的欄位全畫上去,只要關鍵的欄位就夠了。

就像《軟體工程與 Microsoft Visual Studio Team System》書中所建議的:

與人物代表(persona)一樣,情節也應該儘早明確。你會在其中加入操作畫面的簡圖,並顯示從一個畫面切到下一個畫面時的資料流。如果是以使用案例來分析,這些明確的資訊通常會拖到細部設計的步驟時才會出現。不要拖──你應該立刻針對這些明確的需求進行初步的測試。(p.65)

如何確定使用案例規格已經夠細了?

在撰寫使用案例規格時,可以問自己一些問題,來檢驗這份文件的內容是否已經完備:
  • End users 看了這些內容之後,能否確認當初他們所題的需求已獲得充分了解?以及他們是否能提出更進一步的具體需求或建議?
  • 此文件是否包含足夠的資訊,可讓系統分析師或設計師進行下一個層次的分析設計工作(找出互動、介面、關聯性等等)?
  • 現在寫這些細節會不會太快了?萬一下次訪談時使用者更改了部分需求或增加一些功能,會不會導致這個部分要大幅度改寫甚至整個重寫?
  • 使用案例規格是否是以 end users 的語言(problem domain languages)撰寫?是否包含太多與實作相關的專業術語(solution domain languages)?
  • 從這份文件中,能不能抓出將來要測試的項目(測試案例)?
最重要的,我想還是 SA 要有那個心去寫一份讓 user 看得懂的文件,而不是只用自己懂的專業術語來描述,或者敷衍了事。如果出發點正確,剩下的文件撰寫技巧大都可以透過相關書籍的建議逐漸改善。

加快 Visual Studio 2008 IDE 的反應速度

12/26/2008
之前曾聽說過這類問題,但這次總算給自己碰上了:在使用 VS2008 設計 Windows Forms 時,IDE 反應速度慢到令人無法忍受。

Speed up Visual Studio 2005 這篇小技巧也適用於 VS2008,依其建議調整了幾個選項之後,感覺 IDE 的反應似乎是有快一些,但滑鼠點選不同項目時還是會頓一下。

如果是開發 ASP.NET 網頁時碰到 IDE 龜速或其他問題,可以試試微軟提供的 VS2008 Web 開發環境的 hotfix:VS90-KB946581.exe

你也可以在 MSDN Code Gallery 網站上可以找到更多 Hotfixes

翻譯時要第一次就譯對

12/25/2008
有時候覺得,要是自己認識更多艱澀、少見的英文單字,也許翻譯起來就會快多了。但轉念一想,似乎又不是這樣。每次碰到覺得不好翻譯的、猶豫不決的,往往是簡單的詞彙或片語(例如之前提到的 cannot begin to + V),只是沒把握自己譯對了,非得查個字典確認才能放心。萬一正好碰到進度落後或時程很趕的翻譯案子,搞不好就先擱著,待日後校稿時再來推敲。

譯者的好朋友:字典與 Google

12/22/2008
翻譯時若碰到不太有把握的地方,我常常會先用前後文的語境(context)來「猜」作者想要表達的意思。除了英文之外,這還需要一點點想像力。有時福至心靈,隨手捻來都是順當的中文,但也有些時候,在房間踱來踱去也想不出個所以然來,簡直鬼打牆。

魯棒性

12/20/2008
OOADA3 好不容易進入校稿階段,晚上便偷閒去書店逛逛。看到架上一本有關軟體架構設計的書,書籍封面的作者姓名是中文,可是卻又有標示譯者的姓名,不免感到好奇:中文書為什麼需要翻譯?

《搞定一切,還有時間玩》筆記

12/01/2008

書名:搞定一切,還有時間玩
作者:馬克.佛斯特
譯者:鄭文琦

這本書講的是如何管理自己的時間和工作。作者從心理層面的角度來剖析為什麼人們常常都是臨時抱佛腳,拖到最後才焦急地熬夜趕工。是啊!如果不從心理層面著手,光只知道怎麼用 Outlook 或行事曆,最後還是一樣堆了一堆做不完的工作。

以下是一點筆記:

專注,是工作效率提升的原動力。

拖延,因抗拒做某件重要的事,而忙著處理其他瑣碎工作。藉著忙碌的假象來減輕拖延的罪惡感,為拖延找理由。但事情拖到後面,往往形成巨大的壓力而不得不去面對,最終演變成臨時抱佛腳,拼了命趕進度。如此反覆循環,永遠無法從容把事情做完。

越是拖延,阻力會越大,威脅也越大。我們應該要在壓力小的時候就採取行動--也就是壓力剛形成的時候。

我們常在下意識裡先去做那些阻力較小的事情,因為它們會讓我們有藉口逃避處理那些具挑戰性與更大阻力的事情。殊不知後者才會帶給我們人生與工作真正有突破性的進展(就好像「黑天鵝效應」,真正對我們的生活有重大影響的,是那些極端事件,而非經常出現的瑣事。

問自己:「你的時間值多少錢?」如果花一個小時去做某件事,你覺得值得花費你的專注力去做那件事嗎?

抗拒的症狀
  • 拖延
  • 時間常花在處理瑣事與簡單工作上
  • 常做讓自己分心的事
  • 注意力經常分散
  • 有焦慮感
  • 經常出現危機與緊急狀況
  • 不想別人插手幫忙
如何克服抗拒
  • 在抗拒形成阻力前採取行動。
  • 將大型任務拆解成幾個小步驟。
  • 增加不去做的痛苦(刻意增加不便性)。
  • 建立良好的習慣,盡量主動完成任務。
勇敢說不
  • 「效率第一」策略的風險在於,我們極可能將省下來的時間拿去做更多瑣事。
  • 學習時間管理的第一步,就是想辦法減輕手邊已有的負擔。
  • 說「不」時,口氣要婉轉,不要聽起來像被激怒或騷擾似的。
  • 永遠不要找藉口。如果找一些藉口,你會發現你再替自己辯護。
  • 可以這麼說:「我很感激你的請託,但這件事目前無法排入我的優先順序。」或者「我目前正在專心做我的新計畫。」你的理由越平常,對方就越不會質疑。
  • 如果是老闆要求,則可以說:「我手邊還有正在處理的工作,你希望我先暫緩處理哪些,然後優先處理這件工作?」
方法
  • 使用 checklist。把所有大小事情(包括接電話、回覆 email 等)都列在清單上,做完就馬上槓掉。詳細列出所有事項可以協助思考有哪些工作要做,詳細記錄已經做的事項,可供事後檢視自己一天當中的時間都花在哪些事情上。
  • 區分重要性,已決定優先順序。
  • 將資料分門別類,方便查找。
技術提供:Blogger.