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測試。 持續整合 持續整合系統應由原始程式碼管理系統觸發，只要有人更新程式，持續整合系統就會開始建置，並執行所有的測試。 如果發生失敗，每一位成員必須停下手邊的工作，排除錯誤之後才能繼續工作。