什么是技術視野
網(wǎng)上看到不少關于如何提升技術視野的討論谆构，但卻沒有人給出定義署惯，到底什么是技術視野行施？
所謂技術視野，就是看問題時所能切換的不同角（維）度若锁。
下面就以API管理工具（以下簡稱“管理工具”）為例搁骑，來探討背后隱藏的技術視野。
API管理工具
零視角
曾經(jīng)在一個小型創(chuàng)業(yè)公司用到過最簡單的管理工具又固，就是一個開源的文檔管理工具仲器，界面功能類似wiki（維基百科）。
這樣的工具確實能滿足核心需求——API在線文檔化仰冠，并支持用戶管理乏冀。
可是深想一層，對于管理工具的使用者——工程師洋只，操作足夠友好辆沦，功能足夠完善嗎？
使用這類管理工具很多時候都會出現(xiàn)文檔與代碼不一致的情況识虚，也就是說工程師都不愿意去維護這個文檔肢扯。
因為編寫修改文檔是個耗費時間的事情，短期來看担锤，維護了既無利益蔚晨，不維護也無危害~
所以有時候接口的變更通過口頭協(xié)商而非文檔協(xié)商。
小結：零視角其實談不上視野肛循，是大多數(shù)工程師的最容易形成的思維方式铭腕，特點就是只關注功能/問題本身。
單一視角
當時為了解決上面的問題多糠，同時為了練手所學的Node.js累舷，我寫了第一版的管理工具，并參加了線下沙龍分享夹孔。
現(xiàn)在看來其實當初的寫的項目還是比較粗糙的被盈，除了展示界面相較于wiki更加美觀之外，主要加入了 Mock 功能搭伤。
更好的開源項目也有不少害捕，比如阿里的RAP和國外的APIDOC。
之所以把它們歸為一類討論闷畸，那是因為它們都體現(xiàn)了開發(fā)者的單一視角。
RAP就是典型地站在前端工程師的角度開發(fā)的吞滞。
比如第一版是以頁面來對接口進行分組佑菩，這種分組方式顯然不合理盾沫，后端之間的服務調用不涉及頁面怎么辦呢？所以第二版對此進行了修改殿漠。
又比如和 MockJS 深度綁定赴精，為前端工程師提供 Mock 功能。
MockJS 確實很不錯绞幌，不但支持數(shù)據(jù)模擬蕾哟，還支持數(shù)據(jù)校驗，后端也是使用前端工程師所熟悉的 Node.js 編寫莲蜘。
缺點呢后面在講其他管理工具的時候再對比分析谭确。
APIDOC則是站在后端工程師角度來編寫，增加了通過代碼注釋生成文檔的功能票渠。
小結：視角的建立意味著從0到1的質變逐哈，技術視野開始形成。此視野的工程師不再只關注功能實現(xiàn)或問題解決问顷。
多視角
偶然間讀到 Martin Fowler大神的一篇關于契約測試的文章很受啟發(fā)昂秃，文中提出了一種構想，通過管理工具來對前后端進行校驗杜窄，從而保障文檔與代碼的一致性肠骆。
于是開發(fā)了第2版的管理工具。這一版同時從前后端兩個角度設計塞耕。
對于前端不僅支持 Mock服務蚀腿，同時還能對請求參數(shù)進行校驗，甚至模擬服務端響應異常荷科。
對于后端增加了類似 postman 調試接口功能唯咬，同時由于采用 JSON-Schema規(guī)范，可以直接將schema移植到后端代碼中作為校驗規(guī)則來校驗參數(shù)畏浆。（RAP的局限性也在于此胆胰，MockJS的校驗只能用于 Node.js和瀏覽器端，其它語言編寫的服務端則無法使用刻获。同時對于后端來說也沒有如 Mock 服務器般好用的調試功能蜀涨。）
當然它和一些知名的管理工具 Swagger 、 RAML還是有些差距蝎毡，比如工具鏈不夠豐富厚柳，不能通過注釋生成代碼。
小結：多視角的建立是從1到N的量變沐兵，而這個過程需要積累更多的經(jīng)驗别垮，最終形成全局視野。
總結
經(jīng)吃眩看到一些公司在招聘高級前端工程師的時候會要求掌握一門以上后的端語言或者說把掌握后端語言作為加分項碳想，真正的用意不一定會要求前端工程師寫后端代碼烧董，但掌握后端語言的前端工程師會多一個思考維度，也就是技術視野更豐富胧奔。
很多工程師以為自己和大神的差距是技術逊移，但這種差距只是表象，而實質的差距是思維方式和技術視野龙填。
技術視野不一樣工程師胳泉，即使是做同樣的事情，取得的成就也會不一樣岩遗，這也是為什么我會在寫書的時候注重幫助讀者提升技術視野~
一個工程師做事情如果總是只考慮把事情完成扇商，零視角解決問題，最多只能成為中級工程師喘先。
能跳出事情本身钳吟，站在一個合理的角度進行思考，長久積累下來就能達到高級工程師的水準窘拯。
考慮事情的前因后果以及所在系統(tǒng)中的各種聯(lián)動關系红且，已然是架構師的視野了。
