不平凡軟件,始于2014
鄭州軟件開發該如何編寫程序
房子是一磚一瓦砌成的而程序是一個一個代碼敲出來的,大家有沒有覺得其實寫程序跟建房子很相似的,但是為什么很少有房子倒塌而程序卻經常崩潰?鄭州軟件開發!
因為建筑師在建昂子之前會制定好詳細的計劃,構造一個藍圖以便建房時使用,而程序員則不會。藍圖可以保證建筑師設計的建筑按規劃建成,建筑設計師和他們的客戶在著手建造之前,也會通過藍圖來溝通,以理解他們將要建造成的建筑的樣子。這樣周密的計劃才是房子的不會那么容易倒塌的原因吧。但是程序員又有幾個會這樣做呢,哪怕一個簡單的草圖都沒有吧。
其實大部分程序員不構造藍圖是因為他們覺得任何和寫代碼無關的都是在浪費時間,所以就不愿干,但是他卻不知道沒有一個好的構圖怎么入手寫代碼呢,在沒有想好就開始編碼,那樣只會產生糟糕的代碼,我們應該思考些的代碼需要實心什么功能,然后如何下手,這樣在來寫代碼就會很順暢了。
藍圖讓我們想清楚我們打算要建造的建筑。在寫下一段代碼之前,我們應該先寫藍圖。軟件的藍圖稱為技術說明書。已經有太多的借口說撰寫技術說明書只是浪費時間。比如:技術說明書毫無用處,我們不能通過它來產生代碼。這就好像說建筑設計師應該不要畫藍圖,因為他們最終還是需要承包商去建造房子。另外一個反對撰寫技術說明書的爭論也能夠用藍圖的例子來反駁。
還有一些程序員爭辯說,把藍圖和技術說明書作比較是無用功,畢竟程序不是建筑物。他們認為推倒一堵墻要比改變代碼難多了,所以程序的藍圖不是必須的。錯!改變代碼也很難,特別是如果我們不想讓程序有缺陷的話。
我最近需要修改一些不是我寫的代碼,從而給程序增加一個小小的功能。要完成它需要理解一個接口。我花一整天用調試器來研究該接口到底是干什么的——這種事讀讀技術說明書只要5分鐘就能搞定。為了避免導入缺陷,我不得不弄清楚我每次修改之后的結果。因為沒有技術說明書,這個事情變得更加困難。我必須要閱讀上千行代碼,我花了數天來琢磨怎樣才能修改盡可能少的代碼。最后,我花了一周,新增、修改了180行代碼。這可僅僅是這個程序的一個很小的變更啊。
修改代碼只是一項大任務中小小的一塊工作,大多數代碼已經是我十幾年之前寫的了。盡管我幾乎不記得這些代碼是干嘛的,要修改它還是挺容易的——通過閱讀我寫的技術說明書,很容易就能找到我要修改的地方。盡管這些修改工作量不少,而且還影響到其它代碼,我還是能很快搞定它。
我所說的技術說明書到底是什么?通常它被認為是以正式的技術語言寫就的東西。但是撰寫正式的技術說明只需要偶爾為之,如果我們僅僅是蓋個工具棚的話,就不需要畫摩天大樓所要求的那種藍圖。對于大多數軟件來說,我們不需要正式的技術說明書。然而就算是寫小程序也不能不寫技術說明,否則就像沒做任何計劃就要蓋工具棚一樣。
我們做的很多事看上去都是那么的簡單無用但是沒有它你的很多事都做不了,就連一粒沙子也有它的用處,所以說在做事情之前一定要先思考,只有思考了才能將錯誤降低到最底線。
相關新聞換一組