一、日常問題
1）在家辦公
3、4月份上海疫情很嚴重，公司在3月初的時候就果斷讓大家在家辦公。
一開始，我覺得在家辦公會很影響工作效率，但從後面的工作完成度來看，並不是這樣。
以我自己爲例，我感覺工作時間變長了，因爲本來還有通勤時間，現在這部分時間都省了。
早上九點沒什麼事情，就可以開始工作了，中午喫好飯，急的話也可以開工，晚上喫好飯，都能做到20點。
這麼一算的話，去掉喫飯和休息時間，每天工作得有個8個小時以上。VPN、筆記本電腦都配置好，和在公司上班沒啥區別。
只是同事之間的交流只能通過即時通信軟件了。我們團隊的話，會每天下午16點，開個視頻會議。
- 一則是分享些公司消息，瞭解公司動向。
- 二則是大家見見面，聊些近況，免得一個多月不見就生疏了。
- 三責是及時解決工作問題，積累經驗，並且避免掉進坑中浪費時間。
- 四則是做些內部的技術分享、Code Review等事情，維持技術氛圍，保障項目質量。
2）合理修復線上問題的過程
前幾天休息日的晚上，運營對服務端的開發說，客戶端首頁有個版塊的圖片有點模糊，服務端的人就找到了我。
我在簡短的分析後，就發現是因爲圖片的地址中帶了尺寸的參數，要清晰的話，就將該參數去掉即可。
那麼接下來就涉及如何修改了，我給出了三套解決方案。
（1）在首頁接口中，由服務端手動去掉尺寸參數，這是最快速的臨時方案，但服務端覺得這樣不合理，應該在後臺上傳的時候就去掉。
（2）我馬上給出了第二套方案，那就是將後臺那部分相關的接口，全部交由服務端統一處理，但他們覺得工作量太巨大，從長計議。
（3）既然如此，我給出了第三套方案，那就是在後臺中，相關圖片在上傳時全部不做默認的壓縮，只上傳原圖，由服務端根據不同場景動態添加尺寸，但他們覺得改動成本略高。
於是經過討論，敲定了方案一，但是要與運營說明方案的利弊，以及潛在的風險，修復成本等等。
例如將圖片修改成原圖後，首頁的加載速度勢必會受影響，並且客戶端有可能出現不能適配原圖的問題，還有就是在調試接口時，需要先上測試環境，安排QA驗收，意思就是要有一定的時間和人力成本。
因爲圖片模糊的問題既不影響營收，也不影響當前業務的流程，所以在給出方案後，並不是說馬上就要修復的，需要商量上線時間。
既不給自己壓力，也不給其他研發組的成員壓力，客客氣氣協助修問題。
3）HTTPS證書
最近出了兩次事故，都是因爲證書到期，導致無法通過HTTPS協議訪問。
這些域名都是由運維在管理的，但是他們之前沒有將域名統計到一個文檔中。
現在有100多個子域名，分散在各個項目中，手動的蒐集，難免就會有遺漏，運維也意識到這一點了。
他們這次將所有的子域名都統計到一張表格中，而我們出事故的那幾個子域名就被遺漏了。
雖然整理的工作是他們在主導，但是自己組所使用的域名，自己還是得清楚。
依賴別人的話，還是會有點不穩，因此事故後，在組內也組織了人力去將所有使用的域名都統計出來。
其實其他事情也一樣，在自己管轄範圍內，儘量還是做的精細些，並且能識別出其中的隱患，不然出問題了，背鍋的是自己。
4）上線把關
最近上線一個計算積分的活動，但是發現數據多算了一天。
究其原因，就是上線前的測試數據沒有清除乾淨，這就是一個流程問題。
差了最後一步，QA在驗收完成後，需要與我們確認數據，例如緩存是否清除，定時任務配置是否正確。
立刻將這一條寫入協作規範中，並且傳達給了組員和QA組，讓大家未來任何活動都需要有這一步。
以免再次出現此類問題，這次的活動，默認就當早一天進行了，運營也沒有表示異議。
二、工作優化
1）管理後臺響應式改造
爲了提升業務人員操作管理後臺的體驗，花了點時間進行響應式的改造，緊急情況時，掏出手機就能工作。
利用CSS3的媒體查詢，就能根據不同屏幕的尺寸採用不同的樣式來渲染，目前使用的移動端屏幕閾值爲750px。
爲了便於管理，基於Less的語法，聲明瞭一個常量，專門記錄屏幕尺寸。
@mobile-screen: ~"(max-width:750px)";
我們當前使用的管理後臺基於UmiJS3.X和Ant Design 3.X。具體改造過程可以參考此處。
2）團隊內部的技術分享
在四月初，我發起了團隊內部的技術分享，用意其實很明顯，就是想讓大家能花更多的時間關注技術，提升自身能力。
雖然是我強推的，但是大家的響應還是蠻積極的，差不多一個月內分享了4場，平均一週一場。
覆蓋的範圍包括源碼的解讀、工具的使用等，分享下來，聽到最多的就是對該庫或工具有了更深層次的理解。
這就是我想要的，我在他們分享之前，給他們限定了一個範圍，就是要我們當前團隊正在使用的。
因爲你正在使用，所以在知其然後，就能馬上應用到日常工作中，排查問題的思路也能更多，印象也能更爲深刻。
還有一點就是，我會讓大家把分享好的資料整理成文檔，貼到內部WIKI中，也供其他人可以瀏覽學習。
我想通過這個技術分享，來持續保持團隊內部的學習氛圍。
3）日常性的體驗優化
我理想下來，用戶體驗優化，要優化的點的來源於兩處。
第一處是業務方的反饋，第二處是代碼中。
前幾天，一個運營希望我能在一張頁面的過濾條件中增加一個條件，這種需求對於我們開發來說，就是舉手之勞，但是對於她們的工作體驗那是很高的提升。
日常工作中，我其實也一直在給我們組員灌輸幫助業務方提升體驗的意識。尤其是那些改造成本很低，但是見效快的需求。
我們日常工作就是寫代碼，那麼在寫代碼的同時，也會去理解業務邏輯，這個時候其實也可以做體驗優化。
例如之前有個頁面要做修改，在修改時發現這個頁面居然沒有查詢條件，但是頁碼卻不少，一處非常明顯的糟糕體驗。
給此處加個過濾條件，成本也並不高，加完後，業務方還對我們組表示了感謝。
所以說，並不需要大張旗鼓的專門抽時間來做體驗優化，完全可以分散到日常工作中，逐步優化。
對於改造成本較大的優化，那麼就需要排期，走一整套的研發流程。