找回自己的 SOC
最近讀了一些管理書籍, 其中王品學讓我得到很多的啟發。許多管理學都會提到標準作業流程 ( Standard operating procedure, SOP )。在標準作業流程中, 一個完善的公司每項業務都會有適合的處理方法與流程, 通常這些方法與流程都會使用文件化 (Documentation) 來保存, 讓往後新進的人員可以快速的瞭解公司制度, SOP 概念核心是提升作業的品質與效率。
王品集團中，特別引入了 SOC 概念，師法自麥當勞 （McDonald’s） 的「工作站觀察檢查表」 （station observation checklist, SOC），王品將這項成功的經驗複製學習起來。通常顧客從進到一家餐廳、用餐、然後離開，接觸到的服務區域可以分為大廳、廚房、吧檯等，每個區域可以在細分為多個工作站，以大廳來說可以分為接電話、接定位、帶位、送水杯、點餐、上餐、撤餐到結帳離開等，共 17 個工作站，每個工作站都有自己的 SOC。
寫程式也要有 SOC
最近在開發新專案上，決定為自己也訂下一些 SOC，好讓自己的能少犯點錯、增加些品質，以下就大概列出幾條我覺得非常重要的事項與各位分享
程式邏輯正確性
程式設計師每天都在思考 – 解決問題，首先第一步是把問題解決的方法 (想法) 從腦中轉換為電腦看得懂的程式碼，在這個步驟中你必須確保你的想法與最後產出的程式邏輯是一致的，當然，如果你在過程間發現原來的想法有誤謬時，就先放下手邊的 coding，拿出紙筆重新思考然後再繼續這個轉換的過程。
程式碼是否偷吃步
常常為了完成某個功能，腦中自然會想到一些很直覺的方法來完成，直覺而不經過思考的想法通常可以達到目的但它無法持久，為什麼呢? 因為直覺當下腦中思考的是怎麼解決這個小問題，並沒有把整個系統的角度納入考量，常常寫出一些無架構的程式碼，最後專案越做越大就容易遇到無法繼續開發的窘境。
環境確認
通常一個營運中的專案會分為多個版本進行，正式環境是目前使用者正在使用的版本。測試環境通常是一個與正式環境相似的環境，每個新的功能都會在這個環境上確定沒問題才會上到正式環境上給使用者使用。而本地 (Local) 環境是跑在自己電腦上的，通常你會把功能在本地環境實作、測試後上測試環境。那麼環境確認是甚麼意思呢? 也就是你必須保證本地環境 → 測試環境 → 正式環境，這個過程中你的程式碼都是可以執行的，就筆者犯過最低級的錯誤來講，我曾經把 localhost:8080/testlink 這樣的程式碼上到正式環境上執行，這個程式碼只能在我的電腦上執行，這種低級錯誤通常都是複製貼上最容易發生的。
程式碼可讀性
程式碼可讀性可以分為兩類，分別為程式碼排版、程式邏輯表達兩類。程式碼排版是一個重要的議題，好比有些人喜歡使用兩格空白做縮距、有些喜歡四格，有些人命名會使用駝峰式有些人則喜歡使用 – 分開，每個團隊都會有自己的風格 (style)，但很重要的一點是，團隊整體的程式碼風格 (code style) 必須是一致的，否則你們的程式碼看起來會非常的吃力。
在這一類中，其實你沒有那麼急的在說明其實你應該邊撰寫程式邊做排版，就好像寫作一樣，你真的沒有忙到沒時間排版，因為通常排版指占用了最多 10% 的時間。事後排版是個壞習慣，因為你很有可能已經忘記當初撰寫時的動機、邏輯、以及正確性。
第二類可讀性為程是邏輯表達，常常聽到一句話，同一個功能的程式至少會有三種以上的寫法，至於哪一種是最佳解則是看使用時機來定論，這裡要說的是，好的程式碼通常不需要繁複的註解來說明，這些程式碼通常一看就懂了!
版本控制
通常軟體專案開發會使用版本控制軟體作為專案檔案管理，SVN 讓團隊可以輕鬆的處理檔案合併、更新、刪除等操作，在使用 SVN 這類型的工具時，遞交新版本時應注意一件事情，提供註解，通常在專案問題發生的時候，註解可以讓你快速地找到是哪個版本檔案產生問題，可以省下不少的時間。
不是個人是團隊
每個專案經理都會依照團隊成員的專長、能力、性向團隊分工，每個人都屬於專案的部分，除了盡力的做好自己那份外，還要思考與其他功能的連結、並與其他功能的負責人討論，盡可能的了解整個專案架構。團隊中非常討厭有獨行俠的存在，因為這些人只信仰自己的腦袋，他們覺得自己是最聰明的、想到的方法是最好的，這類的人短期間會讓專案跑得很快，因為他們很聰明，以長期來看，在專案中期後期這些人就開始叛逆、自以為是、不參與分工及討論，最後拖垮整個團隊運作。
團隊開發雖以能力分工的方式進行，但人總會有犯錯的時候，所以我認為分工方式可以使用能力覆蓋 (Cover) 的方式進行，簡單的範例為 : 『甲負責 A、B 功能開發，乙負責 B、C 開發…以此類推』，這樣的方式可以確保每個功能項目功能都有兩人負責，並且可以促進成員之間的討論，這與軟體工程中的『pair coding』有異曲同工之味。
還有一點必須提到的，每個人有負責的開發功能，但記住一句話 : 『程式碼是屬於團隊每個人的，不是你一個人的』，很多人在開發專案都會認為自己確認自己負責那部分能如期完工就沒事了，其實不然，往往許多功能是環環相扣的，例如 : 『一個 Bug 的產生表面上是某甲的問題，但實則為某乙的程式邏輯不清楚導致某甲產生誤謬，但 Bug 發生時某乙直接認定是甲的錯誤』。這邊建議一個方法，在使用 SVN 版本控管時，每次 update 下新版本時，你都必須重新確認 (Recheck) 這次更新中與自己開發功能相關的檔案異動細節為何，這樣才能確保每個環環相扣的邏輯能保有正確、可執行的能力。
對於程式設計師來說，上述每個項目幾乎都是天天都要處理的事情，有必要特別說明嗎? 答案是有必要，而且你必須時時刻刻牢記著，原因很簡單，因為人通常在急、忙、亂的時候都會忘了這些細節，很多人 (當然也包含我) 在忙的時候都會不自主的遺忘這些常識，透過這篇文章筆者希望能夠發起你的共識，找回你自己的 SOC，提升生產力及生產品質。
唯有自己打從心裡也認同這些規定，否則再多的規定也是形同虛設
Images via wallbase CC License.
做中學 