開發規範真的很重要

最近阿里巴巴的 Java 開發手冊出了新版（可直接到 github alibaba-p3c 上獲取相關資源哦），我就跟着這個事情說一下我對開發規範的理解吧。
提起開發規範，我印象中最深的就是讀研究生期間，帶個人大牛師兄某導對個人要求。當時是開發一款 B/S 的 3D 渲染引擎，其中 Web 部分由我負責，在大師兄在對我進行 code review 的過程當中，對我提出了「嚴厲」的批評（也一直很感謝他當時的嚴格要求），緣由不是別的，就是我開發的網頁中有一部分是文字介紹，裏面的標點符號是中英文混用，且代碼也不規範，好比縮進不一致、該有的空格沒有等等問題。就是從那個時候起，我對代碼規範很是重視。這對後來本身寫畢業論文等等方面也起到了良好的促進做用，由於導師對這塊要求也相對嚴格。

回到代碼規範這件事情上，好的代碼讀起來真的是賞心悅目，固然本身也一直在追求寫出好的代碼。代碼規範中的 code style 只是其中最簡單的一種，上述提到的 Java 開發手冊也對這部分作出了嚴格的說明，但實際上能作到的人也很少。按道理，這部分也是最容易作到的一種，由於有模板，直接遵照便可。記得有一部電視劇（叫啥來着？）講的就是一堆情侶由於糾結究竟是用空格仍是 tab 鍵（或者是 Vim 和 Emacs）分手，哈哈這固然是一個笑話。不過在一個 team 裏保持統一的代碼風格仍是有必要的，畢竟你寫的代碼不是隻有你一我的看，在不一樣的終端，不一樣的編輯器來說空格和 tab 可能顯示效果都不同，也就影響了閱讀體驗。

（圖 1. hackthon 團隊合影）

對於代碼規範來說，我也但願經過本身的努力去感染身邊的人。好比以前在宜信的 hackthon，我就組隊發起了一個叫 「code review advisor」 項目，實現的目的其實也很簡單，就是讓你們在預先統一的規範下編碼，若是有違反規範的，直接以 Comment 形式告訴代碼提交者須要修改。

（圖 2. hackthon 項目截圖）

後來，我到了大疆，又要求 team 同窗嚴格遵照規範，而且使用了一些技術手段徹底規範你們提交的代碼，對於違反相應規則的代碼直接不讓提交和打包，當時其實就是利用了 alibaba 對外開源的工具支持。不得不說，仍是很佩服阿里巴巴對社區作的相應貢獻的。
如今，我在阿里，發現現實就是規範其實也是一個美好的願景，由於各類歷史等緣由，其實你們的代碼並無按照預期的規範去執行和實施。這應該也是廣泛的現狀吧。就像在其中一次交流會上，孤盡大佬說的那樣，美好願景確定是須要的，實現她，是須要你們花時間和精力去推動的。

（圖 3. 孤盡大佬簽名版開發手冊）

上圖是在那次交流會上，獲得孤盡大佬簽名版的開發手冊（原諒我沒文化，認不出）。下面我就以其中的一個例子來講明一下規範的好處。

public class SimpleDateFormatTest {
    public static final SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

    public static void main(String[] args) {
        Date now = new Date();
        String printedDate = simpleDateFormat.format(now);
        System.out.println(printedDate);
        for (int i = 0; i < 10; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        Date date = simpleDateFormat.parse(printedDate);
                        System.out.println(simpleDateFormat.format(date));
                    } catch (ParseException e) {
                        e.printStackTrace();
                    }
                }
            }).start();
        }
    }
}

上面代碼片斷就是規範中提到的 SimpleDateFormat 使用場景中一個錯誤的示例，其實就是一個線程安全的問題，跑上面代碼片斷，預期輸出應該是一個正確的字符串表達（例如 2020-04-25 15:41:34），實際過程有可能會拋異常（例如 java.lang.NumberFormatException），也可能會輸出一些奇奇怪怪的時間（例如 0015-03-25 15:41:34），這其實都還好，由於畢竟要麼異常了，要麼「時間不正常」，最要命的是可能會輸出一個正確格式的時間，只不過不是預期的，這種問題就相對很難排查了。
還有好比前面剛跨年的時候各個系統都爆出的時間跨年問題（yyyy 和 YYYY 的問題），在此手冊中其實也都有說明。因此，其實相似的規範多多瞭解更好。
end

歡迎掃碼關注
程序猿石頭

往期推薦

由一次磁盤告警引起的血案

RSA算法及一種"旁門左道"的***方式

震驚! 阿里的程序員也不過如此,竟被一個簡單的 SQL 查詢難住

碼農唐磊有收穫 ? 請四連 : 默默點贊喜歡做者