- 軟體系統產品 - 大部分軟體工程企圖要做出來的東西
- 調適自己習於追求完美是學習軟體工程最困難的部分
- 你得先把工作做成功，才會得到越多實質上的權力
- 我們所倚賴的技術基礎是不斷地在進步，當設計完成的那一剎那，從該設計所代表的概念來看，它就已經落伍了
2. 人月神話
- 時程預估技術還非常不成熟，這些不成熟的技術背後都反映出一個假設，"一切都會進行得很順利"
- 預估技術誤把工作量和專案進度混為一談，"以為人力和工時可以互換"
- 以為"每項工作都將只會耗費掉它「理應」耗費的時間
- 用人月來衡量工作規模的大小是危險的，也是一個容易遭到誤解的迷思
- 只有當工作可被切分，而且投入工作的人彼此不用溝通，人力和工時的互換才算成立
- 分配足夠的時間給系統測試是非常重要的
- 在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後
- 軟體專案會耗費多少時間是看它有多少連續性的限制，該投入多少人力是看它可以切分成多少獨立的子工作
3. 外科手術團隊
- 生產力最好和最差的比率平均大約是10:1，經驗和表現好壞之間並沒有任何關聯
- 參與合作的人數會影響投入的成本，你最好盡可能用最少的人來完成專案
- 短小精悍團隊的問題出來了：開發真正大的系統就太慢了
- 要同時兼顧工作效率與概念整體性，這實在是兩難
- Harlan Mills建議大系統中的每個個小部分都分別交由一個團隊來負責，而各個團隊則被組織成外科手術團隊
- 外科醫生 - 首席程式設計師 (副手是出主意、參與討論、評估)
- 傳統團隊裡的成員而言，他們的地位都是對等的，所以因決策的衝突而必須進行溝通和妥協是不可避免的
- 外科手術團隊不切割問題、主從關係
- 就一個200人參與的專案而言，只要那20個外科醫生能一起合作的話就行
- 由一位系統架構設計師由上到下進行全部的設計
4. 專制、民主與系統設計在系統設計時，保有概念整體性是最重要的原則
- 只有當功能增強所節省下來的時間超過學習、記憶和查閱手冊所耗費的時間，電腦的使用便利性才會提升
- 功能概念複雜度比才是系統設計的最終測試標準，好的設計既不可單獨偏重功能性，也不可只偏重簡單性
- 設計人員總是以功能性來評判系統的優劣，而非簡單性
- 若只提供基本功能和組合這些功能的規則，還稱不上是簡單便利，你必須讓使用者養成固定的使用習慣，也就是為這些功能提供一整套同一系列的操作方式
- 架構旨在說明做什麼，實作則是說明如何做
- 使用便利性的好壞是基於系統的概念整體性
- 產品的成本效能比是非常仰賴實作人員才能夠提升的，這跟使用便利性得仰賴架構設計師的道理是一樣的
- 約束對藝術而言是件好事
- 要達成概念整體性，真的是有賴於讓系統反映出單一的理念
5. 第二系統效應
- 第二個系統是最危險的系統
- 一般來說，第二系統都傾向於過度設計
6. 意念的傳達
- 將修改的程予以量化(quantize)是很重要的
- 架構設計師都必須隨時準備好提出一種實作方式供人參考，但不應該企圖硬性規定採用特定的實作方式
- 開會絕對是必要的
- 將最後的決定權明確授權給首席系統架構設計師，使妥協和延宕得以避免
- 配合錯誤的實作來修改規格將會耗費更多的時間和成本，還不如乖乖按照規格來修正實作
- 如果有何任不清楚的地方，我們希望實作人員都應該打電話向負責的架構設計師詢問，而不要妄加猜測或自行解釋
- 解釋架構上的效力，所以應該公告讓所有人知曉
7. 巴別塔為什麼失敗？
- 人與人不能彼此交談，就無法合作，當合作失敗，工作就陷入停頓
- 良好的電話聯繫制度並明確定義出團隊之間的從屬關係
- 例行的專案會議
- 專案工作手冊
- 組織的目的便在於減少溝通介面和協調的需要量，所以組織就是為了上述的溝通問題而存在的 - 透過人力配置和專案分工來減少溝通量
- 樹狀結構的組織是源自於權力和責任的結構，在任何人都不能同時聽命於兩個老闆的原則之下，造成了權力結構成為樹狀的樣子
- 溝通結構是網狀的
- 管理者 - 技術總監
- 組織必須視現有人力的特性來調配，而不是叫人去配合一個純屬理論的組織
- 管理者和技術總監必須給人感覺對主要技術的看法是一致的，重要的技術問題應該在私下場合進行溝通，在他們取得共識之前，管理者必須尊重技術總監在技術上的權威
8. 預估
- 如果採用了合適的高階語言，軟體開發的生產力也許可以提升到五倍
- 寫一個獨立的小程式所花的時間不能拿來做為預估整個軟體系統產品的開發時程之用
- 費力程度 = 常數 x 指令數量 ^ 1.5
9. 地盡其利，物盡其用
- 五磅麻袋裝十磅東西，其隱喻就是在資源不是無限取用的情況下，必須「地盡其利，物盡其用」
- 鼓吹系統的整體觀與使用者導向的態度，也許是軟體管理者最重要的職責
- 管理者可以做兩件事情，第一件就是確保大家的本事是真正透過程式設計的技術訓練而來，而不是憑個人的天賦或過去的經驗，第二件是認知到寫程式有它專業的技術，組件是要去創造才有的
- 每一個函式都應該至少包括兩套程式碼，一套是執行進度最快的，一套是使用空間最少的
- 資料的呈現方式是程式設計的本質
10. 文件假說
- 電腦的操作手冊與性能描述，這是開發任何一項新產品時所必須優先準備的文件之一，並且也是最後完成的文件
- 大部分的管理工作總是由成堆文件中的某一小部分具體呈現出來
- 只有把事情真正寫下來，遺漏和矛盾之處才會顯露出來，也唯有把「寫」這個動作確實做出來，才能導引出更多細節的決定(mini-decision)，那正是從模糊不清之中理出清晰而明確正策的具體方法
- 管理者的基本工作就是要保持組織裡每一個人都朝同一個方向前進，所以他每天的主要工作就是溝通，而非做決定，寫文件就大大減輕他的溝通負擔
- 傾聽、報告、引導、訓勉、商議、激勵
11. 失敗為成功之母
- 所有開發大型軟體系統的經驗都顯示，丟掉重做總有一天會做成功的
- 把必然的一次失敗納入正式計畫之中
- 定義一個底限是必要的，而且隨著專案進行，這項限制應該要越來越嚴格
- 唯一不變的就是變，認清到這個事實，將有助於你面對改變
- 不只是目標會改變，軟體開發的策略和技術也一樣會改變，丟掉重做的概念本身就是要讓你接受先學到竅門、然後改變設計
- 表格驅動技術 (table-driven)、高階語言、自我說明技術(self-documenting)
- 要形成一個利於改變 組織，比設計一個利於改變的系統還要難
- 為什麼無法將錯誤一次修正 1. 除非軟體結構非常單純，或是文件寫得非常好，否則往往只是治標而沒有真正治本。2. 負責修改錯誤的人通常不是程式原作者，而是菜鳥或新手
- 軟體維護必須搭配比一般發展時更多的系統測試
- 任何修改的動作都有破壞原有軟體結構的傾向，並且會增加系統的紊亂程度
- 任何事物總是在開始的時候最完美
- 若說軟體開發是一個簡單化而逐漸趨於穩定的過程，那麼軟體維護則是複雜化且逐漸趨於混亂的過程，即使有很好的技巧，頂多也只能減緩這種趨勢，軟體終究會走到落伍，再也無法修改的那一天
12. 神兵利器
- 使用高階語言
- 交談式程式編寫
- 除錯是編寫程式過程中最難也最耗時的部分，而漫長的回覆時間又是除錯過程中最要命的部分
13. 化整為零
- 最致命也最棘手的錯誤莫過於系統錯誤，這肇因於各個組件的開發人員做出了彼此不協調的假設
- 把產品定義清楚是非常關鍵的工作，有太多太多的失敗都源自於自始至終都搞不清楚要做的是什麼東西
- 開發人員不適合規格審查
- 開發人員 - 他們就算是看不懂規格也不會告訴你的，他們會隨著個人的喜好自行解釋
- 系統除錯所耗費的時間將超乎你的預期
14. 釀成大災難
- 為什麼專案會落後一年？ 因為每次落後一天
- 老闆想要知道真相有兩個方法：第一個方法是降低角色的衝突以鼓勵據實回報；另一個方法是審查制度
15. 一體兩面
- 我們無法主宰我們不了解的東西
- 每個程式使用者都需要一份淺顯的程式說明
- 好的做法是先求淺顯但涵蓋面廣泛，再逐漸深入解釋細節
- 流程圖中的方框符號所代表的涵義跟高階語言的功能相同，可用來將低階的機器語言集合起來，成為較易理解的段落
- 一個有條理的高階語言本身就具備了良好的分段，如果每一行程式都要用一個方框來表示，將會使文件過於冗長，還會佔據大量的空間
- 嘗試同步維護不同的文件是件愚蠢的事，對於同一件事物的相關資訊，應該盡可能統一放在同一份文件中比較好
- 自我說明的做法是來自於使用高階語言的刺激
16. 沒有銀彈：軟體工程的本質性與附屬性工作
- 在制定軟體需求時，採用多次反覆的方式，並把快速原型製作納入所規劃的每個反覆之中
- 讓軟體像生物一樣地發育成長，在系統持續被執行、被使用、被測試的過程中，逐步擴充功能
- 持續尋覓並培養年輕一代偉大的概念設計人員
- 對於一個軟體實體所做的描述，若將其複雜性抽離，結果往往也連帶抽離了他的本質
- 因為複雜性，使開發團隊成員溝通困難，進而導致了產品的瑕疵、成本的超支、時程的落後
- 複雜性造成了學習與理解上的巨大負擔，使人員的異動形同是個災難
- 所謂抽象資料型別，其概念就是一個物件的型別應該由一個名稱、一組適當的值和一組適當的操作方式來定義，而不是以它儲存的結構來定義，這部分應該是要被隱藏
19. 人月神話二十年
- 設計時必須靠許多人的構想共同來完成，但成果又必須讓使用者感覺到其概念是前後連貫的一套心智模式
- 架構設計師也形同使用者的代理人，在功能、效能、程式大小、成本和時程之間總是衝突的情況之下，他得綜觀全局，站在維護使用者利益的角度上做出取捨
- 架構設計師就像是導演，而經理就像是製作人
- 切分的界線所在，必須是能讓子系統之間的介面最小且最容易精確定義之處
- 錯誤而明確，也遠比模糊不清要好
- 架構設計師所要面對的其中一個最困難的議題，就是如何恰如其分地在進階使用方式與便利性之間取得平衡，他們要為新手或偶爾才會用一下的使用者設計出簡單的操作方式，還是要為專業級的使用者設計出比較有效率的進階使用方式呢？最完美的答案就是兩者都提供，並仍然兼顧到概念的連貫與一致
- 不要建構出必然失敗的系統 --- 瀑布模型是錯的
- 為改變而設計
- 當規劃時間比最佳時間的3/4還少時，則幾乎沒有任何專案能夠成功，不論給多少人去做都一樣
- 專案如果要成功，人的品質，以及人的組織與管理，遠遠比他們所運用的工具或技術要來得重要
- 我們在工作中所面臨的，在本質上，主要都是社會性的問題，而非技術性的問題
- 管理者的工作並不是叫人去工作，而是去創造讓人想去工作的情境
- 輔助功能原則告訴我們，假如能夠小心地維持基層的自主與責任，領導中心將在威信與效能上獲益，其結果是整個組織「越快樂，越欣欣向榮」
沒有留言:
張貼留言