職場10年之如何做一名合格的程式員(下)

上一部分中，Aicken介紹到成為合格程式員的四個努力方面，接下來繼續為大家介紹。

5.安全第一

    我指的安全性，不是指如何防止程式碼被人破解，而是如何保護業務資料的安全性。

    為了提高安全性，就要加密，如何加密，在哪裡加密，加密後如何解密，就成了問題的關鍵。

    在可配置性那一部分，我提到了設定檔中的密碼，這就是首先要考慮的一個需要加密的地方，因為那是想找麻煩的人首先想到的一個地方。說到這裡，我想起幾年前，我覺得QQ的密碼是儲存在本地的，我就想法找、找、找，終於有一天，我覺得密碼可能儲存在某個檔案中，於是花了一點時間，把檔案解開了，發現裡面寫著一句話“別找了，密碼不在這裡!”我覺得我們做程式都要向這方面努力，哈。

    第二個要考慮的就是使用者的密碼。在會員管理系統中，都有會員帳號和密碼，這個密碼不應該儲存明文，而應該儲存密文，而且最好用MD5等單向加密碼演算法，與設定檔中的不太相同。如果用單向，那麼怎麼解開再比較呢？答案是不需要解開，我們在登入的時候，把它輸入的密碼按同樣的演算法加密，直接比較加密後的字串即可。只要比較成功，和用原碼比較的效果是一樣的。這樣，即便有人攻破了你的資料庫，也很難用會員帳號類比登入了。有人說MD5也是可以解開的，我想這我就暫時不考慮了，有更好用的，更簡單的演算法我再替換吧，終歸現在很多企業都在使用MD5演算法。

    第三個考慮的是業務資料的加密。以前接觸過一個中原地產那類的房屋中介，他們的資料庫裡儲存的是房源資訊，他們的競爭比較激烈，誰擁有那些資訊，誰就佔有了市場，所以他們對資料的管理非常嚴格，要求在資料庫即使被攻破之後，裡面的資料依然不可讀。其實這個問題在很多企業都存在，在企業中，DBA可以管理資料，只要他們感興趣，他們可以看到很多不該看到的資訊，雖然資料庫廠商想了很多辦法，但是許可權從根本上就給了DBA，還是很難處理的。我處理這種問題的方式是對部分欄位資料存放區再加一層密，當然是雙向的，儲存的時候，把明文加密後存進去，讀取的時候，先取出資料庫的內容，然後在我的程式裡解碼，這樣，只要是用我的系統，不存在亂碼的困惑，但是如果直接查看資料庫，對不起，什麼也看不出來。

    再有就是考慮加密狗之類的硬體加密了，那個東西我沒太用過，不發言了。嘿。

6.層次分明

    聽說最早的開發模式，叫Host模式，可能就是完全在主機上運行吧，後來有了CS模式，BS模式，DNS，MV，MVC，三層架構，四層架構，N層架構等。每種模式的產生和持續都有它的曆史背景，不能用哪個好哪個壞來評論。我們暫時拋開曆史不談，也不考慮未來，只談現在，我們應該採用什麼方式呢?作為一個健康的系統來說，我建議採用分層的方式，分多少層，怎麼分，我不覺得有什麼太多的條條框框，只要能分開職責就可以了。

    分層有哪些好處呢？它可以使各個層面之間的耦合度降低，可以使各個角色的人各司其職，只要中間的介面合理，就可以實現一個良好的組合，就像PC機一樣，在中關村買一些配件裝起來就行了。這樣在出了問題的時候，我可以選擇換CPU或硬碟，而不至於把整個PC扔掉。

    我現在的程式一般這樣分：

    展現層+架構層+資料庫層

    因為我用C#開發，展現層指的就是IIS，也就是指asp.net的容器，展現層和架構層實現了代碼分離，我會把大部分的商務邏輯或常用的控制項封裝在架構層，由展現層來調用，這樣，就可以在人員配置上，把前端和後端分開了，人們可以各幹個的工作，前端發現任何問題，交給後端去檢查，然後發布一個新的DLL即可搞定剛才的問題。而且在系統更新的時候，也比較方便，可以找相應的DLL進行更新，不需要全部整個部署。

    資料庫層指的是除了資料存放區外，在資料庫中再寫一些程式和邏輯，我用Oracle，那麼語言就是它專用的PL/SQL，也就是在我的架構層中，大部分和資料打交道的東西，也全是交給資料庫去處理，可以利用視圖，預存程序等方式，在C#代碼裡盡量少的出現資料庫裡相關的內容，這樣一是可以提高效率，二是把耦合度再次降下來，當你把有些商務邏輯寫在資料庫層的時候，這種優勢特別明顯，業務上的任何風吹草動，可以在資料庫裡輕鬆搞定，而且資料庫位於中央，不需要什麼發布的動作就可以了。

    任何事物有好的一面，就會有壞的一面，分層也不例外，所以大家要根據情況自己選擇合適的方式就行了。不要太過教條。

7.拿來主義

    所謂參考，又謂之學習，還可稱之為拿來主義，我這裡指的拿來主義，並不是指直接使用其它第三方的控制項，而是學習其它系統的實現及設計思路。

    在IT生涯中，有一部分時間您可能是在自己寫代碼，部署自己的系統，還有可能參加實施一些其它廠商的產品，特別是國外的一些產品（不服不行），他們多在中國設有代理機構或實施商，協助他們進行產品實施，之所以他們這樣做，有多種原因，一種可能是出於法律原因，再有就是他們的產品標準化做的真的不錯，實施廠商完全可以根據他們的培訓去幫他們實施，所以很多國外企業在中國的人並不多，但是掙錢反而不少，一度有個說法“中國IT在為海外做嫁衣”，這也是其中體現之一。不管怎麼說，人家的大系統是有它們自身的特點和優勢的，所以誰能取其精華，誰就能得到益處。

    所謂大的系統，到底大在哪呢，一是代碼量肯定不小，再有就是適應性肯定比較強，有些是行業性的，有些甚至是跨行業的，要做到適應性強，那麼系統中的考慮就必須很周到，考慮很周到，系統就會變得越來越龐大。

    我所說的向他們學習，並不是我們一定要做那麼大，作為我們的能力來講，必須現實的考慮問題。但是在這些系統中，確實存在很多標準的東西，如訂單管理，進銷存管理，到底他們是怎麼做的，可以看一下，國外在這方面行業內都比較規範，軟體實現的也比較規範，而且都是在國外經過多年考驗後進入中國的，這時向他們學習一下，能省我們很多事情，當然要考慮怎麼樣去做有中國特色的軟體了，這個另說。

    當你去實施一些產品的時候，你會發現除了業務的考慮外，在技術上，同樣也有一些讓我們興奮的亮點。為了實現一個功能，條條大路通羅馬，我們有我們自己的方式，他們有他們的方式，多向他們學習一下。在資料庫方面，因為基本都不存在什麼加密和編譯的說法，所以很容易知道他們是怎麼樣做的，可以很快學會，將來即便不用它們的產品，把設計思路用在大家自己的產品中，也是個很不錯的選擇，何樂而不為呢。

    取其精華，去其糟粕，讓我們放下架子，盡情去學吧(注意合法性噢)！

8.學會說話

    從我們剛開始學寫程式那天起，就被告之，有什麼機器語言，組合語言，程式語言之類的，具體我也分不清，反正就是覺得機器語言就是給機器看的，組合語言的可讀性稍強，後期的第三代，甚至第四代語言的可讀性更強。

    但是這幾代語言，我覺得都可以算做機器語言，即機器都能很好的認識，當然他們是照著你說的去做了，如果你說對了，他們就能做的對，如果你說錯了，他們就會做錯，你必須用 if else 之類的機器能夠識別的代碼去告訴他們，如果你想用“如果你餓了就去吃飯”告訴它，它恐怕是聽不懂的（E語言例外），在這種情況下，造就了一批優秀的程式員，這些程式員整天和機器對話，和機器打交道，有些甚至和人類的交流都少了，所以有些小MM曾說，嫁人不能嫁給程式員，還有人說，電腦就是程式員的情人。

    現在來說人類語言：這是專門用於和人類溝通的，如果機器語言被認為是“數字藝術”，那麼人類語言可以說為“模糊藝術”，兩種語言看起來並沒有直接的關係，一般人看不懂機器語言，一般的機器看不懂人類語言，但是對於我們程式員來說，我們是比較特別的一個群體，我們既懂機器語言，又會人類語言，我們所做的工作就是把人類的語言轉成機器語言，讓機器能明白人類想做什麼，從而去正確的實現人類的想法。

    以上說了兩種語言的關係，從而我想說一下什麼是好的程式員。好的程式員必須熟練使用兩種語言，不一定精通，但是絕對不能偏腿，散文寫的特美，但是不會寫程式，不行！代碼品質非常高，但是不會表達？不行！前者一般比較認同，但是後者也是很重要的。現在的時代一直在變化，現在都是合作開發，我們寫的代碼，需要其它相關的人員來看懂，並且有專門的人員來保證你代碼的品質。暫且不說別人，對於自己來說，一個沒有注釋的代碼，過一段時間後，有時真的看不懂了，我想很多人會有這種經曆（強人除外）。除了程式的注釋是人類語言外，就是專門的文檔，我以前對文檔就是深惡痛絕的，我一向認為文檔只是給別人看的，自己不需要，直到有一次，需要修改兩年前的一段程式，才覺得沒有文檔真是痛苦。在中國做項目，很多代碼再被其他人接手的時候，接手人都認為自己重寫一次比修改更高效，如此反覆大家都在重複做一件事情，所以很難搞出像樣的產品來。

    回過頭來再看一下國外的大公司，比如MS，Oracle，看看他們的MSDN,OracleDocument，都幾個G的文檔，雖然大部分文檔開篇處都有不少費話,但是這已經成為他們的一種規範，一種文化，對於初次使用者來說，想查什麼資料都可以查到，對公司內部，肯定也起到很好的作用。

    說了半天，我就是覺得人類語言很重要，我們不能只為了學習機器語言而忽略了我們的母語。齊頭並進吧，這樣會有更大的成績！

9.大局為重

    在之前的若干年中，我做了不少的開發，大部分都是單打獨鬥，都是自己從設計到開發一人完成（小項目），只是最近，在公司內部進行開發工作，成立了一個小的團隊，但是因為人手有限，除了做專案管理外，還要兼顧開發工作，整的頭暈腦帳。因為一直是個人戰鬥，所以對團隊開發並不太熟悉，所以組建團隊初始，建立了公用的VSS，認為這樣就是合作開發了，哈。不過同事們都不太買賬，我規定的每天簽入，也很難實現，所以在最後合并的時候都有不小的麻煩。剛才還和項目組開會，也討論了怎麼樣進行有效團隊開發，人雖然不多，但是意見都不統一，我這種老傳統的，就認為以企業需求為主要原則，指哪打哪，因為我認為設計都是為了業務提供服務的，但是一些同事就認為，凡事必須從頭到尾進行規範的設計，一步步的來，公司給我的工期只有一個月，要按規範根本做不完，他們就說要變成兩個半月，其中拿出足夠的時間來做設計。其實我以前也一樣，一直認為技術是最重要的，後來慢慢的在工作中，轉變自己的觀點，慢慢的接受業務為主，特別我們甲方，一般來說並不是在做產品，就是很明顯的在做項目,而且只是為自己公司使用的，必須聽從公司的大方向安排。

    說了半天，除了團隊管理以外，也涉及到對開發的一個思路問題。有些人認為現在有很多流行的工具，流行的就想都能引入到項目裡來，這樣可以提高這個，提高那個的，當然都有道理，但是如果想控制整個項目的全域，必須在這上面做些讓步，我也是做技術的，也喜歡一些新的技術，但是真的沒辦法，也希望做技術的朋友都能以全域為重，這樣可以盡量“造就”“成功”的應用系統吧。