為什麼開發者覺得Best Practices沒鳥用？
僅管疫情限制了實體技術研討會的舉辦，都轉成線上的版本。但技術研討會一向都是軟體工程師應該都要去參加的活動，除了看看有什麼新產品以外，另外一個很重要的內容就是所謂的「Best Practice」系列。工具拿在手上，每個人都會有自己的握法，姿勢不對的話，輕則效率不彰，重則可能受傷。Best Practice通常是在某個產品中匯整濃縮出來的智慧結晶，僅管在特定的範圍/規格限制下，不一定能全數適用於自己正在執行的專案，但不過聽了幾個解法，只要有朝一日有一個解法派上用場，省去了無數個加班的夜晚或是假日，應該都是值得的。
但為何文章的標題會說「開發者覺得Best Practices沒鳥用」呢？而且，實務上我們看看身邊的工程師，一定就能找到沒有按照Best Practice做事的。扣掉那些不知道的，其他人又是怎麼想的呢？以下是作者收集到的幾個理由，也是我們自己應該注意的面向。
不需要「Best」，不要是「Worst」就好了
Best Practice通常是由資深工程師，在大專案的製作經驗中萃取出來的思維，這本身就是適用性的一個限制，而且這幾乎是最大比例的一個理由。適用於大公司或大專案的Best Practice，光是要投入實踐，可能就得購入對應的工具，或是找個專人來監督/工，不然就是會把作業流程擴張成原來的2倍那麼大。對小公司來說，任何一天，任何一個人，都可能是多不得的成本，因此在成本的壓力下，「Best」是完全不必要的，只要不是「Worst」就行了。
而且，小產品最大的"優勢"，就是他們並不會承受極大的負載和要求。他們的產品可能不用72小時不崩潰，不用擔心封包的收送會被此竊聽，不用在意吃了多一點的RAM或是佔用多一點的硬碟空間等。Best Practice要解決的問題，有些就是要解決極端狀況/限制(Edge Case)的問題的，這些問題沒那個時間，或沒那個空間，可以在小產品出現，因為在規格上就爆了。因此他們不需要是「Best」，過得去就行了。
Best Practice ≠ Best Performance
Best Practice有時會給現在正在開發的工程師，帶來一些麻煩，尤其可能會需要對現有的源碼做重構。此時Best Practice帶來的不只是麻煩，可能還會帶來「天使與惡魔」：
天使：這樣寫有風險哦，如果新人來不知道你的設計理念，會把架構搞亂的！😇
惡魔：管他去死啦，新人本來就要乖乖認份的把源碼讀完，為什麼我要替他想？！😈
天使：我們最好把這些類別拆得更小一點，讓這些物件都有明確的用途，這樣之後才好擴充跟維護啊！😇
惡魔：我都寫好了，為什麼還要再拆一遍啊？要是有問題，你要負責嗎？！😈
工程師若有一個非技術出身的主管，可能或多或少都會有這種受挫或拉扯。軟體的品質無法從表面規格上看得見，唯有真正看懂源碼的人，才知道背後投入的心血及要求，若Best Practice無法馬上獲得看得見的成效，像是反饋速度變快，呈現效果更準，服務範圍變大等，投入時間達到Best Practice的境界，非但不是價值，反而就變成是成本，自然就無法等價於Best Performance。
這件事就像做料理一樣，炒菜這件事本身不但不辛苦，而且很有趣，很有成就感，炒出來馬上就可以享用。累的是在備料，在洗碗的那些人。創建產品的人的腦中世界是完美的，是井然有序的，可一但進入實際營運，需要調整的狀況就多了，需要客製的狀況也多了，如果沒在初期的規劃設計好，維護的人就很辛苦了。
正加強不足
在上述的內文中都有提到這件事，從理解Best Practice到實際投入執行，不但需要投入心力，還得說服自己和他人。
可能會有一些資歷較深的學長，會覺得他們過去的作法用得好好的，用新的作法很麻煩，又看不到有什麼立即的優化，他們就會傾向不認同。當大家投入時間去做這件事，而且若是加班去做的，公司若沒有加班費或休假上的補償，這當然也會變成執行上的阻力。維護的複雜度或是還技術債的難度不是被低估，就是變成刻意忽略。交付高品質的源碼非但沒有獎勵，還會因為花了更多的時間，而被認為是「效率不彰」。自然那些Best Practice，就會被排到「以後有空再做」的清單中，永遠不會有空。
軟體開發界中有一個「葛蘭辛法則」，也就是軟體開發的「劣幣逐良幣」問題：
The Gresham’s law of software development, developers will do what is easiest if the reward is the same. 「如果回報都一樣，工程師就會用最簡單的方式做」。
正加強還包括真正的執行。真正的執行通常是包含在一個系統或是流程內的，若只是把Best Practice寫在文件裡，或是期待某個人去做人工的確認或宣導，這注定都會是無法落實的。
小結
Learning from mistakes only once you acknowledge the mistake. 「從錯誤中學習」的前提是，你能意識得到「那是個錯誤」
不只是軟體，任何技術領域都有無止盡的優化空間。Best Practice或許會因各種環境和限制，無法馬上落地執行，但仍然值得我們去多看看這些內容，因為「知道有優化空間」的本身，就算是一點優化了。現在不是Best的，但只要確定是往正確的方向前進，累積起來也會是很可觀的。