其他

今天想在這裡發上幾句牢騷。首先是關於部門內部的知識分享計劃，這是在部門內部開展的一項分享知識和經驗的活動，到現在為止，已經陸續開展了三個月，然而，就在這個月，卻出現了問題，在前三次都結束之後，第四次無人接手來做知識的分享了。大家的理由都很充分，工作忙，時間不夠，準備不充分，等等。其實，反思一下，還是自己做的那次關於分享的介紹沒有得到大家的理解和認可，沒有體會到到底通過分享能夠得到什麼東西，也不清楚到底應該怎麼分享，才能夠得到大家良好的響應，而且也沒有把相關的技巧介紹清楚，這樣就導致大家還是不希望

在從事軟體開發的這些年中，近期越來越多地聽到這樣的論點：當前的程式員越來越浮躁。我的感覺也是如此，由於在軟體公司中，人才流動特別快，因此很多人的職位也變化的比較快，很可能剛剛工作了三年的程式員，就被冠以專案經理的職位，或者是做過幾個項目的人，就成為一家小公司的技術總監、架構師，其實，本身的能力與這個職位真正的要求非常不相配。然而，正是這樣的情況更促使了程式員的浮躁心理，或許也可是說是攀比的心態和虛榮心在作怪。上述情況的直接表現就是，很多程式員在具備了一定的經驗之後，就不喜歡做“小事”，這裡的小事

在系統開發的過程中，如何從客戶那裡擷取正確、有效需求，是每個團隊都需要仔細考慮的問題。如果最初的需求沒有明確，就開始著手開發，到最後可能會有很多東西需要修改，浪費大量的時間、精力和金錢。這件事說起來很容易，但實際做起來的時候，總會遇到各種各樣的阻力，似乎在每個項目中都一樣。所以，有很多人喜歡憑藉之前類似項目的經驗，或者自己對於業務的理解來做需求分析，要牽著客戶的鼻子有，甚至於替客戶決定如何來做系統。但是，這往往會導致客戶抱怨：你們做的系統不是我想要的，根本就不好用！其根本的原因就在於：我們不是客

日前，在InfoQ中文站上翻譯了一篇名為《與客戶“調情”》的文章，其中的觀點和技巧很是值得我們學習。看到這個標題，很多人會覺得比較奇怪，還要與客戶調情，是不是下一步就要與其發生什麼不正常的，比較曖昧的關係呢？哈哈，並非如此，該文的目的是想告訴我們，和客戶直接建立很好的聯絡有多重要，並且有什麼技巧能夠建立起這種良好的關係。作為程式員，其實我們尤其需要這種技巧，特別是在國內的開發環境中，很多情況下，程式員面對的都是最終的使用者，而且就算你現在只是在從事編碼工作，那麼隨著職業生涯的發展，有一天也可能會

平日裡很少看電視連續劇，因為一連續起來就沒完沒了。但是也有例外的情況，比方說國內的《亮劍》，八路軍又是步槍射擊，又是手榴彈攻勢，最後刺刀見紅，讓人很是激情澎湃。還有就是美國的《反恐24小時》，為了看小強jack的精彩表演，甚至可以忍受一年24集，每周一集的煎熬和折磨。小強同志真的是十八般武器，樣樣精通，一會兒用手 槍，一會兒用沖 鋒 槍，還有小手 雷，冷冷的匕

上周寫了兩篇《程式員應知》，得到了大家很好的響應，也非常高興地在這裡與大家展開豐富的討論，得益良多，越是這樣，越是覺得有些話應該對大家說，呵呵。其實，這些文章是讀後感之類的文章，也是“站在巨人肩膀上”的文章，也就是說，我是在看了一系列的書和文章之後，根據其中的內容，加上自己的理解，再根據自己在實際工作中的經曆，總結出來的東西。雖然很多詞彙對於大家來說是比較新的，但並非是我發明的，早已經有人提出過這種觀點，我也只是在學習，呵呵。但不管怎樣，我會繼續讀書、讀文章，也會繼續寫這個系列的文章，希望可以寫

日前，在InfoQ上發布了一篇名為《完成宣言》的新聞，其中探討了什麼樣的代碼才可以算是“完成”了的代碼。文中列出了一些標準，大家可以在這裡查看相關的內容。對於此，我不由地開始反思自己曾經做過的代碼，自己是否真的完成了所有的代碼呢？自己的代碼是否已經滿足了一定的標準，真的可以提交給使用者使用了呢？其實，現在回顧這些問題有些亡羊補牢的意味，每個人在提交自己的代碼之前都應該先問自己一聲，這份代碼真的完成了嗎？文中主要是從代碼的各種特性來界定代碼是否完成的標準的：1、代碼的可用性和易用性2、可維護性和規

我們經常會聽到這樣一句話——簡單就是美，或者是這句話的各種變體，而且這句話不限於行業，不僅僅是在軟體業，在各種涉及到設計藝術的領域，很多大師級的任務都會告訴我們，簡單就是美。在這裡我當然只想針對軟體開發相關的內容來談，其實我們要解決的問題就是——到底要多簡單呢？對於UI設計——不需培訓直接能使用還記得曾經看過的基本講述互動設計知識的幾本書，其中都提到了，最簡單也是最美的介面設計，就是使用者直接就明白怎麼用，而不需要長期的培訓，對於這一點我深以為然，並且努力把這一點貫徹到自己所做的系統中。曾經記得

    大家都知道，現在的軟體開發已經不再是20年前個人英雄主義的時代，一個超級程式員就能夠搞定一切的情況已經很少存在了。更多的情況是我們都是以團隊的形式進行系統的設計和開發，因此，團隊精神也變得越來越重要。  

二.

最近開始協助InfoQ翻譯一些文章，一方面可以強迫自己多閱讀一些英文的文章，另一方面也可以協助閱讀英文有困難的朋友們多瞭解國外的一些相關動態。下面是最近翻譯的三篇文章的連結，歡迎大家去訪問： Cisco為期一年的“Think Inside the Box”開發競賽揭曉Helios使用衛星核心處理異構環境國際軟體架構師協會宣布新的架構師認證方案

從Martin

好久沒有一個長期的計划了，最近越來越感到它的重要性了，所以就給自己打算一下吧。這個計劃主要是針對平時的技術部落格的，今天和一位朋友討論的時候，提出了三個方向：1、Oracle內建包2、軟體開發中哲學思想的應用3、架構CSLA.NET的介紹結果，朋友的喜歡正好是倒序，哈哈。儘管如此，還是想選擇一下，可能同時進行兩個吧，或者以其中兩個為主，另一個隨想隨寫，逐漸積累吧。也許又是一個艱苦的過程，不會比上半年翻譯書輕鬆吧，不過越是那樣，越是能夠得到很多，更希望的是與全國各地的程式員大家們交流，相信那對自己

前幾天曾經給部門內部做了一次交流會，在其中講述了關於代碼規範的一些原則，昨天忽然又想到了之前曾經看過的一本書《寫給大家看的設計書》，發現其中其實有些相通之處。那本書的目的是講述如何設計好的版面，也就是用來展示的作品，比方說橫幅、名片、邀請函以及書籍、雜誌等等，其中講述了四個基本的設計原則：親密性、對比、對齊和重複，在此我不想一一敘述其中的細節，感興趣的同學可以去查看原書，真的是一本不錯的書，看了之後，我自我感覺的改變就是，在看到一些頁面或者版面設計的時候，就能夠提出自己可能專業也可能不專業的意見

 今天編寫了一個Oracle的Package，分享給大家。背景是這樣的：現有的系統是從其他公司的系統移植過來的，因此有很多表都是對原來的那個公司定製的，而在移植過來之後，因為不適合業務的需求，所以就沒有使用，而長期以來也沒有人對其加以整理，因此造成系統中有很多冗餘的表，這對於系統的維護造成了很多不便，所以想要看看系統中到底哪些表是根本沒有使用的，對於這些表檢查出來之後，要做刪除。（當前系統中有2400多個表啊，初步估計其中大約有一半以上都是出於不使用的狀態）Package裡面的內容比較簡單，就是

作為程式員，不可避免地會經曆過下面的情況：你花費了大量心血辛辛苦苦地編寫了一本程式，結果到了測試人員那裡測試的時候，測試人員測了一陣子之後，提交給你一份測試報告，並說：“你裡面怎麼會有這麼低級的Bug。”或者說：“你的程式裡面的Bug好多，到底自己編寫完了之後測沒測試啊？”或者在國內項目中可能是這樣的，你將辛辛苦苦編寫好的程式拿給客戶試用，客戶用了一會兒之後，告訴你，“你做的東西根本就不是我想要的。”或者直接給你的反饋是“不對，能否做好了之後再給我啊？”上面的兩種情況都是作為程式員的我們不願意遇

今天偶然之間有感受到了Google的體貼之處，拿出來說說，呵呵。早上在張逸的部落格上面看到一段話：Δώστε μου ένα υπομόχλιο, και θα μετακινηθούν από τη

三、可測試性和健壯性首先向說說可測試性，而這其中先要交代的就是測試的方法。大家都知道，在一個系統的開發過程中，有很多測試環節，而這些測試環節與設計與開發環節又都是相互對應的，大概是這樣：單體測試----->詳細設計結合測試----->概要設計業務測試----->需求分析但是，在不同的開發環境中，所採用的測試方法也都是不一樣的。通常我們都會使用人工的測試方法，尤其是對於介面上的一些元素針對特定操作的反應，只有真正能夠得出想要的結果，那樣才能夠算是做好了這個功能。但即使是人工的測試

寫在前面：本來“程式員應知”系列中應該寫的都是與程式員密切相關的內容，而資料庫設計似乎應該是資料庫管理員的工作。然而，在實際的工作環境中，我所經曆幾乎所有的項目中，資料庫設計工作都是由程式員來完成的；就算我們是不需要做資料庫設計的程式員，也至少需要對資料庫的結構有充分的理解，那樣也便於我們編寫和維護系統。思量再三，我還是將這篇與資料庫設計相關的文章放在了這個系列當中。在幾乎所有的企業級應用程式中，包括各種MIS、ERP、CRM等等，都會使用資料庫，這樣的好處是顯而易見的，很容易地實現了資料層和商

四.