haha的異想世界

        第十四章作者Bob批評現有教育體制無法教育出會寫程式的學生，Bob主張公司要有輔導機制，大師與熟練工技術指導社會新鮮人學會寫程式。 學無法致用 作者Bob批評美國的教育體系只會訓練出考試很厲害的人，很多計算機相關科系畢業的人，都不會寫程式。 Purpose 依據Bob面試人的經驗，少數厲害的人，都是讀大學之前就已經「自學」會寫程式。 Bob回想過去的人生，Bob也是從小就有接觸計算機相關的玩具，有自學練習寫程式。 兩種學習方法 一種是像武俠小說男主角看武功秘笈學到厲害的武功。 另一種是像《聖鬥士星矢》星矢等人與黃金聖鬥士對打，戰鬥中青銅聖鬥士星矢等人領悟到了第七感。 第七感只可意會，不可言傳 Bob知道很多東西需要實作中才能体會，所以Bob認為要有「輔導」機制，每位出社會的新人都要有工作經驗的資深員工帶領。 作者將軟體程式設計師分為三個等級 大師 曾經在多種系統、語言和作業系統工作過。 懂得帶領團隊。 熟練的程式設計師、架構師。 公司的頂梁柱。 熟練工 對現代技術嫻熟 只了解一種語言、一種平台、一個系統。 經驗豐富的熟練工可以獨立作業。 學徒 / 實習生 學徒需要熟練工擔任導師，確保學徒能夠了解各種原則、設計模式。 學徒先當助手，與熟練工進行結對式程式設計。 以身作則 教學最好的方法是「以身作則」，子帥以正，孰敢不正? 男兒當自強 作者工匠輔導的想法很好，實際上要成功非常難。社會上壞人太多，半瓶水響叮噹，牠們會假扮大師騙新人，詐騙失敗就會罵人。 真的有大師確實厲害，大師會做不一定會教，實作與教學是兩回事。不過看大師實作，就像作者所言，自然會學到東西。 以前沒有google的時代，學習非常辛苦! 現代學習有google 可以找到很多資料。有貴人相助是福氣，沒遇到貴人只好靠自己。

       第十三章作者Bob分享自己工作帶團隊的經驗，介紹團隊與專案之間的關係。 只是簡單混合嗎? 如果是小的專案，可以一個人負責一個以上的專案，但沒有「半個人」這種做法，因為有可能專案不同，團隊不同。 有凝聚力的團隊 團隊需要一段「磨合」時期才能發揮出團體實力，成為有凝聚力的團隊。 作者舉出一個正常團隊的規格 人數基本上是12人，少則3人，最多20人。團隊要有程式設計師、分析師、測試人員，一名專案經理。 若是團隊有12人，會有7位程式設計師，2位測試人員，2位測試人員與1位專案經理。 分析師與測試人員都是負責寫自動化測試程式，兩者視角不同，分析師從業務視角寫測試程式，寫成功的案例。測試人員要關心那些地方可能出錯，測試出邊界與失敗場景。 專案經理負責專案進度，確保團隊成員知道專案時間表與優先順序。 發酵期 發酵期就是磨合期，團隊組建初期會有一段磨合期，過了磨合期之後才能發揮真正的實力。 專案結束之後，不應該將優質團隊解散，之後只需要將新專案交付給優質團隊。 團隊和專案，何者為先? 團隊為先，如同前言是固定團隊接各種不同專案，而不是為了一個專案臨時找人。 如何管理有凝聚力的團隊 作者建議用「點數」管理團隊中專案的速度。 一個優質團隊會接到一個以上的專案，根據業務需求，可以調整每個專案的速度。 專案承包人的困境 作者Bob當過專案經理與老闆，這段內容是從老闆的觀點出發。 專案承包人的工作是說明每個專案的意義與需求，各種專案進度是依據公司業務需要而調整。 結論 團隊比專案重要，每個團隊都要經過磨合期，才能成為有凝聚力的團隊。一個有凝聚力的團隊可以承接多個專案。

       第十二章作者Bob分享自己的工作經驗，一個人的力量有限，專業軟體工程師必須與他人協作。 Bob的真實人生 關於協作Bob舉出自己人生中一個好結果的案例與一個壞結果的案例。 Tim是Bob年輕時候的工作夥伴，兩人一起成功合作完成許多工作。 西元1976年Bob是24歲的年輕人，Bob曾經不負責任，導致Bob被開除! 下星期一有公司高層要看成果，星期五晚上Bob工作沒有做完就下班，導致團隊在下星期一陷入危機。 部門主管立刻給Bob嚴厲的警告，儘管Bob答應立刻改正，之後Bob再度犯了小錯，就立刻被開除。 事後Bob回想這段經歷，覺得小錯只是壓垮駱駝的最後一根稻草，星期一上午的事件已經讓部門主管決定要斬他了。 程式設計師與雇主 Bob提醒讀者工作要「顧全大局」，有的程式設計師寫程式的時候，會想要鍛鍊自己或是有趣，多做與驗收無關的事情。主管與業務關心的事情是完成進度，早一點驗收產品拿到驗收款項。 專業軟體開發人員要記得專案的短期目標與長期目標。 程式設計師與程式設計師 專屬個體所有程式碼 單一工程師壟斷一部分程式碼，別的工程師無法修改。明顯出現這種情況非常危險，萬一有工程師出意外，會沒有工作代理人能夠接替，影響整體工作進度。 協作性的程式碼共有權 程式碼分享，任何相關專案人員都可以修改。 結對 大部分的工程師平日不喜歡結對程式設計，危急時刻才會接受結對程式設計。 作者認為專業軟體工程師平日就應該接受結對程式設計，可以讓程式有代理人，又能夠多一個人檢查一遍程式。 小腦 專業軟體開發人員不是戴耳機躲在角落溝通，而是坐在同一張桌子面對面溝通。 作者鼓勵結對程式設計，「非常簡單」與「需要一個人長時間思考」的情況，才適合一個人獨自程式設計。 結語 程式設計的工作注定要與人合作，工程師要與業務合作，工程師彼此之間也需要合作。 補充 正常的軟體公司會有SVN程式版本控管系統，不會發生一個人壟斷程式碼的情況。

      第十一章是全書的精華之一，作者Bob寫出自己經歷過的真實人生，並沒有用美麗的謊言欺騙讀者。說到「壓力」網路上看到一句名言，傳言是郭董所言「有壓力才是工作，沒有壓力就是在玩遊戲」，工作都一定會遇到壓力。 Bob的真實人生 Bob回想起西元1988年的工作經歷，Bob在一家新成立的公司工作，每星期工作80小時，公司每個人為了員工配股分紅都很「努力工作」，Bob本人是軟體開發部門的鐵血主管，只要有部下沒有達到進度，就會被Bob開除。 持續這種生活一陣子。有一天Bob的太太說不喜歡Bob現在「人不像人，鬼不像鬼」的樣子，Bob照鏡子發現自己已經「走火入魔」，Bob出外散心的時候，天空下了一場大雨，Bob悟道了。 傳統心靈雞湯作品編造的劇情會是「吃得苦中苦，方為人上人」， 「不經一番寒徹骨，怎得梅花撲鼻香?」男主角Bob會重新振作，克服種種困難。 真實的劇情是Bob辭去軟體開發部門主管的工作，Bob成為軟體諮詢顧問，自己做自己的老闆。 Bob並不是萬能，工作上Bob也有撐不住的時候。「上帝關上了一道門，必定會開啟另一扇窗」Bob懂得轉彎，知道自己現在不行了，趕快轉換跑道，才有自己的一片天。 避免壓力 作者認為面對壓力優先的手段是「規避」，當然不可能完全避免全部壓力，但規避手段可以減輕壓力。 不要承諾自己做不到的事，如果是業務向客戶承諾什麼，那是業務自己要負責。如果開發人員做不到業務的承諾，導致被開除，開發人員自己問心無愧就好。 保持Clean Code的風格，想偷吃步反而會欲速則不達。 危機中依然要遵守紀律，例如平日用TDD，危機時也要用TDD。 應對壓力 不要驚慌失措，保持冷靜。 溝通要讓主管知道自己陷入困境。 維持紀律，如同之前的內容保持Clean Code的風格，平日用TDD，危機時也要用TDD。 求助他人，例如找同事與自己進行結對式程式設計。 補充 面對壓力的時候，作者主張優先「規避」壓力，並不是要讀者不負責任，而是要讀者能夠「知己」，承受合理的壓力。

       產品開發人員都會被逼預估未來專案進度，預估正確非常難。第十章作者提供一些增加預估準確率的方法。 什麼是預估? 業務方面認為預估是「承諾」，開發方認為預估是「猜測」，雙方想法不同。 承諾 承諾是確定性的，專業的開發人員在十分有把握的情況下才能夠做出承諾。 預估 預估是一種「猜測」。回到第二章的內容，專業軟體開發人員不能說:「我試試看。」 預估要做三種預估樂觀預估、悲觀預估與正常預估。 可以用「集體智慧」增加預估準確率。 可以把大任務拆分為小任務，針對每個小任務預估，會比較容易預估準確。 I promise 第十章的內容與中英文會話有關，書中的承諾相當於I promise ，聽英文會話的時候常出現「I promise」的語句出現，中文對話極少出現「我發誓」這種話語。會做到就會做到，不會做到「發誓」也沒有用。

        第九章作者Bob教讀者如何成為時間管理大師。 作者作息正常 Bob能夠做到「自律」，作息正常能夠做到早起生活有規律。 會議 會議要確定議程與目標 1.會議是必須的 2.會議浪費了大量時間 「福禍相依」每件事情都有光與影兩面。 不浪費時間 Bob本人是「有力人士」，Bob能夠做到不參加沒有意義的會議，當會議中途議題變無意義的時候，Bob會立刻閃人離開。 站立會議 1.我昨天做什麼? 2.我今天打算做什麼? 3.我遇到了什麼問題? 每個問題不應該超過20秒，每個人發言不超過1分鐘。 Iteration 計畫會議 Iteration 會議是每星期一次的週會，作者認為時間長度應該在2小時以內。 爭論 / 反對 5分鐘無法解決的爭議，都不能靠辯論解決問題。 證據才能證明對錯，有的人會大聲「說服」對方。 會議最怕陽奉陰違的情況，有的人會議上表面上答應，實際行動消極對待。作者認為專業人員如果答應了，就要拿出行動支持。 要小心批鬥大會，這種會議真正的目的是發洩情緒，或是逼大家選邊站。 專注力 作者用魔力 Manna 比喻專注力。 會議對程式設計師傷害大，可能經過一場會議之後，魔力已經耗光，沒有專注力寫程式了。 睡眠最能夠補充專注力 咖啡有助專注力，但不能夠攝取過量咖啡因。 做其他不用專注力的事，可以恢復專注力。 身心靈一体，作者發現固定運動，增強肌肉專注力有助於心智專注力。 輸出與輸入是相對的，作者看科幻小說激發自己對軟體的創意。 時間拆分和番茄工作法 將時間拆分25分鐘為一個階段，25分鐘內專心工作，不處理其他雜事，雜事等過了這一個階段再處理。 要避免的行為 「優先順序混亂」 要對自己誠實，不要說謊騙自己。 專業開發人員會正確評估任務的優先順序，排除個人的喜好與需要，按照真實的緊急程度來執行任務。 「死巷」 相當於無法前進的情況，掉到坑裡的時候，別挖。進入死巷的時候要趕快撤退走回頭路。 「泥潭」 「泥潭」比「死巷」更可怕，「死巷」很明顯無法前進，「泥潭」還會有一點進度，讓人誤會以為可行，變成無法立刻停損。 三十六計走為上策 作者能夠成為時間管理大師，關鍵在於作者沒有浪費時間，陷入不利狀態的時候，「三十六計走為上策」脫離目前惡劣的情況。 作者不參加沒有意義的會議，會議中途變得無異議的時候，作者會立刻閃人。拿出證據說話，避免批鬥大...

     第八章作者介紹各種層級的測試方法。 QA QA不是產品開發人員的敵人，QA在團隊中扮演 Specifier 與 Characterizers Specifier QA與業務人員建立自動化驗收測試，訂定產品規格。 Characterizers QA進行探索性測試，描述系統運行時的真實情況。 自動化測試金字塔 測試分為單元測試、元件測試、整合測試、系統測試與人工探索測試。 單元測試 就是作者推薦的TDD，程式設計師寫給自己的測試，目標覆蓋率90%以上。 元件測試 元件測試是驗收測試之一，元件測試針對元件而寫，測試元件的輸入與輸出是否符合預期。 元件測試主要測試成功路徑的情況，目標覆蓋率50%以上。 整合測試 測試元件之間能否正常通訊，並不會測試業務規則。 系統測試 針對全部整合完畢的系統進行測試，應包含產能測試與性能測試。 人工探索測試 顧名思義就是直接派人去實際操縱系統，看會不會發生錯誤。 補充 大公司員工多才會有QA，小公司開發人員自己就是QA，通常測試程式也是自己寫。關於測試書中有一點說得很好，產品程式與測試程式最好是不同人寫。

       第七章作者主張用驗收測試做為產品開發人員與業務單位、客服單位之間驗收的標準，用來確定需求已經完成。 需求的溝通 作者Bob舉出以前他與現場客服主管Tom的故事，說明溝通的重要性。 「理想很豐滿，現實很骨感」沒有寫過程式的人都會覺得寫程式很簡單，Tom原本找Bob去教他寫程式，最後演變成Tom描述需求，然後Bob寫程式。 Bob有感而發客戶與客服的需求經常是天馬行空，經不起實際程式的檢驗。 過早精細化 「世事多變」隨著專案的進行，客戶與業務的需求都會變化，常常客戶與業務看到初步的成果之後，會有大膽的想法。 需求會一直改變，造成軟體開發人員無法預估正確的工作完成時間。 遲來的模糊性 光憑文字溝通，有可能會出現一段模糊文字，各自表述的情況。 驗收測試 為了避免雞同鴨講的情況，作者認為要有驗收測試。 驗收測試定義為業務方與開發方合作編寫的程式，其目的在於確定需求已經完成了。 完成的定義 完成意味所有程式碼寫完，通過所有測試，QA與需求方已經認可。 溝通 驗收測試的目的是「溝通」，讓開發方、測試方與業務方達成共識。 自動化 避免手動測試，自動化測試可以解省時間節省人力成本。 額外的工作 自動化驗收程式並不是額外的工作，而是為了能夠驗收，確定真正完成的工作。 驗收測試什麼時候寫，又該由誰來寫 驗收程式會交給QA或是開發人員寫，如果是開發人員寫，寫測試程式的人與寫產品程式的人最好不是同一個人。 業務分析員測試正確路徑，證明功能正確可用。QA測出錯誤路徑，邊界條件、異常、例外情況。 驗收測試應該越晚越好，通常是功能完成的前幾天。 開發人員的角色 開發人員有責任讓驗收測試通過。 測試的協商與被動推進 寫測試的人也有可能會犯錯，開發人員要與測試人員溝通。 驗收測試與單元測試 兩者是不同的工作，單元測試是給程式設計師自己看的，驗收測試與業務、程式設計師有關。 測試真正的目的不是「測試」，而是文件與規格。 圖形介面與其他複雜因素 GUI要和業務邏輯分開，測試系統時應當呼叫真實的API。 GUI很容易變化，儘量減少GUI測試。 持續整合 持續整合系統應由原始程式碼管理系統觸發，只要有人更新程式，持續整合系統就會開始建置，並執行所有的測試。 如果發生失敗，每一位成員必須停下手邊的工作，排除錯誤之後才能繼續工作。

       第六章作者介紹各種提高軟體開發人員專業技能的練習方法。 程式的不變 幾十年下來，程式都是 if 判斷句 while 迴圈 assignments 敘述所組成。 程式的轉變 隨著電腦硬体的進步，程式碼編譯到布署程式時間變快很多。 印出「Hello World」是最基礎的練習。 第四章作者反對寫程式的時候進入流態區 (The Flow Zone)，練習的時候是例外。平日的練習讓心眼加反射動作能夠對應大部分的工作，大腦就可以專心處理複雜的工作。 作者將練習比喻成武術，有套招對打。作者平日會練習寫小程式。還有一種練習是TDD，一人先寫測試程式，另外一人接著寫產品程式。 替開放原始碼寫程式是一種練習。 為了避免自己的武功招式受限，要擴展武功套路，可以翻譯不同語言的專案。 自己要找練習時間 作者Bob當過員工也當過老闆，Bob認為公司沒有義務要栽培員工，員工自己要找時間練習。 我覺得想要成為專業軟體開發人員，美國的客觀環境比較好，美國沒有加班文化，只要有心可以做到Bob所言，每天再練習三小時寫程式。 東方社會有加班文化，每天工時長，要再練習寫程式三小時有困難，想變強要靠自己再想辦法。

    《Clean Code》第九章作者Bob有已經有介紹測試驅動開發(TDD)，第五章Bob介紹自己與TDD結緣的過程與TDD的優點。 Bob願意學習新技術 在西元1998年接觸TDD之前，Bob已經寫程式三十多年，起初他也不相信TDD，覺得TDD是「奇技淫巧」，Bob親自找提倡人 Kent Beck 討教一番之後，Bob愛上了TDD，給TDD好評要會TDD開發軟體的人才是專業的軟體開發人員。 TDD的三大法則 第一法則：在寫一個單元測試前，不寫產品程式。 第二法則：只寫剛好無法通過的單元測試。 第三法則：只寫剛好能通過測試失敗的產品程式。 傳統軟體開發方法是先寫產品程式，再寫測試程式。測試驅動程式開發先寫測試程式，再寫產品程式。 此處的測試程式是每的小單元都有測試程式，測試程式只比產品程式早幾秒寫，幾乎是兩者同時開發。 作者用抗原與抗體來比喻TDD，我覺得TDD像太極圖黑與白之間相依又相剋，光與影彼此都是一体。 TDD的優點 TDD讓軟體開發人員不懼怕修改程式。 TDD逼程式去耦合，強迫程式分為許多小單元。 TDD減少錯誤發生，減少除錯時間。 TDD程式碼本身就是程式的說明文件。 TDD是好東西，職場實際執行有困難 如果要無中生有開發新程式，員工必須要花時間學 TDD。 如果要把舊有程式改成符合 TDD 格式也會花很多時間，平日工作能在期限內把程式完成就很厲害了，不可能再花時間重構程式。 TDD算是一種考驗，厲害的人像是作者Bob，就會花時間研究如何用TDD開發程式。  

       第四章作者描寫各種寫程式的「情境」，寫程式的技巧作者寫在《Clean Code》其他書籍之中。作者根據自己數十年寫程式的經驗，指出何種情境不適合寫程式，提供一些扭轉不利情境的方法。「勝兵先勝而後求戰」專業軟體開發人員要保持自己在良好狀態，才動手寫程式。 作者認為要精熟掌握每項技能，關鍵是要具備「信心」和「出錯感知」。 寫程式是一件非常困難的事情，疲勞或是心煩意亂的時候不可以寫程式。 流態區 (The Flow Zone) 這部分內容可參考《北斗神拳》的奧義「無想轉生」，當進入「無想轉生」狀態的時候會用心眼加反射動作處理人事物。 作者不支持進入「無想轉生」狀態寫程式，寫程式的時候進入冥想狀態會很「爽」，實際上會常常寫出有問題的程式。 作者發現自己進入「無想轉生」狀態的時候，會立刻離開座位，停止寫程式。 另一種解決方法是結對程式設計 (pair programming)，兩個人一起開發程式，一個人就不會進入「無想轉生」狀態。 「練習」的情況不同，作者反而認為練習寫程式的時候適合進入「無想轉生」狀態。 音樂 有的人喜歡一邊寫程式一邊聽音樂，作者反對寫程式的時候聽音樂，聽音樂會讓人不夠專心。 中斷 正當專心寫程式的時候，被外力中途打斷是困擾的事情，重新就位之後已經無法回到原來的專心狀態。 作者認為結對程式設計 (pair programming) 與 TDD 測試驅動開發，可以減輕中斷的干擾。 阻塞 有時候真的都寫不出任何程式碼，陷入阻塞狀態。 作者建議停止寫程式，做其他的事情。 作者超愛結對程式設計 (pair programming)，認為結對程式設計 (pair programming) 也能克服阻塞狀態。 創意輸入 「創意輸出」來自於「創意輸入」，平日作者並不是只有看寫程式的書，還有涉獵各種不同領域的書籍。 除錯 作者大讚 TDD 測試驅動開發，以前沒有 TDD 的時候，除錯時間會非常久! 有 TDD 之後，節省了很多除錯時間。 保持節奏 作者認為寫程式如同馬拉松長跑，而不是百米短跑。寫程式並不是一直努力加速衝刺。 要知道何時必須離開停止寫程式，依據作者自己的寫作經驗，當陷入卡關的情況，有時在開車或是洗澡的時候，能夠「靈光一閃」找到解決的方法。 進度延遲 每一位軟體程式設計師都會出現進度延遲的情況，預估時間的時候要...

        第三章內容與英文的特質關係密切，中文與英文有一項差異，例如英文有頻率副詞 never,sometime, often,usually 與 always 表達出「比率」的不同。第三章作者說明專業軟體開發人員要如何說「是」，給人感覺「百分之百」說到做到。 承諾用語 部分內容引用 Roy 的文章 做出承諾包含三步驟 口說、心想、行動。 (Say, Mean, Do) Roy 有舉出三個實例，當事人說了承諾，其他人聽了之後，不會認為當事人能夠說到做到。 識別「缺乏承諾」的徵兆 有幾個英文單字用上了，會讓別人感覺缺乏承諾。 need / should hope / wish Let’s (讓我們，而不是讓我) 真正的承諾聽起來是怎樣的 每個人總有自己所能夠掌握的事，我將在....之前....的句型，例如我將在星期二之前完成這個任務。主詞是「我」，又有「行動」，又有「時間」。聽起來承諾的力度就很強。 有三種無法實現承諾的情況 之所以沒有成功，是因為我寄望於某某人去做這件事 事情能否成功有他人因素，可以與他人多溝通，做自己能做到的事。 之所以沒有成功，是因為我不太確信是否真能完成得了 無法短時間完成所有的工作，還是可以做一些事情，更接近完成目標。 之所以沒有成功，是因為有些時候我真的無能為力 能力不足的時候，要趕快通知承諾的對象，調整目標或是找支援。 小結 嚴謹負責的開發人員是最有價值的評價。 學習如何說「是」 作者寫一個小故事，內容與第二章大同小異，Marge 扮演主管，Peter扮演軟體工程師。 作者對「try 試試看」深痛惡絕，專業軟體開發人員要回答出一個明確的完成時間。 這次故事作者安排一個妥協的結局，Marge 希望 Peter 進度快一點，Peter 堅持做專業的軟體工程師，要完成所有的測試，才能將程式釋出。 最後 Peter 答應「加班」放假找時間工作，程式釋出之後，Peter 有補假，雙方都得到可以接受的結果。 補充 想要對第三章有更多了解，可參考《與神對話》是(be)做(do)有(have)的部分。 Roy 的文章有一點寫得很好，除非一個人真的是廢柴到了極點，再怎麼渺小的個人都有自己能掌握的事，不要管他人、外在環境怎麼樣，做好自己個人能做的事情就是成功。

       第二章作者Bob認為專業軟體開發人員要有勇於說「不」的勇氣，讓人想起《銀河英雄傳說》楊威利的名言「有做得到的事，也有做不到的事」，還有《駭客任務》電影「認識自己」。Bob的說法職場上實際很難做到，很少有員工敢直接反抗主管，又不得不承認Bob說的內容是對的，第二章Bob的舉例都是實際發生的「事實」。 開頭漫畫作者說出第二章的重點，能就是能，不能就是不能。不要說「試試看」。 職場上最常出現的對話，主管問某某項目什麼時候能夠完成? 部下回答一個時間，主管不滿意工作時間太長! 要求縮短時間。部下不敢反抗主管，只能說:「我試試看!」 Bob 對「試試看」深惡痛絕! Bob認為專業軟體開發人員要對自己誠實「認識自己」，回答正確的工作時間，面對主管縮短時間的無理要求，專業軟體開發人員要勇於說「不」。 妥協的結局 書中作者寫出一個妥協的結局，客戶只是要先看看介面，主管答應減少一些功能縮短工期，員工答應能夠在期限內完成任務。 結果比過程重要 作者認為結果比過程重要，「為什麼」是細節並不重要。軟體開發人員不能評估出明確的時間，對主管說:「我試試看!」是不專業的舉動。 對主管說出真相，之後無論主管要強力壓迫、找人協助或是找客戶溝通，那是主管自己要負責任。 Paula 與 Mike Paula 的故事就充滿火藥味，作者設定Paula 是專業軟體開發人員，Mike 是「欺下瞞上」的中階主管，兩人的對話根本就是雞同鴨講，高層主管 Don 被Mike欺騙，一直以為歲月靜好。 作者沒有寫出故事的結局，正常情況還是要高層主管 Don出來收拾殘局。 John John的故事是負面案例，作者舉例證明該說「不」的情況，說「是」會是什麼慘況。 原本John是個有理想有抱負的青年，平日寫程式都要求自己寫出 clean code。John為了賺錢加上救世主情節，John說「是」接下短期內完成App的不可能任務，為了在短時間內完成任務，John 早就不管有沒有clean code，加班儘速把程式完成。 無奈開發過程中客戶又會加新的需求，John的接案人低估專案難度，程式開發到一半出現新的難關，John最後寫的程式慘不忍睹也無法上架。 回到現實職場 美國人較少加班，東方人就會經常加班，如果經常加班還是會出問題。 「口說無憑」會議記錄很重要! 正常情況Paula會把...

       第一章作者Bob整理數十年的職場經驗，歸納出專業軟體工程師必須擁有的修養與技能。Bob坦言自己的職場並不是一帆風順，可以感受到書中的小故事都是字字血淚，職場上Bob什麼亂七八糟的事情都遇過，Bob用毅力撐過去，持續努力外加有天分，才能成為專業軟體大師。 美國挑戰者號太空梭爆炸事件 序章提到西元1986年美國挑戰者號升空到一半爆炸，作者認為會發生悲劇是「政治凌駕專業」的結果，事故發生前已經有專業人士警告可能會有問題，無奈高層不聽，堅持維持太空梭升空計畫。 擔當責任 作者職場生涯曾經偷懶，改了程式之後，沒有跑過一遍全部測試程式，導致客服部門被顧客申訴電話打爆。 作者將負責任排在第一位，更新程式之後要確實執行所有的測試程式，專業軟體工程師要交出能夠正常運作的程式。 首先，不做損害的事 專業軟體工程師首先不是要想做有益的事，而是要想避免做有害的事。 不要破壞軟體功能 作者也知不可能有十全十美的軟體，每個軟體多多少少都有錯誤，但是專業軟體工程師不能用這個情況當藉口，依然要朝向沒有錯誤的方向邁進。 讓QA找不出任何問題 QA是品質保證部門，要讓QA同事找不到錯誤。 要確信程式碼正常工作 要寫測試程式確定程式碼能夠正常工作。作者非常注重測試，可參考 《Clean Code》第九章單元測試。 自動化QA 測試程式要寫到能夠自動化QA，例如一鍵完成測試。 不要破壞結構 要避免破壞結構，並不是儘量不修改程式碼。作者認為專業軟體工程師要經常修改程式碼，有自動化測試程式撐住，可以避免破壞結構。 職業道德 專業軟體工程師必須「努力學習，天天向上」，除了上班時間之外，還要另外找時間提升自己。 瞭解你的領域 專業軟體發展人員至少必須精通的事項 設計模式 設計原則 方法 學科 工具 堅持學習 專業軟體工程師要學習新的知識、工具與程式語言。 練習 「熟能生巧」這段如同《師父》電影的名言「每天揮舞雙刀五百下」，作者自稱每天都有練習寫程式。 協作 能夠與他人合作寫程式 輔導 「教學相長」專業軟體人士會指導新進人員，幫助別人等於幫助自己。 瞭解業務領域 例如寫財務軟體，就要瞭解財務領域。要寫旅遊應用軟體，就要瞭解旅遊產業。 與雇主 / 客戶保持一致 能夠換位思考，瞭解客戶的需求。 謙遜 「海納千川」才能夠成為大海。專業軟體人員能夠做到虛懷若谷。 最後作者...

        第五章介紹編排程式碼，讓程式碼增加可讀性。 編排的目的 程式的編排是一種溝通方式，影響程式碼的可讀性。 垂直的編排 想建造重要的大型系統，只使用200到500行的程式碼可以做到。 簡短的程式檔案比大型的程式檔案更容易理解。 報紙的啟發 閱讀報紙由上而下閱讀，每個段落會有大標題，讀者會先看大標題之後，才會決定要不要繼續閱讀小細節。 原始檔內容就像報紙，程式名稱簡單易懂，原始檔上層提供高階的概念和演算法，下層描述細節。 概念間的垂直空白區隔 每一段程式碼都代表一個完整的思緒，應該用空白行分隔這些思緒。 5-1範例有加空白行，5-2範例沒有加空白行，明顯5-1可讀性較佳。 垂直密度 5-3插入過多無意義的註解，可讀性反而不如5-4高，因為人的眼睛有固定的視野範圍。 垂直距離 變數宣告（Variable Declarations） 變數宣告盡可能靠近變數被使用的地方 區域變數應該在每個函式的最上方進行宣告 private static void readPreference(){      InputStream is = null; 迴圈的控制變數應該在迴圈敘述裡宣告 for ( Test each ; tests)   部分情況變數會宣在程式區塊的上方   for(){     TestRunner tr =  …….   實體變數（Instance variables）   Java實體變數放在類別的最上方   C++根據 scissors rule 放到類別的最下方      文中的範例是錯誤示範，中間突然出現兩個實體變數。   相依的函式（Dependent Functions）   某個函式呼叫了另一個函式，兩個函式之間垂直編排要盡量靠近。   概念相似性（Conceptual Affinity）   就算函數之間沒有互相呼叫，命名規則相似、做的事情相似還是可以放在一起。   垂直的順序   一個被呼叫的函式，應該要出現在執行呼叫的函式的下方。 ...

        有影片編輯的需求，上網搜尋免費影片編輯軟體，決定先使用Openshot 2.4.4。Openshot 2.4.4 介面簡單操作方便，非常適合新手入門。「每個軟體一定都會有Bug」Openshot 2.4.4 同樣存在Bug，嚴重影響到最後成果！上網找解方，別的網友也遇到同樣的情況，目前「無解」，有的網友選擇改用其他軟體，我選擇先做一些設定調整避開 Openshot 2.4.4 的 Bug。 初學者可參考的教學影片 免費的影片剪接軟體OpenShot基本教學 part 1 如何剪輯 OpenShot Video Editing Beginner Tutorial part 1 燒肝工程師有四部教學影片值得初學者入門參考 openshot字幕旁白與匯出 邱小姐有介紹製作字幕的方法，影片很短才可用這種方式，網友大多使用Arctime軟體上字幕。 Openshot 2.4.4 的 Bug 使用Openshot 2.4.4 之後就會發現軟體匯出的檔案有時候會出現「黑畫面」或是聲音沒有轉好出現「怪音」，上網查詢發現別的網友也有出現的同樣的情況，Openshot 2.4.4 輸出轉檔程式沒有寫好。 生命自然會找到一條出路 出現錯誤也有可能是自己的電腦硬體規格不夠力？ 原本我編輯的檔案是MTS，輸出目標轉為1080p格式MP4檔案。我先把編輯的檔案轉為1080p格式MP4檔案再進行編輯裁減，與輸出檔案格式相同。 修改設定快取的選項也有幫助，原本預設的選項是memory，改為disk 並且加大快取的容量。 做了以上兩項調整之後，Openshot 2.4.4 匯出1080p格式MP4檔案聲音和畫面正常。 不過選disk選項預覽檔案的時候畫面會變得鈍鈍的，總之預覽檔案的時候選memory，輸出檔案的時候選disk。 Openshot 2.4.4 很吃資源，一些會用到記憶體與CPU的選項最好點掉不要用，例如平行處理、自動備份與自動回報Bug。 Blender 與 Inkscape 使用 Openshot 2.4.4 之後也會接觸到 Blender 與 Inkscape 兩個軟體，影像製作剪輯要用到許多軟體！「學海無涯」  

       實例103介紹訪問者模式，可先看main函式的內容會比較容易訪問者模式的用途，蘋果與橘子是水果種類，鬆土與澆水是動作，訪問者模式可將水果種類與動作解耦合。 實例描述 範例以不同的果農對不同的果樹進行不同的培育。果園中種植了蘋果樹和橘子樹，有的果農負責鬆土，有的果農進行澆水。果樹種類不同，澆水和鬆土的方法也不同。訪問者模式實現果農對果樹的特殊訪問方式。 輸出字串「培育蘋果樹」、「果農為蘋果樹鬆土」、「培育橘子樹」、「果農為橘子樹鬆土」、「培育蘋果樹」、「果農為蘋果樹澆水」、「培育橘子樹」、「果農為橘子樹澆水」。 實現過程 //抽象果農類 public abstract class Orchardist {    public abstract void VisitApple(Apple apple);    public abstract void VisitOrange(Orange orange); }   //負責鬆土的果農 public class   LoosenOrchardist : Orchardist {    public override void VisitApple(Apple apple)    {        apple.PlantApple();        Console.WriteLine(“果農為蘋果樹鬆土”);    }    public override void VisitOrange(Orange orange);    {        orange.PlantOrange();        Console...

        實例102介紹中介者模式，透過第三者類別降低兩個類別之間的耦合度。 實例描述 範例果園之間互換水果品種進行種植，介紹中介這模式。 輸出字串「北京果園種植上海水果」、「上海果園種植北京水果」。 實現過程 //抽象果園類 public abstract class Orchard {    protected Orchardist orchardist;    public Orchard(Orchardist orchardist)    {        this.orchardist = orchardist;    }    public abstract  void PlantRemote();    public abstract  void Plant(); }   //北京果園類 public class BJOrchard:Orchard {    public BJOrchard(Orchardist orchardist):base(orchardist){}    public Orchard(Orchardist orchardist)    {        this.orchardist = orchardist;    }    public override void PlantRemote()    {        this.orchardist.PlantRemote(this);    }   ...