一個問題的解決過程

昨天發現自己申請的微博興趣認證Title成功了，但是人的整個Title變成了：

感覺這個Title描述太重複啦。順著就想到去重。然後就粗粗寫了一個去重代碼：

然後 @Laruence 鳥哥看到了，說用array_filter()來實現更合適，當時也沒細想粗粗覺得不合適。然後鳥哥說他寫個給我瞅瞅，然後鳥哥Style的代碼出來了：

嗯嗯好，鳥哥這段代碼確實簡潔漂亮，不愧是鳥哥，要贊一個。

同時自己前面還想到了轉換為字元串來查找操作，這裡面用到了substr_count()，估計很多人不認識這個PHP函數吧？PHP不僅處理數組、關聯數組很方便，處理字元串起來也是杠杠滴：

但是有人又提出了「如果前一個元素的最後幾個字跟後一個元素的前幾個字恰好是數組裡的一個元素。這不就出來bug了」？這段代碼應對微博V認證頭銜字元串是沒有問題的，但作為程序員，強迫症又犯了，不去考慮更廣泛的用途顯然自己心裡覺得不爽啊。於是又想了一個這個：

吶！總之呢，寫代碼的魅力就在於你可以充分發揮你的想像力，去寫得更優美、更有效、更易懂......等等等等。同時在圈子裡一起交流，不僅能相互提高，而且充滿了寫程序的樂趣。當然，樂趣僅僅是一個方面，真正的業務代碼還是不太一樣的，寫業務代碼時也需要充分權衡，比如需求設計的適度性，而非在非Key點上過度設計，關鍵是權衡好各個角度：代碼長短？執行性能？代碼美感度？夠用還是完美？等等等等的。

此外，還看到一個網友的正則版本：

也許還有更極客、更有意思的寫法，有興趣的可以來show一下......

----------- 2017-12-22 補充 -----------

原來說的filter不合適，確實應該是我的潛意識認知在當時的一種直接反應，而這種潛意識當時沒有認真思索，但現在發現這個潛意識直覺應該是對的：本問題描述成「歸納出數組中不是其他數組項之子項的數組項」，顯然比「過濾出數組中不是其他數組項之子項的數組項」更合適，因為filter需存在各個項與其他項的一個依次遍歷比較過程，複雜度會比較高，而歸約（Reduce）的過程，只需處理各個項與累加器（Accumulator）中現有項是否存在子項包含關係，複雜度降低。

但我的最後的代碼，進一步地看，仍不是我最滿意的，從可讀性的語義角度考慮，foreach後的處理，並不能一目了然地直觀看出是「不存在包含關係」，看代碼的人的思維會頓一下。所以，我覺得這樣會更直觀：

有時候，代碼長短真不是考量點......