前言
俗話說:”不以規矩，不能成方圓”，在許多專案開發時，最痛苦的就是閱讀他人的程式碼，因為沒有統一的一套標準，導致每個人在接手他人的程式碼時，都是痛苦萬分，軟體開發往往最大的成本在與溝通成本，人數越多時則產生的溝通成本越高，規範也是一種降低溝通成本，提昇團隊協作效率的一種方式。
但是所有制定出的規範是死的，人是活的，要懂得變通，有任何覺得不妥，缺漏或有更好的做法歡迎提出修改的要求。必竟在資訊這領域像逆水行舟，不進則退，所有方法技術管理技巧，都需與時俱進!
(參考: 台灣軟體產業的失落十年)
JS 規範：
- eslint 、pretter 請調整一致，( ibuypwer next專案中有建立 .vscode\init.vscode-env.ps1 可以協助各位配置 eslint 及 Prettier 有一致的規範及排版 )
- 變數及方法命名方式，統一採用駝峰 ( casemel ) 工具也協助檢查
- 兩個 == 和三個=== 不同，可以精準判斷，那麼就不要用模糊判斷 => eslint 工具也協助檢查
- 命名要有意義 get 沒改值，就不要名命為 set
- 方法命名，意途要表達清晰 => ex: ( 動詞 + 名詞 ) getUserProfile
- 一個方法過長時，又做意途不同的事，請拆成不同的方法。
- 重覆兩次以上的的方法，請想辦法抽出來共用，不要複製個好幾分，最後變成7~8份，換個人接手，新需求來要改還改漏了。
- 在設計 React 時元件時，元件太大或可以共用的也麻煩請拆成元件。
- 系統要長期維護，能用 Typescript 就不要偷懶，只有在為了特殊考量情況下才可使用 Any。
- 在 React 的 template 不要做過多的邏輯處理，請先處理好資料 template 部份就只負責渲染就好。
- 三元表達式超過兩組以上，麻煩將他拆成方法或是狀態來控制，因為下個接手的人不好讀懂。
- 變數或方法命名使用英文單詞，不要縮寫，並且要保證單字拼寫正確。
- 在撰寫程式時要適時加入註解。ex: 邏輯複雜或可能不好理解的地方。
- 魔法數字，抽成 const 或 enums 集中管理。
- 能用斷路判斷，就不要用三元表達式
- 短路寫法要注意一下，如果傳入的參數是 undefined 或是 null 要在 props 給預設值或是用||給預設值 parentElement && Style.fixed) || ''
- 三元表達式如果超過兩個，以上請抽成一個方法，不然下一個不好閱讀。
- 在 React 使用 dangerouslySetInnerHTML 要特別小心，並不會像其他框架一樣會幫忙阻擋 xss 攻擊，請記得使用套件 dompurify 加密危險字元。
Git 規範：
-
專案中無用的註解及程式碼、無用的文件（包括圖片、JS 文件、樣式文件、debugger等等）可以全部刪掉，不要提交到 Git；
-
本地測試代碼或本地個性化配置文件不要提交到 Git。
-
先 Pull 更新，再提交 Push，有衝突要先解衝突，再提交程式碼。
-
未來會有越來越多人進入團隊，Git 互蓋的狀況，還是有機會發生，在Git Commit 前，請確認都是你修改的程式 => 可以用 git tortoise。
-
新的分支一律從 staging 建立
-
JIRA 單一單號Commit 格式
IUW-01 fix type error
- JIRA 多單號 Commit 格式
IUW-01 IUW-02 fix type error, refactor modal style
註解
程式設計師，半年前及半後年所撰寫的項目，往往能記住的人不多，有撰寫註解，可以幫助自己及團隊快速的了解此這些程式是在做些什麼，不需要每個都寫，會覺得別人可能看不懂或邏輯過於複雜麻煩寫一下。
寫不寫註解，其實沒有絕對，我熟知像知名外商公司，他們公司就是盡量避免撰寫註解，認為撰寫註解也需花額外的時間成本維護，也常常發生寫了功能，忘了修改註解，而造成一些意外，但這些前提是建立在公司的規範及團隊的水平趨近一致才比較適合。但現階段公司還在起步，我的建議複雜不好懂的地方，仍需撰寫註解。
Hard Code(寫死)
指的是在軟體實作上，把輸出或輸入的相關參數（例如：路徑、輸出的形式或格式）直接以常數的方式書寫在程式中，這種寫法相當的不好，且系統上線後，未來要擴充會相當困難，因此在未必要狀況下，請勿將程式碼寫死，保留一定的彈性，寫死的狀況也並非完全只有缺陷，如只是應付某特定需求，不影響主架構的情況下，利用寫死也是一種縮短開發時間的方法，如有必要寫死，可以的話請先拿出來和同事討論，或是找找那邊有動態資料可以拿，真的不行在寫死。
解決魔法數字的小技巧
程式設計小計巧 我常常會看到很多新人的程式會出現，在程式中Hard Code 數字或文字，反而造成下一位在閱讀不易理解魔法數字代表著為什麼? 錯誤示範:
If (ShippingMethodID === 7)
{
Do some thing
}
if (subItem.OptionID == 127) {
Do some thing
}
這樣的程式碼是不是，魔法數字對於另一個人在閱讀不容易理解，在修改時也很有可能會漏改，這邊會建議採用同一系列的用 enum方式來決解這個問題，不是同一系列就單獨用 const。
短解
短解，可以短期解決暫時，但因為長期就累積很多複雜問題，短解上堆疊短解，簡單問題就變複雜了，既有程式已在線上，要在花力氣改回來，讀懂，不改爆他，得付出更多的成本。
沒辦法立即改，就應該被記錄，事後回過頭和 PM 要時間把他修正。
Commit 可以透 Git tortoise 比較程式異動差異。
alt + 下鍵可以切換到異動的地方
斷路判斷
return (<div>{ showHeader && <Header /> } </div> );
留言