帶團隊後的日常思考（五）
一、日常問題
1）成員間的信任
信任危機不是發生在自己團隊，而是出現在隔壁服務端組。
他們組沒有一個正式的組長，只有一個臨時的代理組長，這種情況從我進公司到現在一直是這種情況，也是蠻奇怪的。
前幾天，這個代理組長和其中的一個組員爆發了點衝突，我從旁觀者對他們對話的理解就是，組員覺得他瞎指揮，他覺得組員無擔當。
其實從平時他們的協作中，我就有點預感會有衝突。
這個組員平時經常會質疑他的決策，並且他們在討論方案時我聽的最多的就是那我該怎麼辦？
一個這麼多年開發經驗的人，總是把這句話掛在嘴邊，我是很難理解的。每當此時，他就會給他詳細的解決思路，像是在教他寫代碼，甚至有時候既然你不想做，那直接自己把活攬了。
而這個代理組長，我感覺也有點問題，什麼事都往自己身上攬。並且掛在嘴邊最多的一句是，這個很簡單的，然後巴拉巴拉講了一堆，從他的組員的表情和反應中，我可以觀察出他們並不是這麼認為的。
這次的衝突點，就是一個支付的功能，組員突然就做不下去了。然後他們就開始針對之前的方案展開討論，後面找了個會議室，再然後說話的聲音越來越大，整個辦公室都聽到了，雖然還沒到爭吵，但氣氛已經很緊張了。
我往深層次的看就是他們之間互相不信任，組員並不服他。而他也過於的干涉組員的開發細節。要讓組員能信服自己，並不僅僅只在技術方面，管理方面也不能拉下。至少得讓他們覺得跟着你這麼干，對他們自己也是有幫助的。
那天之後，自己也會思考若碰到這樣的成員，自己該怎麼應對？現在還沒有特別完善的應對策略，之後會通過研讀書籍、專欄、分享等各種途徑，來替自己解答這個疑惑。
2）JSBridge新功能演示頁
最近遇到個小問題，客戶端有個版本要發佈，其中會涉及到幾個JSBridge的接口。
在測試和預發環境已經驗過這些JSBridge，都是正常的，現在馬上要提審了，在提審之前需要驗證這個包是否能調起JSBridge。
而H5活動頁面會在提審完後再發佈，這樣的話如果要驗證JSBridge是否正確，那麼就得需要個演示頁面或者是通過預發的活動頁面來驗證。
其實這些JSBridge都是需要一張演示頁面的，那就定個規範，每次需要聯調JSBridge時，要先配置好這個頁面，供客戶端、前端以及QA驗收用。
在驗收時，即使活動不上線，也能在此頁面中加以驗證。
3）協作通知
今天產品經理像我抱怨我一個功能開發的太快，她都來不及沒寫產品文檔，也還沒設計原型。
這是一個很小的需求，並且頁面功能非常簡單，一個文本框和一個按鈕，需求幾句話就能描述清楚。
我自以為和產品經理已經達成共識，即不需要原型，文檔編寫與我這邊也可以不同步，但是產品經理並不是這麼理解的。
因為我沒有明確的告知她，這功能不需要單獨的文檔，這次其實還好，她還沒開始，時間上也沒有損失。
但從深層次上來說，這次的事情暴露了跨團隊的協作仍然存在着障礙，雖然這次沒有損失，可是不代表下次也沒有損失，所以得防患於未來，我馬上去更新了協作規範，加了一句。
其實項目管理經常會涉及到很多細節方面的事情，稍不留神，就會踩坑，然後就會爆發這個那個的問題。
4）知行
這其實並不是什麼問題，而是我最近在看的一本書的書名，全稱叫《知行 技術人的管理之路》，書中講了許多管理的方法論和技巧，有兩處的講解讓我感觸頗深，特在此做摘抄。
第一處是分工模糊導致的問題（142頁），在我之前的日常思考中也有提到過，當時我用的標題是「爭議區域」，講的沒有書中那麼理論化。下面是書中的內容：
「管理者為了能夠讓大家互相補位、主動承擔、增強互助，還會刻意去模糊邊界。但是任何不以分工清晰為前提的邊界模糊，結果都會事與願違。
因為只有明確的分工，才能讓員工清楚自己的職責，只有清楚職責，才能帶來歸屬感，才願意主動多付出一些。」
第二處是對下屬的溝通（向下溝通，232頁），書中的第7章介紹了管理溝通的方方面面，涉及到了很多細節。帶團隊免不了向下溝通，這其實是最有挑戰的管理主題。
在此書中描繪了4種溝通場景，並給出了相應的解決方案。
- 批評員工，真實意圖是促其改變，可以先轉換下意圖看看是否需要批評，如果批評依然是最好的手段，那麼指出員工錯誤的行為以及需要改善的地方，同時幫助制定改進方案，提供出路。
- 溝通不順，對於內向沉默的員工需引導他打開話匣子，話題不必局限於工作，首要任務是建立起溝通通道。對於聊不到一個頻道的員工，從事實、判斷和意圖三個層面和對方進行頻道對齊。對於捉摸不透的員工，可以用封閉式問題做一些回放和複述，例如你是不是這個意思、你看我理解的對不對。
- 牛人下屬，對牛人的態度應該是用之，而不是競之。認清自己的角色，認同高工的價值，支持和幫助，以及必要的約束。
- 應對刺頭，刺頭就是那些管理成本很高的員工，對需要淘汰的刺頭應該儘早淘汰，而另外一些需要促其發生積極的改變，即從他的不滿意和願景出發，制定邁出第一步的行動計劃，幫他克服改變的阻力。
5）換位思考
換位思考說起來容易，做起來很難，尤其是要做到持續換位思考，難上加難。此處換位思考的對象主要是業務方和產品，他們關注的比較多的是營收和體驗。
如果保持站在他們的角度看待他們所提出的需求，那麼對於自己、團隊和公司都會有很多益處。
- 對於自己，每天工作時的心情能比較愉悅，而不是在看到提出新需求時，眉頭一皺。
- 對於團隊，在互相理解時，就能高效地配合制訂出多套符合需求的方案。
- 對於公司，員工的高效產出，自然能有更多的收益，這個收益包括時間、金錢等。
雖然有這麼多好處，但是在日常開發的過程中，就會發現自己有時候會有點抗拒，當然，心情好與壞、和自己關係近與遠在處理需求時的心理也會不同。
由此足以見得自己專業素養還不夠，並且還無法做到對事不對人。有個小例子，之前公司需要在多個官網底部加幾句聲明，然後提需求的人在快下班的時候發給我消息。
而這個人之前還提過一些比較無厘頭的需求，因此對他的印象不是很好，對於他的需求有點抗拒，並且還是臨近下班時間，更加抗拒。
但是事情最終還是要完成的，當天就修改好了，中間還有點波折。在中途了解到，這個修改是為了應付某個審核，而這個審核對公司很重要。
若換位思考，那麼就能設身處地的理解他們迫切的心情，我在處理這個需求時也能帶入更好的感情，而不是負面情緒。
還有個小例子，產品提出很多用戶在APP內的一個H5聊天界面中，經常會誤操作返回上一頁，返回後再回來就無法找到與他之前聊的用戶了。
站在她的角度，她當然希望用戶誤操作返回後，再進入還能維持之前的聊天，提升用戶體驗，無可厚非。
但我們在評估後發現保持這種狀態，會對現有系統做些修改，而現有系統內部邏輯錯綜複雜，擔心改了之後就會出現新BUG，更加影響用戶體驗。
換位思考理解她的訴求後，提出了一個比較折中的方案，那就是在聊天界面，阻止返回上一頁的手勢，這樣既能杜絕此類誤操作，也不影響系統的穩定性。
二、工作優化
1）設計方案
最近看了一篇文章，文章中提到在開發流程中包含一個設計方案的階段，位於需求評審之後，用於描述自己對於該需求的實現思路、模塊劃分等相關考慮的點，可供今後自己或他人查閱。
目的就是在編碼前理清思路，整體架構，查缺補漏，作為他人或自己的技術參考文檔。
自己在項目開發的過程中，也曽有過這樣類似的想法，但沒有作者那樣寫的系統，也沒有在團隊中落地。
基於文章中的設計方案，自己做了點修改。設計方案包括4個部分：需求、調研、實現和復盤。
- 需求：在設計方案的開頭，列出相關人員（便於精確找人），需求信息和各類時間。
- 調研：功能的技術選型，對比不同方案的優缺點，適當取捨，形成一套適合當前場景的最優方案。
- 實現：需要考慮業務流程、數據結構、功能邏輯、異常處理、安全性能、組件復用等，可用任意方式表達自己的思路，例如偽代碼、流程圖或純文字等。
- 復盤：內容可自由發揮，按照自己的實踐，記錄與需求相關的一切。
設計方案的難點在我看來有幾個方面，第一個是對於我們這樣的小公司，難以留出三四天專門做設計方案，我們的時間會被壓縮。
第二個就是在實際開發中，會與文檔有些出入，那麼就得實時維護這份文檔，程序員最煩的就是沒有文檔和讓自己寫文檔了，所以維護文檔是對自己的一個挑戰。
第三個就是規範的貫徹，制訂規範很簡單，動動嘴敲敲鍵盤就行，但是真正的執行卻會有很多阻力，其中最大的阻力就是人的惰性以及公司的客觀情況。
2）E2E測試
之前一直在思考一個問題，就是頁面搭建到很後面或者完成後，突然需要修改些邏輯，那該如何保證功能都正確呢？
靠人工測試，擔心會有遺漏，所以得想個自動化的方式。最近正好看到E2E測試，這個就能為我解惑了。
我選取的是比較知名的Cypress框架，功能眾多，文檔也非常完善，只是都是英文的，不過讀起來並不困難。
我並不需要達到多少的測試覆蓋率，我只要保證主流程能夠不出錯，尤其是在後期做修修補補後，有一個可靠的方式告訴我們當前頁面是正常的就行。
接下來就是在團隊中推廣了，得讓團隊成員切切實實的感受到，有了這個玩意兒能提升項目的質量，而並不是僅增加了工作量而已。
3）BFF
BFF字面意思是服務於前端的後端，我的理解就是數據聚合層。我們組在維護一個後台管理系統，會頻繁的與數據庫交互。
過去為了增刪改查會寫大量的對應接口，並且還需要在Model、Service、Router三層寫不同的代碼邏輯，吃力不討好。
為了節約開發時間，構思通用接口，並付諸於實際項目中。雖然簡化了Router和Service部分，但其實就是將該部分的代碼遷移到了前端頁面中。
這裡有一點小隱患，因為目前我們組的成員是全棧維護，所以知道數據庫ORM的語法規則，若前後端分離，那就不可取了，並且工作量其實是從後端轉移到了前端。
雖然時間是節約了一些，但是後端的代碼卻暴露在了前端，維護性方面下降了不少，於是想到了BFF。
首先查看了許多已經在運行的成功案例，有些是基於GraphQL重新封裝的系統，有些是定製化的系統。經過三天的仔細權衡對比後，決定自己定製化。
主要考慮了兩方面，一方面是改造成本，如果基於GraphQL的一些封裝庫（例如Type-GraphQL、apollo、Prisma等）來設計系統的話，那勢必需要了解這些的庫的方方面面，並且還需要將其集成到已經的結構中。
另一方面是使用成本，系統完成後是給人用的，不能太複雜，為了避免讓使用人員來適應這套系統，最方便的就是將之前的開發流程修改成配置化。
BFF的實現邏輯由後端定義，並且⽆需重構，也不必後端配合改造與聯調。
這套系統完成後，會真真切切地影響之前的開發流程，例如不必單獨寫接口文檔，並且可以隨時在系統中調試，而不必藉助postman調試。
具體的實現可參考此文。
4）需求遺漏
這兩天有個活動要上線，但是在上線前一天，才發現遺漏了一個支付需求。
此時離上線已經沒有幾個小時了，產品經理當機立斷，做了降級處理。
雖然臨時方案敲定了，但是這個事件背後，還是有需要我們反思的地方。
當時接到這個活動時，粗略看了下，和之前的活動差不多，於是就直接交給了之前的開發人員。
她在看了這個需求後，表示可以沿用之前的邏輯，沒過多久就完成了這個活動，提測交給QA。
大家都大意了，潛意識中都以為這次的需求和之前差不多，於是就漏了一個比較麻煩的功能，才出現了開場時的窘境。
那麼經過這次事件後，我再一次的完善了與產品的協作規範，要求至少有兩個人確認最終的產品文檔，羅列功能。
5）AST
AST就是抽象語法樹，這個縮寫我在很早之前就聽說了，最近聽一些視頻分享，講某某技術如何實現的，就提到藉助AST實現了一套規則語法。
然後之前在構思通用接口時，找到了一套開源系統，其中也提到根據AST自定義了一套規則。
這說明在設計一套系統時，了解AST的話，可以創造更多的可能。正好在V站上看到個帖子，問如何學習編譯原理，按照網友們的推薦，我搜了幾個視頻。
看了哈工大編譯原理的前面幾個視頻，還能理解，後面越看越悶，涉及到許多的數學原理，雖然每個視頻很短小，但是我的理解已經有點跟不上了。
後面突然想到之前用過的一個模板引擎：mustache.js，它的代碼只有600多行，但是自定義了語法和解析器，學習它的原理，有助於理解形成AST的詞法分析和語法分析。
在拜讀了多篇網上的源碼分析後，了解到mustache.js會先通過正則將模板字符串分割成各種類型的token，然後再將這些token與傳入的數據組合，根據規定的語法渲染HTML。
其中token包含type（類型，例如#、^等），text（匹配值），start（起始索引）和end（結束索引）。我這邊講的比較簡短，其實內部包括context.js、scanner.js、writer.js等模塊。
