fkjava

從程序員到技術領導者

入行

你為什么要當程序員？每當我問起很多人入行的人，回答各不相同。

有很多人是因為喜歡。誰說過：熱愛是最好的老師。當然，關鍵是熱愛是否能支撐自己把愛好做成一份職業。但不論做多久，因為熱愛或曾經熱愛，這個理由就足夠了。你不能希望撒一粒種子，都變成參天大樹。所以，對進來和離開的人，我們都應該鼓勵。

新入行的人，建議他們用1-2年來適應、評估程序員的生活狀態。不論滿懷希望還是充滿失落，這些時間都不會浪費。在如今信息時代，曾經的經歷，都會使有這方面經歷的人擁有獨特的眼光，很容易在其他領域內，引入新的思考。

進入軟件行業，還是其他行業，其實，對一個新人來說，最重要的東西不是行業本身。而是，你自己得明白：你是什么樣的人？你喜歡做什么？你希望做什么？你希望成為什么？你希望現在如何？你希望幾年后又是怎么樣？最關鍵的還有：你現在能做什么？

當然，你不可能憑空亂想，如果你自己都覺得目標遙遠，那就仔細傾聽內心的感受。你隨時得問自己：我到底要什么？

有一定的方向感，就可以上路了，不必患得患失。

技能

作為立身之本，絕大多數的程序員首先關注的是編程知識、技能。他們大多容易忽視自己在從小到大的學習中，已經發展出來的能力：學習的能力、溝通的能力。這些能力雖然并不能馬上換來高薪，但是，卻對一個人后來的發展，有長遠的影響。

程序員的工作，編碼只是一個技能的部分，這種把知識轉化為成果的技能非常重要。一個優秀的程序員所產生的績效，是一般的程序員的幾倍和幾十倍。對一個軟件公司而言，好的程序員仍然是公司的核心資產。

新入行的程序員都應該首先把精力都集中在技能的提高上。隨著技能的提高，工作能力的增強，自信也會提高。

但是，不要光埋頭干活，不抬頭看路。如果你在一個不太正規的公司，你所做的東西和接觸到東西，不太規范、有效的話，你可能在這個行業做了很多年，都算不上入行，就是說專業的起點太低。即使你有足夠的時間學習，但是由于沒有實踐的平臺，你要走的彎路就太多了。這樣，你需要仔細的評估自己的選擇了。

程序員普遍都有一種激情：希望自己做的產品，能為成千上萬的用戶使用。這種職業的自豪感，激勵著每一個程序員的創造力和想象力。

即使程序員的工作能為你帶來很好的收入，但你對自己所做的東西，毫無成就感，或者跟你的價值取向沖突的話，我想，你也應該考慮重新選擇自己的職業生涯。

我認為，程序員的自律性都是比較高的。他們大多數人都熱愛自己的工作，自己學習專業知識，努力提高工作技能。

除了對專業知識的把握以外，程序員還應該拓展自己的視野，程序員要學習關注自己的生存環境，隨時審視未來的發展空間，選擇自己的發展道路。仍然要問：我要什么？我要到哪里去？

總的說來，程序員生存的空間比較直接、單純。程序員普遍不喜歡工作時受人打擾，這一切都在情理之中。

技術管理者

技術管理者和程序員，他們服務的對象和工作方式完全不同。

程序員是大我，主要是完成任務，所有的事情主要靠自己完成，目標就是完成技術思考和轉化。

技術管理者是小我，服務的對象是團隊，目標是組織和連接流程。用俗話說，就是要當“萬金油”。

技術管理者，不論是項目經理，還是技術總監，首先要會選人和用人。要完成什么樣的任務，選什么樣的人，是領導的基本功。

技術管理者跟程序員最大的不同在于知道在有限資源的情況下，如何做出最合理的選擇，不一定是最好的選擇。領導者知道，用人用其長，而不會去苛求每個人都達到完美。

程序員可以談論品味，像藝術家一樣看待工作；而技術管理者談論效果，是現實主義者。好的技術管理者，能在長期的理想和現實的結果中找到一個好的平衡。

技術管理者，關心的是外部目標、內部人員績效和激勵、質量控制、產品服務等一系列的活動，監督、評估并推進項目或產品的流程，直到產生一個可以交付的外部結果。

技術管理者的工作重心在人，在團隊。他的績效是通過組織和團隊的績效體現出來的。

從程序員到技術管理者

中國有句古話：勞心者治人，勞力者治于人。很多時候容易理解為：程序員勞力，技術管理者勞心。這種想法最容易造成程序員內心的不平衡。我想，現在的知識社會，大多既要勞心，又要勞力。只勞心，不勞力的人，有知識，沒有執行和轉換能力，這樣的人，很難駕馭和管理真正的技術團隊；只勞力，不勞心的人，不會提高自己的競爭力，自己也不會滿意。

做程序員，還是技術管理者，這只是分工不同，并沒有高低貴賤之分?？梢钥匆姡捎诔绦騿T和技術管理者定位和服務對象的不同，他們的知識結構的要求也有所不同。程序員看起來更技術化，便于評估，比較深入，技術管理者看起來更行政化，似乎表面，寬泛化，但都需要專業的素養和才干。

程序員也可以成為好的技術管理者，但需要積累和調整自己的知識結構和心態：要能勇敢地獲取外部的力量。因為管理者的目標并不意味著他有多大的能力，而是他的團隊有沒有能力，有沒有成效。那種認為管理者不勞而獲的想法，是一種偏見。大家職責不同，責任不同。

一個優秀的技術人才，一定要選擇一個優秀的團隊。一個好的技術管理者，也要充分發揮技術人才的優勢，這樣，只有團隊的力量，才可以把自己的才能成百上千地放大。

從外部來看待成長

從程序員到技術管理者，是一個眾說紛紜的話題。但是，這不應該是一個非此即彼，孰優孰劣的問題。我更愿意看成是一個組織環境中，不同環節上不同的位置和選擇，跟定位和特長有關。站在組織的觀點來看，在一個團隊的內部，是沒有績效可言的。只有團隊，對外產生了價值，個人才有價值。

或許并不是所有的人都能接受這一點。

所以，當你問自己得到了什么的時候？你也應該問自己奉獻了什么？什么是應該體現你的報酬？你的報酬是否體現了你的責任和承擔的風險？

很多時候，不是你是否值多少錢的問題，而是在一個商業的環境中，沒有貢獻，就沒有價值。

一個人要客觀地看待自己，不論是程序員還是管理者，都不要不可一世或忘自菲薄。天生我才必有用。一個人的成長，應該從外部的趨勢和影響，來學習、選擇和發展。把更多時間和精力，放在建立自己的核心競爭力，找到自己事業的伙伴上。

請勇往直前，不要患得患失，不要怨天尤人，命運就掌握在自己的手中！

幸福和健康

沒有任何正當的理由，讓人用幸福和健康來交換所謂的前途。永遠牢記：身體是革命的本錢。
轉自瘋狂軟件

Java程序員應該遵循的十條戒律

Java程序員有許多應遵循的守則或最佳實踐方式。本文概述了每個開發者最應該遵循的10條守則或戒律，如果不遵循它們，將會導致災難性后果。

　　1：為代碼添加注釋。每個人都知道這一點，但不是每個人都會這么做。你有多少次“忘記”添加注釋了？確實，注釋不會為你的程序增加任何函數功能。但是，有多少次，看到2周前寫的代碼，你都記不起它是干什么的？你很幸運，那些未注釋的代碼是你自己寫的，你腦海中還會有殘存的印象。非常不幸，大多時候，代碼是別人寫的，并且那個人很可能已經離開公司了。有句諺語說的好：“有來有往，互惠互利”，因此程序員應該體諒彼此（還有你自己），給你的代碼加上注釋。

　　2：不要把簡單事情復雜化。我曾經這么做過，我相信你也一樣。開發者都傾向于采用復雜方式解決簡單問題。我們在一個只有5個用戶的系統中引入EJB，為一個并不需要框架的應用實現一套框架，采用屬性文件、采用面向對象解決方案、使用線程，而這些根本用不著。為什么會這么做？一些人可能不知道有更好的解決方案，但另一些人可能故意這樣做來學習新知識，或僅僅是因為有趣。對那些不知道更好解決方案的人，要多聽有經驗程序員的建議。對于那些純粹出于個人目的而將設計復雜化的人，我建議你要更加專業一點。

　　3：記住“越少越好”并非總是如此。高效率的代碼是件好事，但很多情況下，并非代碼行數越少效率就越高。

　　4：不要“硬編碼"。由于時間緊迫，開發者總是會忘記或故意忽略這一條。然而另一種可能是，遵循這條戒律，我們就不會陷入“時間緊迫”的困境。定義一個static final 變量，增加一行代碼，又能花多長時間呢？

　　5：不要發明你自己的框架。不夸張地講，已經有幾千個框架存在了，大多數還是開源的。很多框架都是極完美的解決方案，并已被用到成千的系統中。我們只要關注最新的流行的框架，至少表面上要熟悉一下。一個最成功的、也是被廣泛使用的例子是Struts框架，這個開源的web框架是建立web系統的極佳選擇，不要試圖構造你自己的Struts版本，會累死的。但你必須記住第2條（譯注：原文是“第3條”，顯然不對）戒律 —— 不要把簡單事情復雜化。如果你要開發的系統只有3個界面，就不要用Struts：對于這樣一個系統，沒有足夠的需要被“控制”的東西（Struts將界面做MVC劃分，C即controller，所以作者說there isn't much "controlling" required）。

　　6：對Print行或字符串說不。我知道為了調試方便，程序員喜歡到處用System.out.println ,然后對自己說過一會就刪掉。但我們常常忘記刪掉這些行或不愿刪掉，我們用System.out.println 做測試，為什么測完后還要去改代碼？這很可能導致誤刪一行我們需要的代碼。不要低估System.out.println 的危害。

　　7：注意圖形用戶界面。無論聽上去多荒謬，但有一點我注意過多次了：圖形用戶界面（GUI）對于商業用戶而言與程序功能及執行效率一樣重要。GUI對于應用程序的成功至關重要。 IT管理者（這里是指程序開發方的IT management）常常忽略GUI的重要性，很多公司為了省錢而不雇傭web設計人員，而這些設計人員有足夠的經驗來設計“用戶友好”的應用軟件。 Java程序員不得不依賴他們有限的HMTL知識。我見過非常多對“計算機友好”而非對“用戶友好”的應用程序，同時精通軟件開發和用戶界面開發的開發者非常少見。 如果你是一位不幸被指派做界面開發的Java程序員，你要遵循下面3條規則：

　　1）不要重新發明輪子。去看那些類似應用系統的界面。

　　2）首先建立一個原型。這一步非常關鍵?？蛻粝矚g提前看到他們要用的東西。同樣你可以得到他們的反饋，而不是你辛辛苦苦做出來一個客戶不喜歡的東西。

　　3）試戴用戶的帽子。換句話說，站在用戶的角度查看需求。譬如，一個統計的界面可以分頁，也可以不分頁。作為開發者，很可能會忽略分頁，因為這會減少很多麻煩；而站在客戶角度，這就不是一個好的方案，因為數據可能多達幾百行。

　　8：提前準備需求文檔。每項業務需求都記入文檔。這在童話故事中可能實現，而現實中很難做到。無論時間多么緊迫，無論截止日期如何迫近，你必須確保業務需求被記錄下來。（這條明顯悖于敏捷開發的觀念，大家要獨立思考，甄別是非）

　　9：單元測試，單元測試，單元測試。我不準備討論如何單元測試的細節，我只是想說這必須要做。這是編程中最基本的規則了，尤其不能忽略。如果你同事能為你的代碼創建一個測試計劃，那就再好不過了；如果不能，那就要自己做。做單元測試計劃時，遵循下面原則：

1）編碼前就寫單元測試

2）保留單元測試的注釋

3）對任何“有趣的”公共方法都要做單元測試（“有趣的”是指除了像最常見的getter/setter這類方法外的方法，但包含有自己內容的getter/setter 方法）

10：記?。嘿|量，而非數量。不要待的太晚（除非有必要）。有時因為產品問題，截止期限或其他突發事件，不能按時下班。但經理不會因為你為一般問題待的太晚而感激或獎勵你；他們會為有質量的工作而感激你。如果你遵循上面的列的原則，你就會寫更健壯的、少bug的程序。這才是你最應該做的。(翻譯文章)

轉自：瘋狂軟件

對Java初學者的忠告

1)適合自己的圖書才是最好的，最好的書并不一定適合你，看自己的情況。（如果你是一個Java初學者一上手就捧一本Thinking in Java在手里，我想你的日子是不會好過的，那樣的書給有一定基礎的人看的，當工具書使用的，當然有一定基礎后，可以跟著上邊流程學，如果你能學下來，那么你的基礎就不用說了）

    2)看書要用心，多動腦，實踐很重要，要抱著懷疑的態度看書。（再好的書也可能會出現錯誤，人非圣人嗎！多練這個很重要，如果你光看不練，我想你連過幾天會就會忘的差不多了！）

     3)遇到問題多查幫助文檔，還可以上網站進行搜索。（現如今的搜索引擎功能十分強大，只要你能用得到就能搜到的，還擔心什么，不要碰到一點什么問題，都去煩別人，這樣別人會小瞧你的!可以加一些Java交流群，對于初學者可能會有一些作用，如果你已經是高手了，我認為這樣的群對你的提高不會很大）。

    4)忌諱急功近利，越急就越容易走彎路。（不要急，基礎雖然很簡單，一個月或半年，甚至是一年，這都很正常。但出來的成效絕對是不一樣的，相信你的時間不會白白浪費。）

    5)我們要精而非全，語言都是相同的。學精一門語言再轉其它語言也會容易的多?；A很重要，不要貪高。（這個就不用說了，如果你精通C++，改學Java還不簡單，思想你已經掌握，你要學的就是一點語法，還不容易？）

    6)欣賞他人的代碼：初學者不要看，因為理解別人的思路遠比自己寫要困難的多。認為自己的基礎到了一定的程度，可以看看一些開源的軟件，因為那都是一些優秀的杰作，會對提高你的水平有很大幫助。注意方法:（先找主線——>從界面入手——>在紙上畫出結構圖——>然后再分步分析）

    7)在實踐中提高自己的能力：邊學邊練，別給自己找借口。（買一些帶實例的書，可以試著做一些日常生活中常用到的小程序，只有在實踐中你才會發現更多的問題）。

    8)培養自己發現、思考、解決問題的能力。（能自己想辦法解決，不求別人！對于初學者很重要。）

    9)心態要平衡，不要總覺得高人一等。一個事物的存在總有它的合理性。（你的技術比別人牛，這沒什么，或許你是學的早，也或許你比別人反應快一點，永遠不要自大，計算機是技術更新很快的行業，你不會永遠都站在別人的前頭的。心態平衡，不斷學習，這才是王道?。?/span>

    10)可以下載視頻，買書，借書，在線觀看。（如果你是大學生，那么不要浪費資源，一頭扎頭圖書館里吧。現在網絡資源，網上的視頻和電子書極多，還愁找不到資源嗎？）

    11)認證的價值不大，在一些企業還不是特殊認可，沒必要花費大的精力去考。（個人沒有去學過認證，認為價值不大，但如果你根本不缺那幾個錢，又有能力的話，可以考，多少還是會有一定作用的。如果你的經濟情況不怎么樣，照我說，就先算了。）在職學習比較困難，比較忙，壓力大，時間緊

    12)找工作，基礎扎實，有一年開發經驗，不用擔心。你可能會有3K左右的工資了。

    13)做開發不一定要數學好，只不過你不適合做算法方面的工作。（能當程序員的，誰都不白癡，呵呵?。?br />   14)沒有什么捷徑，如果有的話，價值也就不大了。（別夢想一步登天，給自己作一個學習過程計劃，先學什么，后學什么，合理一點。如果非要說有什么捷徑的話，我認為培訓不錯，條件允許的話，這可以省掉你很多的寶貴時間，當然選擇培訓機構的時候一定要慎重。因為那不只是Money的問題。）

轉載：廣州java培訓http://www.fkjava.org

成功開發人員須記住的8件事

1、保持學習

一個非常重要的觀點是：如果你停留在一個地方不前，并不代表你能一直呆在那里，而是代表你正在落后（不進則退）。往前進并不意味著你是就能進步——這至少你不會淪落到最后（付出就會有收獲） 。程序員為了保持向前發展，就需要不斷學習 ，我們需要的不是慢慢的往前走，而是我們要奔跑起來！下面列出這方面的幾個觀點：

1）讀書

2）訂閱RSS和閱讀一些雜志

3）參加一些研討會，自己準備一些簡報

4）學習一切可以幫助你的東西

5）教其他人其實也是教自己

2、給自己確定目標

如果不知道向什么方向發展，是很難有成就的。這一點關鍵是自己要有一個清晰地目標。這個應該是個長期的目標，然后要有一個目標的愿景。首先要把這個目標分 成一些小的任務，建立實現這些目標的路線圖。你可以創建每月或每年你必須完成的一個任務列表，然后根據這個任務列表去實現。

3、生活中的每一個挑戰都是一個機遇

在日常工作時，總是會遇到各種各樣的問題。你可能會遇到一些程序的bug；項目經理分配的新任務；你同事請你幫助；你請別人幫助。這些都是一個一個的挑戰。問題是：你如何去解決這些挑戰？我的一個答案是：你必需調動你所有的激情去應對這些挑戰，因為每個挑戰就是一個機遇。

4、抱有積極態度

對待每一件事情都應抱著積極的態度。如果發現你犯了一個錯誤，請不要在意，因為沒有人是不會犯錯誤的。你可以想象一下，有誰喜歡那種一遇到問題就抱怨的人 呢？如果你說“好吧,伙計們,我能做到的,請給我一分鐘,我就會解決這個問題。”,然后笑著轉過身就修改自己的錯誤，這樣在別人眼里又是如何看待你呢？當你解決這個問題之后，你會感覺到異常的高興。

相信自己的方法是正確的，自己正在快速進步。千萬不要老是認為自己無法達到自己的目標。

5、給自己尋找一個導師

這并不是說你需要一個人來幫助你來完成你的工作。導師可能就是比你職別高的職員。而且他的職位是你想要去爭取的。如果他的職位你爭取到了，你可以再選擇另外一個更高的。但是你必需一直都需要有這么一個人。也可以能督促你和支持你的朋友、親人、戀人等等.

6、讓自己公眾化

如何讓別人知道你呢？一個最簡單的辦法是寫博客、提問題、幫別人解決問題。起碼要google知道你吧。學會在團隊和項目中分享自己的知識。如果你學了新的知識，就把它分享出來！如果你沒有分享，下次再用的時候，你可能就忘記了。

7、時不時的審查一下自己，確保自己的方式正確

時不時的，你需要檢查你做的方法是否全正確。檢查一下是否完成即將完成的目標。如果沒有，趕快找原因，加緊去完成。尋找你的薄弱環節，加強它們。這聽起來 很滑稽：我認識一個技術很強的開發人員，但他的打字速度卻是很慢。為什么？因為他對鍵盤不熟悉，又不想花10-20小時進行鍵盤訓練。兄弟，如果你會讀到 此，請務必要求自己克服此類的問題。

8、保持健康身體

這個有點像磨刀不誤砍柴工。有一個故事，兩個樵夫打賭砍樹，一個比較強壯，另外一個比較瘦弱。強壯的人相信他會贏得，因為他沒有休息，持續砍了8小時。瘦小的那位，每隔一個小時就休息15分鐘。最后瘦小的那位樵夫卻贏了。他贏的秘密在于休息的時候將刀磨鋒利了。你的健康就像是斧頭，如果斧頭鈍了，你將無法為自己人生道路劈荊斬刺。

來自：瘋狂軟件

考慮云計算安全的幾個方面

當云計算涉及到通過軟件服務交付時，必要的保護措施是獨立的軟件提供商首要關心的事情，他們應該從所有接入點、用戶以及各個角度保護他們的SaaS基礎設施。

　　但需要注意的是并非所有的云計算都是安全的。在大眾市場上，可能會有相對廉價的云存儲或者云計算服務，但都缺乏較高的企業級安全措施。

　　對安全的需求度

　　如果你的客戶需要部署嚴密的安全措施，相同的控制必須在云中進行復制。如果你的數據或者聲譽因為安全而受到損害，那么通過SaaS交付節約的成本對企業來說并沒有太多的價值。

　　當你接受提供商的云服務時，您所要考慮的不僅僅是云本身的安全保護，還要考慮網絡和物理設施安全。

　　云安全

　　當你想把云基礎設施進行外包時，你將會希望找到一個在網絡、操作系統以及最佳實踐等方面都有豐富經驗的服務提供商。加密和VPN（VirtualPrivateNetwork）服務也是必須要考慮的。賣房應提供相應的咨詢服務，無論是自己提供還是通過合作伙伴，都應該提供安全風險評估、入侵測試、威脅管理服務和補救措施。

　　似乎被忽視的領域是web應用防火墻服務。這些服務可以幫助拒絕無效的請求和保護應用程序。

　　開發商和建筑師都說他們的網絡是安全的，因為他們使用了加密技術。當優勢試圖偷聽時加密保護了你應用程序的數據，但他并不能阻值不必要的請求。應用防火墻可以為你的應用程序創建一個“護城河”，可以阻止正在處理的無效或者是不適當的應用程序請求，從而節省了CUP資源和記憶周期，更重要的是防止了數據泄漏。

　　最后，你應該了解你的服務供應商如何相應惡意攻擊。你的供應商是否有一個安全的數據中心。

　　網絡安全

　　網絡安全應該保護你的SaaS環境中所有的虛擬接入點，您的供應商應該有察覺新出現的威脅和應對攻擊的能力，在它們成為真正的威脅之前編寫程序和指定策略，嚴格杜絕危險出現。

　　一些供應商同時監測在互聯網上的多個客戶，所以他們經常能夠看到并迅速接觸威脅。這對獨立軟件開發商來說可能是一個重要的協議，很可能幾天都看不到攻擊，因為它可能不是直接目標。如果外部發生威脅時，廠商可以積極相應、編寫規則以防止它的出現。

　　物理安全

　　目前，虛擬化迅速擴張讓很多人不在考慮物理設施的安全。但是不管你是托管方、托管服務商或是云服務提供商，最重要的是保證你存儲數據的物理設施是安全的。

　　服務提供者應確保其物理設施的接入點是被保護的，利用找值班的看守、安全攝像機、全身掃描和其他的措施以防止違規行為的發生。

　　在考慮物理安全的同時，還要考慮服務提供商的災難恢復解決方案。您的數據存儲安全么？存儲在什么地方？會不會被加密保護，如果將您現有的數據轉移到磁帶，磁帶是否備份加密？

就總體而言，無論你的SaaS應用程序的數據存儲在數據中心、網絡中、或者是云中，安全都是最重要的。IT決策者要提高警惕，對任何事物都不能過度信任。
轉載于：瘋狂軟件

20個數據庫設計最佳實踐

數據庫設計是整個程序的重點之一，為了支持相關程序運行，最佳的數據庫設計往往不可能一蹴而就，只能反復探尋并逐步求精，這是一個復雜的過程，也是規劃和結構化數據庫中的數據對象以及這些數據對象之間關系的過程。下面給出了20個數據庫設計最佳實踐，當然，所謂最佳，還是要看它是否適合你的程序。一起來了解了解吧。

使用明確、統一的標明和列名，例如 School, SchoolCourse, CourceID。

數據表名使用單數而不是復數，例如 StudentCourse，而不是StudentCourses。

數據表名不要使用空格。

數據表名不要使用不必要的前綴或者后綴，例如使用School，而不是TblSchool，或者SchoolTable等等。

數據庫中的密碼要加密，到應用中再解密。 （其實就是散列存儲、單向加密）

使用整數作為ID字段，也許現在沒有這個必要，但是將來需要，例如關聯表，索引等等。

使用整數字段做索引，否則會帶來很大的性能問題 。

使用 bit 作為布爾字段，使用整數或者varcha是浪費。同時，這類字段應該以“Is”開頭。

要經過認證才能訪問數據庫，不要給每一個用戶管理員權限。

盡量避免使用“select *”，而使用“select [required_column_list]”以獲得更好的性能。

假如程序代碼比較復雜，使用ORM框架，例如hibernate，iBatis。ORM框架的性能問題可以通過詳細的配置去解決。

分割不常使用的數據表到不同的物理存儲以獲得更好的性能。

對于關鍵數據庫，使用安全備份系統，例如集群，同步等等。

使用外鍵，非空等限制來保證數據的完整性，不要把所有的東西都扔給程序。

缺乏數據庫文檔是致命的。你應該為你的數據庫設計寫文檔，包括觸發器、存儲過程和其他腳本。

對于經常使用的查詢和大型數據表，要使用索引。數據分析工具可以幫助你決定如何建立索引。

數據庫服務器和網頁服務器應該放在不同的機器上。這回提高安全性，并減輕CPU壓力。

Image和blob字段不應該定義在常用的數據表中，否則會影響性能。

范式（Normalization）要按照要求使用以提高性能。Normalization做的不夠會導致數據冗余，而過度Normalization 會導致太多的join和數據表，這兩種情況都會影響性能。

多花點時間在數據庫設計上，否則你將來會付出加倍的時間來償還。
原文發表于：瘋狂軟件

程序員的八種級別

一名軟件開發人員的職業生涯會是怎樣的呢？我們干著一行是因為我們熱愛編程，并且在這一點上，我們非常幸運。但是，當你50歲的時候，你還會坐在電腦前編程嗎？當你60歲時呢？對于那些渴望成為程序員的程序員來說，最好的職業生涯出路是什么呢？ 開個玩笑，如果我告訴你，程序員可分為八種級別，你會怎么想呢？

1、不朽的程序員：這是最高層次。你寫的代碼并沒有隨你而去，而是保留了下來（萬古流芳）。你會在計算機領域永垂不朽。其他程序員會研究你的成果和著作。你可能獲得了圖靈獎，發表過有巨大影響力的文章，或者發明了一項或多項為眾人所知的基礎性技術，已經影響了編程事業的發展。

介紹你的并不只是個維基百科詞條——很多網站致力于研究你的生平和成就。只有很少的程序員達到這種高度。

2、成功的程序員：這些程序員既聲名遠揚又借助自己的編碼創立完整業務，甚至整個行業。他們給自己創造了真正的自由：自己決定從事什么工作的自由。并且跟自己的同事分享這種自由。

這是大部分程序員都渴望的一種高度。能否達到這種高度往往更多的取決于業務技巧而不是編程能力。

3、著名的程序員：這也是一個不錯的層次，但是美中不足是出名不能當飯吃。在編程這個圈子里，你非常有名。但是，有名氣并不一定就意味著你會藉此獲利來養活自己。出名很好，但成功更佳。你可能為一家著名的大公司或者有影響力的小公司工作，也可能是一個普通創業團隊的一員。其他程序員對你都有所耳聞，你正對這個領域產生積極影響。

4、能干的程序員：作為一名軟件開發人員，你事業有成。公司需要你的技術，找份好工作對你來說永遠不是件難事。你的同事尊重你。你工作過的每家公司都在你從事的方面取得了長足的進展。但是，僅此而已，別無他長？

5、普通程序員：處在這個水平，你有自知之明，知道自己不是一個偉大的程序員——可能你永遠都不會是。天賦跟成功鮮有關聯。如果你擁有生意頭腦和人際技巧，你會非常成功。 如果你是一名平庸的程序員，但是能夠以此謀生，那么可以說你是很有天賦的，但不一定在編程方面。別低估這份自知之明，因為有自知之明的人比你想要的要少。 有沒有天賦無關緊要，只要你能發現自己的強項并且持之以恒。

6、業余程序員：一名業余程序員熱愛編程，這說明：他可能是一名很有前途的學生或實習生，他們正在為開源項目做貢獻，或者在業余時間開發有趣的“僅供娛樂”應用程序或網 站。他們的想法以及代碼表明他們充滿熱情并且很有前途。成為一名業余程序員是一件很不錯的事情，從這個階段可以很快成為一名有作為的程序員。

7、不知名的程序員：這是眾所周知的典型的一種程序員：無名氏。他們有能力(通常會有)但不出色，可能為一家不知名的大公司工作，但那只是一份工作不是生活的全部。不過，那也沒有什么問題。

8、糟糕的程序員：那些沒有一點技術或能力但不知怎么就成了程序員的人。他們接觸的每件事情都會成為同事們的苦難——這些員工更糟糕，他們甚至不知道在和別人合作工作。

這些糟糕的程序員有什么共同特征呢？按理說他們跟寫什么樣的代碼無關——但不管怎樣確實有關。

這種劃分并不是非常嚴格。并不是每一名程序員都渴望在自己的職業生涯里只做同一件事。但是一名程序員在十年、二十年、三十年或者終其一生能夠達到一個什么樣的高度？這值得我們思考。你最敬佩哪位著名程序員？他們取得了怎樣的成就贏得了你的尊敬？

簡而言之，你想怎樣度過此生呢？歡迎你在微博中和大家分享。
原文發表于：瘋狂軟件

我所積累的20條編程經驗

1、估算解決問題所需要的時間。不要怕，承認吧！我曾見過一些程序員為了解決一個特殊問題而坐在顯示器前面8小時。為自己定一個時間限制吧，1小時、30分鐘或甚至15分鐘。如果在這期間你不能解決問題，那就去尋求幫助，或到網上找答案，而不是嘗試去做“超級堆碼員”。

2、編程語言是一種語言，只是一種語言。隨著時光推移，只要你理解了一種語言的原理，你會發現各種語言之間的相似之處。你所選擇的語言，你應該覺得“舒服”，并且能夠寫出有效（而且簡潔）的代碼。最重要的，讓語言去適應項目，反之亦然。

3、不要過于注重程序的“設計模式”。有時候，寫一個簡單的算法，要比引入某種模式更容易。在多數情況下，程序代碼應是簡單易懂，甚至清潔工也能看懂。

4、經常備份代碼。在我年輕時，我就有過因硬盤故障而丟了大量代碼的經歷，這經歷很恐怖的。只要你一次沒有備份，就應當像有著嚴格的期限，客戶明天就需要。此時就該源碼/版本控制軟件大顯身手了。

5、承認自己并不是最頂尖的程序員 - 知不足。我常想，我對編程了解已足夠多，但是總有其他人比你優秀。正所謂，“一山總比一山高”。所以，向他們看齊吧！

6、學習再學習。正如第5點所說，我經常會在手里拿一本計算機或編程相關的雜志或書（不信，可以問我的朋友）。誠然，總有很多你不知道的技術，你可以從中學習以保持不落后。如果你有一種靈巧的方式來獲取你需要的新技術，那你每天都應該堅持學習。

7、永恒的變化。你對待技術/編程知識，就應像你對待股票一樣：多樣化。不要在某一特定技術上自我感覺良好。如果那種技術或語言已經沒有足夠支持，那你還不如現在就開始更新你的簡歷，并啟動培訓新計劃。我能保持前行的主要原則是什么呢？至少了解兩到三種語言，所以，如果某種語言過時了，你在學習新技術的時候還可以依靠另一種語言。

8、提攜新人。協助并且培養初級/入門的開發人員學習優秀的編程方法和技巧。也許你還不知道，在幫助他們向更高一層前進時，你自己也在向更高一層提升，你會更加自信。

9、簡化算法。代碼如惡魔，在你完成編碼后，應回頭并且優化它。從長遠來看，這里或那里一些的改進，會讓后來的支持人員更加輕松。

10、編寫文檔。無論是Web服務的API，還是一個簡單的類，你盡量編寫相應文檔。我曾經引以為豪的代碼注釋，因過度注釋而有人指責。給三行代碼加一行注釋，只需要你幾秒時間。如果那是一個比較難以理解的技術，千萬別擔心過多注釋。如果你能很好做好自己的工作，大多數架構師、后備程序員、支持組都會感激你。

11、測試、測試再測試。我是一名黑盒測試粉絲。當你完成編碼后，你“被認可”的時候就開始了。如果你們公司有QA部門，如果你的代碼中有錯誤，那你得到的評論，會比項目經理還多。如果你不徹底測試自己的代碼，那恐怕你開發的就不只是代碼，可能還會聲名狼藉。

12、慶祝每一次成功。我見過很多程序員在解決編程技術難題后，會和同伴握手、擊掌或甚至手舞足蹈。每個人在生命中都會碰到“頓悟”。如果一個程序員高興地跑來叫你去看他的非凡代碼，也許你已經看過這樣的代碼100遍了，但你也應該為了這個家伙而慶祝第101次。

13、經常檢查代碼。在公司，你的代碼要經常檢查（包括自查和其他同事檢查）。不要把別人的檢查，看成是對代碼風格的苛求。應該把它們看作是有建設性的批評。對個人來說，經常檢查你的代碼并且自問，“我怎樣才能寫得更好呢？” 這會加速你的成長，讓你成為一個更優秀的程序員。

14、回顧你的代碼。在看到自己以前的代碼時，通常會有兩種方式：“難以至信，這代碼是我寫的”和“難以至信，這代碼是我寫的”。第一種往往是厭惡的語氣，并在想如何改進它。你也許會驚嘆，舊代碼也能復活成為一種更好的程序，甚至是一個完整的產品。第二種通常帶著驚奇和成就感。開發人員應該一到兩個自己完成的項目成果，能讓眾人不禁而立并注目而觀的項目。同樣，基于你優越的編程能力，你可以把過去的程序或項目拿出來，把它們更新為更加優秀的產品或想法。

15、幽默是不可缺的。在我20年的開發生涯中，我還沒有碰到哪位程序員是沒有幽默感的。實際上，干我們這行，幽默是一項必備品。

16、謹防那些無所不知的程序員，不愿分享的程序員，還有經驗不足的程序員。當你遇到這幾種程序員時，你自己要謙虛。無所不知的程序員，更想當一個英雄而不是團隊成員；保守的程序員則是在編寫著他們獨享的代碼；而經驗不足的程序員則會每十分鐘就來問你一下，當代碼完成后，代碼已經是你的，而不是他們。

17、任何項目都不會那么簡單。朋友、家人和同事曾請求我倉促做一些事情，倉促做一個程序或者網站。對于這樣的事，應該從雙方做計劃，才能做出令兩方都會滿意的東西。如果某人起初只是需要一個使用Microsoft Access的、只有有3個頁面的網站，但來就很可能變成一個有15個頁面的網站，并使用SQL Server，有一個論壇，還有一個定制的CMS（內容管理系統）。

18、任何時候不要想當然。假如你承接一個簡單的項目，你可能會認為某個部分可以輕松完成。千萬別這樣想！除非你有一個類、組件、或者一段已經寫好的代碼，并且在現有的項目已經測試通過。不要認為這將是很容易的。

19、沒有已經完成的軟件。曾經有一位程序員告訴我，沒有軟件是已經完成的，它只是“暫時完成了”。這是明智的忠告。如果客戶還在使用你寫的程序，并經受了時間的考驗。如果有機會，你仍在更新它，這并不是什么壞事，這讓你不斷地前行。

20、耐心是一種美德。當客戶、朋友或家庭成員用電腦的時候，他們也許會受挫，進而想砸電腦，或氣沖沖地離開。我一直在告訴他們，“是你掌控電腦，不是電腦掌控你。”對于用作編程的電腦，你要有一定的耐心。一旦程序員知道問題所在后，他們就會站在電腦的角度看問題，并且說“哦，這就是為什么它是這樣做。”

摘自：瘋狂軟件