程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> 關於C語言 >> 簡述如何書寫工程化的簡單代碼

簡述如何書寫工程化的簡單代碼

編輯:關於C語言

在壇子裡混了這麼久,看了很多同學的代碼,感覺到大家的代碼,學校裡面的書生氣有點重,對於細節考慮不夠,有時候,感覺和吃了顆蒼蠅一樣,確實很不舒服。

這裡根據我個人的經驗,給大家簡述一下,工程化代碼,以及簡單代碼,不容易出錯的代碼的一些基本寫法。

1、工程化代碼,首先考慮是團伙作案,獨行大盜的時代已經過去了,呵呵,因此,特別強調“人”能看懂,很多教科書上給出的示例,一切以計算機能正確run為准則,寫出的代碼只有計算機能看,作者本人再看都要想半天,這不是好代碼。

工程項目團隊,很多時候都是大家合作開發,你的代碼,可能使用者不是你,下一個維護者也不一定是你,與人方便,與己方便,當有一天你對著一堆看不懂代碼大罵的時候,想想,從我做起,給別人點方便。

2、簡簡單單寫程序,不是說惜墨如金,多敲一個字符都嫌累。

在Unix時代,沒有顯示器,都是電傳打字機,編輯器也是行編輯器,因此,每多敲一行字,都是錢,再加上那會內存小,編譯器能用的空間有限,因此,Unix的老程序員,對於變量名,函數名,標簽,珍惜得很,很少用2字符以上的,這是歷史因素,人家窮,小家子氣。

不過,現在大家用的都是以G為單位的內存,液晶顯示器,IDE又那麼強悍,拜托,起名字給長點,有點表意性好不好,別一段程序寫下來,滿篇都是“你猜”兩個字,看程序的人要瘋。

3、注釋,很多教科書,一說編程規范性,就是注釋,好像這是程序易讀的唯一方法,大學裡面的老師,沒見識過大型工程開發,沒一次干過幾十萬,上百萬行代碼,這麼說也是可以理解的。

不過,工程程序員,項目壓力一般都很重,在開發時,所有的注意力都在如何實現需求上,很少有人能有閒心,有耐心,精雕細琢自己的代碼,甚至,很多代碼,都是交工前最後一刻寫出來的,因此,要求詳細注釋,在工程開發中,實際上沒有可操作性。

起碼我自己都做不到,這就是為什麼我特別強調命名表意,程序寫短點。即使程序員沒有注釋,看字面意思,也能大致理解。這麼說吧,看別人的工程代碼,沒有注釋,是正常,有注釋,是福氣。

嗯,有時候是霉氣,很多程序員,開發時寫注釋,後期出現bug,開始瘋狂Debug的時候,那會哪有時間改注釋哦,能把程序改對,都是燒高香了,最後,很可能注釋和代碼是反的,順著注釋看,順理成章就掉坑裡去了。

還是那句話,別期待注釋,別全信注釋,注意自己的程序,自身的表意性,至於你自己寫不寫注釋,如果在我的團隊裡面,.h文件裡面的公有函數和方法,一定寫全,每個入口參數的含義,返回碼的含義,越多越好,別人正確調用你的程序,bug就不會找你麻煩,這是為了你自己。至於其他方面,愛寫不寫,我不管。

4、再說簡單,簡簡單單寫程序,可不是說你惜墨如金,是說讓讀的人,感到簡單,腦子裡不轉彎。這很好理解,我們做出一個產品,好不好,用戶說了算,你的軟件產品可能有特定的用戶,但你的代碼本身,也是產品,你的團隊伙伴就是你的用戶,大家可能聽說過換位思考,我們寫程序的時候,除了想象客戶會不會罵娘,還有沒有想想,以後讀我們代碼的人會不會罵娘?

團隊中有規范,按照規范來,不要討論合理不合理,先照做,大家養成閱讀習慣,看代碼就不難。

寫代碼,不要耍酷,年輕人,或多或少都有點愛表現自己的欲望,人之常情,可以理解,不過要控制。哪些為了一個算法的優化,絞盡腦汁,最後把三個變量節約成一個變量,把四重循環節約成一重,看似水平高了,可是,算法復雜度高了,看的人就暈了。

不想挨罵的話,老老實實的寫吧。函數內部的變量,只要不是動態申請的,一般都建立在浮動棧上,隨著函數的退出,就會自動拆除回收,給下一個函數使用。對象內部也差不多。所以,不妨多用幾個變量,老老實實地寫,不玩什麼花樣,看得人看得輕松,其實自己腦子也清晰,不容易出錯。

武俠小說中,說越是大宗師,越不喜歡用奇門兵器,一路簡簡單單的太祖長拳,破盡少林寺七十二絕藝,這說明什麼?把事情弄復雜,弄玄妙,不算本事的,能用最簡單的招式,化解最復雜的問題,內力夠了,自然可以。修煉內功,就是減少對招式的依賴,簡單,直接,直奔要害。以最小的成本,獲得最大的收益,大家說,是不是?

5、規矩,很多人,一說工程化開發,就認為編程規范很重要。於是開始找大公司的開發規范,於是,網上的華為軟件開發規范,傳來傳去,大家奉為聖旨。誰要敢說半個不字,管殺不管埋。

規矩是人定的,每個人群,每個開發團隊,都有自己的開發方向,常用工具,所以,編程規范其實是很小范圍的東東,都是針對目前項目最有效的,很難想象,一個做.net的開發團隊,拿著華為用gcc做VxWorks工程的編程規范,能做好事情。

什麼規矩是最好的?我的理解,最合用的就是最好的。系統設計完成,開發之前,項目團隊在一起開個短會,討論一下規范,把大的幾條定出來,之後就隨著項目的進行,不斷補充罷了。很多時候,項目經理也要尊重程序員的習慣,一個程序員用VC的IDE習慣,總不能為了寫gcc,強迫大家都用vi吧。這裡面有個個性化的規矩問題。

大家別不習慣,出去之後,走上社會,大家會發現,很多東東都是靈活的,不是一成不變的,很多人就在哭,這個世界太黑暗了。其實是自己不能靈活變通。項目組,有牛人,大家一般會跟著牛人走,他的惡習都可以變成團隊規矩,這也合理,沒有牛人,大家一盤散沙,就在接口處統一,裡面程序亂點沒啥,也可以,方法太多了,只要能出活,出來的代碼,大家基本能看懂,其實就ok了。

像那種,還沒做事,先說一大堆規矩,程序員學習規矩和習慣養成都要半天,這些,最後都是項目成本。江山易改,本性難移,做項目管理,何苦來和每個人作對,尊重一下大家的習慣,直接把習慣做成規矩,不是更好?

6、輪子,筆者生活中,遇到很多了,壇子裡面喜歡拍磚的人,也不少,開口就說,這個世界需要依賴工具,自己造輪子的人是笨蛋。

這個話確實見仁見智。很難說對不對,不過,筆者建議,初學者還是少用別人的輪子。

大家畢業,走上工作崗位,還有幾十年呢。誰都不知道這輩子是不是一定在某個平台,或者某種語言,某種框架下寫代碼。

一旦年輕時,習慣了享受某種框架的便利性,就很難深入思考了。那隨著年紀增大,走向架構師崗位的時候,由於很多底層的特性思考不夠,會後繼乏力。我們說,出來混,總是要還的,現在享受了,但是,這輩子的債,總得換,到三四十歲再來重新學習研究,會很難的。

很多人大言不慚,一說就是框架,以框架搭建工程固然很快,但是,想想看,做框架的人,和用框架的人,哪個水平高?哪個收入高?其實很多時候,企業的架構師,就是針對項目或產品,為項目團隊制定本企業合用的框架的。

學著自己寫隊列,學著自己寫堆棧,再代入到實際工程中測試,做一些量身定做的優化,你的水平會迅速提升的。

先到這裡吧,感覺沒有講透,看大家有什麼問題,我再補充。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved