四十個讓專案慘死的理由

剛發現這篇被貼上去了! 先聲明! 這篇只是學習筆記! 大家請看原文不要被我爛英文誤導! 原文寫的不賴,會接觸到 "專案" 人看到,應該會點頭如搗蒜! 此篇為方便本人有需要看的導讀文! 非翻譯文!

基本上,我是因為看到 一網打盡軟體開發的設計模式、錯誤模式、重構 這篇推推王的介紹才知道這個網頁,我只能說這是我最愛的菜啊!

資訊很多的壞處就是:

• 很難一次吸收!
• 要用時找不到!
• 吸收完又還給它!

所以為幫助自己學習,就只好邊看邊寫,寫些無聊的話語加強記憶了! 原則上有看就寫,先看個大概(快速掃描),日後碰到可先看此篇找到繼續看下去的入口(資訊太多的下場 Orz). 今天先看 Antipatterns 這部份:

整篇看完,發現大部份的議題著重在政治面上,再來是設計,幾乎沒有編碼技巧的部份.

Reinvent the Wheel

不要重新造輪子!

Death by Planning

不要過度設計!

Intellectual Violence

因為專業知識造成的誤解. 可靠團體內知識分享的會議來解除.

Design by Committee

什麼都要靠開會決定!

The Feud

人際關係! 解法: Pizza Party Orz

Throw It over the Wall

知識傳達的正確性.

Irrational Management

不當的管理(這應該是很多人的痛)!

Spaghetti Code

一堆爛到不行的程式碼,連寫的人都看不懂. 解法: 重構,寫之前先動腦...

Cover Your Assets

一堆沒有做出決定的文件.

Fear of Success

專案快結束了卻開始害怕東害怕西!

Viewgraph Engineering

做不完的圖表報告!

Project Mismanagement

直接翻譯: 專案的不當管理. Orz

The Blob

一個 Class 負擔了太多的責任,裡頭包含了大量的程序,看起來像是 procedural-style .

這讓我想起最近改寫的惡夢 - 一個 OK 按鈕下去就是 500 行以上的爛扣!

解法: 把責任分散出去.

1. 根據設計合約來檢查屬性和方法,將其移至合適的地方.
2. 生命會自己找到出口(原文也很玄,原諒我用這種不負責任的翻譯方法!). 將它放到它該住的地方. 狗身上不會有狗的鼻子,看不出來,你就不是個夠格的 RD!
3. 移除關聯性太弱的連結.
4. 移除弱連結,加上合理的新連結. 有點像公司的組織,董事長不會跟每個人都有聯結,一定是他管理你的老闆,你的老闆再管理你. 此例中,就是移除董事長身上跟所有基層員工的連結(因為這不合理),然後每個中頭目跟小頭目上加入他所管理的成員.
5. 將可抽取的行為搬出來(Strategy Pattern).

Continuous Obsolescence

使用的語言,函式庫...不斷地改版.

Lava Flow

時間一拉長造成的問題:

• 程式碼越來越龐大.
• 逐漸失去正確性的註解.
• 專案成員的替舊換新.

總歸一句, "專案依舊,人事全非".

Ambiguous Viewpoint

恕小弟無知,我看不懂!

Functional Decomposition

自以為用 Java 就是在寫物件導向的程式.

Poltergeists

"我不知道這個 Class 做啥的,但我知道不能刪掉它!" - 工程師 菜先生(28)

Boat Anchor

做一個沒有市場(或自以為有市場)的產品!

Golden Hammer

黃金鎚! Orz

Dead End

修改了一個原本廠商已經沒有在維護的可重用元件,之後維護的工作就落在自己身上.

Input Kludge

沒有針對使用者的輸入做合理的處理.

Walking through a Minefield

Bug 無所不在!

Cut-and-Paste Programming

CP 大法!

Mushroom Management

管理方式導致 程式設計師 跟 使用者 想法上的差距.

Autogenerated Stovepipe

軟體改版成分散式架構所遭遇到的問題.

Stovepipe Enterprise

一個企業應用程式下,分成各自獨立的多個系統,造成後續開發或維護需要付出更多的成本.

Stovepipe System

一整個就是廢的系統!

Jumble

垂直式的設計方式和水平(層級)式的設計方式不適當的混用,造成架構上的混亂及很難重新使用寫好的程式碼.

Vendor Lock-In

專案依賴第三廠商開發的軟體,該軟體的改變有造成整個專案實作需要修改.

解法: 在程式架構中加入一個新的中間層次,將抽象概念和實作概念切割開來.

Wolf Ticket

產品宣稱符合了新的標準. 但實際上,與其說符合新標準替使用者帶來好處,不如說是廠商為了增加品牌可見度而開發了該產品.

Architecture by Implication

做過類似的專案,而輕乎了現在手頭上類似的案子.

Warm Bodies

20個 RD 開發一個專案的效率 != 20 * (1個 RD 開發一個專案的效率)

Swiss Army Knife

一支包山包海能上天能遁地的 Class.

The Grand Old Duke of York

編碼員 vs 系統架構師

Blowhard Jamboree

太多自以為內行的專家,討論或散佈不一定正確的資訊.

Analysis Paralysis

過多為了追求完美的設計或行為.

Corncob

組織內的麻煩人物.

Smoke and Mirrors

一開始行銷或承諾畫了一塊大餅,在不可能達成的時限內,使用者往往只是拿到一個殘缺不全的四不像.

E-mail Is Dangerous

E-Mail 在某些狀況下不是個好的工具.

Fire Drill

管理階層花了大半的時間在規劃,壓縮到編碼及測試的時間.