第一篇:編碼20年的老程序員分享所積累的20條編程經(jīng)驗
編碼20年的老程序員分享所積累的20條編程經(jīng)驗
2011-12-26 17:18 黃利民 伯樂在線 我要評論(1)字號:T | T
本文轉(zhuǎn)自Jonathan Danylko的網(wǎng)站DCS Media。Danylko是一位資深開發(fā)顧問,DCS公司的創(chuàng)始人。
從11歲時,我就一直在編程,并且一直都很喜歡技術和編程。這些年來,我積累了一些艱難又容易的經(jīng)驗。作為一名程序員,你或許還沒這些經(jīng)驗,但我會把它們獻給那些想從中學到更多的朋友。
我會持續(xù)更新這些經(jīng)驗,我可能還會有更多的感想,但就我這20年來看,我想下面這個列表中基本不需要增添額外的東西了。下面就是我至今最難忘的經(jīng)驗。
1.估算解決問題所需要的時間。不要怕,承認吧!我曾見過一些程序員為了解決一個特殊問題而坐在顯示器前面8小時。為自己定一個時間限制吧,1小時、30分鐘或甚至15分鐘。如果在這期間你不能解決問題,那就去尋求幫助,或到網(wǎng)上找答案,而不是嘗試去做“超級堆碼員”。
2.編程語言是一種語言,只是一種語言。隨著時光推移,只要你理解了一種語言的原理,你會發(fā)現(xiàn)各種語言之間的相似之處。你所選擇的語言,你應該覺得“舒服”,并且能夠?qū)懗鲇行?而且簡潔)的代碼。最重要的,讓語言去適應項目,反之亦然。
3.不要過于注重程序的“設計模式”。有時候,寫一個簡單的算法,要比引入某種模式更容易。在多數(shù)情況下,程序代碼應是簡單易懂,甚至清潔工也能看懂。
4.經(jīng)常備份代碼。在我年輕時,我就有過因硬盤故障而丟了大量代碼的經(jīng)歷,這經(jīng)歷很恐怖的。只要你一次沒有備份,就應當像有著嚴格的期限,客戶明天就需要。此時就該源碼/版本控制軟件大顯身手了。5.承認自己并不是最頂尖的程序員 – 知不足。我常想,我對編程了解已足夠多,但是總有其他人比你優(yōu)秀。正所謂,“一山總比一山高”。所以,向他們看齊吧!6.學習再學習。正如第5點所說,我經(jīng)常會在手里拿一本計算機或編程相關的雜志或書(不信,可以問我的朋友)。誠然,總有很多你不知道的技術,你可以從中學習以保持不落后。如果你有一種靈巧的方式來獲取你需要的新技術,那你每天都應該堅持學習。
7.永恒的變化。你對待技術/編程知識,就應像你對待股票一樣:多樣化。不要在某一特定技術上自我感覺良好。如果那種技術或語言已經(jīng)沒有足夠支持,那你還不如現(xiàn)在就開始更新你的簡歷,并啟動培訓新計劃。我能保持前行的主要原則是什么呢?至少了解兩到三種語言,所以,如果某種語言過時了,你在學習新技術的時候還可以依靠另一種語言。
8.提攜新人。協(xié)助并且培養(yǎng)初級/入門的開發(fā)人員學習優(yōu)秀的編程方法和技巧。也許你還不知道,在幫助他們向更高一層前進時,你自己也在向更高一層提升,你會更加自信。9.簡化算法。代碼如惡魔,在你完成編碼后,應回頭并且優(yōu)化它。從長遠來看,這里或那里一些的改進,會讓后來的支持人員更加輕松。
10.編寫文檔。無論是Web服務的API,還是一個簡單的類,你盡量編寫相應文檔。我曾經(jīng)引以為豪的代碼注釋,因過度注釋而有人指責。給三行代碼加一行注釋,只需要你幾秒時間。如果那是一個比較難以理解的技術,千萬別擔心過多注釋。如果你能很好做好自己的工作,大多數(shù)架構師、后備程序員、支持組都會感激你。
11.測試、測試再測試。我是一名黑盒測試粉絲。當你完成編碼后,你“被認可”的時候就開始了。如果你們公司有QA部門,如果你的代碼中有錯誤,那你得到的評論,會比項目經(jīng)理還多。如果你不徹底測試自己的代碼,那恐怕你開發(fā)的就不只是代碼,可能還會聲名狼藉。
12.慶祝每一次成功。我見過很多程序員在解決編程技術難題后,會和同伴握手、擊掌或甚至手舞足蹈。每個人在生命中都會碰到“頓悟”。如果一個程序員高興地跑來叫你去看他的非凡代碼,也許你已經(jīng)看過這樣的代碼100遍了,但你也應該為了這個家伙而慶祝第101次。
13.經(jīng)常檢查代碼。在公司,你的代碼要經(jīng)常檢查(包括自查和其他同事檢查)。不要把別人的檢查,看成是對代碼風格的苛求。應該把它們看作是有建設性的批評。對個人來說,經(jīng)常檢查你的代碼并且自問,“我怎樣才能寫得更好呢?” 這會讓你加速你的成長,讓你成為一個更優(yōu)秀的程序員。
14.回顧你的代碼。在看到自己以前的代碼時,通常會有兩種方式:“難以至信,這代碼是我寫的”和“難以至信,這代碼是我寫的”。第一種往往是厭惡的語氣,并在想如何改進它。你也許會驚嘆,舊代碼也能復活成為一種更好的程序,甚至是一個完整的產(chǎn)品。第二種通常帶著驚奇和成就感。開發(fā)人員應該一到兩個自己完成的項目成果,能讓眾人不禁而立并注目而觀的項目。同樣,基于你優(yōu)越的編程能力,你可以把過去的程序或項目拿出來,把它們更新為更加優(yōu)秀的產(chǎn)品或想法。
15.幽默是不可缺的。在我20年的開發(fā)生涯中,我還沒有碰到哪位程序員是沒有幽默感的。實際上,干我們這行,幽默是一項必備品。
16.謹防那些無所不知的程序員,不愿分享的程序員,還有經(jīng)驗不足的程序員。當你遇到這幾種程序員時,你自己要謙虛。無所不知的程序員,更想當一個英雄而不是團隊成員;保守的程序員則是在編寫著他們獨享的代碼;而經(jīng)驗不足的程序員則會每十分鐘就來問你一下,當代碼完成后,代碼已經(jīng)是你的,而不是他們。17.任何項目都不會那么簡單。朋友、家人和同事曾請求我倉促做一些事情,倉促做一個程序或者網(wǎng)站。對于這樣的事,應該從雙方做計劃,才能做出令兩方都會滿意的東西。如果某人起初只是需要一個使用Microsoft Access的、只有有3個頁面的網(wǎng)站,但來就很可能變成一個有15個頁面的網(wǎng)站,并使用SQL Server,有一個論壇,還有一個定制的CMS(內(nèi)容管理系統(tǒng))。
18.任何時候不要想當然。假如你承接一個簡單的項目,你可能會認為某個部分可以輕松完成。千萬別這樣想!除非你有一個類、組件、或者一段已經(jīng)寫好的代碼,并且在現(xiàn)有的項目已經(jīng)測試通過。不要認為這將是很容易的。
19.沒有已經(jīng)完成的軟件。曾經(jīng)有一位程序員告訴我,沒有軟件是已經(jīng)完成的,它只是“暫時完成了”。這是明智的忠告。如果客戶還在使用你寫的程序,并經(jīng)受了時間的考驗。如果有機會,你仍在更新它,這并不是什么壞事,這讓你不斷地前行。20.耐心是一種美德。當客戶、朋友或家庭成員用電腦的時候,他們也許會受挫,進而想砸電腦,或氣沖沖地離開。我一直在告訴他們,“是你掌控電腦,不是電腦掌控你?!睂τ谟米骶幊痰碾娔X,你要有一定的耐心。一旦程序員知道問題所在后,他們就會站在電腦的角度看問題,并且說“哦,這就是為什么它是這樣做?!?/p>
原文:http://blog.jobbole.com/322/
關于程序員成長的一點思考
2011-12-23 09:16 黃文彬 黑客與畫家 我要評論(3)字號:T | T
作為一名程序員,首先我們要把自己的方向定位好,以及技術的提高是非常重要的。所以程序員應該打好自己的基礎,本文將介紹程序員成長的一點思考。
程序員的我們,是否想過今后的路該怎么走、如何發(fā)展、技術怎樣提高?其實這也是我一直在思考的問題。下面就此問題,分享下我的看法。因為我閱歷有限,有什么說的不對的,大家一起噴!
一、程序員應該打好基礎
1.現(xiàn)在開發(fā)工具眾多、語言泛濫,經(jīng)常聽人說”不學CC++神馬都是浮云”、”CC++才是萬王之王”,CC++就真比PHP、Lua、AS、JAVA牛嗎? 其實不在于語言本身,而在于CC++依附的平臺。因為最靠近操作系統(tǒng),所以能發(fā)揮其它語言不具有的性能優(yōu)勢,而且很多數(shù)據(jù)結構、算法、特殊功能類,CC++是不提供的,需要自己實現(xiàn)。這時就需要自己去溫習”數(shù)據(jù)結構”、”算法”、”TCP/IP”、”操作系統(tǒng)原理”、”編譯原理”等這些知識。正因為如此,我們學習的東西被沉淀下來,也正因如此,CC++經(jīng)過定制的功能比封裝好的功能性能高。
我上大學做項目時,用的是.net平臺C#語言, 因為我本性好專研,老師都是把需要研究、比較難的問題交給我。但C#無論是性能和功能都是都是無法跟CC++比的,記得當時是要做一個”遠程控制”軟件,配置IP和端口后需要連接動態(tài)生成客戶端程序(木馬),但C#是不提供這個功能的。這也是我工作后轉(zhuǎn)為CC++程序員的原因,碰巧也是開發(fā)遠程控制軟件。剛開始寫出來的程序偶爾會莫名奇妙的崩潰,但經(jīng)過兩個月和更長的時候后,我掌握了CC++。在此要感謝我工作時的指導老師翁躍龍,沒有他我的路不會這么平坦,他教我的不僅僅是技術,更多的是解決問題得思路和做人。
2.有些人會說大學學的東西是膚淺的,是沒有用的。想想看,在學校的時候我也經(jīng)常這么想,但出來后才知道這些東西有多么重要。不過大學學得再扎實,出來后仍然是需要再溫習過的。因為上學畢竟實踐少,所學不能所用,計算機是個應用驅(qū)動的學科。我們再來看“計算機考研”專業(yè)課考的什么(這里并不是說考研就一定好),”數(shù)據(jù)結構”、”計算機組成原理”、”操作系統(tǒng)”、”計算機網(wǎng)絡”?!睌?shù)據(jù)結構”、”計算機組成原理”這兩門課程擺在前面,可見其重要性,分別是軟件和硬件最重要的兩門基礎課。我不相信不學好”數(shù)據(jù)結構”能夠把性能優(yōu)化做得很好。若說自己學好了,能不看書、不查資料,說出”B+樹、B-數(shù)的應用和區(qū)別”、”KMP為什么能快速匹配字符串”、”快速排序在什么情況會蛻變?yōu)閛(n^2)”嗎? 我也不相信不學透”計算機組成原理”能搞通匯編和內(nèi)核,不知道”CPU和I/O的交互過程”、”指令的執(zhí)行通路”、”CPU運算器的工作原理”,如何寫出高效的匯編代碼?如何弄清楚內(nèi)核中”中斷”、”GDT”、”IDT”這些概念,實模式保護模式如何切換?”操作系統(tǒng)”和”計算機網(wǎng)絡”則是兩門非常重要的支撐學科,信號量為什么是最快的同步方式、線程調(diào)度比進程調(diào)度快、為什么要做內(nèi)存緩沖池,這些都是來自”操作系統(tǒng)”。而”計算機網(wǎng)絡”主要是講述TCP/IP的,為什么德問”對于一個具有幾百萬粉絲的用戶,數(shù)據(jù)如何實時投遞到所有用戶?”要使用多播的方式解決、”如何計算出C/S單向的延遲?”發(fā)送ICMP包測量,這些都是來自它。
我們大學學的課程經(jīng)過多少國內(nèi)外知名學者專家研究過的,所以計算機理論課是基礎,是解決問題的根源?!彼惴ǚ治雠c設計”是”數(shù)據(jù)結構”的延伸,Divide Conque、貪心、動態(tài)規(guī)劃對于程序算法的優(yōu)化有很大的指導意義。同樣,”計算機體系結構”也是”計算機組成原理”的拓展。其次,”編譯原理”、”數(shù)據(jù)庫”、”軟件工程”等學科的重要性也不言自白。
二、實踐、理論、再實踐
作為程序員的我們,滿足于實現(xiàn)一個程序功能的快感,得意于從網(wǎng)上下載別人的代碼加到自己的程序中,陶醉于自己寫了上百萬行代碼。有想過自己是在創(chuàng)造嗎,還是裝配車間的技術工人。日趨成熟的開發(fā)工具,逐步把有豐富想象力的我們淪為奴隸。從網(wǎng)上下載個壓縮庫就用著、成熟的加密算法直接使了、包裝好的類庫就include。為何不探究其算法實現(xiàn)、性能優(yōu)化、底層機制。有人會說很”難”啊!究竟是難,還是掌握的知識不夠,還是理論沒有達到一定高度。
很難想象不學習”計算機圖形學”,去做3D項目客戶端圖形算法的后果;不研究”數(shù)據(jù)挖掘”去分析大量客戶數(shù)據(jù)會做得多好;不攻讀”概率論”、”線性代數(shù)”、”人工智能”去設計AI有多么智能。很多人說,這些東西游戲用不著啊,學了有什么用?我承認初學編程時,這些東西只是高談闊論。若我們工作了n年后,還只是熟練地做些coding,和剛畢業(yè)的學生有什么區(qū)別。編程工具只是”工具”而已,別忘記了我們是改變世界的程序員,不提高理論,何以創(chuàng)新、公司拿什么優(yōu)勢和別人去競爭。
“研發(fā)”是”研究”和”開發(fā)”兩大塊,只做開發(fā),不做研究,對個人和公司都只是短期目標, 當然理論提高了,是需要投產(chǎn)的,不然理論很快淪為”空想社會主義”,公司白花銀子養(yǎng)活研究部門?!睂嵺`、理論、再實踐”,符合馬克思主義哲學思想,也是計算機學科的價值體現(xiàn)。真正的計算機科學家不是只搞理論的,理論是要應用到產(chǎn)品中的。工程師也不是只做開發(fā)不做研究的,是要應用創(chuàng)新,理論微創(chuàng)新。計算機科學家相比于程序員,主要是數(shù)學功底相當深厚,所以他們能在理論上有突破。
三、技術、管理兩路線。
1.“游戲能玩多深,技術就能做多深”,這句話說得很好。只因為我們執(zhí)著,所以在游戲中能攻破一層層難關,凌晨2、3點還能練級打裝備。若能走回正道,做技術就想玩游戲一樣,技術做不深才怪呢。走技術路線的人,一定是對技術癡迷的人。但要走得長遠,我們需要把技術做穿、做透。如何做穿、做透?計算機底層(C、匯編、逆向工程、驅(qū)動、內(nèi)核)、計算機算法(網(wǎng)格計算、音視屏壓縮、語音識別?)、架構(軟件工程、跨平臺、多語言等)都要有涉及。只有我們掌握了這些,才能做到”看問題看到本質(zhì)”、”思想有穿透力”。這些才是最寶貴的,需要沉淀下來,僅僅靠做項目、寫代碼是無法達到的。
2.對于走管理路線的人,是具有”完成任務為第一要務”、”有計劃、善于管理時間”、”善于與人打交道”性格特點的人, 重要的是”綜合素質(zhì)”,而不是”專攻”。但是這些都是可以改變的,很多公司也會選擇技術做得最優(yōu)秀的人做管理。由于我是一個技術癡迷狂,管理這塊,我沒有發(fā)言權,不做多解釋。
四、心態(tài)。1.人活在世界上在于奉獻而不是索取,幫助別人是一件很快樂的事情, 作為程序員的我們心胸要開闊些,低調(diào)些、虛心些, 公司的李老師、老張就是一個心胸很寬廣、低調(diào)的人,值得學習, 三人行必有我?guī)?,我們熟悉的只是自己的這一塊、這個領域,不懂的地方要虛心向別人請教, 我見過浮躁、過于自信的人,也見過做人低調(diào)的人,發(fā)展結果完全不同。
2.樂于分享,支持開源。這是一個很需要心胸、氣度的事,也是決定個人、公司發(fā)展快慢的重要砝碼。技術發(fā)展日新月異,總守著自己手中的那點技術,得不到長足的發(fā)展。中國兩千年的封建歷史、門戶關閉政策還不夠慘痛嗎?”技術是交流和玩出來的”,這是銳安龍哥告訴我的。他也是一個大黑客、正義的黑客,開源是黑客的一項重要精神,所以黑客能引領技術。
3.每日學習。很多人認為畢業(yè)了就不用學習了,或者不用那么那么地學習了。這是一個非常非常錯誤的思想,無論何時何地都要把自己當成菜鳥、應屆生地去學習。書本是學習的一個捷徑,Google、百度解決問題是快,但不是系統(tǒng)化地學習。看書要了解作者背后的知識底蘊,想一想這個問題得解決作者是怎么想到的,這樣比單純解決一個問題更進一層。更重要的是聆聽作者的心聲,感受大師的心態(tài)。最后給大家推薦”黑客與畫家”這本書,寫得真的很好,老吳不提,我還不知道。原文鏈接:http://hp.dewen.org/?p=56
第二篇:ASP+SQLServer2000編程經(jīng)驗積累總結
ASP+SQLServer2000編程經(jīng)驗積累總結
http://004km.cn 更新日期:2007-04-21 22:13 出處:網(wǎng)頁教學網(wǎng) 作者: 收藏本文
前幾天幫人調(diào)試一個ASP+SQL2000+IIS5.1/6.0的網(wǎng)站程序,調(diào)試過程中遇到的問題如下:
一、SQLServer登錄
原先存在備份數(shù)據(jù)庫,通過附加數(shù)據(jù)庫導入到SQL Server,原網(wǎng)站數(shù)據(jù)庫不能正常登陸。并且已在安全中添加用戶角色。賦予管理員權限以及數(shù)據(jù)庫所有者權限。發(fā)現(xiàn)角色添加有問題,檢查原因,原導入數(shù)據(jù)庫中包含一個用戶角色,去掉后再添加即可。
嘗試登陸,仍然報錯:未與信任的SQL連接。選擇屬性—〉安全性,修改身份驗證為:windows和SQL Server?;蛐薷淖员恚?/p>
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSSQLServerMSSQLServerLoginMode的值決定了SQL Server將采取何種身份驗證模式。
1、表示使用“Windows 身份驗證”模式
2、表示使用混合模式(Windows 身份驗證和 SQL Server 身份驗證).后正常登陸。
二、IIS5的http 500內(nèi)部服務器錯誤
主要錯誤表現(xiàn)就是asp程序不能瀏覽但html靜態(tài)網(wǎng)頁不受影響,查詢網(wǎng)絡屬于“IWAM賬號在ActiveDirectory、IIS metabase數(shù)據(jù)庫和COM+應用程序三處的密碼無法同步”問題,解決方法參考網(wǎng)絡嘗試(括號內(nèi)為嘗試結果和處理):
手動修改:(我按照步驟但是手動修改并沒有成功,郁悶)
1、重新設置IIS的IWAM賬號密碼。右鍵單擊 我的電腦->管理,打開計算機管理界面打開 本地用戶和組->用戶 右鍵單擊 啟動IIS進程帳號 IWAM_****(注:****一般是計算機名)點擊設置密碼,設置為一個你想要的密碼。
2、同步IIS metabase中IWAM_MYSERVER的密碼,在CMD中:c:inetpubadminscripts>adsutil set w3svc/wamuserpass “yourpassword”也可:選擇“站點 屬性”->目錄安全性標簽->編輯“匿名訪問和驗證控制”->在彈出的框中選中匿名訪問,單擊編輯按鈕->用戶名瀏覽,選擇IWAM_MACHINE,密碼框中輸入同一的密碼,選中“允許IIS控制密碼”->確定。
注意:
在WIN2000中,查看到的密碼為星號,若要不為星號,必須要先修改adsutil.vbs文件。
a.到c盤 inetpubadminscripts找到adsutil.vbs(根據(jù)裝系統(tǒng)時設定的不同,有的路徑可能不一樣)
b.右鍵單擊,用記事本打開
c.查找 IsSecureProperty = True注意=前后各有一個空格
d.將 IsSecureProperty = True 改為 IsSecureProperty = False 獲取 IWAM 帳戶密碼命令: cscript.exe adsutil.vbs get w3svc/wamuserpass 獲取 IUSR 帳戶密碼命令: cscript.exe adsutil.vbs get w3svc/anonymoususerpass
輸入以上命令,按回車可分別查看IWAM和IUSR的密碼。
修改密碼命令:
修改 IWAM 帳戶密碼 cscript.exe adsutil.vbs set w3svc/wamuserpass “password” 修改 IUSR 帳戶密碼 cscript.exe adsutil.vbs set w3svc/anonymoususerpass “password”
password 設置為你想修改的密碼,即與第一步中你設置的用戶IWAM_****的相同,按回車即可修改完成。
修改密碼前請一定停止所有的Internet信息服務,否則后面可能會出錯,并且IWAM帳戶可能會被鎖定。
3、同步COM+應用程序所用的IWAM_MYSERVER密碼,在CMD中:
c:inetpubadminscripts>cscript synciwam.vbs –v。不成功。也可:
(1)啟動組件服務管理單元: “運行”->“mmc”,啟動管理控制臺,打開“添加/刪除管理單元”對話框,將“組件服務”管理單元添加上。
(2)找到“組件服務”->“計算機”->“我的電腦”->“com+應用程序”->“out-of-process pooled applications”,右擊“out-of-process pooled applications”->“屬性”。
(3)切換到“out-of-process pooled applications”屬性對話框的“標識”選項卡。選擇“此用戶”,瀏覽,選擇用戶名“IWAM_MACHINE”。這些都是缺省的。在下面的“密碼”和“確認密碼”文本框內(nèi)輸入正確的密碼,確定退出。
(4)系統(tǒng)如果提示“應用程序被一個以上的外部產(chǎn)品創(chuàng)建。你確定要被這些產(chǎn)品支持嗎?”時確定即可。
(5)如果在iis中將其它一些web的“應用程序保護”設置為“高(獨立的)”,那么這個web所使用的com+應用程序的iwam賬號密碼也需要同步。
但是在進行第三步操作時總是報8004e00f錯誤。進入組件服務,查看組件服務/計算機/我的電腦/COM+應用程序,結果報錯“COM+ 無法與 Microsoft 分布式事務協(xié)調(diào)程序交談”,無法查看里面的對象。在事件查看器中msdtc服務沒有正常啟動。解決方法:運行 msdtc-resetlog 最后解決:“COM+ 無法與 Microsoft 分布式事務協(xié)調(diào)程序交談”在安裝了Windows組件中的消息隊列后,就不會出現(xiàn)這個錯誤了,同時“消息隊列”組件又對服務中的“Distributed Transaction Coordinator”(即msdtc服務)有依存關系,這個服務必須啟用,才可以安裝消息隊列組件!消息隊列裝好后,COM+應用程序菜單就可以打開了,表示其已正常工作!如果在這個時候再裝IIS或者把IIS卸載重裝,就正常了!實際上,手工同步密碼太過麻煩,成功率不高!
三、數(shù)據(jù)庫中的存儲內(nèi)容在ASP頁面不解析
問題表現(xiàn):網(wǎng)頁原來使用正常,但是在使用了一段時間之后很多內(nèi)容不能正常顯示。
問題分析:開始以為是連接池問題,后來發(fā)現(xiàn)沒什么關系,在頁面上察看源碼已經(jīng)將數(shù)據(jù)庫中的內(nèi)容讀了出來,卻沒有在頁面上展現(xiàn)。發(fā)現(xiàn)是出現(xiàn)了"\"符號。這個符號在ASP中被認為是轉(zhuǎn)義字符的特殊字符,無法解析,故無法正常顯示。
第三篇:編程經(jīng)驗
1.當性能遇到問題時,如果能在應用層進行計算和處理,那就把它從數(shù)據(jù)庫層拿出來。排
序和分組就是典型的例子。在應用層做性能提升總是要比在數(shù)據(jù)庫層容易的多。就像對于MySQL,sqlite更容易掌控。
2.關于并行計算,如果能避免就盡量避免。如果無法避免,記住,能力越大,責任越大。
如果有可能,盡量避免直接對線程操作。盡可能在更高的抽象層上操作。例如,在iOS中,GCD,分發(fā)和隊列操作是你的好朋友。人類的大腦沒有被設計成用來分析那些無窮臨時狀態(tài)——這是我的慘痛教訓所得。
3.盡可能簡化狀態(tài),盡可能局部本地化,適用至上。
4.短小可組合的方法是你的好朋友。
5.代碼注釋是危險的,因為它們很容易更新不及時或給人誤導,但這不能成為不寫注釋的理由。不要注釋雞毛蒜皮的事情,但如果需要,在某些特殊地方,戰(zhàn)略性的長篇注釋是需要的。你的記憶會背叛你,也許會在明天早上,也許會在一杯咖啡后。
6.如果你認為一個用例場景也許“不會有問題吧”,它也許就是一個月后讓你在發(fā)布的產(chǎn)品
中遭受慘痛失敗的地方。做一個懷疑主義者,測試,驗證。
7.有疑問時,和團隊中所有相關人交流。
8.做正確的事情——你通常會知道這指的是什么。
9.你的用戶并不傻,他們只是沒有耐心理解你的捷徑。
10.如果一個開發(fā)人員沒有被安排長期的維護你們開發(fā)的系統(tǒng),對他保持警惕。80%的血、汗、淚水都是在軟件發(fā)布后的時間里流的——那時你會變成一個厭世者,但也是更聰明的“行家”。
11.任務清單是你的好朋友。
12.主動讓你的工作更有樂趣,有時這需要你付出努力。
13.悄無聲息的崩潰,我仍然會為此從噩夢中驚醒。監(jiān)控,日志,警報。清楚各種的假警報
和不可避免的感覺鈍化。保持你的系統(tǒng)對故障的敏感和及時警報。
14.復雜是大敵。
第四篇:程序員從編程總結的 22 個經(jīng)驗
以下所列是我在這些年來軟件開發(fā)工作過程中受到的啟發(fā),還有總結而來的好經(jīng)驗。
開發(fā)
1.從小事做起,然后再擴展
無論是創(chuàng)建一個新的系統(tǒng),還是在現(xiàn)有的系統(tǒng)中添加新的功能,我總是從一個簡單到幾乎沒有任何所需功能的版本開始,然后再一步一步地解決問題,直到滿意為止。我從來沒有妄想過能夠一步登天。相反,我一邊開發(fā)一邊學習,同時新掌握的信息還可以用于解決方案中。
我很喜歡 John Gall 的這句話:
“復雜系統(tǒng)總是源于簡單系統(tǒng)的演化?!?/p>
2.一次只做一件事
當我們在開發(fā)時,碰到測試失敗和功能無效的情況,如果你一次只研究一個問題,那將會更容易找到問題的關鍵。換言之,就是使用短迭代。必須確保這個問題解決之后,再轉(zhuǎn)移到另一個問題上。這適用于向下提交。如果在你添加新功能之前需要先重構代碼,那么先提交重構,然后再添加新的功能。
3.盡早地添加日志和錯誤處理
在開發(fā)新系統(tǒng)時,我做的第一件事就是添加日志和錯誤處理,因為這兩者從一開始就非常有用。對系統(tǒng)來說它比一大把代碼更有用,你需要一些了解程序狀態(tài)的方法。如果系統(tǒng)不能照常工作,那么你就需要知道程序中發(fā)生了什么——這是日志的作用。錯誤處理也是如此——錯誤和異常越早處理越好。
4.每一行新代碼必須至少執(zhí)行一次
在你真正完成一個功能之前,你必須對它進行測試。不然,你怎么知道它是不是按照你的想法在執(zhí)行呢?通常情況下,最好的方法是通過自動測試,但并非總是如此。不過,不管怎么說,每一行新代碼必須至少執(zhí)行一次。
一般,我們想觸發(fā)某種條件很難。但幸運的是,我們可以作弊。例如,數(shù)據(jù)的錯誤處理可以通過臨時拼寫錯一個列名來觸發(fā)?;蛘?,一個if語句可以暫時顛倒過來(從 if error 變成 if not error),這樣來觸發(fā)那些平時很難觸發(fā)的條件,這樣只是為了確定代碼是否正常運行和它會出現(xiàn)什么結果。
有時,我發(fā)現(xiàn)有一些行代碼永遠都不會被運行。當我們做代碼檢查是它看起來沒有什么問題,但就是不工作。你要避免這樣的尷尬狀況,如果你想你的每一行新代碼都會被執(zhí)行。
5.在整體測試之前先進行模塊測試
先進行部分模塊測試可以節(jié)省時間。通常說來,我們在整合不同的模塊時也會出現(xiàn)問題,例如模塊之間的接口不匹配。但是如果我們能夠信任各個組件的話,那么跟蹤集成問題就會變得簡單得多。
6.所有事情所花費的時間總是比你預期的要長
特別是在編程中,即使一切進展順利,我們也很難對功能所需的時間做出正確的預算。并且,開發(fā)軟件時碰到各種意想不到的問題是非常常見的。一個簡單的合并操作會導致一系列小bug,一次框架升級意味著一些函數(shù)必須改變或者一些API不按照你想象的那樣工作。
Hofstadter Law(霍夫施塔特定律)其實道出了真諦:做事所花費的時間總是比你預期的要長,即使你在預期中已經(jīng)考慮了 Hofstadter Law(霍夫施塔特定律)。
7.先了解現(xiàn)有的代碼
大多數(shù)的編碼都需要以某種方式改變現(xiàn)有的代碼。即使是新功能,也需要適應現(xiàn)有的程序。所以,在你加進去新的內(nèi)容前,首先需要了解當前的解決方案。否則,你一不小心就很有可能會打破現(xiàn)有的功能。這意味著,閱讀代碼和編寫代碼都是必要的技能。這也是為什么看似微小的變化仍可能需要很長時間才能解決的原因之一,因為你首先必須了解上下文。
8.閱讀和運行代碼
幸運的是,對于理解代碼,我們有兩種互補的方法。你可以閱讀代碼,也可以運行代碼。運行代碼的確是個非常棒的好方法。所以,請確保充分利用這兩種方法。
故障排除
9.Bug 總是難免的
我不喜歡那些宣稱軟件開發(fā)可以“一蹴而就”的高談闊論。不論你再怎么努力,bug總是難免的(BUG的定義基本上是:“我們沒有想到”)。最好能夠做成可以快速故障排除、修復bug和部署修復的系統(tǒng)。
10.解決故障報告
每個開發(fā)人員都應該花時間去處理來自客戶的故障報告,并修復bug。這能讓你更好地理解客戶的意圖,明白如何使用系統(tǒng),知道排除故障的難易程度,了解系統(tǒng)的設計情況。這也是為自己的開發(fā)成果負責的好方法。不要錯過這些好處。
11.重現(xiàn)問題
修復bug的第一步就是重現(xiàn)問題。然后你得確保修復之后,問題能夠徹徹底底地消失。這樣一個簡單的規(guī)則,可以確保你不會誤將非問題當作是問題,并確保解決方案真的能夠奏效。
12.修復已知錯誤,然后再看看有沒有其他不對的地方
有時候,可能同時存在著幾個不同的問題。它們之間的互相作用,可能會讓你毫無頭緒,束手無策。不要糾結于搞清楚發(fā)生了什么,先去解決所有已知的問題,然后再看看還有什么不對的地方。
13.沒有巧合 在測試和故障排除時,不要相信會出現(xiàn)什么巧合。就像你改變了定時器的值,那么就會改變系統(tǒng)重啟的頻率。所以一切都并非是巧合。添加新功能,另一個不相干的功能變慢了?這絕對不是巧合。相反,是你應該仔細調(diào)查的內(nèi)容。
14.關聯(lián)時間戳
在故障排除時,事件的時間戳可以作為你的好幫手。尋找偶數(shù)增量。例如,如果系統(tǒng)重啟了,并且剛剛發(fā)出過一個3000毫秒左右的請求,那么可能是觸發(fā)了某個定時器,才導致出現(xiàn)重啟的動作。
合作
15.面對面的交流最有效
當我們需要討論如何解決問題時,那么面對面的交流比視頻、打電話和電子郵件都要好。我經(jīng)常在與同事討論完后發(fā)現(xiàn)一個令人興奮的更好的方案。
16.小黃鴨調(diào)試法
遇到你絞盡腦汁也解決不了的問題時,不妨找一個同事,然后將問題解釋給他們聽。很多時候,當你在敘述時,即使你的同事一言不發(fā),你可能也會突然靈光乍現(xiàn)找到問題的關鍵。聽起來像魔法,但是這經(jīng)常起作用。
17.問問題
閱讀和運行代碼往往非常有助于指出代碼的目的和它的工作原理。但是如果你有機會咨詢那些更為了解的人(例如原來的程序員),那么千萬不要錯過。繼續(xù)問他們具體的問題、后續(xù)的問題,這幾分鐘內(nèi)給你的信息可能是你需要花費好幾天才能獲得的。
18.共享榮譽
不要貪圖榮譽,該是誰的就是誰的。例如:“Marcus 想出了這個主意……”(如果真是他想的話),而不要說“我們想出的……”。大膽的說出那些幫助過你或者貢獻過力量的人的名字。
其他
19.動手去做
如果你不知道某種編程語言功能的工作原理,那么不妨寫一個小程序來理解它是如何工作的。這同樣適用于測試你正在開發(fā)的系統(tǒng)。如果我將參數(shù)設置為-1,會發(fā)生什么?當我在重啟系統(tǒng)時,如果服務當?shù)?,會發(fā)生什么?以此來研究它的工作原理。經(jīng)常做這些會幫你發(fā)現(xiàn)bug,在此同時也會加深你的系統(tǒng)工作的了解。
20.帶著問題睡覺
如果你正在解決一個很難的問題,那么不妨帶著問題睡覺。有科學研究表明,這樣做雖然你表明上并沒有在主動思考,但你的潛意思卻這么做了。其結果就是,第二天再去研究問題,解決方案已經(jīng)呼之欲出了。
21.改變/跳槽
不要害怕角色變化。和不同的人共事,開發(fā)不同的產(chǎn)品,感受不同的公司文化是非常有意思的。在我看來,太多的人只是被動地呆在同樣的地方年復一年的工作,只有在被迫的情況下才去改變。
22.活到老學到老
軟件行業(yè)的一大魅力就是我們隨時有機會可以學到新的東西。你可以嘗試不同的編程語言和工具,閱讀軟件開發(fā)的書籍,接受MOOC課程。相信我,量變才能達到質(zhì)的飛躍,這些小小的學習積累,終有一天會大大地提高你的知識和能力。
第五篇:編程規(guī)范(程序員必看)
編程規(guī)范(程序員必看)
作者:
評價:
上站日期:
內(nèi)容說明:
來源:
.基本要求
1.1 程序結構清析,簡單易懂,單個函數(shù)的程序行數(shù)不得超過100行。1.2 打算干什么,要簡單,直接了當,代碼精簡,避免垃圾程序。1.3 盡量使用標準庫函數(shù)和公共函數(shù)。
1.4 不要隨意定義全局變量,盡量使用局部變量。1.5 使用括號以避免二義性。
2.可讀性要求
2.1 可讀性第一,效率第二。2.2 保持注釋與代碼完全一致。
2.3 每個源程序文件,都有文件頭說明,說明規(guī)格見規(guī)范。2.4 每個函數(shù),都有函數(shù)頭說明,說明規(guī)格見規(guī)范。
2.5 主要變量(結構、聯(lián)合、類或?qū)ο螅┒x或引用時,注釋能反映其含義。2.7 常量定義(DEFINE)有相應說明。2.8 處理過程的每個階段都有相關注釋說明。2.9 在典型算法前都有注釋。
2.10 利用縮進來顯示程序的邏輯結構,縮進量一致并以Tab鍵為單位,定義Tab為 6個字節(jié)。
2.11 循環(huán)、分支層次不要超過五層。
2.12 注釋可以與語句在同一行,也可以在上行。2.13 空行和空白字符也是一種特殊注釋。2.14 一目了然的語句不加注釋。
2.15 注釋的作用范圍可以為:定義、引用、條件分支以及一段代碼。2.16 注釋行數(shù)(不包括程序頭和函數(shù)頭說明部份)應占總行數(shù)的 1/5 到 1/3。
3.結構化要求
3.1 禁止出現(xiàn)兩條等價的支路。3.2 禁止GOTO語句。
3.3 用 IF 語句來強調(diào)只執(zhí)行兩組語句中的一組。禁止 ELSE GOTO 和 ELSE RETURN。3.4 用 CASE 實現(xiàn)多路分支。3.5 避免從循環(huán)引出多個出口。3.6 函數(shù)只有一個出口。3.7 不使用條件賦值語句。3.8 避免不必要的分支。
3.9 不要輕易用條件分支去替換邏輯表達式。
4.正確性與容錯性要求
4.1 程序首先是正確,其次是優(yōu)美
4.2 無法證明你的程序沒有錯誤,因此在編寫完一段程序后,應先回頭檢查。4.3 改一個錯誤時可能產(chǎn)生新的錯誤,因此在修改前首先考慮對其它程序的影響。4.4 所有變量在調(diào)用前必須被初始化。4.5 對所有的用戶輸入,必須進行合法性檢查。4.6 不要比較浮點數(shù)的相等,如: 10.0 * 0.1 == 1.0,不可靠
4.7 程序與環(huán)境或狀態(tài)發(fā)生關系時,必須主動去處理發(fā)生的意外事件,如文件能否 邏輯鎖定、打印機是否聯(lián)機等。
4.8 單元測試也是編程的一部份,提交聯(lián)調(diào)測試的程序必須通過單元測試。
5.可重用性要求
5.1 重復使用的完成相對獨立功能的算法或代碼應抽象為公共控件或類。5.2 公共控件或類應考慮OO思想,減少外界聯(lián)系,考慮獨立性或封裝性。5.3 公共控件或類應建立使用模板。
附:C++ 編程規(guī)范,delphi作相應的參考
.1適用范圍
本標準適用于利用Visul C++ ,Borland C++進行軟件程序開發(fā)的人員.。
.2變量命名
命名必須具有一定的實際意義,形式為xAbcFgh,x由變量類型確定,Abc、Fgh表示連續(xù)意 義字符串,如果連續(xù)意義字符串僅兩個,可都大寫.如OK.具體例程:
BOOL類型
bEnable;
ch
*
char
chText c
*
類對象
cMain(對象實例)h
*
Handle(句柄)
hWnd i
*
int n
*
無符號整型 p
*
指針 sz,str *
字符串 w
WORD x,y
坐標
Char或者TCHAR類型
與Windows API有直接聯(lián)系的用szAppName[10]形式否則用
FileName[10]形式,單個字符也可用小寫字母表示;
Int類型
nCmdShow;
LONG類型
lParam;UINT類型
uNotify;
DWORD類型
dwStart;
PSTR類型
pszTip;
LPSTR類型
LPTSTR類型
LPVOID類型
WPARAM類型
LPARAM類型
HWND類型
HDC類型
HINSTANCE類型
HANDLE類型
HICON類型
int
float
DWORD
lpszClassName;lpReserved wParam, lParam hDlg;hDC;hInstance hInstance, hIcon;iTmp fTmp dw* 4
lpCmdLine
String , AnsiString
str *
m_
類成員變量
m_nVal, m_bFlag g_
全局變量
g_nMsg, g_bFlag
局部變量中可采用如下幾個通用變量:nTemp,nResult,I,J(一般用于循環(huán)變量)。
其他資源句柄同上
.3常量命名和宏定義
常量和宏定義必須具有一定的實際意義;
常量和宏定義在#include和函數(shù)定義之間;
常量和宏定義必須全部以大寫字母來撰寫,中間可根據(jù)意義的連續(xù)性用下劃線連接,每一 條定義的右側(cè)必須有一簡單的注釋,說明其作用;
資源名字定義格式:
菜單:IDM_XX或者CM_XX
位圖:IDB_XX
對話框:IDD_XX
字符串:IDS_XX
DLGINIT:DIALOG_XX
ICON:IDR_XX
.4函數(shù)命名 函數(shù)原型說明包括引用外來函數(shù)及內(nèi)部函數(shù),外部引用必須在右側(cè)注明函數(shù)來源: 模 塊名及文件名, 如是內(nèi)部函數(shù),只要注釋其定義文件名;
第一個字母必須使用大寫字母,要求用大小寫字母組合規(guī)范函數(shù)命名,必要時可用下劃線 間隔,示例如下:
void UpdateDB_Tfgd(TRACK_NAME);
//Module Name :r01/sdw.c
void PrintTrackData(TRACK_NAME);//Module Name :r04/tern.c
void ImportantPoint(void);
//Module Name :r01/sdw.c
void ShowChar(int , int , chtype);
//Local Module
void ScrollUp_V(int , int);
//Local Module
.5結構體命名
結構體類型命名必須全部用大寫字母,原則上前面以下劃線開始;結構體變量命名必須用 大小寫字母組合,第一個字母必須使用大寫字母,必要時可用下劃線間隔。對于私有數(shù) 據(jù)區(qū),必須注明其所屬的進程。全局數(shù)據(jù)定義只需注意其用途。
示例如下:
typedef struct
{
char
szProductName[20];
char
szAuthor[20];
char
szReleaseDate[16];
char
szVersion[10];
unsigned long
MaxTables;
unsigned long
UsedTables;
}DBS_DATABASE;
DBS_DATABASE GdataBase;
控件的命名: 用小寫前綴表示類別
用小寫前綴表示類別: fm
窗口 cmd
按鈕
cob
combo,下拉式列表框 txt
文本輸入框 lab
labal,標簽 img
image,圖象 pic
picture grd
Grid,網(wǎng)格 scr
滾動條 lst
列表框 frm
fram
7注釋
原則上注釋要求使用中文;
文件開始注釋內(nèi)容包括:公司名稱、版權、作者名稱、時間、模塊用途、背景介紹等,復 雜的算法需要加上流程說明;
函數(shù)注釋包括:輸入、輸出、函數(shù)描述、流程處理、全局變量、調(diào)用樣例等,復雜的函數(shù) 需要加上變量用途說明;
程序中注釋包括:修改時間和作者、方便理解的注釋等;
引用一: 文件開頭的注釋模板
/******************************************************************
** 文件名:
** Copyright(c)1998-1999 *********公司技術開發(fā)部
** 創(chuàng)建人:
** 日 期:
** 修改人:
** 日 期:
** 描 述: ** ** 版 本:
**---------------
******************************************************************/
引用二: 函數(shù)開頭的注釋模板
/*****************************************************************
** 函數(shù)名:
** 輸 入: a,b,c
**
a---
**
b---
**
c---
** 輸 出: x---
**
x 為 1, 表示...**
x 為 0, 表示...** 功能描述:
** 全局變量:
** 調(diào)用模塊:
** 作 者:
** 日 期:
** 修 改:
** 日 期: ** 版本
****************************************************************/
引用三: 程序中的注釋模板
/*---------------------------*/
/* 注釋內(nèi)容
*/
/*---------------------------*/ 8 程序
a.程序編碼力求簡潔,結構清晰,避免太多的分支結構及太過于技巧性的程序,盡量不采用遞歸模式。
b.編寫程序時,亦必須想好測試的方法,換句話說,”單元測試” 的測試方案應 在程序編寫時一并擬好。
c.注釋一定要與程序一致。
d.版本封存以后的修改一定要將老語句用/* */ 封閉,不能自行刪除或修改,并要 在文件及函數(shù)的修改記錄中加以記錄。
e.程序中每個block 的開頭 ”{“ 及 ”}” 必須對齊,嵌套的block 每進一套,縮進一個tab,TAB 為4個空格,block類型包括if、for、while、do等關鍵字引出的。
f.對于比較大的函數(shù),每個block 和特殊的函數(shù)調(diào)用,都必須注明其功能,舉例如下
:
count.divisor = 1193280 / freq;
// compute the proper count
OutByte((unsigned short)67,(unsigned char)182);// tell 8253 that a count is coming
OutByte((unsigned short)66, count.c[0]);
// send low-order byte
OutByte((unsigned short)66, count.c[1]);
// send high-order byte
×××××××××××××××××××××××××××××××××××××××
bcb,delphi中的變量命名:
遵循匈牙利命名法,命 名必須有意義,制定如下規(guī)定
窗體: 以大寫的W開始,如About版權窗體,命名為WAbout
文件:以大寫的F開始,如About版權窗體,文件命名為FAbout.cpp
按鈕(Button):如退出按鈕,命名為btnExit ……
基類: 加base標記,如報表基類,窗體命名為:WBaseRep, 文件命名為FBaseRep.cpp