1. 程式人生 > >純忽悠程式設計師的開發要求(2):要學會用別人已經開發的程式碼

純忽悠程式設計師的開發要求(2):要學會用別人已經開發的程式碼

記得剛開發linux驅動的時候,我對linux驅動為何物都不甚瞭解,作業系統的基礎也一般,就有很多人對我雞歪:不要什麼東西都一開始自己做,把別人的東西拿過來,改改能用就好,程式設計師不是發明家,要考慮效率問題,而且舉了半打兒例子,當時俺還覺得有道理,畢竟飛機一個人不可能造出來。

現在想想純忽悠剛入門的程式設計師的,如果自己已經是大牛了,類似的程式搞了很多,當然沒必要每次都自己搞,問題是剛入門連二叉樹遍歷,快速查詢都沒實現過的程式設計師就讓他們借用別人的程式碼,那我們的軟體開發又有什麼前途,況且國內對軟體產業根本不重視,像樣兒的培訓幾乎沒有,社會上的也都是騙錢為主,如果自己再不寫程式碼鍛鍊,靠porting過一輩子嗎?如果哪天人家不給你porting怎麼辦?

前幾天一個iphone破解黑客撂挑子了,搞得深圳華強北一陣騷亂,為啥啊?幾千人的work全base在他的工作上面呢!他不幹了,這些人都傻眼了,這就是盲目porting別人成果的下場。相信以後這類事情會越來越多。

而且移植別人的程式碼很容易出bug,具體情況的變化不是十分清楚,原來程式碼設計的原理也不是十分明白,出現問題除錯起來那叫一個累啊!最關鍵的是這些bug由於慣性思維很難查出來,一出問題就要人命!

最經典的是1996年6月4號—501太空梭爆炸事件,對於Ariane 4火箭的工作程式碼在Ariane 5中被重新使用,但是Ariane 5更高速的運算引擎在火箭航天計算機中的演算法程式中觸發了一個bug。該錯誤存在於將64位浮點數轉換為16位帶符號整數的程式中。更快的運算引擎導致了 Ariane 5中的64位資料要比Ariane 4中更長,直接誘發了溢位條件,最終導致了航天計算機的崩潰。首先501太空梭的備份計算機崩潰,然後0.05秒之後,主計算機也崩潰了。這些計算機崩潰直接導致了火箭的主要處理器使火箭的運算引擎過載,同時導致火箭在發射40秒後解體破碎。

還有一個:1982年—蘇聯的石油管道事件,根據CIA(美國中央情報局)的陳述,為其工作的間諜們在蘇聯購買的用來控制跨西伯利亞石油管道的加拿大計算機系統中種下了一個bug。當時是蘇聯通過祕密購買或者偷竊美國的敏感技術來獲取到了該系統。據說CIA發現了這個存在bug的程式,決定對可以通過蘇聯人檢查的裝置做一個讓蘇聯人事與願違的破壞,使得該裝置一旦執行起來將會失敗。該事件的結果據說在歷史上造成了最大的非原子破壞。 這兩個軟體問題都在史上十大軟體bug之列!http://www.techcn.com.cn/index.php?doc-view-132285.html

所以我的建議是:無論是什麼水平的程式設計師,可以參考別人的程式碼,儘量自己設計與實現,特別是剛入門的程式設計師,不管簡單還是複雜的東西自己動手,別養成懶惰的習慣,懶惰是程式設計師的大敵啊!還是那句老話:自立更生,艱苦奮鬥, 有了足夠程式碼量的積累就可以有自己對軟體開發的理解,提高自己設計開發的能力,早晚有一天會成為大牛的!