故事是這樣的

各位還記得前幾天的故事中講過的「資料科學部主任」-- Yincheng 嗎？這也是有關他的故事。

在資料科學部裡面，技術最強的就是 Yincheng 他自己了。應該說，因為他認為自己的程式與架構能力都屬一流，因此他找的人都只管找「聰明人」，程式能力不在他考慮範圍內。

是說，要怎麼定義聰明人，我也是看不懂就是了…

有一次，筆者剛好路過，看到他們在 Code Review，一時好奇就停下腳步看了一下。不看還好，一看嚇一跳。畫面上的函式，竟然是用「編號」命名的。編號耶！就是 Function_F_001、Function_A_566 這種編號！真的假的？這實在是太讓我好奇了，於是我默默拉了把椅子坐在角落看還有什麼其他不同的東西。

我大概看了半小時，就看到了自己刻的 Bubble Sort Function、自己刻的 Tree Map、集中管理全系統定數的 Final Number Manager、八百多行的「演算法選擇器」、不用 Class，硬是用 Array of Object 來當參數傳遞… 等我人生只有看過那麼一次的程式寫法，而要解決的問題，大多是業界已有很通用的寫法，或是坊間已有常用 library，甚或是程式語言原生就已經支援的功能。

當時我本想說點什麼，但想想還是算了。

想想還是算了示意圖，圖片截自 Meme 梗圖倉庫

我的寫法我的 Team 都看得懂

不久後有一次在與另一個 Team 的 Mike 聊天時聊到此事，Mike 說：「你幸好沒提，我跟他聊過，他不會改的，不要浪費時間。」

「你跟他聊過？那他當時怎麼說？」我好奇問。

具體內容我忘了，但據 Mike 回想，大概就是不出「我的寫法我的 team 都看得懂」，以及「如果沒什麼好處，只是大家都這麼寫，那我不想改寫法」之類的論述。

「那你沒跟他說耦合度的問題嗎？」我不死心問。

「有啊！他就說他一個類 800 多行，所有事情都在同一個 class 裡面做，完全零耦合！」Mike 笑答。

「那…那，那日後修改時難找也難改的問題呢？」本來是想這麼繼續追問的，但話到嘴邊，我就想到了，不問也沒差，反正就算問了，到時一定也就不出「我把所有未來可能發生的變化都想好了，不會有需要修改的時候。」之類的回應吧！

為了我們下午的工作情緒，我們就馬上換話題了。

業界標準做法

我們今天要來討論的主題叫做業界標準做法。

什麼叫業界標準做法？為什麼不是正確答案，而是標準做法？主要是在軟體工程的世界中其實也沒有什麼正確答案：亦即，就算你不照這些大家會用的方式來做，其實也不能算錯。可是為什麼筆者要在這強調業界公認？其實說到底軟體界的歷史說長不長，但說短也不算真的很短。

你現在當下面臨到的問題， 也許你覺得很特別，也許你覺得只有你會遇到，但是很遺憾的，這些問題絕大多數已經在其他軟體工程師的經驗被解過了。既然大家都解過的問題，他肯定有個既定的做法，於是當你遇到一樣的情況的時候，如果直接使用這個通用的解法，那麼這個行動所造成的後果就是可控的，否則不但不可控，你還得要花很大的力氣去想你自己的解法。

這樣子的行為看起來很帥，但其實是非常浪費的：不只浪費時間，也浪費你的精神。

舉例來說：

• 如果你想要排序，那你就一定找得到你使用的語言的社群中，廣為通用的第三方完整的 Library 可以使用，甚至有些語言內建 SDK 就已經有了。
• 如果你想要為你的變數、類別，或函式命名，那麼你所使用的語言肯定在社群中已經有大家約定俗成的 Coding Convention了。
• 如果你想要做一個後端的 API Service，那麼軟體架構社群已經有很多眾所皆知的分層架構可以使用了，例如 Clean Architecture 或是六角架構。
• 如果你今天使用的是物件導向語言，那麼軟體社群已經有大家都通用的物件導向設計原則可以遵守了，也就是 SOLID 五大原則。
• 最後，如果你想要做單元測試（你真棒）那麼在單元測試的社群中也已經有大家都通用的測項的既定寫法了，譬如說 Given-When-Then 結構。

我想說的是，在現在這個年代，這些常見的問題你絕對不會是第一個遇到。因為你不是第一個遇到，你應該要預設先去找先前遇到同樣問題的先進前輩們，都用什麼方法來解決這個問題。如果（而且很有可能）這個問題已經有了一個業界通用的解法，那麼不要客氣，直接使用因為它可以接生命很多的時間，而且，如前所述，套用這些解法的結果是可控的。

耍帥的後果

假設你這放著這些既定解法不用，還是要針對相同的問題去想自己的 Solutions，也不是不行，帥是很帥啦，但筆者認為你會至少遇到兩大問題：

1. 人員訓練不易：因為這些東西所有進到你團隊的人都是第一次遇到，所以他還沒開始做你真正交付給他的工作，他就要開始習慣你對這些常見問題的獨特做法，因此你的團隊的新進人員要比別人花更多時間才能融入團隊。
2. 遇到問題很難解：一般開發者在遇到技術問題的時候，如果採取的是通用解法，那麼他很容易在網路上找到前人已經遇過的阻礙，並且很快地找到解決的方法，以及（最重要的）正確的觀念。然而，如果這些Solution 都是你們團隊自創的，那麼當團隊遇到問題的時候，他們就只能自己想辦法。就算他真的純靠自己解決了，也頂多就是做到別人花 5 分鐘 Google 後能做到一樣的事情而已。

上面這些都是無謂的時間成本的浪費，不可不慎！

Domain Language

當然，你也不太可能在工作中遇到的所有問題都被前人解決過了。

工作中的確是有一些問題是幾乎沒有人解過的。什麼問題？就是你的領域問題。在 Clean Architecutre 中，為什麼 Uncle Bob 要把 Entity 放在整個結構的最中間？因為這就是你的領域。什麼是領域？Uncle Bob 是這麼說的：「Enity 裡放的就是你的核心邏輯，是你的行業中最獨特的事情，這件事情造就了你的產品，或是形成了你的組織與別人最不同的地方。」

所以你可以想像， 既然你已經在開發一個全新的服務、全新的系統，那麼你所遇到的領域問題應該幾乎都是全新的，而既然他是全新的問題，你就應該要自己去想解法，因為以前從來都沒有人遇過，自然也就沒有通用結髮好參考了。

因此，遇到你自己的領域的專業問題，當然你要花很大的心思在研究如何解決這些問題上，而別人在「類似問題」上的解法，也就僅供參考了。

你的工作是什麼

如果各位還記得的話, 在前幾天我們有討論過：「身為軟體開發者，你的工作是什麼？」

其實啊，如果我真的要說你的工作是幫老闆解決問題，那其實也有點太廣了。你的工作其實是拿著你的專業來幫老闆解決問題。

㚒是我們更進一步想問了：「那麼你的專業是什麼？你應該拿什麼樣的專業來發揮在你的工作上？」上是 sort 嗎？是創立物件導向新標準嗎？是發明程式語言嗎？是創造新的網路傳輸 protocol 嗎？當然有些人是的，但我相信大部分的人不是。

你的工作是什麼？對大部分的人來說應該是把你的 Domain 專業發展到最好，其他瑣事交給外人就好。

因此在現在這個年代，如果你真的想要把你的軟體專業做到最好、把你的效率提到最高，那麼不要客氣，只要是前人遇過的問題，都不要再自己造輪子了，用前人發明過，已經被證明有效的解法就好。

謎之聲：「把時間都花在最重要的事情上。什麼年代了，sort 還要自己寫喔？」

Reference

1. Robert C. Martin，無瑕的程式碼－整潔的軟體設計與架構篇，博碩文化，2018