30多年程式設計師生涯經驗總結【轉】
在我30多年的程式設計師生涯裡,我學到了不少有用的東西。下面是我這些年積累的經驗精華。我常常想,如果以前能有人在這些經驗上指點一二,我相信我現在會站得更高。
1.客戶在接觸到產品之後,才會真正明白自己的需求。
這是我在我的第一份工作上面學來的。只有當我們給客戶展示產品的時候,他們才會意識到哪些是必須的。給出一個功能性原型設計遠遠比一張長長的文字表格要好。
2.只要有充足的時間,所有安全防禦系統都將失敗。
安全防禦現如今是全世界都在關注的大課題、大挑戰。我們必須時時刻刻積極完善它,因為黑客只要有一次成功,就可以徹底打敗你。
3.安全防禦是否失敗取決於及早規劃。
假設有黑客會徹底破壞你的防禦系統,那你就得提前做好準備。這樣即便真的讓他們侵入了系統,也盜取不了任何有價值的東西,因為你已經對伺服器做了安全設定,比如對資料庫中的內容進行了加密,並且對每臺有可能遭受攻擊的伺服器進行了隔離。
記住,再強大的防禦都會有它的薄弱之處,關鍵是要有備無患。
4.良好的安全防禦系統不要在乎它的費用,因為這是戰略投資;不及格的安全防禦才是被浪費的資源。
在我的職業生涯中,經常聽到有人抱怨說安全防禦是多麼多麼的複雜和昂貴,他們沒有意識到的是,如果防禦失敗,公司將損失的可能不止幾十億美元。為了節約幾塊錢而導致企業破產,這種做法毋庸置疑是非常愚蠢的。
5.將複雜的東西整理成簡單的,是很難的,但是要是把複雜的搗鼓成更加複雜的,那就簡單了。
這一條適用於程式設計、設計和幾乎所有的創造領域中。我一直以來都希望自己的程式碼能越易於理解越好。如果你的程式碼過於複雜和晦澀,那十之八九它正常工作的可能性很低。我曾非常有幸地見識到有些程式設計師費勁千辛萬苦,反而讓程式碼更加難以捉摸了。
6.成功源自於失敗中的學習;失敗則是因為容忍錯誤的橫行。
有很多程式設計師總是在辯解,說什麼“程式這麼難,犯錯誤很正常了,軟體變得糟糕也在所難免了”。這種理由聽得多了,於是,大家也逐漸接受了這些扯淡的藉口。但是我們作為程式設計師真的不應該讓這些藉口阻礙我們的進步,應該謹記,錯誤只能犯一次,要吸取教訓。話說是程式設計師都會希望自己下一次就能一次性搞定程式碼。但是沒有人是完美的,不過至少我們是在朝著這個方向前進的路上。
7.唯一不變的是變化本身,這是誰都無法改變的法則。
計劃永遠趕不上變化,以為明天的世界和今天一樣,這種想法本身就是愚不可及的。尤其是在程式設計世界裡,沒什麼是永恆的。人不能兩次踏進同一條河裡。
8.永遠不要停止學習,一旦你停下來,技術的浪頭就會狠狠將你拍死在沙灘上。
作為程式設計師立於不敗之地唯一方法就是,不斷學習、不斷進步。因為一旦你鬆懈下來,你的所有優勢都將隨風而逝。
9.整個軟體行業建立在“百家爭鳴”的思想上。
在我的職業生涯中,我看到過很多程式設計師會對各種事情較真:預估完成時間上較真,規模大小上面較真等等。而且有的人還屢錯屢戰。有些以前被批判為“行不通”的技術,現在卻已經牢牢佔據了人們生活的一席之地,並且現今正向著另一個高潮衝刺。
10.適合你的不一定適合他。
在軟體專案中我們可做的選擇很多很多。有的英明,有的糟糕。但是適合你和你當前情況的選擇可能一點都不適用於其他人。我們經常能聽到別人說自己又在幹什麼偉大的創舉,但是如果他們說什麼這是唯一的好方法時,我會對此嗤之以鼻。
11.在這個不斷變化的世界中,評估是最為重要的技能。
這一點有些人可能並不知道。但是如果你願意認識新事物,看得到他人的努力,比較做事方法之後再擇優使用,那麼不但是你自己,還有你的團隊、你的專案、你的公司,都將受益無窮。但是很多人對此都不擅長,而很多負責人甚至在這方面表現得非常糟糕。照著別人說得做,以及看別人做什麼自己也做什麼,是非常容易的。但是如果要全方位地看問題然後再基於自己的需要選擇對應的最優方向,這就很難很難了。在軟體行業中做抉擇是必須的,但是如果當你在不得不評價分析的時候頭腦一片茫然,那最終的結果只能是隨機挑一個或者是盲從隨大流。
12.不管黑貓白貓,能抓到老鼠就是好貓。
只要你的軟體能實現客戶指定的功能,他們才不會關心需要解決哪些問題。系統出問題了,異常情況發生了,硬體壞了,程式猿被女朋友甩了,黑客盜號了:使用者永遠不會對這些發生興趣。如果發生意外情況,最好能坦誠說出來,但是你最好要能確保這種情況不會持久,因為你總給將最終的產品交給客戶。
13.客戶的意見決定質量。
無論你設定了多少指標,檢查過多少表單,稽核了多少程式碼,寫了多少測試:這都不是關鍵,除非客戶自己親眼目睹軟體運作正常。關於程式碼質量、效能、設計和可用性,客戶的意見才是決定質量的唯一要素。
14.對某方面的無知可能會讓你一敗塗地,因為你在這方面毫無經驗。
即使到了今天我依舊在不斷驚歎,有的同行竟然仍然沒有收集足夠的日誌、崩潰報告和使用資訊來掌控自己的軟體。那些對這方面資訊不屑一顧的傢伙,大多會高估產品的質量。因為如果你不採取措施和記錄結果,渾渾噩噩地混日子,終將會導致你對當前情況一無所知,包括你的客戶。我一直反覆強調,詳細而有用的日誌記錄、程式崩潰跟蹤、評論和意見,反正各種只要能讓我儘快瞭解發生了什麼問題的途徑和方法,都是可行的。不過,我也知道有很多人認為“這種事和程式設計師有一毛錢的關係嗎?”。
15.總有更好的辦法,但是時間不允許。
評估中最難把握的節點是什麼時候應該停止頭腦風暴開始開工。或許我們會錯過那個更好的方法,但是如果要耗費很長時間,那就不值得了。但是這是很難界定的,不過有時候今天的一個小小的選擇可能會打敗明年那個更佳的選項。Who knows?
下面兩點引用自一名銷售人員,他是我很早以前的同事。有些東西我並不是完全同意,不過也能給予我們不同的角度看問題。
16.客戶要找愚蠢的。
這是我最喜歡的一句話,這個銷售人員就職於一家諮詢公司。他認為,要找那種不懂技術但是有足夠資本揮霍的金主。聰明的人總是會問很多問題;沒錢的人無力購買我們的服務。我很慶幸我是一名程式設計師,哈哈!
17.我的工作是欺騙客戶,而你的工作則是支援我。
第二句話來自於同一個銷售人員。他總是喜歡不斷地承諾一些不可能的任務,然後當我們終於嘔心瀝血加班加點趕出來了,他就來收穫我們成功的果實。挑戰的確讓人exciting,但是每次都是這種不可能的任務未免太痛苦。我的建議是,換一個更好的銷售人員!【譯者注:這不是傳說中的PM和程式設計師之間的“和諧”關係麼?】
相關推薦
30多年程式設計師生涯經驗總結【轉】
在我30多年的程式設計師生涯裡,我學到了不少有用的東西。下面是我這些年積累的經驗精華。我常常想,如果以前能有人在這些經驗上指點一二,我相信我現在會站得更高。 1.客戶在接觸到產品之後,才會真正明白自己的需求。 這是我在我的第一份工作上面學來的。只有當
專案管理心得:一個專案經理的個人體會、經驗總結【轉】
本人做專案經理工作多年,感到做這個工作最要緊的就是要明白什麼是因地制宜、因勢利導,只有最合適的,沒有什麼叫對的,什麼叫錯的,專案經理最忌諱的就是完美主義傾向,尤其是做技術人員出身的,喜歡尋找標準答案,耽誤了工作進度,也迷茫了自己。以下是本人一些做專案的個人體會,寫出來供大
一個6年Java程式設計師的經驗總結,寫給還在迷茫中的朋友
前言 很多年前,剛剛從大學畢業的時候,很多公司來校招。其中最爛俗的一個面試問題是:“你希望你之後三到五年的發展是什麼?”。我當時的標準回答是(原話):“成為在某一方面能夠獨當一面的技術專家“。後來經歷了幾家不同的公司,換了不同的方向,才知道這個真是一個很難的問題。因為兵無常勢,什麼東西都是
風雨20年:我所積累的20條程式設計經驗--一個老程式設計師的經驗總結
編者按:原文作者喬納森·丹尼可(Jonathan Danylko)是一位自由職業的web架構師和程式設計師,程式設計經驗已超過20年,涉足領域有電子商務、生物技術、房地產、醫療、保險和公用事業。正如喬納森在文中所言,本文適合剛畢業的大學生和剛入門的程式設計師。如果你已是高
讀書筆記之程式設計師的自我修養【day1】
第一天翻起這本書,其實按理來說學pwn的應該認真讀讀的,現在做個記錄吧。 first chapter 其實主要講的就是靜態連結的事和編譯一個elf檔案的過程 首先是.c檔案——>轉化為.i 檔案過程叫做編譯,也就是把我們的.c檔案轉化為彙編 接著是.i檔案——>轉化為.o
程式設計師的職業素養【2】
1 程式設計非易事。因此,互相幫助是每個程式設計師的職責所在。 給他人提供幫助並非說明你比人家聰明很多,而是因為你帶來了一個新的視角,對於解決問題起到了顯著的催化作用。 要以樂於助人為榮一樣,也要以樂於接受別人的幫助為榮。 2 輔導缺乏經驗的程式設計師是那些經驗豐富的程式設計師的職責
程式設計師晒晒你的【神器】!
點選有驚喜 在程式設計師的職業生涯中,我們需要不斷地學習、積累、提升,除了一些基本的必備知識、技能外,一些【神器】的出現,也會為我們的能力提升錦上添花。那麼,在我們工作時,有哪些【神器】呢? 工具篇 文件【神器】——markdown,一種輕量級標記語言,它允許人們使
程式設計師的學習方法【思考】
程式設計師的學習方法 作為IT業的一員,我們幾乎每天都有大量的知識需要學習,有大量的技能等待我們去掌握。幾乎從我決定“獻身”程式設計師這一偉大事業之後,我就一直在考慮怎麼提高
用戶空間與內核空間,進程上下文與中斷上下文[總結]【轉】
存儲器 com ont article 模式 tab 用戶代碼 ssi 而在 轉自:http://blog.csdn.net/lizuobin2/article/details/51791863 本文轉載自:http://www.cnblogs.com/Anker/p/3
Git常用命令總結【轉】
mda 同時 owa rem resolve fff gin spl 包含 轉自:http://www.cnblogs.com/mengdd/p/4153773.html 查看、添加、提交、刪除、找回,重置修改文件 git help <command> #
C#高級編程六十六天----表達式樹總結【轉】
reac ins method 有一個 創建 exc environ 開始 定義變量 https://blog.csdn.net/shanyongxu/article/details/47257139 表達式樹總結 基礎 表達式樹提供了一個將可執行代碼轉換成數據
11條最全面的C/C++編碼規範總結【轉】
(轉自:https://blog.csdn.net/zang141588761/article/details/50608736) 對於不同的程式語言來說,具體的編碼規範可以有很大的不同,但是其宗旨都是一致的,就是保證程式碼在高質量完成需求的同時具備良好的可讀性、可維護性。例如我們可以
C++中STL用法總結【轉】
(轉自:https://blog.csdn.net/piaoxuezhong/article/details/54348787?utm_source=blogxgwz8) 1.1 什麼是STL? STL(Standard Template Library),即標準模板庫,是一個具有工業強度的
C++ vector型別要點總結【轉】
(轉自:https://blog.csdn.net/suool/article/details/13295439?utm_source=blogxgwz22) 概述 C++內建的陣列支援容器的機制,但是它不支援容器抽象的語義。要解決此問題我們自己實現這樣的類。在標準C++中
高通平臺讀寫nv總結【轉】
本文轉載自:https://blog.csdn.net/suofeng12345/article/details/52713993 一,引言 1. 什麼是NV &nbs
PHP操作Redis常用技巧總結【轉】
一、Redis連線與認證 1 //連線引數:ip、埠、連線超時時間,連線成功返回true,否則返回false 2 $ret = $redis->connect('127.0.0.1', 6379, 30); 3 //密碼認證:成功返回true,否則返回false 4 $ret = $redis-
strerror函式的總結【轉】
本文轉載自:https://www.cnblogs.com/xrcun/p/3210889.html 定義函式:char * strerror(int errnum); 函式說明:strerror()用來依引數errnum 的錯誤程式碼來查詢其錯誤原因的描述字串, 然後將該字串指標返回. 返回值:返
Redis資料"丟失"討論及規避和解決的幾點總結【轉】
轉自 https://blog.csdn.net/shangyuanlang/article/details/81297970 Redis大部分應用場景是純快取服務,請求後端有Primary Storage的元件,如MySQL,HBase;請求Redis的鍵未命中,會從primary Sto
spring web.xml 難點配置總結【轉】
web.xml web.xml是所有web專案的根源,沒有它,任何web專案都啟動不了,所以有必要了解相關的配置. ContextLoderListener,ContextLoaderServlet,DispatcherServlet 區別 web.xml中可以
dmesg 總結【轉】
在dmesg裡我們可以檢視到開機資訊,printk產生的資訊等。若研究核心程式碼,在程式碼中插入printk函式,然後通過dmesg觀察是一個很好地方法。 2.dmesg輸出含義 dmesg 輸出的數字含義是什麼,糾結了一會兒,下面給出解釋 終端輸入dmes