Tom's IT notebook

        上次『 大禹治水 』提到，對於採用 Windows＋ASP.NET＋MSSQL 技術的網站服務，找出網站系統變慢、效能不佳的原因其實有一簡易 SOP 可以起手，減少無頭蒼蠅盲目亂撞的時間成本浪費，這篇就簡單介紹一下這簡易的 SOP。         符合 “簡易” 的這個特徵有 兩個 條件： 不用額外安裝任何第三方軟件或工具 ，只使用作業系統內建的基本工具即可。 與系統特性無關 ，不需要先理解遇到麻煩的系統任何內部原理與商業邏輯。         所以任何任何人，都可依照這個 SOP，花個半天時間迅速判斷 80% 以上的網站效能瓶頸點。

（圖片源自 ”log4net面面觀之工作原理“ ）         一個系統是否容易追蹤與維護？出了問題容不容易快速查閱、釐清問題癥結？系統日誌（ System logging ）絕對佔著舉足輕重的角色。.NET 寫系統日誌的方案，最出名的大致上只有兩種： log4net 和 NLog 。兩者之間沒什麼優劣比較，這種東西，精通其中之一就很夠用。

        楚狂人 的『 玩股網 』前陣子發文公告系統不穩的情形，這兩天他寫了篇『 玩股網驚魂記 』說明了前因後果，看完後覺得可以當作一個個案解析的案例。         先談談文章所說最後發現玩股網無法正常運作的結論：被大量的 Crawler（ 網路爬蟲 ） 抓資料導致伺服器過於忙碌。開頭原本說判斷這應該不是駭客攻擊，其實就結果來看，這也算是一種攻擊手法： 分散式服務阻斷式攻擊 （ DDoS ） 。

        今年四月，正徘徊在職涯下一步的十字路口，當時剛好接到前同事電話力邀我加入一個剛成立半年的新創公司團隊，一起打造一個全新的新產品而努力。         當時被原公司既有的營運系統基於管理上風險的考量，而搞得拳腳難伸的我，在與灰心喪志之下，很受 眼前這個可以盡情嘗試各種全新技術與各種假設的創業機會所吸引，毅然訣然地揮別前公司 。         由於要能盡情試驗新技術、開發流程與團隊合作的模式，我加入的條件就是我必須擔任掌握這些權力的  Team Lead（這篇） 。         然而真正置身此處，才發現事情也沒有想像中那般美好。

        科技幫助人溝通越來越快速、方便，但是人與人之間的溝通，還缺了一個重要的環節。 我們團隊所製作的 Bubble Chat ，就是為了補足這遺落的環節。           進入我們的 APP ，首先結合超級好用的 YahooMap，精準地呈現你所在地週圍，其他人透過這個 APP 所分享的生活大小事，心情喜怒哀樂。

        剛好透過 INSIDE 網站宣傳得知 Yahoo 今年所舉辦『 駭客松（Hackthon） 』。         我實在認為自認有熱情的開發者，一生中都應該至少來體驗一次這種 “ 燃燒生命、爆肝寫 Code ” 的活動！所以之前總是錯過這類活動的我，這次看到比賽消息，立刻在 FB 上揪團參加。         由於這次競賽的要求跟過去以往不同，特別強調 UI / UX 設計，並且要求團隊中一定要有至少一個 Designer 參加 ，所以造成這次比賽隊伍中，女性比例大幅提高，每隊通常會有一個女性參加（ 本隊也是 ），甚至有團隊是完全女性組成的四人隊伍。如果去網路上尋找過去幾屆的比賽作品，相比之下也會發現這屆 DEMO 的作品視覺上質感有大幅提升的效果。

        前幾天一位前同事到家裡做客，邊玩邊聊，談到他最近在工作遇到的挫折。         這位前同事跟我一樣都離開前公司後，帶著一些理想加入了新創公司。先前我一直鼓吹他要積極爭取新公司新團隊內 Team Lead 的角色，但 自認淡薄名利、不想爭權奪利，只想好好做事的他，覺得誰當 Team Lead 都一樣，所以並沒有把我當時的建議當回事 。如今，在這個依然 沒有 Team Lead 的新創公司內，他遇到了團隊合作中 無法跨越的磨合障礙 。         這個新團隊的組成各有各的來源與背景，大家帶來的做事方式、文化、習慣與見解各不相同。而其中兩人洽巧是同氣連枝的夫妻檔，難以溝通和差異頗大的做事方式讓他配合起來苦不堪言。         對原本堅信透過實事求是、良好的溝通就能達成共識的他，我直白的說：「 我的經驗告訴我，溝通不是萬能。你們需要的，就是一個拍板定案的 Team Lead 。 」         「 但是公司 Manager 說：Team Lead 要等第一階段上線後，看誰的表現好，再決定由誰擔任。 」         真是大錯特錯！         已經陷入群龍無首局面這樣糟糕的團隊，管理階層還想把問題拖到上線後才處理？這樣的思維，代表管理層把 Team Lead 這個位置當作一個 promote 的獎勵手段。無功不受祿，對於才剛成立尚未有戰功的新團隊，用這樣的思維當然會找不到 Team Lead 的合適人選！ 這時間點該立即找到的人選，該是願意挺身而出為成敗負全責的人擔任 ！也只有願意替成敗負全責的人，才有拍板定案的權力！          這時候的 Team Lead ，未必他的薪水就該拿的比其他人多，單純只是承擔更多的責任和壓力，所以不必用 promote 的眼光看待這個職位 ，這需要事先跟其他團隊人員溝通清楚，避免破壞團隊合諧的誤會。   ...

        這次榮幸獲 Yahoo HR 的安排參加這場 2013 Tech Conference。看到活動邀請函上寫著『 無限供應的自助餐點 』，抱著白吃白喝看熱鬧的心情，在 9 / 12 日當天晚上，來到了南港軟體園區的雅虎辦公室。

原圖取自馬克的部落格         我最感到幸運的，是這一路上遇到幾個願意帶我的師傅。其中一個待我相當嚴苛（ 當時我常常心裡有很多抗拒 ），然而現在回想起來，卻也從他身上學到、領悟許多。其中他讓我體悟到影響至深、最重要的一點，不是技術，而是某些做事態度， 尤其是『程式交接』這件事 。

        JD，Job Description ，是應徵招募職缺時重要的參考資訊、也是一個公司營運方向的重要體現。讓我們來看個我手上最近拿到的範例： 1.         BU Team Lead   a.        Product technical owner   b.        Provide technical support to project/incident   c.        Provide mentorship and guidance to fellow team members   d.        Assist to manage/review release process 2.         Technical Architect   a.        Review project/incident design by request   b.        Code review by request   c.        Establish the code standard 3.         Production Support   a.        Analyze sticky incident   b.        Support...

        今年初，我以系統架構師的頭銜離開了前公司，來到了一個才 start-up 三個月左右的新創公司當 Team Lead，帶著五、六個人的開發團隊力挽狂瀾、力保三個月後能讓該公司的新創產品能順利上線。         這段時間我算是忙到昏天暗地，每天工作時間超過十二小時，甚至還有做到清晨四點下班，然後早上十點又繼續上班。可以說沒什麼體力心力寫部落格，任其荒廢了好一段時間。         這段時間，我不斷受到內心或是外在所謂『架構師』和『創業家』角色之間的拉扯。但想想自己當初跳脫上一間公司的角色來到這裡，諸多原因之一，就是我想認真學習如何成為一個『創業者』！         但是，架構師和創業家在思維上是很衝突的。

        傳說中葉師傅是個以一打十的功夫英雄、深居簡出，是個頂尖的人才 。         求才若渴的老闆，三顧茅廬尋訪多年、重金禮聘，花費 9999K 終於請出葉師傅到我們公司上班。老闆欣喜若狂，認為嘔心瀝血總算讓這麼一等一的高手出任敝公司職務，公司前途光明，發展不可限量。         「 這位老闆，先說好，沒有以一對十的場面我可是不幹的。 」葉師傅醜話說在前頭。

        只要在軟體開發圈子混一段時間，尤其已經有系統 run 在 production 環境上，十之八九會聽到這句廣為流傳的經驗談：「 東西沒壞就不要修。 」         這句話，常常被反對重構（ refactoring ）者掛在嘴上。

        在進行軟體開發的系統設計，有兩種迥然不同的思維模式， 一種是由下到上的 BottomUp，也就像是蓋房子一樣，由地基規劃打底開始，逐步往上；另一種是由上至下的 TopDown，由需求主導，逐步向底層延伸 。甚至，微軟曾經為了不得罪兩邊的支持者，提出了折衷的 MiddleOut 從中間往兩邊延展的模式，但落得兩邊都不討好的下場，所以這個含糊其辭的異教論我就不在此討論了。         十年前當 XML base 的 WebService 初試啼聲，彷若帶來一道曙光，是 IT 界整合的創世救星的年代，那時候各種系統整合的名詞蜂擁而出，開始有 SOA（ Service-Oriented Architecture：服務導向架構 ）、 BPM（ Business Process Management ）或是 ESB（ Enterprise Service Bus：企業服務匯流 ）⋯⋯等令人眼花繚亂的名詞，當年我負責協助金融業導入相關技術產品與專案，就遇到究竟該 TopDown or BottomUp 僵持不下的爭論。

        當單機軟體服務已經幾乎被淘汰，網路服務已經成為顯學，所有的應用幾乎都要求 web 化，網路應用服務供應商如何自己建置，或找到穩定、經濟、合用的伺服器 Hosting 環境，已經成為燃眉之急的要務。        雲端這個詞正夯，有人認為這只是個行銷名詞，跟過去網業虛擬主機或是主機代管並無差異。為了釐清這樣的誤解，微軟替現在的『雲端運算』做了如下的定義： 虛擬化 和 可攜性 。