11/29 ~ 12/5 週記(v2.0)
終於要上日文、12月的第一週…
週記部分嘗試一點變化，最後一部分更加詳細&分類。
讀書
泡在日文的一週。
日文
在最後練習之前特地為了考前保留的模擬試題，作為複習的收尾，並看一些前幾天整理的常混淆的句型比較，並看點日劇做聽力練習，這些就是我考前最後的掙扎了。
技術
資料流的處理
雖然前端畫面不管什麼方法，只要你做得到基本上都可以做到一樣的效果，但是一旦需要擴充或是修改的時候，就會牽涉到自己當初是如何「設計」的了，尤其是資料流的處理，該如何切分資料的大小顆粒度，哪些部份是由視圖(view)在轉換就好，哪些是要事先處理，以及狀態的儲存與更新該怎麼分配，一旦組件之間耦合的比較深，那麼在修改時會非常難處理。
例如，可能你先做了A功能，做B功能時才發現原本的A功能需要大改，這表示你在前期階段沒有考慮到之後的情境(也有可能是需求方沒講清楚)就做比較封閉的設計了，然而該怎麼設計資料流與組件，這就端看你的經驗了，也可以參考SOLID、OPP之類的設計原則多加以練習，漸漸把程式寫得更加彈性吧(自己也在朝這方向努力…)。
雜談&反思
雑談(電影) — 生存家族(Netflix)
原本以為是主角被辭職之後，轉換人生跑道之類的故事，經典日本作品常見的套路，沒想到故事是在描述，突然的”全球大停電”導致所有電器都無法使用，主角家族一行人如何度過難關活下來的故事，其中有幾個轉折滿令人意外的，是個值得一看、會令人反思的好電影呢。
更詳細的心得與電影摘要(有暴雷)
雜談(日劇) — 半澤直樹其中一段的小感想
尤其是看不見的人際關係與小動作，都藏在平時說話中不經意流出的”習慣”之中，像是半澤注意到在平常不過的對話中的”不尋常”，才發現tomy和老闆娘是舊識；也從各種抱怨和態度中發現對方真正的立場，進而說之以理、動之以情地攏絡對方成為自己人，一起為了同樣的敵人戰鬥!
雖然現實職場或許沒有如故事般的波瀾起伏，但是觀察及注意身邊的細節，在人際關係上可以避免踩到他人的底線；工作上也能藉此得知對方的一些真正想法，例如講某些話語時眼神飄移、講的東西前後矛盾等等，能讓交涉更加順利，甚至讓你占上風，讓交涉偏向對你自己有利的局面。這些都是透過細微觀察，並抓出”令人在意”的細節，或許就能透過這些”小兵”立下大功呢。
雜談 — 關於中風的處理
看白色巨塔剛好看到”中風”這一段劇情，查一下關於中風的緊急處理及預防，主要有幾個重點:
檢查(FAST): 主要檢查是否左右兩側的動作是否”對稱”
- Face: 請對方”微笑”，看兩邊的肌肉動作是否對稱
- Arm: 舉起雙手，如果其中一隻手垂下來，表示有可能是中風
- Speech: 講話咬字是否如平常時清晰
- Time: 詢問”何時”出現徵兆
緊急處理:
保持呼吸順暢，讓病人維持側躺，以防口水嗆到
預防:
只有一個重點: 均衡飲食、充分休息、適度運動
反思 — 職業與業餘的差異
最近在開發公司專案的相關功能時，業主他們參考的範例就是「第三方」製作的網站，網站呈現、操作都不是問題，而重點差異是「背後的資料來源」，別人的網站並不用「背負任何責任」，只要一個聲明即可。
然而我們做為官方的製作者，則必須負起「資料正確」的這個責任，使用者操作或介面或許可以接受一些不滿意，但是資料上的「誤差」，則是一點點都不能接受的。
然而這個功能的資料並非我們公司製作及維護的，等同是我們必須花人力、時間成本去「維護」這份「假」資料（正常流程是由官方提供數據，如政府公開資料等等的Open Source API才進行製作），而這次應客戶要求，必須人工抄一份資料到資料庫作保存，只是為了這個特例，就要花上許多「未知」的追加成本，實在是不太划算呢！
反思 — 數據分析果然還是要有結論或建議
在這週與客戶討論的會議之中，PM秀了一份文件，該文件的內容主要是呈現一份數據報告，因應客戶之前提過需求而做的調查的數據整理，然而，這份文件「就只有」數據整理，沒有開頭與結尾，更沒有「結論」。
因為客戶自己似乎也不記得該調查數據的緣由了，一直在問說這份文件到最後是要說什麼? 是否有什麼結論或是建議? 雖然討論的事情與我的專案無關，但是看到PM也啞口無言，實在令人印象深刻，畢竟對於客戶來說，數據僅僅只是「數字」而已，我們必須賦予「意義」，該調查才有價值，必須說明是否為趨勢變化，或是哪些數字代表著什麼，亮點在哪等等。
總之，不管是調查、簡報之類的報告，尤其是針對客戶或老闆，最重要的不是內容而是結尾，一個好的結尾會令人印象深刻，是影響你該次報告成功與否的關鍵呢。