Mystic Pieces

最近突然靈光一閃，運用 LEGO® SERIOUS PLAY® （LSP）引導了一場團隊的 Retrospective 會議。我們使用的是探索包（Window Exploration Bag），每包的組合都相同，含有 52 塊各式各樣的 LEGO® 積木。運用這樣的工具，展開了這次的 Retrospective～

（圖片來源：https://shop.lego.com/en-US/LEGO-SERIOUS-PLAY-Window-Exploration-Bag-2000409）

LINQ 如同 C# 一般，是門易學難精的學問。也或許有人會覺得，要用再查就好啦～ Stackoverflow 滿滿的東西可以挖呢！但問題就在很多時候連關鍵字該怎麼下都想不出來，先記憶一些心法，我想會非常有幫助。細節再 Google 就好，至少關鍵字可以下得出 LINQ 的關鍵字啊！

※ 以下範例程式碼均來自黃忠成老師 skilltree 課程講義範例。

上了黃忠成老師的課，才知道平時用得很開心自在的 Where 竟然藏有陷阱！

此篇是將我自己的心得感想做一次簡單的整理。如果你之後想要參加 Daniel 的 CSM 課程，建議別閱讀這篇文章，這不是預告片阿～多少會有一咪咪微劇透，會減少您個人透過身體得到的感動。預告片請見另一篇：[CSM] Certified ScrumMaster® (CSM) 課程。

剛結束參加 Daniel Teng 2017/11/07 在台北的 Certified ScrumMaster® (CSM) 課程。此篇文章希望能夠給有興趣參加 Daniel CSM 課程的捧優一些參考，會盡可能減少任何劇透，避免有損各位在課程中產生驚豔的權益。

開腦實紀第一天草稿。第一個迭代XD

第三天的開腦雜記。未整理的草稿。

僅用條列的方式做個紀錄，讓自己未來能夠不斷回顧。

C# 的繼承架構中，除常見的 virtual、override 修飾字之外，再來就是 new 這個禁忌之術啦（不是 Class1 obj  = new Class1();  這種 new 啊～）！！何謂禁忌之術？以下的介紹就可以讓你瞭解為何不要輕易使用，很容易造成程式碼難以閱讀。各可怕的是在不知不覺中可能就使用了，不小心就會啟動的禁忌之術才是它可怕的地方，完全是手滑就開大的節奏。

這篇文章主要會簡單探討這三種變數型別如何分類：Primitive Type （基礎型別）、Reference Type（參考型別）、Value Type（資料型別）。但不會提及使用的差異性。若有錯誤，請多多指教。

是不是曾經很納悶， Google、Facebook、Apple 不是世界頂尖的軟體公司嗎？怎麼連這個小東西都會有 bug，這 bug 看起來也太愚蠢了吧～！

今天小弟就稍稍介紹一下軟體開發的世界，希望可以讓各位更瞭解這個世界到底是怎麼運作的。

條件式是程式中常見的描述句，但對於難以一眼看懂的描述邏輯無疑是增加了閱讀的困難。

人腦的暫存記憶區是有限的，當 Function 中的判斷式越「巢」，對於閱讀就更具負擔。排版上也不好看，這是應當避免的情況。此篇列出一些不佳的情況，以及提供一些避免的手段以供參考。

眾觀而言，程式碼是否好閱讀，編排、排版佔了相當大的份量。此篇列舉一些項目，提供各位參考。

沒有什麼可以比一段放對位置的註解，更能提供助益。沒有什麼可以比一段無聊教條式的註解，更能弄亂模組。也沒有什麼可以比一段陳舊而混沌不清的註解，更能傳播傷害性的謊言及提供錯誤的資訊。

曾經我以為註解多多益善，然而在閱讀完這些書籍及課程後顛覆了我原有的認知。

這又是另外一個有趣的問題，在我腦海裡，不知道哪來的錯誤認知，曾經以為只有在該段程式碼被重複使用時，才會被擷取為 Function。然而，在 Clean Code 的世界中，擷取 Function 對於改善程式碼的可讀性，是一個非常重要且必要的方式。我摘取了幾項重要的準則。

這是寫程式最基礎也最困難的問題...先撇除英文單字詞彙不足的問題，單單在命名的原則上就有很多值得注意之處。

此系列文為閱讀完 「Clean Code 無瑕的程式碼  -- Robert C. Martin (Uncle Bob.)」及 Udemy 課程 ―「C# Developers: Learn the Art of Writing Clean Code  -- Mosh Hamedani」，再加上一些團隊內部分享後的心得整理，請各位多多指教。

當我接觸到 Agile、XP (eXtreme Programming) 時

也常常聽見 TDD 這個名詞，在學習這門課前

僅約略知曉就是開發前先撰寫測試，以確保產品品質

心中不免晃過一絲絲「這只是測試人員推卸責任而已吧～」的念頭
（真的只有一絲絲喔～XD）

上完了第三天課，不只是顛覆既定的刻板思考

而是紮實有一種醍醐灌頂的感動。

Unit Test 在使用 TDD 開發時，除了單元測試的角色之外

更像是需求的描述者

但回歸到真正的實務情境上，往往遇到的不是從無到有的開發

而是從既有的架構中去新增額外的功能

於此， Unit Test 更像是重構時的保險裝置

在敏捷的團隊中，理論上至多只能擁有團隊績效，沒有個人成績

敏捷團隊重視的團體大過於個人，鼓勵所有成員能夠相互幫助、相互支援

將一切都透明化，一起成長、一起進步。

但現實生活中卻不是這樣，多數的公司的文化制度，仍保有個人 KPI 的規範

那基於敏捷模式下的團隊，該如何去訂定個人 KPI 呢？