Search
這是 @Odd-e Philippines 團隊的 Ealden 針對 Specification by Example 與 cucumber 整理的一篇介紹文章。
workshop 的題目叫 Emerson’s game。（Emerson 是 Odd-e US 的同事）
※ 但文章封面圖的照片沒有他們兩個，哈哈，上面是 Odd-e Thailand, Australia, Singapore 的同事。
文章這裡去：https://ealden.escanan.com/specification-by-example-1096b613cce2
文章內容不深，用 java 當範例，該有提到的點都有，大家如果在菲律賓也有 agile/tech coach 的需求或是技術培訓的需求，也可以聯繫我，我可以幫你跟 Ealden 建立連結。
Web Testing + Page Object 暖身中。
其實這邊我覺得搭配 cucumber 並沒比較好，如果沒有需要跟 PO/需求單位確認，而且測試重構完的意圖呈現可以很清楚的話，目前我還是會傾向直接寫 test case + testing code。
specification by example 還是要做，但是不是非得用 cucumber/BDD style/Robot Framework 來實現，我還是會建議 by case，你得看用這些東西可以滿足你什麼需求、解決什麼問題，再決定要不要用它。
※ 可以捨棄年久失修的 fluent automation 了。
補上 living documentation 的產生：https://www.youtube.com/watch?v=a3gu4UT91FY&feature=youtu.be
這一位也是從高雄搭車到台北參加兩天 重構與TDD 培訓的熱血夥伴。
他提到拍肩膀的那一段，也是那兩天課程裡面我最大的一個記憶點。
孟哲跟他的 pair 正一起 pair programming 開發我給的需求，孟哲發現這樣設計好像會有問題，提問之後，pair 回答問題跟解釋作法的方式，我發現他的神情有些困惑。接著孟哲說：「好吧，那你先寫好了...」
我其實知道他們兩個在講的，是不一樣的東西，而且孟哲的提問是對的，但他放棄繼續溝通了。 （反正等你寫完你就知道我剛剛在講什麼...XD）
所以我趁這機會告訴他，你的問題很好，不要放棄溝通啊。你們兩個的思路不一樣，但這是個很好的問題，有機會提早發現設計上的問題。
接著讓他們再交流聚焦了一下，他們就一起往有共識跟比較合理的方向繼續設計了。
---
其實挺有趣的，這種幫助不純粹跟技術有關，卻跟開發很直接相關。
越晚發現問題，修復成本越高，這是軟體開發的定律。然而有機會在第一時間發現問題，卻放棄這個機會，這真的相當可惜。
能藉由這兩天，發現並正視自己還有哪些可以改善的方向，並找到方式改善。能發現自己不知道的東西，並對這個未知感到興趣跟有動力繼續往下研究。
對我來說，這才是點火師的專業效果。
上課的價值，不是只有這兩天的內容。如果只有這兩天顯式的內容跟代碼，那太不值了...
要把培訓當作是種 #投資，就要想辦法把投入的成本，發揮效用、創造價值，獲得更多的收穫，才是投資。不然就只是買個心裡暖暖、嘴巴爽爽的 #費用，或是一張證書的 #收據。
你們的時間與青春，比這珍貴多了。
上個週末參加了 91 哥開的 TDD 與重構課程，兩天課程體會蠻多的，除了更全面地了解 TDD 的精神、怎麼使用、跟持續重構的搭配、親身體驗 TDD 會遇到的挫折以及如何避免/突破，也深深覺得 TDD 實在是個富含生活哲學意味的開發模式，各種要點似乎都能和生活觀緊緊相扣。以下整理一點個人心得紀錄，文長慎入。
話說這課程蠻神奇的，一張投影片都沒有，除去開場講師用母雞帶小雞的步調詳細解說需求探索的部分，大部分時間都是同學們照著講師提出的需求，在現場被抵在脖子上的時限逼著實作，很有一般專案開發的臨場感吧。由於對 TDD 模式不熟悉，在有緊迫時間壓力的情境，很容易就讓人忍不住跳回傳統開發思維的舒適圈，於是就容易寫出一堆高耦合的糞 code。不過糞 code 倒也不是毫無用處的，它們在之後都變成了練習重構的肥料。
此外，兩兩 pair 進行的 coding 模式，也考驗兩人的溝通能力，記得我在第一 round 實作開始沒多久，馬上就被 91 哥從背後拍拍肩膀糾正：「不要放棄溝通啊。」的確，我的確很容易放棄溝通，在發生雞同鴨講或是彼此頻率沒對上的對話時，假如對方不是熟到爛掉的親友，我總在第一時間會退一步，說好聽點是想要觀察對方想說/想做什麼，但說穿了就是懶得花心力取得共識。在開發的情境中，能及早取得共識是一件極重要的事，哪怕第一時間需要多花點口舌釐清兩人的想法，也比後面走了岔路再回到原點依然要花費口舌重新釐清來得划算。這一點其實也和 TDD 的精神不謀而合，對於錯誤及早發現及早治療，沒弄清需求就往下走，無異於賭博。很高興這一點能被戳破，讓自己有一個改善的契機。
至於要怎麼確認對方認知和自己認知是否確實一致? 91 哥也傳授了一個意外簡單的方法：丟出錯的答案來逼對方以正確答案糾正自己。把自己認知的邏輯代入具體數字的表述給對方聽，如果認知是錯誤的，就可以得到即時的糾正，要是明明認知錯誤對方卻沒有即時糾正，那認知錯誤所導致的結果就是兩人一起承擔，不會有責任都在某一方身上的問題，不得不說真的是人性化！很像用爛提案逼出好點子的麥當勞理論，也有 Specification By Example 的味道，「怕犯錯或怕問錯」則是這簡單方法最大的門檻，所謂「要臉就學不會」就是這麼回事吧。
91 哥霸氣的宣言可以精準地描述 TDD 精神中個人最喜歡的一部分，「如果是沒必要的，我連一個字都不想寫。」大概類似這樣的句子，有需求才有動作，需求不用很大很遠，但要清楚並且有效益。而凡事過猶不及，如果一直坐在原地等所有需求或計劃都出來了才動手，又不符合 TDD 精神了。TDD 的啟發是走出第一步，後面的路才能繼續走下去，計畫永遠趕不上變化，掌握大方向以後就可以開始前進，細節是依著沿途的需求來慢慢完成的，人生和專案啟動以後永遠都是隨時在變動的渾沌狀態，一個能死守的完美制度或計畫只能是妄想，"Plans are nothing. Planning is everything."
回到技術的部份，單元測試是 TDD 循環中最基礎也最重要的一個環節，沒有它做為基底，說要重構什麼的都是假的。單元測試是盾、重構是劍，也不是沒有不帶護具就上戰場的人，但如果這人不是身經百戰的老兵，我們就會覺得應該是梁靜茹給了他勇氣。如何寫優質的單元測試本身就是一門大學問，在這次的課程裡其實並沒有太深入的著墨，這部分另有開一堂專門的課程探討。
當初報名課程之後覺得自己好像有點衝動，竟然就這樣花了萬把塊跑去台北上才短短兩天的課，上課內容還是我才認識不久甚至在實務上都沒使用過的 TDD。但一方面是當下真的想把這開發模式納為己用，另一方面則是對 91 哥的課程蠻有信心的，畢竟也是大前輩而且看課程口碑都不錯，所以也就還是衝了，這對於一個失業人士來說還真算是一筆不小的投資啊，但反正我是「錢沒有不見只是變成你喜歡的樣子」思想派的，哈哈。上過極度燒腦的兩天課後是真的覺得獲益良多，當然距離能活用還要經過反覆不斷的練習(91 名言：「不練習，都是屁。」) 這是一條漫漫長路，但至少是方向明確的漫漫長路。
以前都覺得資訊流通的時代獲取知識應該不再需要花什麼錢了，這個想法在近來才漸漸被自己推翻。前陣子上 Hahow 的前端特效課程時清楚地感受到，沒有專家在前指引，在現在知識量爆炸的環境下自行摸索一門全新領域的知識所要花費的時間簡直是以倍數計算，更危險的是自己摸索的過程，有可能根本就「不知道自己不知道什麼(You Don't Know What You Don't Know)」，所以我覺得完全自學而成為專家的人，真的很強。這次的 TDD 課程再次有這種感覺，由網路上片面資訊所建立的 TDD 認知跟實際上的 TDD 之間便已經有一段差距了，如果沒有實際走過一遭挫折到突破的路，永遠不會對這模式有信心，自然也不太可能在實務上咬牙決定使用結果遇到問題時想盡辦法克服，信心真的太重要了啊。91 哥說他的課很難留下一些實體教材這類 KPI 性質的東西，但課程帶來的影響其實是直接種在學員們心裡了吧。轉職中的無業遊民也沒法推薦同事去上課什麼的，僅以此文幫 91 哥的課程做個口碑推薦，軟體業朋友如果有興趣想要體驗一下懷疑自己「是不是不會寫程式」的感覺，可以看看他開的課程和一些之前課程花絮照片之類的，因為名額不多通常都蠻快就額滿了，大概都要提前半年報名。最後感謝雅令老ㄙ優秀的前同事兼學弟推了我一把讓我下定決心去上課，感恩感恩。
Previous Video
●How to download Hyper-rom for S3
○ https://m.youtube.com/watch?v=Kw6tSIHl3Dg
Description
The objective of this technique is to provide a way to link to remote long descriptions in technologies that do not have a long description feature built directly into them (e.g., longdesc) or where the feature is known to not be supported.
With this technique, the long description is provided in another location than the non-text content. This could be at another location within the same URI or at another URI. A link to that long description is provided that is immediately adjacent to the non-text content. The link can be immediately before or after the non-text content. If the description is located along with other text then put "End of description" at the end so that they know when to stop reading and return to the main content. If a "Back" button will not take the person back to the point from which they jumped, then a link back to the non-text content location is provided.
This technique was commonly used in HTML before 'longdesc' was added to the specification. In HTML it was called a D-Link because it was usually implemented by putting a D next to images and using the D as a link to the long description. This technique is not technology specific and can be used in any technology that supports links.
ExamplesExample 1: Bar chart
There is a bar chart on a Web page showing the sales for the top three salespeople.
The short text alternative says "October sales chart for top three salespeople."
Immediately after the non-text content is a small image denoting a long description. The alternate text for the image is "Long description of chart". The image links to the bottom of the page where there is a section titled "Description of charts on this page". The link points to this specific description: "Sales for October show Mary leading with 400 units. Mike follows closely with 389. Chris rounds out our top 3 with sales of 350. [end of description]"
Example 2: Bar chart - in non-HTML technology where user agent "back" is not supported for security reasons.
There is a bar chart on a Web page showing the sales for the top three salespeople.
The short text alternative says "October sales chart for top three salespeople."
