爛規矩好過沒規矩

1.
作項目的時候，有沒有遇到過由於開發規範的異議產生的爭論甚至爭吵呢？我遇到過很多。大多數時候，只是停留在爭論這個表象上。事後，只記得咱們爭論過，可是結果是什麼，沒人關心沒人在乎，由於大多數時候，老大會幫咱們拿個主意。

爲何必定須要有一我的拿個主意呢？就像個人一位前同事所說，如今的規矩是個爛規矩，爲何要用？你們自由自在的，各用個的，很差嗎？

自由自在的，聽起來真的不錯的。因而你用 react 我用 vue，你寫 nodejs 我寫 go，各取所需各得所願，鑼鼓喧天，鞭炮齊鳴。

因而，哪天你閱讀別人代碼的時候，傻眼了？這 tm 是什麼鬼東西啊？

甚至，哪天你想要和別人集成的時候，你這 tm 是什麼接口啊？嘻哈嗎？別侮辱嘻哈好嗎？

這個時候，你會無比但願有個哪怕屎同樣的規矩，能約束約束你們蠢蠢欲動的創造力。

2.
這兩天使用india那邊開發的 user service。我拿過 api 文檔一看傻了。對了，有文檔是個好習慣，好過沒有對吧。

讓我傻眼的是這不三不四還號稱本身 restful 的 api。怎麼不三不四呢？
若是我想查用戶信息，我調用

GET /users/userId

沒毛病吧。

若是我想查用戶 profile，我調用

GET /users/profile/userId

你大爺的。

若是我想知道用戶郵件呢？

GET /users/profile/email/userId

好吧，你的路數是這樣的。

那若是我想更新用戶郵件呢？

POST /users/profile/userId
body { email: "my@haha.com"}

好吧，我服了。

我後來和對方開發和測試溝通，他們很耐心很誠懇的解釋了整個 api 的設計/流程，手把手教我怎麼註冊/登陸/更新/註銷，我很感謝他們。但我深深地懷疑，若是再過一兩天，我會不會把這風格特別的流程和流程所依賴的 api 都給忘乾淨了。

好吧，寫這篇文章的時候，我已經都忘得差很少了。

3.
有些聰明的人總會以爲條條框框方方面面限制了本身的發揮創造力，興許一不當心我就改變世界了呢。可現實是可能連一個有質量的項目都搞不出來。作項目不是一我的單打獨鬥逞英雄，固然，我想確定有大神能一我的擼出一個react like 不須要任何人的幫助。可是，更多的狀況是你我他，身邊的同事們，都是凡人。而咱們的目標，興許就是星辰大海呢？團隊協做，揚長避短，這是咱們到達彼岸的惟一方式。

這麼多人，一人一個聲音，沒點規矩怎麼行？

連大草原上的野獸們都知道，團伙行動，規矩很重要，誰埋伏，誰恐嚇，誰堵截，誰主攻，誰協助，開幹前都要弄個清清楚楚。一樣的，一個項目剛開始，不算需求（獵物是誰），規矩應該排第一位。用什麼框架，代碼風格，測試辦法，能今天定下來的，千萬不要拖到明天。你寫的代碼我能看懂，你作的 api 我能輕鬆理解，這樣真的很棒啊。

4.
惡果。
前幾天，抱歉又是 india，我往 message queue 發消息他訂閱消息，居然收不到。我真是醉了，明明 queue 已經收到了你的程序收不到關我鳥事啊？好吧，又被拉去開會，balabala 半天，原來是他們訂閱的名字寫錯了。你本身發郵件告訴我名字還寫了個 wiki記錄，結果最後本身寫錯了？

結束完會議我就建了個 wiki 說這裏之後存放全部的 message topic，大小寫敏感都別搞錯了，順便 @ 某人。

爲了這事折騰了一天半，會上對方各類甩鍋幸好我身經百戰經驗豐富，成功的逼迫對方認可錯誤。心好累。作程序員不但要寫的好代碼，還要鬥得過賤人，甩的了黑鍋啊。

5.
原本想總結一下，也不知道該說啥。

不以規矩不能成方圓