「提效」這個話題很大，涉及了很多方面，雖然會和技術等工具有關，但它們相對來説不是重要的，由參與活動的人的認知、意識及其所決定的行為更為重要！
在《反思軟件開發：人為因素（上）》與《反思軟件開發：人為因素（下）》中嘗試闡述了「人」對「效率」的影響，本文和下兩篇文章我將試圖從「知識」的角度説明「效率」問題。
常見問題
我們在日常工作中遇到的問題很大程度是以分工協作及溝通交流為中心的——不僅是人與人之間，還包括人與機器之間和機器與機器之間。
業務支撐
在支撐業務功能時，前端是如何做的？
當今前端開發的主流做法就是在基礎組件（頂多再加上所謂的「業務組件」）之上新建個相應業務功能的「頁面組件」，一頓操作猛如虎之後，至少幾百行代碼出來了，如果佈局和交互稍微複雜點，破千行輕輕鬆。
設計師和產品經理驗收後很高興，不僅還原度高，還沒什麼「八阿哥」。可過了幾個月甚至一兩年，在需要加點新功能或做些調整時，打開代碼文件，傻眼了——
當時的業務邏輯是啥來着？這個地方當初為啥這麼寫？怎麼一個小調整要改這麼多地方？！這地方太複雜了，不敢改啊，改出問題又得背鍋……
有經驗的人都能看出問題主要出在哪，以及該如何避免，包括當初寫下那些代碼的人——
對代碼和邏輯進行適當切割，拆分出文件；語義化命名，以將部分隱性知識顯性化，並減少無意義註釋；抽象出具備高內聚性和可複用性的模塊；遵循各種「原則」，使用高大上的「模式」……
然而，真正有動力去做這些事情的人並不多，代碼寫得好又不會升職加薪，並且我們大部分人沒有什麼「正當理由」要求他人寫出好代碼——除非這成為帶有行政屬性的制度。
前端在業務支撐時的主流模式加上人的惰性，在人與機器的溝通交流中形成很大的障礙。
崗位職責
有些人對前端從業者抱有「不切實際」的期望和要求——前端應該懂業務——我覺得這很荒唐，這是他們的「幻想」。
當前一般意義上屬於「前端」的工作有網站開發、函數庫、組件庫、CLI 工具、開發框架等專注於「前端」這個領域且與企業「業務」不相關的；與「業務」有所關聯的，基本只有應用開發。
在以軟件及服務為營生的企業中，涉及到「前端」的職業、崗位有前端工程師、前端負責人、全棧工程師、（Modern.js 所倡導的）應用開發者/產品開發者、業務架構師以及產品經理。其中，是「純前端」（專注於「前端」這個領域）的只有前端工程師。
如果一個人，他的工作內容與職責不侷限於「前端」，那他實際上不是一個前端工程師，並很大可能也不會自稱為「前端工程師」；那些自稱「前端工程師」且説自己「（要/該）懂業務」的人，極有可能是被動的——在應聘或被安排工作時如此要求，或者是為了 KPI 和升職加薪。
「前端」理應是做「業務無關」工作的「前端工程師」——以此為前提，前端專注於展示與交互，代碼中不應有業務語義，與前端溝通時的語言也是業務無關的，轉化為與展示、交互強相關的用語——從「前端」的世界中剝離一切「業務」強相關的事物。
但是，應用開發中一定會有業務相關的事物，該如何處理呢？
在用合適的架構和框架將業務語義的邏輯、狀態等從 UI 組件中剝離出去之後，由非前端人員（通過 Handie 類的工具）去完成領域模型定義、業務相關的狀態控制等。
「非前端人員」是指除做「業務無關」工作的「前端工程師」之外的人——前端負責人、全棧工程師、應用開發者/產品開發者、後端工程師、業務架構師、產品經理等。
那些對前端抱有「不切實際」的「幻想」的人，估計是認為這會提高協作效率或價值產出？他們應該是想多了……
當一個人對「業務」一知半解且有自己想法時，溝通協作中發生摩擦的概率和次數會更高，不僅不會提高價值產出，還會降低協作效率。這個人，無論是不是「前端」。
在這方面，「設計」與「前端」實則屬於一類人——着眼於展示與交互，不需要去了解和揹負「業務」上的事情。要求「前端」和「設計」去懂業務，從「人」的角度看，這也算是一種壓迫行為。
測試左移
在軟件開發流程中，「測試」是在「開發」之後的，也就是在功能開發完成後才進行功能上的測試。這樣一來，只是程序單元上的問題還好説，但若是架構甚至是業務上有問題，返工的成本可就很大了。
為了儘早發現問題，並在沒造成什麼實際影響時解決掉，測試人員或行為需要介入到上游環節中，如測試人員參與需求評審、設計稿評審、軟件設計評審，開發階段進行單元測試等——這就是「測試左移」。
雖説這樣在一定程度上能夠達到預防的目的，但依然會存在信息同步上的問題——
在開發過程中發現了評審時沒意識到的問題，與產品、設計私下溝通後做了修改，但沒同步更新相關文檔也沒告知測試人員，這時就很容易會在不知情的情況下漏測，進而導致線上故障。
跨部門協作
總的來説，跨部門協作是很煩的事情，比同部門協作煩上幾個等級。究其原因，就是人性導致的利益衝突，考慮更多的是自身利益，而非共同利益；並且思想狹隘、目光短淺，做一錘子買賣，而非長期合作。
一個比較普遍的問題就是——
業務部門在功能迭代時需要用到中台/平台部門的服務，倘如此時中台/平台部門的基礎服務還不完善，無法「開箱即用」，那麼就面臨「業務方的個性化邏輯代碼寫到哪和誰維護」的選擇：
- 各自部門的人在各自的代碼倉庫中開發調試各自的邏輯代碼；
- 中台/平台部門在開發基礎服務的同時，在業務部門的代碼倉庫裏開發調試業務方的邏輯代碼；
- 臨時放在中台/平台部門的代碼倉庫裏，基礎服務完善後將業務方的邏輯代碼遷出去；
- 寫到中台/平台部門的代碼倉庫裏，並且後期變動和維護也繼續由中台/平台部門的人做。
正常情況下，無論如何不可能也不應該選最後一種，這是最基本的部門定位和職責劃分問題。然而，也許也會存在比較無奈的情形，比如：當不夠強勢的中台/平台部門遇到比較無賴的業務部門時。
更糟糕的是，業務方的邏輯比較繞，開會討論時已經各方自認為達成了共識，並按照自己的理解去開發了；但在測試時業務部門的人卻説中台/平台部門的人實現得不對，業務邏輯有問題，甚至還推翻了之前開會討論時所達成的共識……
由中台/平台部門去維護業務部門的邏輯代碼，這本身就是一件很扯蛋的事情！這對中台/平台部門來説幾乎是無利可圖，反而容易惹得一身腥！
小結
本文述説了我們在日常工作中常會遇到的幾類問題，並針對它們各自十分簡單且淺顯地表達了我的觀點。
這幾個問題雖然看起來五花八門，它們之間貌似沒有什麼關聯，但正如文章的標題和開頭説的一樣——它們的背後都與「知識」有莫大關係！
具體是什麼將在下篇文章中揭曉，在那之前各位有興趣的話可以先想下～😁
本文其他閲讀地址：個人網站｜微信公眾號
