從一次開發聯調的問題覆盤，理解「規則即自由」

最近與後端開發過程當中遇到一個特別難受的問題。自已覆盤了一下。也慢慢有了對於「規則即自由」的一些想法和思考。

事件

背景

在我與後端合做開發過程當中，首先我會定義好數據結構並評論在需求文檔的下方，後端按照我定義好的數據結構來返回Response。

過程

我正常定義好結構後評論並@他，在站會上同步了這件事，而且讓他看了我mock以後的效果圖。但聯調時並無按照我給的結構來，致使聯調不能正常進行。但因爲他又有高優先的任務要去作，由於我就給他犯的錯買單了。

結果

主要有如下幾點使我煩擾：

• 嵌套結構轉換大，字段名不一致，好的代碼不該該有這種大量轉換數據結構的代碼
• 修改公共組件字段，特殊兼容處理較多，代碼可維護性大大下降
• 帶着怨氣去作這件事，使得個人心情很糟糕，這一點遠比前面兩點更重要，由於情緒帶來的負面價值是不可估量的。固然話說回來，其實也是本身沒能處理好本身的情緒，怪不得別人。

產生緣由

我推測有如下幾點

• 可能因爲他的上個任務delay了，致使這個需求時間緊，沒有去看結構
• 看了可是沒細看，覺得就是某個以前的其餘結構
• 看了可是以爲這個A結構太複雜，而後使用了B結構沒同步給我

思考

苦難不能令人成長，苦難後的反思與行動才能

如何改進

那麼我就想怎麼才能避免下次出現這種相似的問題呢，答案是規則與約束。

每一個項目都有SOP，既然現有的通用SOP不能知足要求，那麼就創建有業務屬性或我的屬性的SOP。因而我在follow通用SOP的前提下，與後端溝通一致後並落實成「先後端開發合做規約」【簡易版SOP】。爲何是規約呢，我是這麼想的，其實這是帶有業務屬性或我的屬性的內部SOP，可能不被其餘人認同，所以也不會去涉及定責背鍋等問題，只是誰沒遵照規約，誰去改的問題。這就是我想要解決的問題。

具體內容就是我定義好結構，後端double check以後須要有一個「確認」的行爲，無論是回覆評論仍是IM回覆，須要有一個留底來證實是他確認過的就OK。

從新認識流程規則與約束

「人少的公司」能夠理解爲小的初創企業幾百我的那種，或是微信事業部初期那種，人少開會少執行力快。辦事快，流程簡單，扁平化管理，沒有繁瑣的流程管理機制。

以前的認知是在大點的廠最讓人詬病的是流程複雜，每每一件小事各類審批使得辦事效率低下。而「人少的公司」那種流程簡單扁平化是多麼高效。

經歷過這件事以後，我從新思考了我leader給我說過的一句話「流程是一個讓全部人都能達到最大溫馨度的一個東西」。此次我終於有點理解這句話了，若是沒有流程管理，那麼偌大的公司將沒辦法運做，每一個人都遵照這一套規則去執行才能更加高效的去工做。固然規則是你們都承認的而且是通過實踐檢驗而且不斷優化改變的，顯然現有的不少廠子沒有這麼作，也許國外作的也很差，我猜的。當我從0開始踩過坑以後才明白好的流程機制的重要性。我也逐步去嘗試從0開始運用「規則」這個東西來使得工做更加溫馨，使得規則發揮應有的價值，當你們都遵照一個相對滿意的「規則」以後，其實這是更大意義上的「自由」。

多想一點！以前爲何沒有意識到規則的重要性？

緣由很簡單，其實這和學習某些技術也很相似，當你連CSS都不會寫的時候我給你講持續集成的重要性，固然沒法理解。就好像我連駕照都沒有的時候，你給我講特斯拉哪款車的座位更舒服。我只能記在腦子裏哪款車座位舒服，但我絲毫沒有感受到它的舒服。所以認識一個事物的歷史，瞭解他要解決的問題，有機會親身去嘗試或推導出這個事物存在的緣由，才能更好的認識並學習這個事物。這其實就是爲何九年義務課本的裏面的新概念的第一課老是講歷史。第一課的內容其實也側面印證了一個哲學問題「發展就是解決矛盾」。

後話

後話1

爲何先後端都不想如下兩種狀況發生呢？

1. 需求變動
2. 數據結構變動

緣由說白點有如下幾點：

• 改需求至關於以前所作的全部付出基本白費，而且這些「付出」很大程度上其實並無多少價值，無論是對於整個產品的價值輸出仍是對於本身的提高來講。總結：浪費生命的事情誰都不想作，作這種事情還不如我去玩幾局遊戲，至少遊戲在某些條件下能讓我放鬆，讓我更好的投身於其餘事情。
• 增長溝通成本，程序員工做至少一半時間是在IM，IM正在虐殺生命。

若是是一個健康的迭代，以上兩點「變動」是比較少的發生，若是發生必定是某一個環節出了問題。無論誰是始做俑者，以上兩種狀況下產生的「變動消息」經過「產品迭代合做鏈」必定會透傳不少次，在小的項目可能看不出來，在大的項目若是沒有好的流程管理機制，簡直是爆炸。就算有好的流程管理機制和工具去制約，消息透傳的次數也是指數級別上升的。這還不考慮

1. 與工具去交互的成本。
2. 「變動消息」未被確認，或即便被確認了但沒有被執行而產生的不符合預期的結果甚至更糟的結果，或「變動消息」的理解誤差。

若是考慮以上兩點，可想而知「增長溝通成本」這件事是多麼恐怖。

打個比方，若是出現了變動，會發生什麼？

首先全部人要知道並準確理解這個變動意味着什麼，消息同步x。而後討論誰來改和改動成本(小的變動能夠忽略這一步，但大的變動可能須要開發提供幾張解決方案並與產品開會討論決定執行哪一種方案)，影響的scope，改動過程當中可能會遇到問題「變動致使的新問題和與以前是否兼容的問題，指需求層面不是代碼層面」，遇到問題如何處理，再來一次「變動問題處理」溝通，消息同步y。OK一切肯定了，變動處理，改動結束，消息同步z相關人員，迴歸測試。所以一次變動致使的溝通成本一會兒就提了上來，而且若是消息同步不到位有可能引發某一環節的問題。若是變動小或者涉及的人員很少的話，可能會很簡單，但若是你一旦遇到這種複雜點的流程，真的就要爆炸了，耽誤不少時間才搞定一件事，這仍是冒着出鍋的風險。

所以當我leader問我這個變動到底讓我花了多少時間去改代碼，我說10分鐘，但付出的代價遠不止10分鐘這麼簡單。由於溝通的時間有大概有40+分鐘去完成上面的複雜流程，而且還要在當前手裏的事情和這個緊急變動之間去切換，這樣算下來，這個變動致使的「整體成本」計算爲半天一點都不過度，由於一我的一天也就大概專一四個小時在編程，其餘都是在IM、切換工做上下文狀態等事情上。這僅僅是「執行變動」的人的成本，若是加上整個「產品迭代合做鏈」全部人，那真是資源的極大浪費。

後話2

我leader給我說，不該該給別人犯的錯買單，我這麼作了主要考慮是如下幾點

• 後端很強勢，雖然是他的錯，但我不想撕破臉
• 不要臉的怕不要命的，沒有最強勢的人，只有更強勢的人。我還在尋找一個從容的狀態，這種從容的狀態是指「什麼場景下強勢，什麼場景下可商量」。
• 自信心不足，對別人提出更高要求的同時，其實也是對本身提出了更高的要求。畢竟參與合做的人的level基本差異不大，若是很大，那麼合做的溫馨度必定會下降，溫馨度下降到沒法承受的地步，合做必然不能繼續下去。

後話3

改一個傳參可能須要30s，可是因爲後端說的話先後矛盾，我要去和他爭辯「爲何說話先後矛盾」這個問題須要20分鐘。但我認爲這20分鐘的意義遠大於那30s，所以我選擇了後者，但如今看來，我仍是太年輕了。純屬吐槽。

以上僅限於我我的的想法，不針對某我的，只是本身的一些觀察和思考。

最近知乎上也看到相似的文章，但願能夠給你們一點啓發和思考。 zhuanlan.zhihu.com/p/68435690

End ~