今天的筆記

在做產品的時候，才意識到前處理和後處理的重要性。也就是說，模型在成本的考量下應該不會是完美的。如果以前就了解這點的話，也許當初當兵的時候遇到的動線和計數問題，就可以好好想一個可接受的解法了呢。

趁著剛剛寫完 Another 的觀後感，來寫一寫讀過的偵探作品們。 前一篇有提到，大學的時候有機會做日本偵探小說的流派的報告，卻沒有把握機會好好了解。那這次看了 Another 這個綾辻行人的作品，也算讓十年前的未竟續上了一些補完。而因為提到「我也讀過一些偵探小說」這句話，讓我趕快去查了下我讀過的小說。 一開始進到我腦海裡的是福爾摩斯的叢書，還記得小時候爸爸媽媽帶我到東海大學的敦煌書店裡面看書，那時就看到了福爾摩斯，對於偵探這個概念覺得又神祕又帥氣，並且覺得墨綠色的封底的小說，整潔與莊重感湧現，便讓媽媽為我買了這本書，記得是「血字的研究」。或許就是這個時候開始喜歡書擺在眼前、拿在手上的感覺吧。但福爾摩斯並沒有怎麼激起我推理的天賦，我當初直到現在都還是用一種讀冒險小說的心情去讀的。當然，謎底解開的時候的舒暢的感覺是蠻喜歡的。小時候後來也收了很多同系列的福爾摩斯的書，我有意識到我好像是在收集整套叢書，我喜歡他有質感的封面設計還有排起來的充實感，而不是真的熱愛推理小說。XD 另一套書進到我腦海的是， 赤川次郎的「糊塗偵探迷推理」（或「大貫警部」）系列，由希代出版社出版（寫這篇文章的時候，完全不記得書名和作者的名字，只好從維基百科的日本推理作家列表開始一個一個看。）。在搬家前，家裡有這麼本書，大概是爸爸買的，我一直沒有跟爸爸確認過。同作者的書，家裡也有三色貓系列，但我沒讀過。總之這本書裡面收錄了，謎題漫畫（起承転結殺人事件）、搖滾殺人（満員御礼殺人事件）、攝影蒙太奇（四苦八苦殺人事件）。在小時候的時候，就這麼一本反覆看了好幾次，並不是享受推理的樂趣，而是單純的喜歡作者的輕鬆詼諧筆法和活靈活現的逗趣人物，記得戀愛的橋段也讓我蠻喜歡的。 後面的其他日本推理小說，我是查了維基百科才知道原來有些現代作家的作品也是推理小說，我還以為大部分會是我沒讀過的經典作品。聊列讀過的作品如下，幾乎都是青少年時期、高中的時候讀的： 我孫子武丸 殺戮之病 伊坂幸太郎 死神的精確度 西尾維新 DEATH NOTE Another Note 洛杉磯BB連續殺人事件 乙一 GOTH 斷掌事件 大澤在昌 新宿鮫．新宿鮫 Ⅰ 小野不由美 黑祠之島 (我才知道原來綾辻行人是小野不由美的丈夫。XD 做這些記錄很不錯，那也是我曾經燃燒興趣的所在。 這些書，可以想到基本上都是封面做得很漂亮，我以前的時候真的是很看封面...

  之前不知道是聽到誰推薦 Another 這部動畫很不錯看，就一直放在心上了。後來發現在 Netflix 上面有，最近就一集一集的追完了。是說像這樣的鄉下某種壓抑的、不可多談的鄉下禁忌或傳說或儀式，還真的是很常見的題材呢。現在讓我印象最深刻的還是小野不由美的「黑祠之島」。 先說這部動畫的優點，整體的氣氛塑造得很不錯，蠻壓抑的，來回過幾次突如其來的詛咒死亡，也讓人在後面有任何風吹草動都會緊繃起來。前期的便當也發的很不錯，電梯失速的橋段尤其精細精彩，緊張、恐怖和絕望感濃烈。 我不太喜歡的地方是，我覺得主角的行為蠻反人類的，他對於鳴有莫名的執著，只要是聽到跟鳴有關的東西，馬上就會分心掉，不管當下在進行什麼事。相反的，他對於同學的死異常冷漠的。最誇張的橋段是，他在河岸邊逼問同學高林關於詛咒的事，不知是由於緊張或是詛咒，高林疑似心肌梗塞班倒地不起口吐白沫。畫面切換後，我們才得知高林後來去世了，但主角不但對於高林的死不置一詞，也完全沒有想過他的死是不是與詛咒或與他自己有關，一點愧疚感或者恐懼感都沒出現，這真的還能算是人嗎？看多了他這樣的反應，還真的會開始懷疑他是不是就是死者。XD 另一個點是，我覺得主線不斷地跳動。從一開始的鳴是不是活人，到鳴為什麼被無視，然後是主角到底是不是死者，再到後面的以前的學長留下的線索是什麼？錄音帶裡說了什麼？本來以為一切都是串連在一起的，尤其是男女主角的身世，但看到最後才發現鳴的身世其實與此事件關聯並不大。尤其是當知道鳴是活人，只是被班上的政策排除在外的時候，再回想起一開始的懷疑真是令人發噱，原來只是鳴移動的速度比較快、然後主角從來沒有想過跟別人確認鳴的存在而已。 既然是綾辻行人的小說改編，當然要來看看解謎的部分。謎底揭示的時候我覺得有兩個地方斧鑿之跡也未免太重。其一是鳴突然回想起來，當怜子遇害時候，她就在現場目睹一切。我猜導演想讓主角陷入該相信哪邊的困境。「會不會只是鳴為了說服他揮下斧頭而說了謊？」但如果是這樣的話，也代表恆一從一開始也沒下定決心嘛（當然這是在說動畫裡，現實中有人可以這樣下定決心的相信一個人的話對至親揮下斧頭的話，那還真是令人毛骨悚然）。其二是主角回憶起在家裡怜子綁起頭髮變身成為副班主任的橋段，這個前面完全沒有出現的線索，讓我覺得導演好像在嘲諷我說「你沒注意到這點對吧？難怪你找不到答案。」。當然我有注意到一個違和點是主角...

我在高中讀的國文補充教材〈梅花嶺記〉，提到了史可法死前的故事，讓我印象深刻至今。 大意是史德威臨危受命，要取史可法性命不讓它落入敵人手中。怎料在危機關頭，德威終究心軟沒能砍下殺死史可法那一刀。最後還是讓史可法被綁到敵軍面前，大罵而死，連屍體都沒能保存葬於梅花嶺。一次違背兩個交代。 我看完後只想說：「德威，你真的蠻雷的。」。

 在最近開發的過程中，發現了每次增加新的 feature 就要來重構，想要歸納一下每次我在做的事情。 我想我每次重構的心得如下： inner static class 最後好像還是會被抽取出來 在一開始，必然是先用簡單的變數組合來代表某一觀念。 然後會組成 static class ，概念是不必要讓這個類別暴露給其他類別知曉。 然後在功能越加越多的時候， static class 一定會被獨立出來。而通常有兩個原因： static class 變得過大。如果一個 inner class 的內容與他的 outer class 內容差不多多的話，那還是不要放在一起喧賓奪主了。 static class 會被第三個類別存取。在這種情況下，當初的封裝變得多此一舉了。 那也許一開始就不要用 inner class ？ Strategy Pattern 終究會被引入 在一開始通常沒有這需求，等到差異性顯現出來時，不抽成抽象方法而是使用 interface 作為參數傳入。 這在美感上也比較討喜，將兩件權責劃分開來，測試的時候的排列組合更少。（個人想法） 終究會抽出更多短方法。 在一開始寫的過程中，總會覺得這段邏輯抽成方法太冗。 但在重構的時候，卻又反而會覺得他不易理解。 「不要輕易相信自己的記憶」？同一段程式碼在過一段時間回頭看仍需要重新理解它？ static / non-static 來回切換。 在最後總有些東西好像擺在 static 也行  non-static 也不錯，這時候會經歷來回切換的時期，不過或許在更之後，重新審視就會覺得這個東西應該是無懸念的  static 或 non-static。 方法的參數過多，通常會被拆開。 這個確實就是所謂的壞程式碼的味道，幾乎一定會需要被拆開。 盡可能地多命名。 這跟第三點很像，每次回來還是需要重新理解，所以第二次第三次回來看的時候，都會再給所有暫存變數更好的名字。 終究第一次取的名字就是不好，第二次的也差不多活不久。 在新暫存變數、新功能引入的時候，不免會有與現有命名重疊、或不一致的情況發生。所以第一次和第二次的命名大概以後都會被爆改。 終究會引入 stream。 有時候只是沒有把判斷式寫成方法，就直覺得寫 for loop ，但重新回頭看，用 stream 這樣有點 transcation 概念的解決，...

第一篇居然是菜雞的自以為的寫法，誠惶誠恐。我想試試看能不能在網路上找到共鳴，或當然，有指正那最好了。 在寫 java 的過程中，一些與類別實體無關的方法，就會很自然而然地把他們寫成 static method，然後包裝在一個只含有 static methods 的 class，在命名上給他加上個 -Utils 後綴。 這個寫法的啟發，來自於在公司參加的 Clean Code 讀書會。在 Clean Code 的第三章，作者 Uncle Bob 提到「應該避免使用多於兩個參數」。那當參數過的時候該如何解決呢？很簡單，把其中幾個參數提升為類別變數就可以了。 這讓我想到在專案裡面四散的 static methods，幾乎每個方法的參數都有五六個以上，其中又至少有三四個是要層層傳遞下去的。而仔細一看，層層傳遞的那些變數基本上都不會變化。 該怎麼做呢？ 我現在嘗試的寫法，是建立一次性的類別物件來處理。 以矩陣乘法為例， static method 的寫法如下： Matrix c = MatrixUtils.multiply(a, b)    一次性物件的寫法如下： Matrix c = (new MatrixMultiplier()).multiply(a, b) 以上的例子或許過於簡單，不過在構想裡是，把「設定」類型的參數放在建構元中，或者把所有的所需要處理的參數也都放進來（畢竟是一次性的），然後再處理的過程中，讓類別方法去修改類別變數，降低每個方法的參數量。 我想，對於與實體較無關聯的功能，寫成 static method 再正常不過。 但當完成一個 static method 需要呼叫多個 static method 的時候，或許就可以考慮用類別進行封裝。 或許是因為這個方法太顯然？或太不值一提？我不是很確定這個東西有沒有名字，我自己暫時把它叫做 Builder-like 寫法。如同 Builder Pattern 最後總是呼叫 build() 來結束這回合（回傳建立好的物件），這個寫法也是呼叫某個方法完成所有事情，就可以把這個物件拋棄。  但這個寫法缺點是有點不直覺，同時完全使用 static method 的寫法也沒有任何錯誤，這樣的寫法差異算是哲學層次的。究竟以後會不會繼續這樣寫，我也不是很清楚。只是先紀錄一下，想知道以後自己會...