我眼中軟件工程裏的常識

背景

提及工程人員/團隊應該具有的「常識」，真正促使我認真思考這個問題，仍是由於知乎的一篇貼跟沒有常識的人聊天是一種怎樣的體驗？，裏面笑料百出，各類因爲「常識」不足致使的尷尬癌真真是忍俊不由。但笑過以後我發現，所謂的「沒常識」，可能由多種緣由致使，這點在知乎裏多位答主都提到過：

1. 信息不對等 － 你們所處環境不一樣，對「常識」這樣一個相對概念自己囊括的內容就有不一樣定義

2. 道德水準低下 － 雖常被歸類爲「沒常識」，但經過仔細甄別是能夠分辨出來的

3. 邏輯混亂 － 可見於24種常見的邏輯錯誤 – 做者：謝至理

拋開第二種暫且不論，就一、3而言，在咱們軟件工程中，這些緣由是否可能致使溝通成本提升、工做效率變低呢？下面結合我本身的痛苦經從來談談「常識」的故事！若是我下面所述你早已爛熟於胸、甚至還有補充，恭喜你，你爲本身所在團隊增添了一抹幸運！若是你對裏面的部份內容還不清楚，或許那正是你須要的。

操做系統是不一樣的

Windows 與 OS X

你們能夠看獲得，左邊是OS X的finder，右邊是windows的explorer，不管從UI設計仍是功能設置，他們都有很大的不一樣，譬如：一樣是小叉叉，但在兩個操做系統上功能是有差別的。

iOS 與 Android

盜圖，侵刪(若有冒犯，先行致歉)

如圖，一樣是facebook的應用，左邊是iOS版；右邊是Android版。

有我的喜愛沒有問題，但若是生硬的將之帶入工做中，並執拗的忽略操做系統間的差別就會影響到工做質量。

我曾不止一次看到有測試人員爲OS X應用提了bug － 「[OS X]點擊關閉按鈕應用沒有徹底退出」；

又有人爲windows應用提bug - "[windows]ctrl + q快捷鍵不起做用"。

可是大哥，真心的，若是你實在懶得不想去了解兩個系統到底有哪些不一樣，也最好靜下心來聽別人說說，至少你得認可操做系統是不一樣的。

這個問題上，我認爲，做爲一個軟件工程人員，首先應該理智的認可——操做系統是不一樣的。

Web不僅是前端的事兒

跨域問題

近年來由各大巨頭公司猛推的先後端分離炒得火熱，不過我發現實際操做中一些團隊都受困於對跨域問題的理解。舉例：因爲先後端團隊對跨域問題的理解程度不一樣，甚至有時候是都不瞭解，致使當錯誤發生時，前端找後端要求支持cors，後端反問「那是什麼東西，你都說不清，我不能幫你」。搞得最後連post、put、delete等方法都要上jsonp，試圖繞過跨域問題，可jsonp畢竟是有侷限的，這裏咱們不過多深刻，各位能夠參考構建public APIs與CORS。

restful

以前合做過一位後端「大神」，他說本身的API設計擴展性超強，是真正健壯的restful接口。因而我請他講解，其滔滔不絕道，個人接口直接把前端和數據庫打通，大家直接傳數據庫字段和對應值，我一一幫你錄入數據庫。當我問及，那會不會被人利用黑咱們數據庫，致使大量廢數據產生，「大神」鄙夷的看我一眼說，你本身都說是廢數據了，業務不通，是不會顯示在用戶界面裏的，怕什麼！可我想說的是「大神」啊，壞人能夠分分鐘幹爆你的數據庫，這麼「透傳」真的是擴展性好麼？

還有一事，對於一個數組字段，沒有值的時候究竟是返回null仍是[]又成了一個問題，一位友人和我強調他們後端就是要返回null，理由是"java語言設計了null，那麼返回null就是最好的選擇"。因而我又默默的去一邊呵呵了。

咱們並不是要求每一個人都對restful的各類約定、要求滾瓜爛熟，但網上關於restful接口設計的經典案例、最佳實踐，一搜一大把，並且內容都很少，既然都說本身在用restful了，那麼看看別人的最佳實踐，不過度啊！

URL

盜圖，侵刪(若有冒犯，先行致歉)

一個URL到底由哪些部分組成，各部分的學名又是什麼，我猜你可能已經發現周圍有人不知道了。我曾見過兩個在討論subdomain問題的人，然而1個多小時過去了，也沒什麼結果，吵得不可開交。後來我讓他們畫下本身說的究竟是URL的哪一個部分，結果發現二人說的所謂subdomain根本不是同一個東西。

既然你們都在互聯網圈子混，可以準確指出URL各部分都叫什麼名字，專業且溝通成本低，不過度啊！

渲染？

常常看到有朋友問及相似：「AngularJS裏有模板，咱們公司用Node作服務端也有模板引擎ejs，兩者可否混用，如何混用？」，其實這種問題多見於初入門者，沒搞清楚的「前端渲染」和「後端渲染」有什麼區別，並且基本能夠判定對一個URL從敲在瀏覽器地址欄起，到頁面最終顯示出來，都經歷了哪些過程並不清楚。因此你可能須要知道當你輸入一個網址的時候，實際會發生什麼?。而後還須要搞明白「後端渲染」究竟是什麼，最後再回想你關於"混用"的問題。

複用

「複用」這個詞咱們每天見，就像「大寶」同樣(年齡暴露)，但複用都有哪些層次，這個問題就有點意思了，我想了想，大概可能有如下幾種吧：

• 拷貝、粘貼 － 這應該是最多見，也是最簡單粗暴，容易理解的那種了。你寫好，我來拷貝、粘貼到個人項目裏，複用達成！

• 運行時複用 - 之前網站開發中常見的模式，一個css文件，全部的頁面樣式都在裏面；一個js文件，全部頁面的業務也都在裏面。好處是你真的不用關心誰配誰，反正一共就倆文件，壞處也顯而易見，當你要優化網站時，可能想要需加載、可能想剔除沒必要要的代碼、也可能只是想按業務拆分代碼，立馬讓你抓瞎。

• 開發時複用 - 在browserify, webpack, rollup之類打包工具的誕生之後，前端圈子也愈來愈注重這個層次的複用。各類資源均可被定義成「模塊」，在開發過程當中按需引入，rollup甚至還具有了tree-shaking這類神同樣的優化能力，使其更顯逼格。

至於你在項目中須要採起哪一種複用，這就看你本身對複用的認識和項目自己的需求了，但不管如何，複用真的分不一樣層次，這點做爲軟件工程人員你是須要知道的，並且在團隊溝通中，最好統一你們的認識，以避免驢脣不對馬嘴。

自我驅動

「學而不思則罔，思而不學則殆」 － 孔子在2000多年前就講了學習和思考的關係，咱們活在當下，又怎麼能超脫！？

咱們經常在工做中遇到這樣那樣的問題，有時候人們是這樣回答的：「咱們的業務很是特別，對於這個功能，沒法支持」。首先我相信世界上有些功能的確作不到，但這種話聽多了就會奇怪，你的業務真的就那麼「特殊」麼？或者說，你遇到的技術問題，就那麼「惟一」，網上一點痕跡都找不到？

其實我想說的是:

盜圖，侵刪(若有冒犯，先行致歉)

但爲何你就是找不到問題的答案呢？總結了一下我多年的工做經歷，我發現如下幾點是形成「無解」假象的主要緣由：

1. 第一名就是不會善用搜索引擎，尤爲不會善用google。還記得多年前曾帶過一個實習生，他說沒辦法在servlet裏獲取請求的query參數，我大驚並質疑其答案的正確性，他說反正在google沒找到結果，隨後即猜想應該是必須引入框架，僅憑servlet應該是沒法拿到參數的。對話進行到這裏我基本判定是他的搜索姿式不對了，由於就問題而言真的沒有那麼special。當讓他展現搜索過程時，他在搜索欄寫到"i have an issue about retrieving url parameters, which is balabalabala"。也許你可能會笑，但這是咱們工做生活中常常遇到的可愛的人，或許他們真的覺得網絡的另外一頭有一個大神正戴着耳機，眉頭緊鎖的盯着屏幕回答來自世界各地的問題呢(儘管他本身也是個工程師，但仍然會迷信的認爲後面有什麼鮮爲人知的大招兒)。在使用搜索引擎時，準確的分解、抽象問題，而且使用友好的分詞組合是很是重要的手段，也是在人人平等的搜索引擎裏，你如何脫引而出的根基。

2. 坐井觀天必定穩坐第二把交椅，很多朋友對於新知識是深惡痛絕的，他們善於利用已知的(僅有的)知識來解釋本身未知的領域，譬如常見的觀點有：管他什麼聲明式仍是命令式，我都不關心。我就是要寫$(...).show()/hide()，多直觀的代碼啊！你去搞什麼Angular、React、vue，弄些什麼數據驅動，都是吃飽了撐的。這些框架最後不也都乖乖的作DOM處理？與其等框架處理，我本身寫很差麼；管他什麼模塊不模塊，我一股腦的寫完腳本，最後concat -> minify一下，不也是一個文件麼，亂七八糟的又是commonjs、又是ES6，還有什麼AMD，看的頭都大。＝＝＝＝＝＝有自信是好事，但在不瞭解背景緣由的狀況下，生硬的拒絕並非高明的表現，或許數據驅動不適合你，但你肯定已經掌握數據驅動要解決的問題了麼？或許模塊化不適合你，但你又搞明白了ES6是怎麼解決循環依賴的問題？AMD最先是爲何被提出的？

說實話，沒有誰是與生俱來的the one，咱們大多數時候遇到的業務模型，也沒那麼舉世無雙，不恥下問、兼聽則明，只有不斷的鼓勵本身多學、多看、多聽，多想纔有機會躋身前列，或者說，起碼能夠作個對得起本身職業的人。

忙碌 !== 高效

下面絕對是張你們相識已久的圖，我就很少說了：

盜圖，侵刪(若有冒犯，先行致歉)

有位朋友是這麼評價圖裏推方輪子的人的，「你永遠無法叫醒一個裝睡的人」。

對於尸位素餐者，想必也不會來看我這篇東西，也就不用給出什麼提升的建議了，由於他們「不關心」

但對於團隊管理者，以及團隊其它成員，大家要注意的是，團隊如今的情況，究竟是高效率的忙碌，仍是使勁推着方輪子在趕路。

責任邊界

圖片是從百度搜的，侵刪(若有冒犯，先行致歉)

有朋友可能會對該圖產生疑惑，其實這裏我想說的，軟件工程團隊講求合做，合做首先要求每一個人把份內之事作好！

咱們常在工程師論壇看到人們抱怨PM的不專業和拍腦殼，總須要開發擦屁股、背黑鍋。但話說回來，這個事情真的沒有改進空間，沒有避免的可能麼？

咱們先假設工程師說的都是對的，問題就是出在PM身上，那做爲一個團隊，除了抱怨，你就沒有責任幫助他提升麼？你可能說PM的專業技能包含好多，我不會怎麼幫？但溝通技巧、注意事項老是能夠幫的吧？有人又說，PM趾高氣揚，即使我想和他說說溝通的注意事項，他也未必聽個人。接下來我想說的就是針對這類牛逼的合做選手的腹黑手段(固然也會迫使對方自我提高)。

我經歷過一個團隊，每次要從PM、設計師那裏拿到需求和設計，可是因爲PM和設計師的不專業，他們提供的需求裏每每僅包含正確邏輯，譬如：一個登陸頁面，只告訴你用戶名、密碼都輸入正確時的應對場景；但沒有說，用戶名沒輸入怎麼辦，輸入錯誤怎麼辦？密碼沒輸入怎麼辦，輸入錯誤怎麼辦？用戶名、密碼的格式要求是怎樣的？這些交互上的其它問題他們都無論了。因而咱們的開發就和愛心媽媽同樣，本身把可能遇到的問題，以及UI該是怎麼樣的，所有都開發一遍，而後demo給PM/設計師，讓他們挑選一款，其他的再刪掉！我去，這是多大的開發資源消耗啊！團隊給個人答覆就是，他們不懂，沒辦法，只能咱們作了給他們挑。因而開發進度被拖慢，誰之過？PM說了，開發團隊不給力，作的太慢！開發質量不夠高，經常一堆冗餘代碼刪也刪不乾淨，由於不知道以前哪一個設計待選稿里加的，刪除時忘了，誰之過？PM說了，開發團隊不給力，多版本處理不當。設計、交互不夠好，誰之過？設計師說了，開發團隊不給力，作東西東拼西湊還老是錯。

我去，這讓我想起了東郭先生和狼的故事，咱們辛辛苦苦幫你PM、設計師作大家該作的事，完事還被反咬一口！但仔細想一想，問題的緣由不是他們壞，而是開發團隊模糊了團隊協做時每一個人的責任邊界，咱們固然須要親密無間，但這不表示個體之間責任能夠混亂。能者多勞當然牛逼，但任何角色都應該按質量完成本身份內的工做，這裏開發團隊只要咬死需求缺東西、設計不完善，迫使責任人修正就行了，而不是一味的幫他人善後。

自動化測試

提及自動化測試，經常有人會站出來反駁道，反正作不到100%的覆蓋率，並且花費時間甚多，何須浪費時間寫各類測試用例。這是一個重大誤解，自動化測試及其意義咱們能夠看到如下幾點：

• 更省錢 － 對於穩定的功能(常見於迴歸測試)，能夠作到一次編寫，屢次運行

• 更快速 － 對於相同的測試內容，自動測試顯然要比手工測試快

• 更可靠 － 對於相同的測試內容，自動測試的結果顯然也比手工測試更可信(人是有可能犯錯的，譬如：分神了)

• 更低風險 － 對於項目轉手的狀況，若是有自動化測試，更利於再維護

• 更強大 － 自動化測試能夠模擬1w甚至100w人同時訪問的併發情況，手工測試則仍然須要藉助工具，不然沒法完成

markdown

markdown做爲一種輕量級的「標記」語言，愈來愈受歡迎，不管是Github，stackoverflow仍是segmentfault，都支持markdown編寫、提問、回答。

不要被「語言」兩個字所嚇到，其實markdown超級簡單，容易掌握，並且話說回來，不會寫markdown，你就連在stackoverflow、segmentfault上提問都作不到格式整齊，還期望別人根據你混亂的描述回答你？別鬧了好麼，你們都挺忙的！

沒有銀彈

不管你遇到了什麼問題，須要引入額外的技術手段，或者流程來解決，都必定要先了解即將引入的技術、流程的背景，工做原理，而後正確、準確的使用，不然事倍功半。

我見過很多人/團隊，據說AngularJS好，都沒仔細看明白人家到底解決了什麼問題，就直接一股腦引入到本身項目裏，胡亂使用，在controller裏操做DOM，在service裏也要操做DOM，出現問題後反而處處抱怨說Angular就是狗屎，咱們用了半天，什麼問題沒解決，反而出了一堆錯。

也見過有團隊據說scrum有助於提升團隊工做效率，就引入了，甚至都沒有作系統的scrum培訓。結果致使連最基本的形式流程都作的缺斤短兩，更別提深層次的理論結合實踐再創新了。結果就是場面一片忙亂，但效率卻絲毫沒有提升。因而又處處批評，scrum就是一幫閒着沒事的人搞出來的蛋疼產物，除了耍人，沒有卵用。

這種思惟方式就是《建黨偉業》裏辜鴻銘說的：「孔子教人之方法，如數學家之加減乘除，兩千年前是三三得九，今日還是，不會三三得八。自家學藝不精將題目算錯，卻怪發明之人，毫無道理」。

開發和測試的關係

當你認爲開發和測試是敵對關係時，你就進入誤區了。開發、測試沒必要你死我活，也沒必要互相仇視，你們是在一個團隊，爲同一個產品貢獻力量，正確認識團隊，正確認識合做，才能使咱們走的更遠。

結束語

關於軟件工程團隊裏的「常識」，我相信仍有好多內容須要普及，所謂普及，並非要求諸位關於上述的每一項都成爲專家，而是時刻懷有敬畏之心、進取之心、鑽研之心。坦白講我不是什麼高手，但我熱愛個人工做，我但願把它作好，也鼓勵入行者都熱愛程序員這份職業，以上篇章或有疏漏、錯誤，歡迎指正！

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝分割線========================================

後記(補充)

最近看到一些朋友的評論，質疑本章並不是軟件工程常識，而是前端／web常識。我大膽猜想一下，幾位朋友應該是看到本文中大量的前端／web詞彙而有此結論，那麼我想有必要稍微解釋一下，本文並不是關於工具、技能、技術的整理，我原意不止於此。

一般咱們訴諸文字亦或語言來試圖闡述一個觀點、講述一個道理時，會使用舉例的方式使觀點、道理更簡明易懂，主旨並不是例子自己，而在於其背後的寓意。 就好像成語「脣亡齒寒」那樣，咱們從中學課本里看到抗美援朝的緣由是「脣亡齒寒」，你不會真的覺得50多年前幾位國家領導人由於本身牙齒不舒服，就派兵去朝鮮參戰吧？

我之因此使用大量的前端案例，僅僅是由於我近幾年工做重心於此，拿來順手而已，若是因爲個人例子過於貼近前端／web而給部分讀者形成了誤讀，那我得爲我自己知識的侷限給你們道歉！同時也建議同窗們學好語文！

再有一個須要解釋的東西，前端 !== web， 準確的關係是 前端 > web。

下面我來分別解釋下我每一個章節都具體想說什麼(語文很差的朋友，權當此補充爲"總結中心思想"吧)

操做系統是不一樣的

若是你糾結于于例子中的finder和explorer，facebook app，就認爲我是在講前端常識，那若是把舉例對象換成shell和cmd呢？不會又以爲我在講命令行常識吧^^。本章的主旨在於，工程人員由於工做環境的緣故可能涉及不一樣操做系統，因此必定要從心裏中承認她們是不一樣的，不然本身使用不愉快、和他人交流不暢、錯誤描述不許確。。。均可能影響你的工做。

複用

若是我不用browserify、webpack...而換成make、ant、maven會不會好些？軟件工程界都會涉及複用問題，不管你寫什麼語言，作何種業務。

自我驅動

例子1中的servlet是但願把讀者帶入具體場景，更容易理解問題。中心思想是，準確、正確的使用搜索引擎以及其餘諸如stackoverflow、segmentfault等工具來解決你的問題是很是關鍵且重要的技巧。換句話說，難道不作前端，搜個delete row in mysql就不能夠了？

例子2中，若是不用jquery和angular等舉例，命令式、聲明式編程，數據驅動的概念總仍是存在的，不信你去Wikipedia上找找Data-driven programming，不見得就是前端／web特有的吧？又好比後面提到的ES6等模塊化概念，重點不在ES6，而是模塊化的應用，關於代碼的組織規範，總不見得只有前端／web才關心吧？

本節主要想探討對於知識的渴望、運用與敬畏，若是你只能看到ES6和angular，^^....

忙碌 !== 高效

這節若是還能聯想到前端／web，我就無能爲力了

責任邊界

本節我我想討論的是團隊協做中，責任邊界的重要性。不管你是否開發一個登陸界面，在團隊中都須要與他人合做、溝通，如何把握責任是相當重要的一點。

自動化測試

我相信大部分公司都沒把UI自動化測試提上議事日程，因此本節不能說我在講前端／web吧

markdown

我並不認爲markdown是一種前端／web技能，難道做爲一個常和matlab打交道的數據分析工程師/科學家，就不能用markdown寫博客，不能用markdown在stackoverflow、segmentfault上提問了？不能由於和web有關係，就硬說這是web開發常識，不然，「你是學計算機的，那必定會修電腦嘍？來給我看看個人顯示器怎麼了!」

沒有銀彈

若是我把AngularJS換成Berkeley DB呢？關於慎重引入新技術的這個話題，你還以爲是前端／web麼？

其實本節的中心思想在原文中已經給出了：「孔子教人之方法，如數學家之加減乘除，兩千年前是三三得九，今日還是，不會三三得八。自家學藝不精將題目算錯，卻怪發明之人，毫無道理」。我不是在談數學哦

開發和測試的關係

別告訴我，你只見過前端／web有測試，作別的內容都不須要測試？

其實認認真真在討論web開發的，就只有Web不僅是前端的事兒，但若是你仔細讀一下會發現，裏面僅僅是一些詞彙，我並沒過多的介紹web開發技巧，所談的無非是 做爲軟件工程師的職業操守罷了