一、日常問題
1）模糊的提測時間
最近有個活動，在提測后的第二天，大家才得知上線時間是后天。但是問各個技術，大家都不知道這個時間，而產品是知道的，運營也知道這個時間。
那這就有點詭異了，為何會出現這個情況呢，進一步了解后，才發現原來在一次會議上，口頭說了下上線時間和提測時間。
在那次會議上，大家都說了自己的開發時間，但是，對於提測時間，開發和運營卻有不同理解。我的提測時間是11或12，但運營的提測時間是10號，以后對於這種時間截點還是要更敏感一點。
UI給到我們設計稿的時間，晚了一天，其實如果不晚的話，即使我們不知道上線時間，也會按預期進行。
但現在晚了一天，加上大家都不知道上線時間，從而就沒有緊迫感，按照往常節奏推進，項目就會有延期風險。
還好發現的早，還能補救，運營肯定是不接受突然延期，因為她們做了很多前期准備。那只能加加班，趕進度了。
細究下來，其實還是溝通出現了障礙，之前也發生過一次對上線時間理解不一致的情況，只是當時是精確到小時，而這次是精確到天。
未來，對於項目，心里一定要明確各個時間截點，免得再出現這種烏龍了。
2）招聘
招聘是件蠻難的事情，就像找對象一樣，要對上眼很不容易。
在年前的時候，因為業務的上升，需要擴編，於是發布了兩個前端崗位。
可能是年前的原因，也沒收到幾份簡歷。HR也很忙，年底還有很多事情要做，也不能全部撲在招聘上。
后面自己也在V站上發帖，也投稿給知名前端公眾號和知名技術周刊上發布招聘信息。雖然轉化率還是很低，但是終於收到了幾份簡歷了，也算是0-1的突破了。
其中年前面試了一名候選人還不錯，年后讓他過來繼續后面兩輪，談下來都還不錯，就發了offer。自己也總結了些對求職者的一點小建議。
3）無人維護業務的修改
客服在半年前提過一個業務需求，當時其實也沒什么結論，因為是中等級的，所以也沒放心上。
后面又提過一次，得出的結論是服務端招人后，將整個服務全部遷移過去，做個徹底了斷。
但是近期，客服說要經常處理那個業務問題，很影響工作效率，於是提升優先級，當即安排。
我們組內的其他成員手上都有事情，所以我自己來修改。在改的過程中，根據域名查到了項目文件。
根據package下載依賴包，但本地卻無法運行，代碼已然缺失。還好改動程度並不大，於是就將代碼修改后，發到預發環境。
發代碼我自己還無法發布，權限在服務端那邊，我這邊也因為權限組的原因，無法給我開這個項目的發布權限。
所以我每次修改完，都要請服務端的人發布，然后再讓QA驗證。期間調用一個接口，涉及到另一個項目的改動。
這個項目也一樣，無法本地運行，也只能發到預發環境。期間查看日志，沒有訪問記錄。
這個問題還請運維介入排查，原來是因為接口調用了線上的域名。而這個域名其實是個IP地址，直接關聯網關。
由網關根據地址路徑做轉發，預發環境沒有這類地址，又折騰了半天才調好。
運維前幾天打算釋放幾台服務器，這其中有台服務器搞了個私有的npm，服務於這次修改的項目。
如果運維將那台服務器釋放掉了，那么這次連代碼都無法發布了，還要重新配置。
就是一個簡單功能的修改，涉及兩個無人維護的項目，前端、QA和運維三端參與，服務端還需要配合，在人力成本上面，還是蠻大的，ROI（投資回報率）有點低。
不僅開發調試困難，QA驗收也困難，沒有需求文檔，只能通過我對代碼的解釋和她說明整個項目的流程。
還有一個比較麻煩的點是，修改的功能需要與支付寶對接，支付寶會回調我們這邊的一個接口，需要外網訪問，就不能在內網的測試環境驗證了。
有個地方比較慶幸，那就是回調地址可以根據環境改變，否則的話，又要改造，開發成本就更高了。
這些項目就是安全隱患，平時看不出，一旦有問題，要修復就要花費巨大的成本，今年需要推進遷移計划。
后面和運維單獨將正在使用且無人維護的后端服務找出，並且篩選出正在訪問的接口或定時任務，擇機做遷移，交給服務端維護。
二、工作優化
1）項目管理的流程漏洞
最近有個功能的修改是由服務端的人提出的，在和產品溝通后，拉上相關人員開了個需求會，還整理出了相應的產品需求。
后面產品就沒怎么跟，讓我們自己開發去了。這個功能前前后后總共持續了1個多月，服務端的那個人由於要去考試，就只能斷斷續續的開發。
中間他請假了好多天，QA在預發上對功能都驗收后，發出了上線郵件。
然后這里就有問題了，雖然這個功能只是改動了售后流程的一個地方，但勢必會更改客服的工作流程。
直接上線后，和他們簡單的溝通如何使用后，他們就開始使用了。晚上19點多的時候售后有個地方卡住了，咨詢服務端，也沒響應。
那么客服只能按照自己的理解采取措施，但是那些訂單都創建失敗了，等到第二天早上10點，服務端才說他們漏了一步。
大家都很無奈，一個早上都在配合着改，我這邊還回滾了代碼。
從這邊我看到了一個項目管理流程的大漏洞，就是在上線前還是得和業務方同步一下，讓他們先了解整個操作的步驟，避免出現歧義。
如果能多這么一小步，那么就不會搞出這么多麻煩事兒出來。很多時候都是人為的給自己制造麻煩，都自以為是很簡單的事情，其實不然。
2）Tower
Tower就是一個需求管理工具，公司的業務人員會將雙月需求提交到此工具中。
我們技術部的工作就按照此工具來排，老板的想法是讓業務和技術兩個部門的人溝通能無障礙。
他覺得現在技術部和業務部之間的信息還不夠透明。業務部提了需求，有時候就會泥牛入海。
借助此工具，就能了解到需求進行到了哪一步了。
在實際操作中，就暴露了很多問題，其實已經實行了一年，但是大家並不會太關注上面的狀態。
也就是說，大家並不會及時更新，也就是上面推了下，自己再寫點東西。
這個工具中的大部分工作，都指向了我們。對於我們來說，這上面的需求排在版本和活動之后，屬於第三優先級的需求。
在過去的一年中，由於人員有限，在完成版本和活動后，也就沒剩下多少時間來改需求了。所以對該工具就更不上心了。
但今年有所不同，管理層對這個工具很上心，還說要和OKR關聯。這個雙月開了好幾次Tower會議，一遍遍的強調該工具的使用。
其實每個雙月都會遺留很多需求到下個雙月，除了人員緊缺之外，還有就是落后的生產力，今年這種局面都會有所改變。
3）UmiJS升級
去年因為要引入微前端，所以做過一次 1.0 到 2.0 的被迫升級。
今年是想主動升級到 3.0，一則是與主流技術棧接軌，二則是因為3.0 版本默認支持TypeScript。
今年想要在組內推廣 TypeScript，進一步的提升項目質量。
升級的過程也不是說很困難，但是遇到些體力活，改文件和移動文件，弄了一下午，具體過程在此。
還有比較擔心的是，升級后業務的穩定性，我們缺少有效的全局測試，目前只能人工一個一個頁面的點擊。
在發到正式環境之前，會先在預發環境發布，邀請相關業務負責人，先在該環境中操作界面，提早發現問題。
4）管理后台發布提速
管理后台的界面代碼發布一直很慢，基本保持在12分鍾左右，去年也一直嘗試着去優化，不過都沒很好的成效。
這次和運維仔細分析了下症狀，嘗試着再做一次優化。
每次發布大致可分為四段，第一是下載依賴包（2分鍾），第二是構建（3分鍾），第三是上傳鏡像（3分鍾），第四是部署（3分鍾）。
除了構建之外，其他都可以靠運維來優化。
依賴包可以開啟緩存，鏡像原先要1.4G了，所以上傳才要幾分鍾，主要是因為將 node_modules 目錄中的文件也打包了，這部分其實在網頁運行時，並不需要，所以要去除。
部署也在優化后，總共的發布時間控制在5分30秒左右，未來如果將構建也進一步優化的話，那發布速度還能往上提。