職場10年之如何成為一名合格的程式設計師(上)

    合格在這裡如何定義呢？起碼來說，我這裡所說的合格並不代表“優秀”，因為如果我用優秀來做標題的話，那就表示成為一名沒有“瑕疵”的程式設計師了，首先我不是那樣的人，所以我也不能給出任何建議。所以我給“合格”下的定義就是：能滿足企業需要，能有比較好的心態，能以大局為重，能夠與團隊進行合作，能夠開發出符合需要的產品，這些就夠了。從這裡可以看出，我並不是一個完美主義者，實際上可以說是現實主義者，只是聽起來我的做法有些中庸。
    在給合格下了一個定義後，如果能同意我的觀點，可以看一下以下幾種幫助您達到這種“境界”的方法，如果不喜歡我的觀點，歡迎砸磚(zrsoftcn@yahoo.com.cn)。
    本文雖然不包括一行程式碼，但是都是寫程式碼多年的一些體會，值得一讀。
    1.興致盎然
    寫程式和其它事情一樣，最好是帶著興趣去做，不要太勉強，人的興趣點都是不同的，如果僅把它當做吃飯的一個工具，那可能做著會很累，比如我做開發這麼多年，除了覺得有些累外，對開發的興趣是一直沒有減的，一直關注新的技術，一直不斷的對它們進行嘗試，要能做到這一點，必須有興趣在後面做支援。
    如何做到有興趣呢？首先就是要知道程式是幹什麼的，我用它們能做什麼，又能為其他人帶來什麼好處。早在上大學的時候，老家的一個朋友在我回家的時候問我，你們都學什麼呀，我提了計算機，寫程式之類的，他就問，寫程式能做什麼呀，我就開始努力想，想到了什麼呢，可以計算1+1=2，可以算老母牛生多少小牛兒，可以做什麼漢諾塔之類的，可程式除了這些又有什麼用呢，當時真把我問住了，我不知寫程式到底有什麼用。那就是我在上學時對程式的理解。
    後來好多了，在校期間幫人家寫軟體，有些還很有實用價值的，再後來就更多了，走上了工作崗位，天天都在寫程式，也知道程式可以控制太空梭啊，衛星上天啊，什麼都能做。當然這些範圍太大，不是我們處理的範圍，簡單一些，可以做財務電算化，可以做ERP，可以做小遊戲等，可以處理很多事情。
    程式設計師學會了寫程式做什麼呢，我覺得除了應用於工作外，還可以在自己生活中體現一下自己的專長，比如在家中，已經是爸爸的人了，就可以給孩子寫一些小軟體，幫他學習啊，幫他遊戲啊，很有意思的，有時並花不了太多的精力，但是能收到不錯的效果。當然也不能指望你的作品的生命週期有多長，因為孩子的心思是會很快變換的。
總之，我個人認為，寫程式要帶著興趣去寫，要把心思鑽進去，那裡面是別有洞天的。也許我們那時候還早，和現在不一樣，現在我看到很多小程式設計師同志們，寫程式純是為了一份工作，並看不出來太多的興趣在裡面，全部是為了寫程式而寫程式，這樣就造成心態不是很好，責任心也會有所不同。當然，生活最重要。
    2.完美主義
    任何一個稍大一點兒的系統一般都會經過什麼設計呀，開發呀，測試呀之類的流程，而且一般的系統這些角色都是分開的，設計人員先設計一個XXX，開發人員會去做一個YYY出來給測試人員測試。設計人員一般應該懂得開發，這樣保證他們設計的是能被實現的，如果設計人員是從空中降落下來的神仙，那麼有可能開發人員看不懂他們的天書。儘管設計的很完美，但是如果無法實現的話，就等於零了。
    我以前有個同事，他本身就是做技術的，技術做的相當牛，牛的不能再牛了，我們全體都很佩服他，在我們公司，任何解決不了的問題，只要找到他，一般都可以搞定。後來我們做一個專案，也用到分層次的概念，他負責做業務層的設計，當時覺得他設計的就特別好，好的不能再好了，好的可以成為一個專門的產品了，因為他開始自己設計指令碼解析器，就像VBScript那樣，但是語法是他自己創造的，和ASP類似，但是又不完全一樣，展現層必須按他的語法去寫程式，然後他的中間層負責解析。一開始，加了一些 for/while if else之類的語法，後來發現還有其它的語法需要處理，因為不加上這些，就不能實現所有的業務，於是一直新增新增再新增，一直到有一天，他忽然發現，呀，要是我用ASP的話，這些我都不用處理了！於是最後改用asp.net來開發，前期設計及開發全部不用了。這就是追求完美的一個體現。
    在中國，很多小軟體企業一般都是拿到了專案就做，專案做完了就關門兒，和微軟等財大氣粗的企業不一樣，我們沒有足夠的經費去做研究，如果我們一直追求完美，可能會影響整個公司的生命。儘管我也覺得對於一個民族來講，這種研究很有必要，但是讓我們先生存下來再說後話吧。
    3.可配置性
    程式對使用者來說，只要能執行，只要能有結果，並且結果正確，所佔用的時間他們能接受，一般都被認為是過關的，在驗收的時候一般難度不會太大。但是考慮他們在運營過程中，可能會隨著業務的調整，對程式提出一定的修改意見，這時，對程式就有了一定的考驗，你的程式是否可以很快的適應業務的變化呢，為了這個業務變化，程式要做哪些調整呢？可能有以下幾種可能性：
         程式已經無法修改，全部扔掉重新開發一套
         找到開發人員，對部分業務變更在程式上加以實現，重新編譯，重新發布
         對程式配置進行調整，不需要編譯程式，即可直接使用
    在程式設計比較“簡單”的情況下，可能對業務使用者的需求變更方向並不太確定，所以會出現第一種情況和第二種情況，當然有時也是業務提出者的需求不明確造成的，有時他們會很明確的說“就這麼多，不可能再修改了”，但是後期他們一般不會認賬的。前面兩種情況無法離開程式開發人員，所以在實際運營過程中，有可能造成系統的延誤，甚至更可怕的後果。
    第三種情況，對應用系統更加“禮貌”，業務部門的工作人員，可以在經過適當的培訓後，自己對配置加以調整，完全適應新的需求。
    舉個例子，做一個資料同步的小程式，需要從一個庫中匯出資料，放入另一個庫中，源資料庫可能是Access，FoxBase，目標資料庫可能是MSSQL，Oracle，資料庫的欄位也有可能一直在變，這時就要考慮配置的靈活性，儘可能考慮全面一些，能寫在配置檔案裡的，不要寫在程式碼中。我身處甲方公司，曾經有些公司給我們開發軟體，我一再告訴他要做配置，可就是不聽，造成後面比較麻煩的局面。
    配置可以有多種方式來支援，我記得我最早用VB的時候，好像習慣用INI檔案，因為MS有專門的API來讀寫INI，效率非常高；後來又都開始搞XML，好像INI就不太流行了，大家紛紛開始解析XML去了，聽說那東西的效率比INI那種方式要低一些，不過其實也無所謂，一般都是系統載入的時候讀出來就OK了。還有一種方式就是把配置資訊儲存在資料庫中，資料庫有一些優勢，當然和XML具體哪個好，我覺得並不重要，根據個人喜好和實際情況就可以，比如儲存資料庫連線資訊，此時還沒有連線到資料庫，當然要寫在XML等外部檔案中了。
    配置檔案也有一定的安全性要求，一般在配置檔案，會儲存一些密碼，如果用明文儲存，有可能會造成一定的隱患，我一般是用雙向加密演算法，用的時候自己再解開，演算法並不一定要很嚴格，差不多就行了，因為我們做的系統也沒什麼太保密可言。但是我看過一些比較大的系統，如OracleEBS，他們的配置檔案，就直接儲存明文密碼，並不做加密處理，反正他們也知道，誰能找到這個配置檔案已經相當不容易了，隱藏的非常深。總之，我覺得在程式設計初期就考慮一下配置的靈活性，對後期的維護會非常有好處。
    另外關於O/R Mapping，在開發簡單的和專用的程式的時候，很多問題都是不需要考慮的，這種程式的設計，是相對“規範”的，只要能滿足當前的環境，100年可能不需要調整，對於這種案例，我覺得就沒有必要設計的太複雜，能用就行了。但是對於大部分案例來說，特別你想做產品化的時候，必須要考慮的事情就會多起來。比如我們做一個會員系統，會員會有很多的屬性，如“會員號”，“密碼”，“姓名”，這幾個可能是常用的，然後當你的系統推廣到不同的公司甚至不同的行業的時候，你會發現，同樣是會員管理，他們所提出的要求也不是完全一樣的，有些要生日，有些要身份證，有些還要老婆孩子的資訊。這時就涉及到資料庫裡的儲存欄位和你的程式是如何對應的，也就是所謂的O/R Mapping，我還是以C#為例吧，我聽說JAVA界有很多這方面做的相當不錯的框架，我沒有資格去評論。對於這種O/R Mapping的實現，我認為有兩種方式：
         用類的屬性去實現物件與資料庫欄位的一一對應
         實現更靈活的對應
    對於第一種方式，無論資料庫增加了什麼欄位，就需要馬上修改相應的程式，在類中新增新的屬性，實現與資料庫一一對應，這種方式比較麻，它涉及到程式碼的重新編譯與釋出，但是聽說現在有些程式碼生成的比較好的工具和方式，可以快速的實現這一點。但是我還是覺得有些麻煩。這種方式的好處很顯然，對客戶感覺比較“禮貌”，他們使用的系統，完全是給他們定製的，他們看到的，正是他們需要的，一般二次開發的時候，出錯的機率都會下降。也就是把難度留給開發商，把好處留給客戶，只要客戶日後不做修改，還是不錯的方式。
    第二種方式，也是我常用的一種方式，在類中，設定一個通用的Properties屬性，在系統讀取的過程中，把所有和使用者屬性相關的欄位全部讀入這個大的集合中，它是一個hashtable，然後使用的時候，只要按Properties["NAME"]這樣的方式即可，可以看出，無論客戶化如何實現，這種方式都不需要改變程式碼即可實現。
    以上的Mapping資訊，具體是儲存在XML中或資料庫中，並不太重要，重要的是實現這個思路就行了。
    4.國際應用
    目前大部分開發可能都是在中國本地執行，但是也少不了有些是需要考慮國際化的。
    在N年前，做國際化聽說是很煩人的，那時我反正不需要考慮這種事，後來好像Unicode，UTF8等編碼，解決了這個問題。現在VS2010裡新增Item，都直接儲存為UTF8格式，在VS2003裡，還是GB2312格式吧，反正不行的話，自己轉存一下就可以了。
    對於多語言程式的檢測，最好能在當地語言的作業系統裡安裝測試，僅在中文或英文環境下測試，理論上沒什麼問題，但是有些時候可能還是存在偏差的。 最早用C++開發程式的時候，應該是有個什麼資原始檔，把所有的字串都放入那個地方，所以很多做漢化的，直接把那個檔案翻譯一下就可以了。
    我也看過有些公司做PHP的，做多語言也是用資源包，到時把它搞一下，重新編譯一下就行了，我不確定是不是所有的大公司都用這種語言包的形式來實現多語言，不過肯定有他的好的地方和優勢。
    採用語言包的形式，要求所有的語言資訊必須下載到客戶端，由客戶端來解析，如果語言包需要做任何更新，那麼客戶端必須每次更新下載，這種方式的特點是速度快，一次下載，終身離線，但是，如果我們開發的系統並不是太健康，需要頻繁更新，就會比較麻煩了。
    我經常採用的是另一種方式，即所有的語言翻譯資料全放在伺服器上，一般是儲存在資料庫中，客戶端聯機後，從資料庫中先讀取語言包資訊，直接在記憶體中使用，不需要下載到本地，這樣保證不會因為下載錯誤而造成資訊不準確。有人覺得每次下載太浪費時間，其實想一下，一般的系統，能夠儲10K的語言資料，已經很大了(因為我的系統也不大，一般是選單及按鍵等簡單的文字)。這點頻寬，在聯機一瞬間可以完成。
    為了適應多國語言，我在系統裡建立了語言列表，表示所支援的語種，客戶端或IE裡，可以去選擇。
    在資料庫儲存方面，有這樣一個例子，比如產品：有中文名和英文名，有些公司做的系統就是加兩個欄位，分別儲存中文和英文，後來又要繁體中文，就再加一個欄位，我說我們需要全球N多個語言的支援，你怎麼辦呢，確實，這種情況下就不行了，雙語不等於多語言支援。對於多語言支援，應該在“資料行”上想辦法，而不是“資料列”，也    就是分別儲存多條記錄，這樣根據語言去取相應的記錄就可以了。
    對於多語言，我相信大家各有個的高招，只要適用自己的專案就算過關了。

未完
我是Aicken(李鳴) 請關注我的下一篇文章