軟件論道二：考試、規范和良心

小引

在本文中我們將探討如下問題：

1.??軟件工程需要哪些能力以及如何保障這些能力？

2.??哪些地方我們需要注意復雜度的問題？

3.??考試的目的是什么？

4.?莫要讓規范束縛了我們的手腳，成為技術的奴隸。

5.??要讓人的能力發揮到極致，良好的心境是必須要有的。

6.??專注于自己擅長的事情。那么，在軟件工程當中，這樣的理念應該如何貫徹呢？

7.??為什么我們需要對代碼和設計進行重構？如何做？

8.??如何保證軟件開發的質量呢？

考試

考試的目的是提高開發人員的基本素質，是督促大家自覺學習的一個重要手段。

先來分析一下軟件開發工作的的特點，再來談考試的作用。

關于軟件的工作劃分，?大體上可以劃分為20%腦力和80%體力的比例，?20%這一部分偏重于創造性的工作，包括架構設計代碼。創造性的研究工作，主要是明確方向，把握質量，這部分工作需要經驗和長期的項目積累，當然有人說需要天賦（這個天賦我強調的是因時、因事、因地變化的能力）也可以，這一部分工作需要這個項目的靈魂人物來擔當和把控。

80%這一部分偏重于重復性的工作，代碼的編寫，文檔的編寫，通過上面20%工作的指導具體展開實施工作。這一步考察的主要是理解力和紀律性。尤其是在項目快速推進的過程中，讓團隊上下整齊劃一，統一行動，直到完成目標版本的開發任務。

由此衍生到團隊建設和成員能力方面，團隊的籌建源于某個目標，比如業務需求，研究任務等等。有了這個目標以后，可以著手物色合適的人選去做上面提到的20%的創造性工作。這部分人員素質一定要高，經驗豐富，反應迅速，學習能力極強。

基礎架構設計工作明確以后，需要把任務分派下去，這就是80%這部分工作的實施階段。這部分人員素質當然越高越好，但不是第一位的，理解力和認真執行能力更重要。

對應上面的分析，結合關于通過考試來取舍軟件工程師的做法,?個人認為不妥當，考試可以作為能力提升的一種手段，比如剛入職的員工沒有具體的任務分配，可以通過考試這種簡單的問題需求提高自己的能力和經驗。

或者在項目完成以后，大家長期無事可做，也可以通過考試來收斂思緒，督促自己學習。

規范

原則和模式是軟件工程質量的基石。原則如SOLID, ACID等等，也就是高內聚低耦合的指導原則。模式是可以借鑒的一些實踐經驗模板，如MVC, MVP, MVVM, DDD, TDD, BDD, ATDD等等。

本節要討論的是不要教條主義，莫要讓規范束縛了我們的手腳，成為技術的奴隸。

這個話題借API技術來展開說一下，我有如下的理解跟大家分享一下:?技術是工具,?是為人服務的。而不是反過來。我們不能說為了迎合某種技術而束手束腳，讓我們自己特別難受。

你比如說rest的理念，就是提供簡單的對單一資源的crud請求操作。而實際的業務場景中，我們需要用到多種資源，而不是單一資源，這樣子如果嚴格的按照rest的理念來教條式的應用，必然就會導致請求效率和計算效率的低下。

那么自然而然的，我們就想我一個請求是不是可以定義一個model，然后這個model包含我需要的多種資源數據。

這里的model的要區別于rest中使用的entity,?entity是對應具體資源表格的,?model是對應多個資源表格的某些字段的。

我們知道這樣的一個請求，在rest中對應著一個路徑，若干參數，一個負載payload。在服務器后端處理這個請求的時候，它會對應一個處理函數。

在這個處理函數中，我們可能涉及到多個表格，多個數據源的計算操作。那么通過這樣的設計，我們就避免了在前端進行多次的請求，而改成通過一個請求就完成了對于多個數據資源的獲取。這樣就可以提高整個業務請求的處理速度。

上面這個過程是采用了graphql的理念，使用了rest的技術。

graphql作為一個理念本身沒有指定具體的技術,?那么這里就有一個問題:?我們應該選擇什么樣的技術來踐行這個理念。

上面我提到的是一種，我認為這種是目前最好的選擇。

以appello為代表的SDK為graphql的理念踐行了很多有意義的工作。

讓程序員感到比較興奮的是對前端工作的簡化。這部分工作的具體實施跟我上面提到的用model來代替entity的模式是一樣的，異曲同工。

但是后端這一塊兒,?使用graphql的復雜度增加了,?在rest中一個handler?function可以做的事情,?在graphql中需要endpoint?class,?schema,?resolver,?parser等等。不僅僅是編碼的復雜度，程設計的復雜度也提高了。相比，rest中直接調用repository或者service處理邏輯,?graphql需要繞一圈以后再去調用repository或者service進行處理,執行效率也相比rest下降了。

gRPC使用二進制數據作為傳輸媒介，相比graphql和rest，傳輸效率更高了。定義proto文件以后，使用編譯工具生成客戶端和服務器端代碼的方式提高了編碼效率。

通過函數調用的方式來實現網絡請求也簡化了代碼的編寫。

但是它的一個問題是不支持HTTP1.0和1.1。這意味著網頁程序無法使用gRPC的API。

關于編程規范部分,?首先需要通過工具來規范，比如說代碼編輯器里面的語法檢查高亮功能。一個團隊里面所有的開發者，都應該使用相同設置的語法檢查工具，配置相同的規則。通過這種方式可以讓編碼者把主要的精力放在業務代碼邏輯的編寫上，而不需要過多的考慮規范的限制。

其次，命名規則和格式的共識可以寫到編程規范里面，通過人為的約定來制定共識，從而避免不必要的代碼重構。

再次，實際上，代碼讓別人看不懂的主要原因是代碼的復雜度過高。所以在代碼功能完成以后，一定要回過頭來看一看能不能把代碼的復雜度降到最低。

關于架構和設計部分，在業界有很多種方法都比較流行，都可以把任務完成。最忌諱的一點就是生搬硬套。應該活學活用，結合具體的業務場景，以這些方法為參考，服務于我們的工作，而不是反過來讓我們的工作去迎合這些方法。

規范是助力不是阻力。

規范是參考的路標，不能生搬硬套，也不是“畫地為牢”，應該作為參考書。

規范越簡單越好。

架構與設計的原則是簡約，不能生搬硬套。

Simple?is not simple.

做到簡單并不容易。

大道至簡。

良心

這一節說一下軟件人員心境的問題。軟件工程中的一個核心因素是人的因素。要讓人的能力發揮到極致，良好的心境是必須要有的。

我本人在頭條，知乎，B站和油管上有《丁哥開講》這個欄目，在向廣大軟件從業人員分享經驗的同時，也不斷地收到大量的業內反饋。

各方問題涉及到方方面面，其中影響心境的因素，我大體歸結了一下，有如下幾種：

1.?入職的時候工資和級別要低了，很糾結。

這個問題非常普遍，也很現實，這會非常影響工作效率。很多人糾結這一點主要是因為入職以后發現有些能力不如自己的同事級別比自己高很多。感覺自己虧了，搞得心情很不好，于是就問該怎么辦。我在回答這類問題的時候，我的建議要點如下：

a.??錢是王八蛋，有能力就能賺；

b.??能力是安身立命之本，不能讓心境影響能力的發揮；

c.??擺正心態，假定自己的級別比現在的自己高出許多來做事情，更嚴格的要求自己；

d.??假以時日，即使所在公司無法識別你的付出，你依然擁有強大的自己；

e.?有了強大的能力，天下之大，你哪里去不得？

2.?被加班文化搞得筋疲力盡。

很多朋友提問了這類的問題，說哪些公司不能進。下面就粗淺的談談這個問題。

先說一說對于加班的看法。國內最嚴重的是阿里系的公司。我了解到在國內科技公司，公司上下形成一種氛圍，就是說大家在比誰每天在公司待的時間長，所以就有了996的說法，還有5+2白加黑。還有的人說996是福報。

這個是非常可怕的，這是一種典型的消耗戰法。不僅僅是針對體力和腦力，也是對員工斗志的消耗，進而是公司工作效率的消耗，對企業文化也是一種極大的摧殘。

研究開發類工作是充滿激情的工作。在沒有想透徹之前不應該動手去做，需要繼續想，繼續思考。這跟生產零件的工作不一樣，開動機器以后，只要看著這個機器在運作，零件就會不斷的生產出來。

比如說，一個典型的案例，工程師忙碌了一天，把事情收個尾，到下班的時間該走了。很多老板不是看你做了多少工作，而是覺得你做完了別人沒做完，說明你的工作量不飽和。所以你不能走，走了就會給你績效低分。可以給你扣些帽子，比如說你不團結，不考慮集體，起壞的帶頭作用。

這種企業思維在國內是非常普遍的，我了解到很多來溫哥華這邊交流或者開公司的老板，他們的思維和行事風格就是這樣子的。

這種思維的一個好處，俗稱傻大膽兒。什么都敢干。至少可以起到“吆喝一聲，引起別人注意”的作用。這一點對大公司來說非常重要，就像跟大家說一聲，嘿，這個事我要做了哈，這里可是高工資996，5+2白加黑，你們小心點兒。那別人如果想入這個行業的話都會掂量一下，因為這個塊頭兒這么大，實力這么強，我們還是不要做了？這樣子就會嚇退很多比較小的競爭者。

但是壞處也是很顯然的。如果工程師不是發自內心的想把這個事情做好的話，工作的產出很難保證高質量。

要解決這樣的問題，首先要確定公司文化的正確理念，以產出為導向，以高質量為導向，而不是以坐班時間長短為導向。

說的直白一點，就是你并不是想讓員工在公司里熬時間，而是想讓員工身心愉悅，能夠產出更多更高質量的產品。這個需要給員工很大的時間支配自由度，有條件的話，可以讓員工擁有更多空間的自由度。

上面說的是文化的一種構建。

3.?趕鴨子上架，痛苦不堪。

錢和時間是優質產品的必要條件而非充分條件，產品和輸出都是有靈魂的，不是想當然就能出來的。趕鴨子上架是不行的，鴨子會很難受。

這些文化構建當然還不夠，不是說把這個文化建立起來了就萬事大吉了。打破機械式管理是為了提高生產效率。

歸根結底還要關聯到產品上，輸出上。那么我們該怎么做呢？這個地方我的觀點還是要不厭其煩的重復這個產品靈魂的觀點。也就是對于某個產品或某個具體的輸出必須要有一個靈魂人物。這個人需要從0~1，一直把這個事情跟完。這個產品可能涉及很多種技術，那么這就要求這個人要有很強的學習能力，最開始的時候可能對一些技術不是很熟悉，但是在做的過程中，要通過不斷的學習，才能夠把相關的一些技術理解明白，只有這樣他才能夠對自己做的產品心中有數。

4.?對抗文化不是出路，看似競爭，實則內耗，互相傷害。

有的人推崇叢林文化，弱肉強食，講的是一個“杠”字；

我推崇潛移默化，以柔生剛，以柔克剛，講的是“容”字，“化”字。

我認為“杠”無法持久，無法形成合力，一個火車不能有多個方向的牽引力，否則最終會作鳥獸散。

“容”“化”追求的是相互融合，彼此扶持。這種模式不僅可以成就工作上的伙伴，也可以找到生活中的朋友。此時的狀態已經不是追求一城一池的得失，不再在意一兩個項目的成敗，而是有一個共同的目標、彼此欣賞的情懷。基于此理念打造的團隊，其毅力是頑強的，戰斗力是強悍的，成果是可期的。

前段時間有人跟我講阿里內部就很崇尚對抗文化，認為這樣很有血性和斗志。的確有的人喜歡搞對抗文化，比如說一個團隊里多個大牛，讓這些大牛互相頂牛，形成彼此的掣肘。討論茴香豆的HUI字有幾種寫法，然后某些領導就感覺自己的位置比較安全。這樣的情形說明領導把自己的主要精力放在辦公室政治文化上了。

這種對抗文化實際上不利于整個團隊的協同作戰。軟件工作內容的劃分大體而言就是20%的腦力、80%的體力的劃分。

在項目工作的常態中，服從和執行的情形，是占絕大多數時間和工作量的。

如果說經常產生爭執，團隊成員疲于奔命，溝通成本占了很大的比重，那絕對是浪費時間和精力的，進而影響產出和質量。

(未完待續……)

軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。