?

聲明：

Technorati 標(biāo)記: IT生活

本文檔來自：http://developer.51cto.com/art/201203/321936.htm

宅男程序員給老婆的計(jì)算機(jī)課程之0：認(rèn)清本質(zhì)

這個(gè)系列來自一位宅男程序員，這個(gè)系列是他寫給老婆的電腦課程。以下，開始本系列的第0篇——認(rèn)清本質(zhì)。只要掌握了編程的思想、數(shù)據(jù)結(jié)構(gòu)、算法，使用不同的語言去表達(dá)是很容易的。

【51CTO獨(dú)家特稿】從今天起將開始的這個(gè)系列來自一位宅男程序員，這個(gè)系列是他寫給老婆的電腦課程，后來經(jīng)他老婆的建議，決定在51CTO這個(gè)平臺(tái)上公開出來與大家分享。

在系列開始之前，先介紹一下兩位主人公——

男主角：Wuvist（新浪微博），真名翁偉，自稱胖程序員一個(gè)，幸好已婚。學(xué)習(xí).net出身，現(xiàn)常用python做服務(wù)器端開發(fā)，曾任新加坡某創(chuàng)業(yè)公司主程。公司被techcrunch blog過后，覺得新加坡生活太過安逸，終于于去年辭職只身回家鄉(xiāng)汕頭創(chuàng)業(yè)，活躍于珠三角技術(shù)沙龍，熱衷于與其他技術(shù)宅分享。

女主角：Katze，Wuvist的老婆，女程序員，在某跨國投行任Unix系統(tǒng)管理員，常被Wuvist嘲笑技術(shù)太差。

總之，因Wuvist只身回國創(chuàng)業(yè)，這對(duì)分隔天涯的技術(shù)宅男宅女竟然想出了定期寫技術(shù)課程、交作業(yè)這種方式來保持聯(lián)系，這何止是令人發(fā)指？簡直就是令人發(fā)指！

技術(shù)宅的你，想看看他們究竟是如何令人發(fā)指嗎？以下，開始本系列的第0篇——認(rèn)清本質(zhì)。

×××大學(xué)計(jì)算機(jī)系有兩門課：CS 1101 / 1102。

幾乎所有的大學(xué)計(jì)算機(jī)系課程都有兩門類似的課程；但幾乎所有的學(xué)生都誤解了這兩門課；以為前者是教C，后者是教Java；但實(shí)際上前者是 Programming Methodology 后者是 Data Structure and Algorithm。

所以這兩門課可以有選擇，1101c 或者 1101s，使用不同的語言作為媒介。語言并不重要。

只要掌握了編程的思想、數(shù)據(jù)結(jié)構(gòu)、算法，使用不同的語言去表達(dá)是很容易的。

會(huì)了很多種電腦語言后，學(xué)一門新的編程語言，幾乎只要花一個(gè)晚上看看官方的語法文檔就可以立刻開始使用做東西了。最多就一個(gè)星期。

基本上，那些說長時(shí)間說自己在學(xué)C#，學(xué)java的程序員，都是2B程序員，他們完全不懂得程序開發(fā)中“思想”、“數(shù)據(jù)結(jié)構(gòu)”、“算法”的本質(zhì)，而將大量的時(shí)間耗費(fèi)在語言實(shí)現(xiàn)的細(xì)枝末梢中，純粹浪費(fèi)自己時(shí)間。

不同的語言會(huì)有不同的特性，有一些特性是比較重要的，普遍存在于多種語言當(dāng)中的，“學(xué)習(xí)”一種新語言，實(shí)際上僅需要查看文檔，看這種語言是以怎樣的語法支持這些特性而已。

=========

OO是影響很廣的編程概念，基本上，是Enterprise Developer（注：企業(yè)級(jí)開發(fā)者）的圣經(jīng)、法則。

ED認(rèn)為，越OO越好。

基本上，計(jì)算機(jī)業(yè)界有兩批人，一批是真正的程序員，或者說hacker，一批就是ED。

ED實(shí)際上是企業(yè)的工具，他們很少有自己創(chuàng)新的想法；企業(yè)說啥米，就做啥米。所以，會(huì)有大量的vender，提供工具、支持、新技術(shù)，去train這些ED。

典型的vender有微軟、IBM、Oracle等等；這些vender為了向企業(yè)推銷產(chǎn)品，他們就經(jīng)常會(huì)鼓吹一些新的“技術(shù)”，然后打包成為解決方案，推銷給企業(yè)。

為了鼓吹、宣傳這些技術(shù)，還有一批企業(yè)是專門在“布道”的，他們是所謂的“咨詢公司”。

這樣的咨詢公司，他們會(huì)專門聘用一些所謂“Evangelist”，屁事不做，整天四處布道，名頭都很牛逼，如XX金牌講師。

他們實(shí)質(zhì)上，就是推銷員，只是，他們推銷的產(chǎn)品，是所謂的“新技術(shù)”而已。

微軟在新加坡好像就招了不少Evangelist 。每隔幾年，微軟所推廣的技術(shù)就會(huì)“革新”一次，Evangelist們就不斷的四處去宣傳新技術(shù)改變了一切，能夠提高效率無數(shù)倍。

Evangelist本身的技術(shù)，很多是很差的；就好像推銷員本身，是不會(huì)做產(chǎn)品開發(fā)、不懂技術(shù)的。他們僅僅是會(huì)宣傳、鼓吹新技術(shù)而已；滿口各種新技術(shù)名詞，但他們本身，可能僅僅只是會(huì)使用這些技術(shù)寫一個(gè)Hello World。

因?yàn)樗麄儽旧硭刭|(zhì)很差，所以，他們是無法分辨他們所推廣的技術(shù)本身是否好，他們只是復(fù)讀機(jī)。有時(shí)候，vender本身在推的技術(shù)也其實(shí)不錯(cuò)，但復(fù)讀機(jī)們也會(huì)把它夸張到荒謬的地步。

OO就是一個(gè)典型。

OO僅僅是無數(shù)編程模型中的一種而已，但它被過度的夸張，詮釋。

Hacker們寫程序，基本不會(huì)去追求程序本身是否符合OO規(guī)范。Hack這個(gè)詞的意義本身就在于打破規(guī)范。

但是，大多數(shù)的ED是很笨的，他們?nèi)狈Κ?dú)立思考的能力，他們需要被Train，而無法自學(xué)。Hacker的那套，他們接受不來。

所以，才會(huì)有vender / consultant / 培訓(xùn)學(xué)校一系列的產(chǎn)業(yè)，去鼓吹：

OO、XML、SOAP、Web Service、Silverlight等等一系列偽技術(shù)。

有的ED，一輩子都無法意識(shí)到他們實(shí)際上是中了vender的圈套；無法掌握真正的編程技術(shù)，而沉迷于vender們所鼓吹的“新技術(shù)”，一代接一代。

然后，只要有其中的一代技術(shù)ED沒能掌握，ED就立刻被淘汰了；因?yàn)檫@種ED，窮其一生都沒有學(xué)會(huì)真正的編程；他們僅僅是學(xué)會(huì)了一代又一代的被封裝的偽技術(shù)使用技巧而已。

偽技術(shù)的典型特征是封裝。

它本身沒有任何新的東西，只是把舊的技術(shù)封裝一下，換湯不換藥而已。

OO是最好的封裝技術(shù)；所以它被無底線的推崇。

封裝很重要；但是，對(duì)于程序員來說，掌握封裝技術(shù)本身，跟學(xué)習(xí)使用別人封裝好的技術(shù)工具；是兩回事。

“程序員從此不再需要關(guān)心XXX”，這是evangelist最常用的宣傳語句；2B ED，看了就很高興，然后拼命去學(xué)習(xí)新的“技術(shù)”，把他們?cè)?jīng)掌握的XXX底層技術(shù)給忘掉。

微軟所宣傳的理念被Hacker理解為“Even monkeys can code”。ED被evangelist鼓吹的新技術(shù)洗腦，最終就是成為monkey而已；所做的工作，毫無技術(shù)含量；很容易被淘汰。

所謂的程序員30歲必須轉(zhuǎn)行這種說法，便是源于ED被洗腦。

這種ED，從未掌握真正的編程技術(shù)，是必然被淘汰的。

=========

而這種ED，在大學(xué)時(shí)，就是把cs 1101 / 1102理解成為教 c / 教 java的那群人。

他們，從一開始就走錯(cuò)了。

=========

作業(yè)（編輯說明：在技術(shù)宅和他老婆的故事中，只有女主人公完成作業(yè)之后，男主人公才會(huì)發(fā)出新課程。當(dāng)然，身為看客的您可以無需完成這些作業(yè)，但如果您仍是學(xué)生，或者您正在帶學(xué)生或小弟的話，倒是可以做個(gè)參考）：

1. 用500字講述什么是Programming Methodology?

2. 列舉10種Data Structure.

3. 列舉10種Algorithm.

【作者聲明】Katze實(shí)際上是正宗計(jì)算機(jī)系科班出身，而且大學(xué)成績甩開Wuvist九條街，這其中還包括算法、計(jì)算機(jī)架構(gòu)等傳統(tǒng)上被技術(shù)宅男壟斷的科目。Katze畢業(yè)后長期于投行從事Unix服務(wù)器運(yùn)維工作，故研發(fā)編碼水平會(huì)被Wuvist嘲笑；但Wuvist不會(huì)寫shell腳本時(shí)，絕對(duì)是第一時(shí)間向Katze求助。

Wuvist寫的這系列教程以及作業(yè)安排，是為Katze量身定做的，像第1課的作業(yè)便因此會(huì)出現(xiàn)Perl這門研發(fā)中不常用，但在運(yùn)維中卻非常普遍的語言。這系列Wuvist是寫給老婆的私人課程，其中充滿了各種主觀偏見，有緣發(fā)布到51CTO來，各位看官若看得不爽，請(qǐng)盡管拋磚頭狠踩，但是請(qǐng)盡量噴得準(zhǔn)確、到位、兇狠一些～

宅男程序員給老婆的計(jì)算機(jī)課程之1：認(rèn)清實(shí)際

“算法”、“數(shù)據(jù)結(jié)構(gòu)”等，是本質(zhì)；很重要，需要掌握，但一般開發(fā)時(shí)，很少需要自己去實(shí)現(xiàn)。

覺得多數(shù)開發(fā)，是“拚積木”。

即便是業(yè)務(wù)邏輯需要對(duì)一些數(shù)據(jù)進(jìn)行排序，也不可能自己去實(shí)現(xiàn)一個(gè)quicksort算法；而是直接調(diào)用quicksort的現(xiàn)成類庫。

這也直接造成了2B ED窮其一生都不能掌握真正的編程能力。

他們認(rèn)為，能夠“解決”問題就好，至于問題是怎么解決的，他們并不關(guān)心。

對(duì)于細(xì)節(jié)的認(rèn)識(shí)、掌控能力，直接造成了水平的天淵之別。

以拍照為例子，以前人們用傻瓜相機(jī)，現(xiàn)在人們用iPhone去拍照；很快，很方便，還可以加濾鏡。

但是，普通人們?cè)诓涣私馐裁词枪馊Α⒕睢⒈彻獾雀拍畹那闆r下，是沒有可能成為攝影師的。

即便他們放下iPhone拿起DSLR。

普通人跟攝影師拍攝同樣的東西；出來的照片也許會(huì)差不多，但如果深入去比較，景深、角度、光線、取景等等等等細(xì)節(jié)，則都會(huì)有差別，而這些差別積累起來，就造成了普通照片與攝影作品的差別。

畫家要畫好畫，必然要對(duì)畫筆、顏料、紙張的特性有深入的了解。

廚師要做好菜，必然要了解食材的特性，對(duì)調(diào)味料、廚具等有嫻熟的掌控。

ED的“解決問題就好”，跟沒有下過廚房的千金×××拿著菜譜使用微波爐做菜沒啥區(qū)別。

在大廚手里，微波爐也可以是神器；但：

“有的人，縱然神刀在手，亦無法成為刀中之神。”

程序員要“拚好積木”，那必然需要對(duì)積木的種類、材質(zhì)、特性，有深入的了解。

總得對(duì)quicksort的實(shí)現(xiàn)有認(rèn)識(shí)，才能夠用好quicksort。在有的場景下，quicksort的性能反而是最差的。如果不了解，就無法去把quicksort用好。

程序開發(fā)中，有一個(gè)著名的 80 / 20 原則。

我想，這個(gè)原則也可以適用于ED。

程序員只要花20%的努力就可以成為一個(gè)混日子的ED；80%的程序員均是如此。

但如果要成為一個(gè)優(yōu)秀的程序員甚至hacker，那么，需要花多至少4倍的努力。

有什么積木可以用？積木本身是怎么做的？積木A比積木B好在哪里？

這些，是需要花大量的時(shí)間去了解。

全部都是實(shí)在的經(jīng)驗(yàn)積累，沒有捷徑。

都是.NET語言，C# 跟 VB.Net的差別在哪里？對(duì)于ED，他們偶爾也會(huì)對(duì)這樣的問題感興趣，然后，他們會(huì)去看介紹，看比較文章。。。。但其實(shí)，這事完全是木有用的。

他們看了別人的介紹，以為自己懂的，但實(shí)際上，他們只是在復(fù)讀而已，完全木有懂。

作為一個(gè)ED，要了解C#跟VB.Net的差別在哪里，最好的方式，就是花時(shí)間去把兩種語言都學(xué)了。用這兩種語言分別去寫個(gè)幾萬行程序，然后就懂了。

當(dāng)某天ED成為Hacker的時(shí)候，那就反倒可以去看各種介紹，看一眼，然后瞬間就可以悟了。

這也就是為什么很牛程序員學(xué)習(xí)新語言可以那么快，因?yàn)橛刑嗟闹R(shí)可以復(fù)用；而這些知識(shí)的積累，必然是需要通過在實(shí)際中，無數(shù)行的實(shí)際編碼，無數(shù)篇的資料閱讀中得來的。

沒有捷徑。

很多初學(xué)者，或者說，編程的偽愛好者，他們，會(huì)熱衷于去四處請(qǐng)教大師，下載各種經(jīng)典書籍，企圖讀一本編程圣經(jīng)，然后一夜脫胎換骨。

這是，不可能的。

這種偽愛好者，永遠(yuǎn)不可能成事；在學(xué)習(xí)的過程中，抱著去“走捷徑”的心態(tài)，本身就已經(jīng)是入了歧途；最終會(huì)花更多的時(shí)間。

原來Ruby / 現(xiàn)在 Python的一個(gè)光頭大牛Zed A. Shaw，為了表達(dá)“沒有捷徑”這樣的觀點(diǎn)，特意寫了本《Learn Python The Hard Way》：
http://learnpythonthehardway.org/

甚至有一個(gè)系列：http://learncodethehardway.org/

從長遠(yuǎn)來看：The Hard Way Is Easier。

我完全同意。

作業(yè)：

1. 列舉10個(gè)Python Web框架

2. Python有多少種不同的解釋器？

3. Perl 跟 Python 有什么不同？

宅男程序員給老婆的計(jì)算機(jī)課程之2:怎么看待牛人

請(qǐng)看這個(gè)帖子：
http://blog.csdn.net/hu_zhenghui/article/details/7184799

快速瀏覽即可，無需細(xì)讀；瀏覽過后再繼續(xù)往下看。

讀后的感覺是不是：

“雖然不知道在說什么，但是看起來很厲害的樣子！”

整篇文章的關(guān)鍵是在這句：

“作者胡某某。曾任完美時(shí)空（現(xiàn)更名為完美世界）顧問，承擔(dān)互聯(lián)網(wǎng)方面的部分管理工作。現(xiàn)在主要精力研究互聯(lián)網(wǎng)產(chǎn)品設(shè)計(jì)，是Axure授權(quán)的高級(jí)咨詢顧問和高級(jí)培訓(xùn)講師。”

這也就是，我在第一課中提到的“啥事不做，整天四處布道，名頭都很響亮，如XX金牌講師”，“Evangelist本身的技術(shù)，很多是很差的；就好像推銷員本身，是不會(huì)做產(chǎn)品開發(fā)、不懂技術(shù)的。他們僅僅是會(huì)宣傳、鼓吹新技術(shù)而已”。

碰巧今天看到這個(gè)非常有代表性的帖子；整個(gè)帖子看下來，作者毫無海量數(shù)據(jù)處理實(shí)際開發(fā)經(jīng)驗(yàn)，純粹堆砌這些流行技術(shù)名詞而已。他沒有用過這些技術(shù)，隨便亂丟技術(shù)名詞，整篇似是而非，必然的結(jié)果就是：“雖然不知道在說什么，但是看起來很厲害的樣子！”

學(xué)習(xí)技術(shù)的人，如果受了這種“看起來很厲害的樣子！”的蒙騙，會(huì)走很多很多彎路。

那么，如何識(shí)別“看起來很厲害”跟“真的很厲害”？

就好像，CSDN雖然有些忽悠人的文章，但也是有些好的文章在里面，如何辨別？

1. 看得多了，自然會(huì)分辨。

研發(fā)知識(shí)的最好來源之一是技術(shù)博客，就我自己而言，看了博客園自創(chuàng)辦伊始前5年的所有首頁文章；外加常年訂閱400+博客，twitter fo 400余人等。

我這么做，主要是因?yàn)榭吹每?#xff1b;沒有“看不過來”的問題；但實(shí)際上是個(gè)很笨的辦法。

要保持最新技術(shù)的了解，確實(shí)是需要看很多blog；除此之外，我想不出別的途徑；但這并非必要。

2. 看書

多看，最大的好處是了解最新技術(shù)，而且這是很土的方法。很多時(shí)候，并不需要了解很多“最新技術(shù)”；很多“最新技術(shù)”都是屬于第一課中所講的“封裝技術(shù)”，不了解，也完全沒有關(guān)系。

計(jì)算機(jī)的經(jīng)典好書并不多，好書是公認(rèn)、經(jīng)得起時(shí)間考驗(yàn)的。

看完這個(gè)豆列也就差不多了：
http://book.douban.com/doulist/995755/

完全可以不去理解“最新”的浮躁，去上面的豆列挑幾本看，仔細(xì)的看，就可以脫胎換骨了。

就我自己而言，對(duì)我技術(shù)影響最大的一本書倒不在上面豆列的20本書中，而是：
http://book.douban.com/subject/1467587/

經(jīng)典書，是必須看，并且反復(fù)看的；如果說有什么“捷徑”的話，看經(jīng)典書就是最快的捷徑了。

這些經(jīng)典書中的思想，是永遠(yuǎn)不會(huì)過時(shí)的；任何時(shí)候看，都不會(huì)太晚。

給ED看的書也有經(jīng)典：
http://book.douban.com/subject/1229954/

首先，這是本好書；而且這本500多頁書的傳奇在于它講了無數(shù)企業(yè)開發(fā)的模式，但其中的一頁半講述的：Active Record Pattern影響了過去5年多6年的Web開發(fā)潮流。

3. 寫代碼 + 看代碼

學(xué)習(xí)編程，是一定要去編程的。

書、資料再好，光看不練；也很容易把自己看成傻子。

在實(shí)際項(xiàng)目中寫代碼；然后看別人是怎么做的。

別人，指的往往是開源項(xiàng)目；而不是Google搜來的某個(gè)不知名博客中貼的代碼。哪個(gè)開源項(xiàng)目比較厲害，同樣是有目共睹的。

做Web開發(fā)，幾乎所有人都會(huì)去造ORM的輪子，沒事，就去造一個(gè)；然后比較自己的版本，跟優(yōu)秀的開源ORM在API風(fēng)格、架構(gòu)設(shè)計(jì)、實(shí)現(xiàn)細(xì)節(jié)上，有何不同。

作者給的作業(yè)：

1. 找出一篇看上去很厲害的文章。

2. 找一本書，開始看，作為期中考書目。

宅男程序員給老婆的計(jì)算機(jī)課程之3:架構(gòu)比較

本文作者：Wuvist

【51CTO獨(dú)家特稿】承接上文，12306的案例是蠻不錯(cuò)的題材；看過咨詢師“很厲害的樣子”，那么，究竟要如何做好 「海量事務(wù)高速處理系統(tǒng)」 這個(gè)方案？

“Hacker”提出了方案：

caoz，出自百度的超低調(diào)牛人：
http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html

云風(fēng)，原網(wǎng)易杭州研究中心總監(jiān)：
http://blog.codingnow.com/2012/01/ticket_queue.html

同樣的，也有另外一些“ED”在討論方案：

林仕鼎，百度首席架構(gòu)師，曾任微軟亞洲研究院研究員：
http://qing.weibo.com/2244218960/85c41050330009xm.html
http://weibo.com/2244218960/y0l4S7Y1d

白碩sse，上海證券交易所總工程師：
http://weibo.com/1922397344/y0jMo9IaD
http://weibo.com/1922397344/y0jP6jNRB
http://weibo.com/1922397344/y0jUy2rkf

且不論“Hacker”跟“ED”誰更加牛，從他們的解決問題的手法、角度上看就非常不同。

“Hacker”所追求的是解決問題，只要是問題被解決，怎么解決的無所謂；并發(fā)流量太大，系統(tǒng)處理不過來；caoz / 云風(fēng)兩種的方案，實(shí)質(zhì)上都是直接去處理源頭 - 避免并發(fā)。

caoz把高并發(fā)的請(qǐng)求直接分流去非主業(yè)務(wù)服務(wù)器，主業(yè)務(wù)服務(wù)器無需面臨高并發(fā)；云鳳則提出排隊(duì)系統(tǒng)，避免高并發(fā)的出現(xiàn)。

而林仕鼎、白碩則是正兒八經(jīng)的去討論在有這樣高并發(fā)的前提下，要怎么處理。

哥倫布的雞蛋。

能夠用手去扶住雞蛋，“Hacker”絕對(duì)不會(huì)猶豫；而“ED”則努力的去把雞蛋豎起來。

注意，牛“ED”未必就不懂得可以用手。

這樣“Hacker”精神，在云風(fēng)的blog上，還有另一個(gè)體現(xiàn)：屏蔽垃圾評(píng)論的驗(yàn)證碼。

博客有很多垃圾評(píng)論，需要屏蔽，有很多很多種方式，各種神奇的驗(yàn)證碼，葉貝斯規(guī)則過濾等等。

“ED”可以設(shè)計(jì)出來很多方案，并實(shí)現(xiàn)。

云風(fēng)腫么做呢？

他在評(píng)論發(fā)表的時(shí)候，增加了一個(gè)項(xiàng)目：為了驗(yàn)證您是人類，請(qǐng)將六加一的結(jié)果（阿拉伯?dāng)?shù)字七）填寫在下面

“只要能解決問題，就采用最簡單的設(shè)計(jì)。”

這個(gè)驗(yàn)證碼插件是我自己寫的，只有一行 perl 代碼。就是判斷輸入是不是 '7' 。

結(jié)果它很管用。從后臺(tái) log 看，攔截了幾萬條 spam 。”
http://blog.codingnow.com/2012/01/dev_note_7.html#comment-42161

注意，牛的“Hacker”未必就不懂得做出龐大架構(gòu)并實(shí)現(xiàn)。

“要如何做好「海量事務(wù)高速處理系統(tǒng)」這個(gè)方案”本身就可能是個(gè)偽命題，

「海量事務(wù)高速處理系統(tǒng)」這個(gè)需求本身可能根本就不存在。

作業(yè)：

1. 林仕鼎是百度首席架構(gòu)師嗎？

2. 看完caoz所有的blog。

宅男程序員給老婆的計(jì)算機(jī)課程之4:SQL vs NoSQL

本文作者：Wuvist

在幾乎所有的web應(yīng)用中，數(shù)據(jù)庫都是核心的一環(huán)。

Web應(yīng)用往往都是“Database driven”，業(yè)務(wù)、數(shù)據(jù)都是由數(shù)據(jù)庫完成，而前端頁面僅僅是演示、修改數(shù)據(jù)的一個(gè)“殼”。

因此很多web框架，都會(huì)標(biāo)榜自己能夠兼容多少多少數(shù)據(jù)庫，做CRUD多么多么容易。

一般上，提到數(shù)據(jù)庫的時(shí)候，指的都是關(guān)系型數(shù)據(jù)庫；但關(guān)系型數(shù)據(jù)庫并非唯一的一種數(shù)據(jù)庫類型。

關(guān)系型數(shù)據(jù)庫，一開始便是設(shè)計(jì)為通用，并有ACID支持的。

Atomicity 原子性、 Consistency 一致性、Isolation 隔絕性、Durability 持久性

殺手歐陽盆栽說：“每件事都有它的代價(jià)”。上述四個(gè)特性，都是有代價(jià)的。

對(duì)于嚴(yán)謹(jǐn)?shù)纳虡I(yè)應(yīng)用，如銀行、交易系統(tǒng)；為求業(yè)務(wù)的安全，他們不得不，或者說，能夠并且愿意付出這些代價(jià)。

回到12306，后端數(shù)據(jù)庫傳說使用的是Oracle，而站出來說吐槽12306的行家往往都會(huì)提到 redis \ mysql 這樣的替代。

有些菜鳥“ED”看到這些吐槽就出來噴了，說這些行家不懂神馬業(yè)務(wù)安全性的重要，這幫做互聯(lián)網(wǎng)的弱爆了，票務(wù)是必須使用 Oracle才能搞定云云。

好像還有人專門去噴了Fenng，這實(shí)在是太諷刺了。Fenng實(shí)際上是Orcale ACE Directorhttp://www.hudong.com/wiki/%E5%86%AF%E5%A4%A7%E8%BE%89，國內(nèi)屈指可數(shù)的Oracle專家。

很多人，特別是弱“ED”、“專家教授”，沉寂在自己所在的領(lǐng)域，然后就以為“悟”了；實(shí)際上，僅是把自己變成了井底之蛙。

知識(shí)的廣博、全面性非常重要。

在某個(gè)領(lǐng)域，通用的東西成熟之后，往往就會(huì)有專用的解決方案出現(xiàn)。而專用的解決方案多了之后，又會(huì)有新的通用解決方案出現(xiàn)。

天下大勢(shì)，分久必合，合久必分。

計(jì)算機(jī)，最早有很多專用系統(tǒng)，如王安打字機(jī)；個(gè)人電腦通用之后，這些專用設(shè)備就湮滅了；而iPad、手機(jī)的涌現(xiàn)，則又是專用系統(tǒng)。

是的，傳統(tǒng)上需要去購買 Orcale、DB2 等巨貴無比的數(shù)據(jù)庫系統(tǒng)，去滿足業(yè)務(wù)需求；不是因?yàn)樗鼈儼褑栴}解決到了極致，而是因?yàn)闆]有別的選擇。時(shí)代已經(jīng)變了，井底之蛙若把Oracle當(dāng)成是王道，那只能被時(shí)代淘汰。

關(guān)系型數(shù)據(jù)庫作為通用解決方案，是非常非常好的；它是一把神刀。

但是，它有以下問題：

===== ED總是要寫爛SQL ====

首先. 還是那句話，有的人縱然神刀在手，亦無法成為刀中之神。關(guān)系型數(shù)據(jù)庫提供的SQL能力，是高度抽象的，封裝了無數(shù)層的。寫SQL的人，太多太多根本不了解SQL背后所執(zhí)行的事情；爛“ED”都是如此。

這甚至造就了一個(gè)職業(yè)：DBA。DBA去負(fù)責(zé)數(shù)據(jù)庫微調(diào)、優(yōu)化，聽起來很高級(jí)，但實(shí)質(zhì)上，就是給濫用SQL的“ED”擦屁股而已。

對(duì)于龐大的企業(yè)來說，管理者是知道大部分ED都弱爆了，他不期望也不需要ED去了解數(shù)據(jù)庫，他只需要ED去完成最基本的業(yè)務(wù)功能，然后讓DBA去給ED擦屁股。

大部分的ED，并沒有意識(shí)到這一點(diǎn)；他們拼命去追求方便快捷的“搞定”；濫用SQL的各種高級(jí)功能；甚至，他們把分享SQL的復(fù)雜使用當(dāng)成是樂事。

ED所努力的，是把自己變笨，把活盡可能的都交給神奇的數(shù)據(jù)庫去解決；數(shù)據(jù)庫怎么解決的，他們不關(guān)心；這實(shí)質(zhì)上，是在削弱自己工作的技術(shù)含量，自我貶值而已。

工程師如果能夠把數(shù)據(jù)庫給用好了，哪里還有DBA什么事？

DBA所謂的數(shù)據(jù)庫優(yōu)化，往往就是把工程師不負(fù)責(zé)任寫下的2B SQL查詢找出來，然后改寫為文藝方式罷了。

不要濫用數(shù)據(jù)庫，一點(diǎn)都不難。

===== 通用數(shù)據(jù)庫性能有極限 =====

其次，關(guān)系型數(shù)據(jù)庫作為通用解決方案，它提供了太多的東西，它做了太多的事，而所有的事情，都有它的代價(jià)，直接而言，就是犧牲性能了。

所以，DBA的另一個(gè)職責(zé)，則是把數(shù)據(jù)庫的各種參數(shù)調(diào)配好，讓其能夠發(fā)揮最高的性能。

從這個(gè)意義上去說，DBA的工作就不僅僅是給ED擦屁股了。

但，這樣的微調(diào)，是有極限的。DBA拚了命去把雞蛋豎立起來，考慮了桌面摩擦、空氣流動(dòng)、手指顫抖等等因素，雞蛋雖然可以豎立一會(huì)，但終究還是會(huì)倒下去；這也就是微調(diào)的極限。

在某些場景下，是可以用手的：把業(yè)務(wù)中沒有用到的數(shù)據(jù)庫功能都去掉；甚至，去掉完整的ACID支持。

這樣一來，數(shù)據(jù)庫的性能就可以有數(shù)量級(jí)的改善了。

===== 關(guān)鍵在于靈活性 ====

最后，上面兩點(diǎn)，其實(shí)都是跟性能相關(guān)的；關(guān)系型數(shù)據(jù)庫即便作為通用方案，它的性能有極限，但也能夠滿足絕大多數(shù)應(yīng)用場景了。關(guān)系型數(shù)據(jù)庫的軟肋，是在靈活性上。

數(shù)據(jù)庫有表、而表有結(jié)構(gòu)；而表的結(jié)構(gòu)，在應(yīng)用上線之后，很難修改。

這同樣造就了一些專業(yè)學(xué)問：嚴(yán)密的業(yè)務(wù)分析、設(shè)計(jì)數(shù)據(jù)庫結(jié)構(gòu)、如何在數(shù)據(jù)庫上線之后修改結(jié)構(gòu)等等。

這些問題或者說學(xué)問之所以存在，是植根于關(guān)系型數(shù)據(jù)庫表結(jié)構(gòu)不靈活的前提之上。

再次”Think out of the box“，如果數(shù)據(jù)庫可以做到靈活、隨時(shí)修改的表結(jié)構(gòu)呢？

====== NoSQL ======

關(guān)系型數(shù)據(jù)庫的三個(gè)問題，被NoSQL全部解決了。

（同樣的，所有事情都有它的代價(jià)；NoSQL在解決SQL固有問題的同時(shí)，也引入了新的問題；另一方面，NoSQL解決的也不僅僅是SQL的這三個(gè)問題。）

ED要寫爛SQL？沒有關(guān)系，徹底不讓他們寫SQL好了。

數(shù)據(jù)庫支持功能太多？砍功能還不容易么？

Schema不靈活？那就schema-less好了。

目前，NoSQL的實(shí)現(xiàn)方案很多，MongoDB、Redis、Carssendra等等等等；每一個(gè)都可以非常不同，是專用解決方案：有自己獨(dú)有的特性，去解決特定場景的特定問題。

（當(dāng)然，像MongoDB，已經(jīng)很有NoSQL通用解決方案的意味了。）

普通程序員用SQL，文藝程序員用NoSQL，2B程序員把NoSQL當(dāng)SQL用。

普通程序員在從SQL切換去NoSQL時(shí)，會(huì)受固有的SQL知識(shí)限制，總有把NoSQL當(dāng)成SQL去用的沖動(dòng)，但這是非常2B的行為。

從微觀的角度講，原來SQL查詢中所支持的各種神奇joining / groupby都不見了；拼命的想要去找在NoSQL數(shù)據(jù)庫環(huán)境下同樣的神奇工具。

這徹底違背了使用NoSQL的初衷：為了就是不讓你濫用SQL的這些神奇功能。

濫用SQL會(huì)造成嚴(yán)重的性能問題，而在性能問題浮現(xiàn)之后，需要耗費(fèi)更大的力氣去糾正。

是的，信用卡透支購物很方便；但付賬單的時(shí)候就×××了；所以，換成無法透支的借記卡。

固然沒有了透支的便利，會(huì)有不方便，但徹底杜絕了還不起賬單，被收取高額利息的問題。

要透支的便利？ED，請(qǐng)先去掌握好理財(cái)技能，徹底了解透支的影響，然后我們?cè)賮碚劚憷?/p>

從宏觀的角度講，會(huì)有人企圖去給NoSQL做封裝，讓NoSQL表現(xiàn)得跟SQL一樣；甚至，去把NoSQL去掉的那些SQL功能加回去。

SQL已經(jīng)是一個(gè)非常非常成熟的方案，它所能夠解決的問題范疇里面，幾乎沒有辦法做得比SQL更好。

在NoSQL的基礎(chǔ)上，去試圖模擬SQL，只能成為SQL的蹩腳模擬；還不如直接用回SQL。

在網(wǎng)路編程里面也有類似的例子，TCP跟UDP。可以把SQL看成是TCP，它是可靠、神奇的。UDP雖然不可靠，但是會(huì)比TCP更快。要做視頻、語音通訊，UDP是更好的選擇。但要去做“不丟包、不失幀”的可靠視頻通訊，選擇在UDP的基礎(chǔ)上添加確認(rèn)、重發(fā)機(jī)制模擬TCP，那就是2B了。不是天才，沒法做得比TCP更好，直接用TCP就好。

作業(yè)：
1. NoSQL的方案，如MongoDB還解決了SQL的什么問題？

2. NoSQL的應(yīng)用場景有啥米？

宅男程序員給老婆的計(jì)算機(jī)課程之5:設(shè)計(jì)模式

設(shè)計(jì)模式，應(yīng)該是很多ED心目中牛B的編程方式。

上回說到ED的好書POEE，實(shí)際上便是一本專門講企業(yè)開發(fā)中使用的設(shè)計(jì)模式中的書。

設(shè)計(jì)模式，并不多，基本上看完GoF的這邊《Design Pattern》便可以有足夠了解了。

而實(shí)際開發(fā)中常用的設(shè)計(jì)模式更是屈指可數(shù)，Singleton，Factory，Facade，Active Record、Provider等等。

就那么幾個(gè)，花花功夫，仔細(xì)了解一下這幾個(gè)，然后在實(shí)際編碼中應(yīng)用一下，便可以算是掌握了。

設(shè)計(jì)模式，并不難。

它是開發(fā)中非常必要的知識(shí)，實(shí)際上，是非常基礎(chǔ)的知識(shí)，并不牛B。

開發(fā)的時(shí)候，需要時(shí)刻明確自己的目標(biāo)：解決問題。

解決問題才是最重要的。

設(shè)計(jì)模式的存在，是為了更好的維護(hù)、管理代碼，或者是為了擴(kuò)展性；絕對(duì)不可以為了設(shè)計(jì)模式而模式。

在Java程序中，為了模式而模式的現(xiàn)象蠻普遍的。

我猜想這是因?yàn)镴ava是一門工業(yè)語言，有大量的ED使用的緣故。

ED把設(shè)計(jì)模式的使用，當(dāng)成是一種可以炫耀的編程技巧，或者說，他們遵從的編碼規(guī)范中，要求他們?nèi)ナ褂媚衬吃O(shè)計(jì)模式。

至于為什么要使用設(shè)計(jì)模式，最常見的理由便是：為了將來可以XX，或者YY。

程序開發(fā)中，有一句名言：“Pre-mature optimization is the root of all evil”。

過早優(yōu)化，是萬惡之源。

非常多的情況下，將來預(yù)想中的XX或者YY；并不會(huì)發(fā)生。大部分代碼，寫了之后就會(huì)被丟棄掉，再也不會(huì)有人去維護(hù)。

當(dāng)XX或者YY發(fā)生的時(shí)候，往往，都是會(huì)推倒重來。

除非你很牛B，只有牛到一定程度，才有可能對(duì)將來可能發(fā)生的情況做好合理的預(yù)測，并預(yù)留出改善、調(diào)整的空間。

但非常諷刺的是，為將來做設(shè)計(jì)的最好方法就是：什么都不做。

只有空白，才能夠留下最大的發(fā)揮空間。

現(xiàn)在為將來可能發(fā)生的情況，做了編碼，任何一行編碼，都是很可能是在為將來添加限制、制造麻煩。

現(xiàn)在寫下去的代碼，將來，都是要被刪掉的；能夠不寫，就不寫。

在任何時(shí)候，都應(yīng)該保持代碼簡潔。

函數(shù)，盡可能的短；當(dāng)一個(gè)函數(shù)的長度，超過一個(gè)屏幕的時(shí)候，便應(yīng)該考慮重構(gòu)、拆分。

牛B的程序，都應(yīng)該是簡單、易懂的；采用大量的設(shè)計(jì)模式，復(fù)雜得讓人無法直接看懂，或許有它的意義以及應(yīng)用場景，但這絕對(duì)不是編程功力牛B的表現(xiàn)。

打個(gè)比方，設(shè)計(jì)模式就是武術(shù)招式。

學(xué)徒，必然需要熟悉什么“有風(fēng)來儀”或者“屁股朝后平沙落雁式”。

但更高的境界是：無招勝有招。

簡單、直接的把代碼搞定。

Python大牛沈崴有云：“得道的程序員，既不封裝，也沒有重復(fù)代碼。”
http://eishn.blog.163.com/blog/static/6523182010102342531684/

作業(yè)：

1. 使用一種編譯語言實(shí)現(xiàn) Singleton 模式

2. 使用一種動(dòng)態(tài)語言實(shí)現(xiàn) Singleton 模式

3. 說說對(duì) Provider 模式的理解。

宅男程序員給老婆的計(jì)算機(jī)課程之6:模版引擎

【51CTO獨(dú)家特稿】設(shè)計(jì)模式再“高級(jí)”一點(diǎn)，便是所謂的“框架”了。

從事Web開發(fā)，一般都會(huì)接觸到MVC框架這個(gè)概念。

M：也就是Model，直接跟網(wǎng)站數(shù)據(jù)庫相關(guān)。

V：也就是View，是網(wǎng)頁的模版，跟顯示數(shù)據(jù)相關(guān)。

C：則是Controller，相當(dāng)于網(wǎng)站的業(yè)務(wù)邏輯。

MVC也不僅僅是應(yīng)用于網(wǎng)站開發(fā)，它的概念實(shí)際上植根于桌面軟件，并且在手機(jī)軟件開發(fā)上也有應(yīng)用。

MVC本身是一個(gè)設(shè)計(jì)模式，是一個(gè)被驗(yàn)證過的，可以用來很好歸納、管理代碼的軟件開發(fā)方式。

基于這樣的設(shè)計(jì)模式，提供了很多相關(guān)的類庫實(shí)現(xiàn)，則“設(shè)計(jì)模式”升級(jí)為“框架”。

MVC的任何一個(gè)方面，擴(kuò)展出去講，都可以講上幾天幾夜。

今天只講V。

傳統(tǒng)的ASP / PHP網(wǎng)站開發(fā)，V是很混亂的。

默認(rèn)只有一種文件，html與業(yè)務(wù)邏輯代碼混雜在同一個(gè)文件；相當(dāng)難以維護(hù)。

ASP.NET相對(duì)于asp做出了很大改進(jìn)，提出了code-behine的概念：默認(rèn)將html的模版代碼，以及c#或者vb.net的邏輯代碼切分到兩個(gè)不同的文件。

這樣的方式算是有很大進(jìn)步。

微軟平臺(tái)上做開發(fā)是比較苦逼的，微軟掌控了整個(gè)開發(fā)平臺(tái)的前進(jìn)速度。

asp跟PHP在開始的時(shí)候，是相似的技術(shù)。有類似的便利，以及類似的麻煩。

微軟推出了.net，推廣了code-behind的模式；然后，所有的微軟程序員都超著微軟指定的這個(gè)方向去邁進(jìn)。

asp被拋棄了，自從ASP.NET誕生之后，就不再有任何改進(jìn)。

而PHP，在開源世界中，則不斷的得到各式各樣的改進(jìn)。

各種模版引擎層出不窮；不僅可以實(shí)現(xiàn)code-behind這樣簡單的模版、業(yè)務(wù)代碼分割；很多還直接引入了MVC的概念；實(shí)現(xiàn)了三層的分割。

而ASP.NET，則長期止步于web form的code-behind，在開源世界中的MVC方案大放光彩若干年后，才推出 ASP.NET MVC。

模版技術(shù)，最初的目的就是要把業(yè)務(wù)代碼，也就是說，把獲得數(shù)據(jù)的代碼跟html分割。

在模版實(shí)現(xiàn)上，因此涌現(xiàn)了不少不同的設(shè)計(jì)哲學(xué)。

Python的Django框架中的模版，是一種典型。

它徹底的禁止程序員在模版中嵌入任何代碼；模版中，只可以出現(xiàn)html；以及一些跟業(yè)務(wù)邏輯無關(guān)的控制標(biāo)簽，如：

1 {% If XXXX %} foo {% else %} bar {% end %}

條件XXXX，必須是一個(gè)數(shù)據(jù)值，不可以是一個(gè)復(fù)雜表達(dá)式、不可以包涵函數(shù)調(diào)用等等。

模版中，也不可以聲明任何新的變量，下面的做法是被禁止的：

2 {% set i = 0 %}

3 {% foreach item in items %}

4 {% i += 1%}

5 <div>

6 ` item `

7 {% if i mod 2 == 0 %}

8 <hr />

9 {% end %}

10

11 {% next %}

Django的模版，從技術(shù)上徹底禁止程序員添加任何邏輯，強(qiáng)迫程序員必須在controller中去寫各種邏輯，以確保模版內(nèi)容的純潔干凈。

所以Django的模版，一般都非常簡單，有很好的移植性，并且可以讓網(wǎng)頁設(shè)計(jì)人員直接編輯。

ASP.NET則是另一種典型；雖然有了code-behind，但是它沒有對(duì)前端代碼，以及后端代碼做任何限制。

在前端aspx頁面中，可以嵌入任意的邏輯代碼，而code-behind的code，為空白；這種偽“code-behind”的方式，跟原來的asp沒啥區(qū)別。

ASP.NET從框架本身，并不阻止程序員去做這樣的事情，實(shí)際上，它還標(biāo)榜它這樣的特性：方便原有的asp項(xiàng)目直接升級(jí)到.NET的平臺(tái)上。

也有另外一種奇葩的做法，前端aspx頁面保持空白，然后在code-behind的code中去拼接所有的html。這樣的方式，ASP.NET框架本身也不禁止。

只要ASP.NET程序員喜歡，沒有什么不可以的。

ASP.NET把對(duì)模版使用方式的選擇權(quán)留給了程序員，如果程序員自律，他們可以按Django模版那樣的方式去使用模版，并擁有Django一樣的優(yōu)點(diǎn)；如果程序員自律？！

在某些可以通過嵌入代碼去快速處理的場景，ASP.NET的模版也保留了程序員去hack的能力。

還有一些模版技術(shù)，則是折衷的（如tornado的模版）：允許嵌入單行代碼，如聲明變量，調(diào)用函數(shù)等等；但是不允許整塊、整塊的業(yè)務(wù)代碼出現(xiàn)模版中。

上述三種模版設(shè)計(jì)哲學(xué)，各有它們的道理，以及應(yīng)用場景。

需要根據(jù)具體的業(yè)務(wù)、應(yīng)用場景，才能說其中哪種比較合適。

開發(fā)人員的能力也是直接相關(guān)的，如果團(tuán)隊(duì)中，普遍不自律；缺乏將業(yè)務(wù)、模版代碼分割、以提高代碼可維護(hù)性的意識(shí)，那么Django的做法是最好的，它直接禁止去濫用模版，強(qiáng)迫他們?nèi)ナ褂酶玫拈_發(fā)風(fēng)格；即便在某些場景下會(huì)更麻煩。

武斷的認(rèn)為任何一種模版設(shè)計(jì)哲學(xué)是“最佳”的想法是極其膚淺的。

各種成熟的模版技術(shù)，一般也都會(huì)有包括以下特性：

1. 嵌入

也就是說，編寫各種可以復(fù)用的小模版塊，然后供多個(gè)不同地方調(diào)用；比方說，用戶頭像（甚至名片）的顯示。

具體頁面不需要重復(fù)編寫這些重復(fù)的模塊。

并且，這些模塊需要調(diào)整時(shí)，只需要修改一個(gè)地方，便可以在所有地方生效。

2. 繼承

能夠編寫一些基礎(chǔ)模版，定義常見的頁面結(jié)構(gòu)。

具體頁面繼承這些基礎(chǔ)模版，便不需要重復(fù)編寫那些結(jié)構(gòu)代碼。

同樣的，當(dāng)頁面結(jié)構(gòu)需要調(diào)整時(shí)，也是修改一處，所有生效。

3. i18n

網(wǎng)頁模版的國際化支持是一個(gè)模版引擎是否成熟的表現(xiàn)。

如果沒有，當(dāng)網(wǎng)站需要同時(shí)提供多種不同語言支持的時(shí)候，會(huì)很麻煩。

成熟的模版，都會(huì)提供內(nèi)置的支持。

因?yàn)榫W(wǎng)頁模版實(shí)現(xiàn)實(shí)在是太多了，大家功能也都差不多，那么性能，也就成為了相當(dāng)重要的比較指標(biāo)。

有的模版，能夠“編譯“，渲染起來快些。

一般可以簡單認(rèn)為，功能越多的模版，性能會(huì)約低。有的模版，甚至將i18n的支持變成可配置的，不需要的時(shí)候就可以關(guān)閉，以提高性能。

也有的模版認(rèn)為，寫 {% %} <%%> {{}} 這樣的符號(hào)太麻煩了，可以直接忽略，它可以自動(dòng)聰明的識(shí)別 html，以及模版控制代碼。簡單的說，就是以極其華麗的方式，去方面程序員少打幾個(gè)字符。

還有的模版，在實(shí)現(xiàn)嵌入功能的時(shí)候，還可以選擇所依賴的的css / js文件。

比方說，要顯示用戶的名片，需要引入 namecard.css；那么，可以在 namecard的模塊文件中指定這個(gè)依賴，然后模版渲染的時(shí)候，自動(dòng)把這個(gè)css的引用，放在html的頭部。

直接在模塊文件中寫 namecard.css 的引用是很傻的，因?yàn)槟K可以在模版中引用多次。重復(fù)引用同一個(gè)css文件是沒有道理的。

種種模版功能細(xì)節(jié)，實(shí)際上，都是可以在沒有模版支持的框架中去實(shí)現(xiàn)。

想想PHP，它本來是非常簡單的，默認(rèn)只能夠在同一個(gè)文件中混雜邏輯與代碼。

但一旦程序員有了追求，它也可以有模版實(shí)現(xiàn)。

模版不支持 i18n，程序員一般也是有辦法在現(xiàn)有模版實(shí)現(xiàn)中添加相應(yīng)的支持的。

并不復(fù)雜，關(guān)鍵是看程序員的態(tài)度；看程序員是否有把事情做得更好、更優(yōu)雅的態(tài)度。

一般情況下，程序員選擇去實(shí)現(xiàn)更多的模版功能的時(shí)候，必須先看看別人是怎么做的。比方說，如果完全不知道什么是gettext就去自行實(shí)現(xiàn)模版的 i18n 功能，是非常2B的。

絕大多數(shù)情況下，程序員面臨的問題，都不是自己獨(dú)有的，一定是別人已經(jīng)解決過的問題。

是否有足夠的見識(shí)，有足夠的知識(shí)廣度，了解別人的解決同樣問題的做法是程序員能力的表現(xiàn)。

是否有快速的搜索出類似的解決方案，也是能力的表現(xiàn)。

1. PHP的Smarty 模版的設(shè)計(jì)哲學(xué)是什么？

2. Perl的Mason 模版的設(shè)計(jì)哲學(xué)是什么？

3. 什么是gettext?

4. 前端Javascript實(shí)現(xiàn)的模版中，目前最成熟的是哪個(gè)引擎？

宅男程序員給老婆的計(jì)算機(jī)課程之7：運(yùn)維的重要性

【51CTO獨(dú)家特稿】先摘錄一段話勉勵(lì)一下生日寶：

截止2010月6月，Facebook接近2000雇員。10個(gè)月時(shí)間從1100人增長到2000，一年時(shí)間員工人數(shù)翻了一番！

最大的兩個(gè)團(tuán)隊(duì)是開發(fā)工程師和運(yùn)維，都是400-500人的規(guī)模

豬頭寶，在Facebook，運(yùn)維跟開發(fā)是一樣重要的。運(yùn)維才不是用vender提供的軟件，然后按manual去step by step的做事情。

有很多創(chuàng)造性的工作可以做。

豬寶你知道twitter是腫么更新服務(wù)器的么？

Twitter有幾千臺(tái)服務(wù)器，一旦網(wǎng)站要跟新，這幾千臺(tái)服務(wù)器上面的代碼部署都要更新。

腫么讓這幾千臺(tái)服務(wù)器快速的獲得新代碼呢？逐臺(tái)服務(wù)器下載太慢了，數(shù)千臺(tái)服務(wù)器同時(shí)向代碼中央服務(wù)器獲取新代碼又會(huì)把中央服務(wù)器的帶寬擠爆。

腫么辦？

Twitter的運(yùn)維工程師直接用了BT的協(xié)議，使用p2p下載來解決這個(gè)問題：
http://engineering.twitter.com/2010/07/murder-fast-datacenter-code-deploys.html

它們就這樣把部署的時(shí)間從原來的40分鐘大幅減少到只要12秒～～

運(yùn)維，很多時(shí)候都是要編寫腳本，把很多原本需要人手工做的事情通過腳本自動(dòng)化管理起來。

這些腳本乃至系統(tǒng)的編寫與開發(fā)，都是需要能力的。

運(yùn)維的投入，都是為了節(jié)約別人的時(shí)間；而時(shí)間節(jié)約、效率提高、穩(wěn)定性提高，這些都是有意義的。

之前豬寶去廣州參加技術(shù)沙龍，有一個(gè)人人網(wǎng)之類的運(yùn)維去講自己的工作木有意義，是“花×××的心，賺賣白菜的錢”；當(dāng)場就被金山的過程改進(jìn)經(jīng)理周琦 Zoom.Quiet給吐槽了。

說他的態(tài)度不對(duì)，運(yùn)維部門應(yīng)該是一個(gè)盈利的部門，而不應(yīng)該是一個(gè)被無視的部門；運(yùn)維，應(yīng)該是通過提高技術(shù)水平，提高效率，節(jié)約成本；以達(dá)到“賺錢”的目的。

caoz很推崇的一個(gè)技術(shù)牛人楊建；便是做運(yùn)維的，在新浪、騰訊呆過，現(xiàn)在應(yīng)該是被caoz收去4399了：http://blog.sina.com.cn/iyangjian

如果木有楊建這樣的運(yùn)維高手，新浪是木有可能支撐起一小時(shí)近20億實(shí)際http請(qǐng)求處理量的：http://blog.sina.com.cn/s/blog_466c66400100cfrj.html

Facebook的有9個(gè)級(jí)別的代碼發(fā)布流程：http://www.dbanotes.net/arch/facebook_how_facebook_ships_code.html 這些都是運(yùn)維的工程師牛B才有可能的；并且也確實(shí)解決了實(shí)際業(yè)務(wù)問題。

如果僅僅是做普通的SA，那么工作是很routine，很無聊，很沒有技術(shù)含量的；但是如果能夠提高，面臨的問題是完全不一樣的。

這跟爛ED與Hacker的區(qū)別也是一樣。

實(shí)際上，很多職業(yè)都是一樣；如果是做那底層的普通工作，都必然是無聊的，木有意義的。但一旦有進(jìn)步，層次提高，面臨的就是完全不一樣的環(huán)境。

有做文書工作，收集、整理資料的律師；也有Alan Shore。

工作是否有意義，在于職位的層次。

親親豬頭寶～

宅男程序員給老婆的計(jì)算機(jī)課程之8：控制器

設(shè)計(jì)模式再“高級(jí)”一點(diǎn)，便是所謂的“框架”了。

從事Web開發(fā)，一般都會(huì)接觸到MVC框架這個(gè)概念。

M：也就是Model，直接跟網(wǎng)站數(shù)據(jù)庫相關(guān)。

V：也就是View，是網(wǎng)頁的模版，跟顯示數(shù)據(jù)相關(guān)。

C：則是Controller，相當(dāng)于網(wǎng)站的業(yè)務(wù)邏輯。

MVC也不僅僅是應(yīng)用于網(wǎng)站開發(fā)，它的概念實(shí)際上植根于桌面軟件，并且在手機(jī)軟件開發(fā)上也有應(yīng)用。

MVC本身是一個(gè)設(shè)計(jì)模式，是一個(gè)被驗(yàn)證過的，可以用來很好歸納、管理代碼的軟件開發(fā)方式。

基于這樣的設(shè)計(jì)模式，提供了很多相關(guān)的類庫實(shí)現(xiàn)，則“設(shè)計(jì)模式”升級(jí)為“框架”。

MVC的任何一個(gè)方面，擴(kuò)展出去講，都可以講上幾天幾夜。

今天只講C。

傳統(tǒng)上，php / asp / asp.net web form等，使用的是所謂的 Page Controller Patterns:http://martinfowler.com/eaaCatalog/pageController.html

Page Controller簡單的說，便是一個(gè)網(wǎng)址對(duì)應(yīng)一個(gè)程序文件。

所以，我們會(huì)看到大量類似： show.php / show.asp / show.aspx 的網(wǎng)址存在，這樣的網(wǎng)址，背后都有相應(yīng)同名的文件。

這樣的模式，是網(wǎng)站從靜態(tài)轉(zhuǎn)向動(dòng)態(tài)是最自然的改變方便，也最為容易讓初學(xué)者接受。

但隨著網(wǎng)站的復(fù)雜化，這樣的模式會(huì)慢慢顯得不夠方便；比方說，多個(gè)不同的網(wǎng)址，映射到相同的處理；比方說，處理的時(shí)候，復(fù)用共同的資源。

頁面內(nèi)容的動(dòng)態(tài)化，同一個(gè)程序文件，顯示的內(nèi)容是動(dòng)態(tài)生成的 - 根據(jù)不同的query string，生成不同的內(nèi)容，如：show.php?id=1234

網(wǎng)頁程序內(nèi)部，實(shí)際上是需要解析網(wǎng)址中的query string，并做不同的操作。

這實(shí)際上是一個(gè)映射的過程，將網(wǎng)址映射到相應(yīng)的處理。

為了方便做這樣的映射，慢慢的出現(xiàn)了所謂的 Front Controller Patterns:
http://martinfowler.com/eaaCatalog/frontController.html

這是通過某種機(jī)制，將符合各種規(guī)則的網(wǎng)址請(qǐng)求映射到程序中的一個(gè)類，或者是一個(gè)函數(shù)處理。

一般上，是使用正則表達(dá)式解析網(wǎng)址，并映射。

將網(wǎng)址映射到一個(gè)類；

1 urls = ("/home", "hello")

2 app = web.application(urls, globals())

3

4 class hello:

5 def GET(self):

6 return'Hello, world!'

將網(wǎng)址請(qǐng)求映射到類，是相對(duì)較“重”的處理方式，比方說，需要處理類的初始化等等。

有的框架，也可以是一個(gè)函數(shù)，則相對(duì)“輕量”一些：

7 (r'^$', 'home'),

8

9 def home(request):

10 return HttpResponse("Hello, world.")

類、函數(shù)，均各有優(yōu)劣，但實(shí)際差異很小：

映射到類的方式，往往還會(huì)根據(jù)不同的HTTP header映射到類里面中相映的函數(shù)，比方說，將對(duì) /home 的HTTP GET請(qǐng)求映射給 hello 類的 GET 函數(shù)；而對(duì) /home 的 HTTP POST請(qǐng)求映射給 hello 類的POST函數(shù)。

這部分 url routing的設(shè)計(jì)與實(shí)現(xiàn)，各種語言、平臺(tái)上的功能均向正則表達(dá)式靠攏，大同小異。

有的可能專門為 restful 做了優(yōu)化，但即便木有，自行實(shí)現(xiàn)也并不復(fù)雜。

很多請(qǐng)求，都會(huì)有一些常用的默認(rèn)處理，比方說，檢查用戶是否登陸，檢查用戶是否有權(quán)限等等。

這些業(yè)務(wù)控制邏輯，是完全可以復(fù)用的。

在Page Controller的場景下，一般是通過繼承來實(shí)現(xiàn)；而Front Controller場景下，而一般通過函數(shù)修飾符的風(fēng)格實(shí)現(xiàn)，如：

11 class UploadImgHandler(BaseHandler):

12 @tornado.web.authenticated

13 def post(self):

14 XXX

(上述代碼，實(shí)際上既使用了繼承，也使用了修飾符。)

Controller的改進(jìn)，目的在于更加方便的維護(hù)代碼、修改業(yè)務(wù)邏輯。

如果程序員有良好的開發(fā)風(fēng)格，基本是使用最基礎(chǔ)的php page controller，也可以達(dá)到類似的效果。

各種“先進(jìn)框架”，實(shí)際上是將常用的模式抽象出來，并通過便利的約定方式向程序員開放；如果程序員缺乏維護(hù)代碼的意識(shí)，也很可能將良好的約定習(xí)慣用濫。

需要了解的，是為什么各框架的controller設(shè)計(jì)會(huì)有這樣的設(shè)計(jì)，并用好；而不是死板的遵循“開發(fā)指南”。

在簡單業(yè)務(wù)場景下，實(shí)際上page controller會(huì)更加方便。

有這么一個(gè)“定理”：概念越簡單的模式，在處理簡單場景時(shí)，是越便利；但隨著場景復(fù)雜化，簡單的模式會(huì)越來越難以維護(hù)。

而概念相對(duì)復(fù)雜、高級(jí)的模式，處理簡單場景時(shí)，會(huì)相對(duì)麻煩；但隨著場景復(fù)雜化，則比簡單的模式容易維護(hù)。

“復(fù)雜度是守恒”的：
模式簡單，維護(hù)則復(fù)雜。
模式復(fù)雜，維護(hù)則簡單。

一個(gè)復(fù)雜的地方變簡單了，則另一個(gè)地方會(huì)變復(fù)雜；保持代碼結(jié)構(gòu)的清晰，不要自己給自己添麻煩。

什么叫自己給自己添麻煩？

普通復(fù)數(shù)形式，加s: pigs / cats / dogs

已經(jīng)可以很好了，但偏生有人要增加不規(guī)則復(fù)數(shù)：

sheep / mice / wives

這種就是自己給自己添麻煩。

作業(yè)：

1. 說說對(duì) restful 的理解

2. 什么是 reverse proxy ?

宅男程序員給老婆的計(jì)算機(jī)課程之9：數(shù)據(jù)模型

這次來講MVC中最后的M。

Model，幾乎可以說是網(wǎng)頁應(yīng)用的核心。

之前課程提到過網(wǎng)頁應(yīng)用是由數(shù)據(jù)庫驅(qū)動(dòng)，而在很多場景，數(shù)據(jù)庫 = M ； M = 數(shù)據(jù)庫。

所謂的ORM； object relational mapping。

現(xiàn)在新的網(wǎng)頁開發(fā)框架，特別是MVC框架，都會(huì)提供ORM支持，避免程序員直接寫SQL、操作數(shù)據(jù)庫。

傳統(tǒng)上，ASP/ php臭名昭著的sql注入問題，便是因?yàn)椴锁B程序員直接在程序中根據(jù)用戶輸入拼接數(shù)據(jù)庫造成的；而使用ORM框架，則可以徹底避免這種問題。

ORM有兩種風(fēng)格，一種是 R => O；一種是 O => R 。

====== R => O ======

傳統(tǒng)上，程序員也都是先完成數(shù)據(jù)庫設(shè)計(jì)（甚至是由DBA完成），然后再考慮相應(yīng)的對(duì)象生成，也就是所謂的 R =＞ O。

在這樣的場景下，整個(gè)軟件的框架，還是以數(shù)據(jù)庫為核心，業(yè)務(wù)的設(shè)計(jì)思維是以關(guān)系型數(shù)據(jù)庫的表結(jié)構(gòu)為基礎(chǔ)去考慮的，具體應(yīng)用實(shí)現(xiàn)上，會(huì)考慮很多關(guān)系型數(shù)據(jù)庫的功能特性，比方說，外鍵，joining等等，并且，程序員需要直接考慮“數(shù)據(jù)庫設(shè)計(jì)三范式”，以及冗余字段等面向數(shù)據(jù)庫的優(yōu)化手段。

并且，程序員也很可能會(huì)采用數(shù)據(jù)庫的一些高級(jí)特性，如視圖、存儲(chǔ)過程、甚至觸發(fā)器等等以方便使用。

O的存在，僅僅是為了方便操作數(shù)據(jù)庫表。

====== O => R ======

這種設(shè)計(jì)哲學(xué)則是相反，程序員做業(yè)務(wù)分析、實(shí)現(xiàn)架構(gòu)設(shè)計(jì)的時(shí)候，并不過多考慮數(shù)據(jù)庫的特性與限制；程序僅考慮自己的業(yè)務(wù)對(duì)象：編程語言中的對(duì)象。

數(shù)據(jù)庫僅僅只是作為一個(gè)對(duì)象持久層來考慮：

* 程序運(yùn)行的時(shí)候，對(duì)象是自動(dòng)保持在內(nèi)存中。

* 但在對(duì)象狀態(tài)改變、程序退出的時(shí)候，將對(duì)象保存進(jìn)數(shù)據(jù)庫。

* 程序重新啟動(dòng)的時(shí)候，則從數(shù)據(jù)庫中獲得原先數(shù)據(jù)，并還原為內(nèi)存中的對(duì)象。

在這樣的場景下，數(shù)據(jù)庫是一個(gè)可以被替換的存儲(chǔ)層，它可以是關(guān)系型數(shù)據(jù)庫，也可以是NoSQL，甚至是硬盤文件；所以，即便使用關(guān)系型數(shù)據(jù)庫，一般也不會(huì)使用其高級(jí)功能。

設(shè)計(jì)哲學(xué)的不同直接造成了使用技術(shù)的不同。

====== 比較 ======

在ED開發(fā)圣經(jīng)PEAA中，列舉了下面三種方案：

1. Trascation Script

也就是直接拼接SQL啦～

2. Table Module

R => O；并且，O非常簡單，直接以類似數(shù)組的方式讀取表數(shù)據(jù)。

.net中ADO.net的DataTable / DataRow對(duì)象便是這種設(shè)計(jì)的典型實(shí)現(xiàn)。

3. Domain Model

O => R，直接設(shè)計(jì)業(yè)務(wù)領(lǐng)域(Domain)的對(duì)象，然后在考慮對(duì)象的持久化方案。

針對(duì)上面3中方案，Martin Fowler畫了下面這張著名圖解：
http://www.hamishgraham.net/page/Work-Habits.aspx/Architecture/Business-Layer

他的結(jié)論是：

使用Table Module的方式，永遠(yuǎn)比直接寫SQL簡單；在簡單的業(yè)務(wù)場景下，Table Module也會(huì)比Domain Model簡單，但Table Module的方案復(fù)雜度會(huì)隨著業(yè)務(wù)復(fù)雜化而快速增長。

反之，Domain Model的復(fù)雜度跟業(yè)務(wù)復(fù)雜度相比始終保持水平增長；它雖然一開始最復(fù)雜，但隨著業(yè)務(wù)復(fù)雜度超過一定程度后，它反而會(huì)成為最簡單的方案。

就我自己的開發(fā)經(jīng)驗(yàn)，基本與Fowler的描述吻合；但隨著ORM技術(shù)的成熟，Domain Model，未必如他在圖中畫的那樣，一開始就有那么高的復(fù)雜度。

關(guān)鍵是看程序員是否習(xí)慣于關(guān)系型數(shù)據(jù)庫的實(shí)現(xiàn)方案，如果是，那么，切換去Domain Model，確實(shí)會(huì)比較麻煩，各種不適應(yīng)。

但如果是一個(gè)沒有關(guān)系型數(shù)據(jù)庫經(jīng)驗(yàn)的程序員，或者說，沒有強(qiáng)制使用SQL思維習(xí)慣的程序員，使用Domain Model，也可以是很自然的方案。

下一課，講繼續(xù)詳細(xì)說明Domain Model。

作業(yè)：

1. ED開發(fā)圣經(jīng)PEAA究竟是哪本書？

2. 數(shù)據(jù)庫三范式是什么？

3. 關(guān)于Domain Model，什么是充血模型？什么是貧血模型？

宅男程序員給老婆的計(jì)算機(jī)課程之10：做，就對(duì)了！

?

【51CTO獨(dú)家特稿】學(xué)以致用，很多時(shí)候，學(xué)習(xí)一樣?xùn)|西最好需要能夠在實(shí)際中應(yīng)用起來。

所以我在第2課"怎么看待牛人"中強(qiáng)調(diào)的必須“看代碼 + 寫代碼”。

不過我在里面提到的例子“ORM”卻并不好，ORM太過龐大。實(shí)際編碼，應(yīng)該是從小開始。

運(yùn)維工作中更經(jīng)常使用的是腳本語言，腳本程序甚至是shell命令都可以完成很多有意義的事情。

這些豬頭應(yīng)該在工作中體驗(yàn)很多；但作為程序員，程序能夠發(fā)揮的作用也可以體現(xiàn)在生活上。

玩Draw Something單詞想不出來，是完全可以寫個(gè)程序來輸出單詞列表的。

上網(wǎng)下載一個(gè)英文單詞詞庫；然后甚至可以用最傻X的方式去逐個(gè)單詞檢查，看Draw Something給出的字母是否能夠組成各個(gè)單詞。

程序首先是要完成需求，這里的需求僅僅是要方便玩游戲，猜出朋友的單詞謎語。

程序運(yùn)行慢點(diǎn)完全無所謂，千分之一秒輸出結(jié)果，還是10秒輸出結(jié)果，都不會(huì)影響這個(gè)需求的實(shí)現(xiàn)。

（當(dāng)然，如果是玩Facebook上的限時(shí)拚單詞游戲那需求又是不同。）

這種“程序”是所謂的Throw-away code，寫完就扔。

像Draw Something這樣的游戲，樂趣就在于努力去想、努力猜成功之后的成就感。有了這樣一個(gè)程序，那就不用努力去想，游戲的樂趣也就會(huì)在瞬間喪失，“破解工具”自然也就得扔掉了。

即便寫完就扔，但寫這樣的程序卻有其意義。寫與不寫是差別是0與1的差別，這是本質(zhì)的區(qū)別。

我會(huì)非常鄙視那些熱衷于看各種語言的介紹但卻一行程序都不寫的人。

有的人，聽說erlang很牛B，上網(wǎng)搜了一堆介紹，不斷的感嘆“哇～Erlang確實(shí)很牛！”，“哦耶！Facebook Chat跟Web QQ都是在用erlang，果然erlang才是王道！”

但是，他自己卻不寫任何一行erlang程序；有時(shí)，還會(huì)抱怨公司的管理層都是×××，這個(gè)項(xiàng)目用erlang再合適不過，為什么不用，為什么不給團(tuán)隊(duì)使用erlang的機(jī)會(huì)呢？

一定要寫程序，沒有機(jī)會(huì)，也要?jiǎng)?chuàng)造機(jī)會(huì)。

而在我看來，生活中這種“玩游戲”的機(jī)會(huì)再合適不過。

寫了Draw Something的“破解工具”，會(huì)使得猜單詞沒有成就感，喪失游戲的樂趣；但，完成了一個(gè)程序去破解一個(gè)游戲，這本身也是一件有成就感的事情啊～

并且，游戲的樂趣會(huì)轉(zhuǎn)移為編程的樂趣；而樂趣，是讓自己變厲害的最大動(dòng)力。

Geek享受這樣的機(jī)會(huì)；而ED則等待別人享受這樣的機(jī)會(huì)。

“做，就對(duì)了” - 慈濟(jì)宗創(chuàng)始人 證嚴(yán)法師

作業(yè)：

1. 使用Perl 實(shí)現(xiàn)一個(gè)程序輸入若干字母，輸出這些字母所能組成的所有單詞列表。素，就是要寫個(gè) Draw Something的“破解工具”。

2. 比較Perl的實(shí)現(xiàn)跟云風(fēng)的lua實(shí)現(xiàn)有何不同：https://github.com/cloudwu/guess-word

宅男程序員給老婆的計(jì)算機(jī)課程之11:域模型

【51CTO獨(dú)家特稿】在前面的課程中提到PEAA中只有一頁半的Active Record Pattern (http://martinfowler.com/eaaCatalog/activeRecord.html )影響了過去5年多6年的Web開發(fā)潮流。

這個(gè)潮流是由Ruby On Rails引領(lǐng)的。

RoR的作者DHH David Heinemeier Hansson是Hacker，他因?yàn)镽oR在2005年被Google跟O'Reilly選為年度***。

他在設(shè)計(jì)RoR時(shí)，選用了Active Record作為RoR的M層。

Active Record非常簡單，一個(gè)類對(duì)應(yīng)一個(gè)表，一個(gè)對(duì)象實(shí)例對(duì)應(yīng)一行數(shù)據(jù)；并且有簡單的有Save / Delete以及查詢等簡單的函數(shù)操作。

嚴(yán)格的說，Active Record不是福勒所推崇的充血Domain Object模型 （http://martinfowler.com/bliki/AnemicDomainModel.html ），Active Record對(duì)象提供的功能函數(shù)太少，只有通用的數(shù)據(jù)操作方法，而不包涵業(yè)務(wù)邏輯；但它又不像POJO （http://martinfowler.com/bliki/POJO.html ） 那樣完全的貧血。

（充血、貧血Domain Object之爭，可以去iteye翻帖子）

從福勒 AnemicDomainModel 一文看，他在當(dāng)年（2003）是推薦了充血Domain對(duì)象跟POJO，但過去幾年在Web開發(fā)領(lǐng)域所流行的卻是 Active Record這樣兩邊都沾點(diǎn)，但卻又不全是的中間妥協(xié)方案。

不搞教條主義，什么實(shí)用用什么，POJO不夠，那么就加一點(diǎn)；充血太復(fù)雜，那么就減少一點(diǎn)。

從互聯(lián)網(wǎng)的發(fā)展看，我一時(shí)間完全想不出有什么在理論上被設(shè)計(jì)得很好的模型，能夠最終經(jīng)歷時(shí)間考驗(yàn)成為事實(shí)標(biāo)準(zhǔn)。

因特網(wǎng)的7層模型，實(shí)際用到的遠(yuǎn)不到7層；Java的EJB掛了；XML被JSON取代等等等等。

也許學(xué)院派提出的理論有他們的應(yīng)用場景，只是，這樣的場景，在快速發(fā)展互聯(lián)網(wǎng)似乎很難找到例子。

互聯(lián)網(wǎng)產(chǎn)品的業(yè)務(wù)相對(duì)簡單，Active Record已經(jīng)足夠好，足夠方便，因此大行其道。

另一方面，互聯(lián)網(wǎng)產(chǎn)品做大后，也往往有著極大的性能要求，一個(gè)復(fù)雜的模型，是難以做性能優(yōu)化的。

像Active Record，因?yàn)樽銐蚝唵?#xff0c;Twitter在當(dāng)年遇到性能問題的時(shí)候，便直接Hack掉RoR的實(shí)現(xiàn)，增加了 Cache-Money （ https://github.com/nkallen/cache-money ） 這么一個(gè)透明的緩存層。

如果RoR使用的是充血對(duì)象模型，對(duì)象中有復(fù)雜的業(yè)務(wù)邏輯，如何增加透明的緩存呢？

Active Record的實(shí)際上是對(duì)數(shù)據(jù)庫操作做了抽象。

封裝、抽象是一門藝術(shù)。

什么該封裝，什么該暴露，什么徹底不可見，需要拿捏得很準(zhǔn)確。

最容易犯的錯(cuò)誤是過度封裝，使得一些本來很簡單的底層操作，到了上層變得完全不能用；或者說，很難用。

開發(fā)者需要用到hack的方式，才能去做這些簡單的操作。

Active Record便是一個(gè)抽象封裝得恰到好處的例子。過度設(shè)計(jì)、過度封裝的數(shù)據(jù)操作層？EJB。

按照教科書對(duì)OO的定義，OO的核心特性之一是：encapsulationhttp://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29

Private屬性、方法，對(duì)象外部是完全不能訪問的。

但如果遇到了需要訪問的場景怎么辦？！

有的人會(huì)說：“這樣的場景本來就不應(yīng)該出現(xiàn)，這是對(duì)象設(shè)計(jì)一開始沒有做好造成的，錯(cuò)誤的應(yīng)該設(shè)成Public的屬性設(shè)成了Private”。

ORM，采用O => R的映射的設(shè)計(jì)哲學(xué)，只考慮業(yè)務(wù)對(duì)象，完全不考慮底層數(shù)據(jù)庫，數(shù)據(jù)庫僅僅是一個(gè)可以被替換掉的持久層，它可以是關(guān)系型數(shù)據(jù)庫、也可以是NoSQL，甚至是硬盤文件。

也就是說，Domain Object是把后端數(shù)據(jù)庫給設(shè)成“Private”了，即便底層是關(guān)系型數(shù)據(jù)庫，你也不可以直接去寫SQL。

即便你使用的是MS SQL Server，你也不能去調(diào)用它特有的SQL特性。

Asp.Net剛出來的時(shí)候，微軟曾經(jīng)鼓吹過一個(gè)叫 N-Tiers 的架構(gòu)：http://msdn.microsoft.com/en-us/library/ms973279.aspx /http://msdn.microsoft.com/en-us/library/bb384398.aspx 。

我曾經(jīng)以為這是王道，直到我膝蓋中了一箭……呃，不，直到我看了Joel Spolsky寫的 The Law of Leaky Abstractions：http://www.joelonsoftware.com/articles/LeakyAbstractions.html

理想很豐滿，現(xiàn)實(shí)很骨感。

ORM工具再怎么封裝都好，底層用了數(shù)據(jù)庫，就是用了數(shù)據(jù)庫。

開發(fā)者必然需要了解數(shù)據(jù)庫的特性，能否直接調(diào)用數(shù)據(jù)庫的特性，是一個(gè)選擇。

是否要徹底對(duì)上層屏蔽掉數(shù)據(jù)庫的存在，也是一個(gè)選擇。

N-tiers架構(gòu)推薦一層又一層的封裝，如果錯(cuò)誤使用，把選擇當(dāng)成教條，是會(huì)有噩夢(mèng)的。

========

Python是一門很有趣的語言，它支持繼承，能實(shí)現(xiàn)OO，但是缺乏 encapsulation 的語言支持。

Python根本就沒有public / private這樣的關(guān)鍵字，然后呢？

然后可以回過頭再去看：“這樣的場景本來就不應(yīng)該出現(xiàn)，這是對(duì)象設(shè)計(jì)一開始沒有做好造成的，錯(cuò)誤的應(yīng)該設(shè)成Public的屬性設(shè)成了Private”。

這句話，這話說得對(duì)嘛？

作業(yè)：

1. N-tiers架構(gòu)的噩夢(mèng)場景是？

2. 什么系統(tǒng)/場景需要充分使用特定數(shù)據(jù)庫的特性？

宅男程序員給老婆的計(jì)算機(jī)課程之12：作業(yè)點(diǎn)評(píng)

【51CTO獨(dú)家特稿】h1. 作業(yè)分析

作業(yè)是課程的一部分，實(shí)際上，還是這個(gè)課程最重要的部分。

如我在前面課程中提到的一樣：

很多初學(xué)者，或者說，編程的偽愛好者，他們，會(huì)熱衷于去四處請(qǐng)教大師，下載各種經(jīng)典書籍，企圖讀一本編程圣經(jīng)，然后一夜脫胎換骨。

這是，不可能的。

同樣的，如果僅僅是看了這個(gè)課程，而不做作業(yè)，那么在看課程前后，個(gè)人的能力是不可能有變化的。

充其量，跟看了一部或許好玩的小說差不多。

作業(yè)并不是考試，而是課程的延伸，是沒有可能參照著課程的內(nèi)容，然后對(duì)作業(yè)做出回答。

每節(jié)課，僅僅只是指出一個(gè)方向，然后需要大量時(shí)間的去朝這個(gè)方向做學(xué)習(xí)、探索，然后以作業(yè)的形式做出對(duì)這個(gè)方向的回答。

這才是學(xué)習(xí)。

花幾分鐘看幾眼課程，然后就期待自己技術(shù)能力有變化？能夠有改變，從不會(huì)做作業(yè)變成會(huì)做作業(yè)？

別開玩笑了，如果能夠這樣，那么程序開發(fā)會(huì)是一門非常沒有技術(shù)含量，非常沒有含金量的行業(yè)。

只有用心好好完成了作業(yè)之后，才有可能獲得知識(shí)。

這個(gè)課程的作業(yè)，也完全不是：

小明有5個(gè)蘋果，他吃了一個(gè)。然后給小寒了一個(gè)，求太陽到地球的距離。

這樣無厘頭的題目。

每節(jié)課的作業(yè)，都是跟課程有直接關(guān)系的。

h2. 第一課

1. 用500字講述什么是Programming Methodology?

2. 列舉10種Data Structure.

3. 列舉10種Algorithm.

這課的作業(yè)實(shí)際上是在問，你對(duì)“編程本質(zhì)”的內(nèi)容掌握了多少，如果不夠熟悉，了解得不夠多，要趕快去學(xué)習(xí)。

h2. 第二課

1. 列舉10個(gè)Python Web框架

2. Python有多少種不同的解釋器？

3. Perl 跟 Python 有什么不同？

這課的作業(yè)，同樣是在問具體到Python這個(gè)語言平臺(tái)，在實(shí)際開發(fā)中可供挑選的現(xiàn)成工具有哪些？問的是對(duì)自身工作所使用的平臺(tái)熟悉程度。這課的作業(yè)，也完全可以根據(jù)使用的語言不同，而改成別的技術(shù)題目。

這課講的是實(shí)際中對(duì)工具掌控的熟悉程度這個(gè)方向，如果熟悉，那么這三個(gè)問題是很容易回答的，如果不熟悉，而為了做作業(yè)去打開Google，搜“python web框架”，然后填名字。那么就完全木有做作業(yè)的意義。

h2. 第三課

1. 找出一篇看上去很厲害的文章。

2. 找一本書，開始看，作為期中考書目。

這課講的是閱讀的重要性，兩項(xiàng)作業(yè)，一個(gè)要求閱讀的廣度，一個(gè)是要求閱讀的深度。

作業(yè)是要做的。OK，這課講了閱讀的重要，明白了，然后就洗洗睡了？自身的閱讀的東西，無論是廣度還是深度，都跟以前一樣，那學(xué)這課程有個(gè)毛用？

宣稱喜歡這個(gè)課程，并且表示關(guān)注、期待的同學(xué)，請(qǐng)問，你選擇的期中考書目，已經(jīng)翻了幾頁？

如果一頁還沒有翻；那么請(qǐng)好好問一下你自己，你究竟是不是要學(xué)習(xí)提高改變自己的？

h2. 第四課

1. 林仕鼎是百度首席架構(gòu)師嗎？

2. 看完曹政所有的blog。

這一課其實(shí)還是在講閱讀的重要性，以及對(duì)事物的好奇心。

如果，你對(duì)技術(shù)有熱情，有追求，課程中居然出現(xiàn)了“百度首席架構(gòu)師”這樣的字眼，你必然會(huì)對(duì)他有無限的好奇，會(huì)去刨根問底的了解他。

那么，是很容易就發(fā)現(xiàn)林仕鼎根本就不是百度首席架構(gòu)師，相反，caoz曾經(jīng)更符合這個(gè)身份。

我列舉了兩個(gè)hacker風(fēng)格的IT人物，一個(gè)是caoz，一個(gè)是云風(fēng)。

作業(yè)有一項(xiàng)是看完caoz的所有blog，他的blog很好看的。如果你真的看完了，那么，請(qǐng)問你是否有完成這課實(shí)際上還有另一個(gè)隱藏的“作業(yè)”，“看完云風(fēng)的所有blog”？

如果沒有，那是什么阻止了你？一個(gè)非常優(yōu)秀的技術(shù)博客知識(shí)就放在你眼前，你，為什么不去看？

OK，沒有時(shí)間，很忙，這些我很了解。

我只問一個(gè)：是否有過要把云風(fēng)的blog也看完的念頭？

如果連這基本的好奇心、求知欲都木有的話，那還是洗洗睡吧。

h2. 第五課

1. NoSQL的方案，如MongoDB還解決了SQL的什么問題？

2. NoSQL的應(yīng)用場景有啥米？

這課是講數(shù)據(jù)庫，分析、比較了SQL、NoSQL，同樣的，需要課后去做更加深入的了解并且思考SQL、NoSQL的適用場景。

h2. 第六課

1. 使用一種編譯語言實(shí)現(xiàn) Singleton 模式

2. 使用一種動(dòng)態(tài)語言實(shí)現(xiàn) Singleton 模式

3. 說說對(duì) Provider 模式的理解。

如果連最簡單的Singleton模式實(shí)現(xiàn)都是上網(wǎng)google的現(xiàn)成代碼，那。。。還是那句話，洗洗睡吧。。。

這課講的是設(shè)計(jì)模式的必要以及局限，如果只是看到后面對(duì)設(shè)計(jì)模式局限的調(diào)侃，而無視了前面提到的：“開發(fā)中非常必要的知識(shí)，實(shí)際上，是非常基礎(chǔ)的知識(shí)”。

你究竟對(duì)非常基礎(chǔ)的設(shè)計(jì)模式了解得多深入了？第三題換個(gè)模式，你說得出理解么？

h2. 第七課

1. php 的 Smarty 模版的設(shè)計(jì)哲學(xué)是什么？

2. perl 的 Mason 模版的設(shè)計(jì)哲學(xué)是什么？

3. 什么是gettext?

4. 前端javascript實(shí)現(xiàn)的模版中，目前最成熟的是哪個(gè)引擎？

這課是講模版，模版有很多現(xiàn)成的實(shí)現(xiàn)，作業(yè)純粹就是在要求去了解、認(rèn)識(shí)各種模版技術(shù)的實(shí)現(xiàn)。

h2. 第八課

1. 說說對(duì) restful 的理解

2. 什么是 reverse proxy ?

restful / reverse proxy等，都是跟controller相關(guān)，但延伸出去的相關(guān)知識(shí)。

相關(guān)性究竟在哪里？這個(gè)可以做為獨(dú)立的一課去講述，但也完全是可以自學(xué)了解的。但這絕對(duì)不是在跟小明講了1+2=3后，問太陽與地球的距離。

h2. 第九課

沒有作業(yè)。

h2. 第十課

1. ED開發(fā)圣經(jīng)PEAA究竟是哪本書？

2. 數(shù)據(jù)庫三范式是什么？

3. 關(guān)于Domain Model，什么是充血模型？什么是貧血模型？

第一題純娛樂，第二題是確認(rèn)課本知識(shí)掌握；第三題則又是在要求延伸閱讀，實(shí)際上，也是在為下一課做預(yù)習(xí)。

h2. 第十一課

1. N-tiers架構(gòu)的噩夢(mèng)場景是？

2. 什么系統(tǒng)/場景需要充分使用特定數(shù)據(jù)庫的特性？

這課作業(yè)是在要求對(duì)課程做思考，寫課程時(shí)，我實(shí)際上是碼了很多字，去描述N-tiers的噩夢(mèng)場景。但后來我又全部刪除。

因?yàn)?#xff0c;我前面已經(jīng)講了很多關(guān)于分層、封裝的問題，也提供了The Law of Leaky Abstractions的連接，對(duì)N-tiers有了解，對(duì)分層的問題有了解，那么如果還不能認(rèn)識(shí)到N-tiers這么一個(gè)多分層的技術(shù)的噩夢(mèng)場景是什么的話；那么我還是只能說：洗洗睡吧。

整個(gè)課程，是在強(qiáng)調(diào)對(duì)數(shù)據(jù)庫的封裝。為了避免產(chǎn)生封裝就是好的教條思想產(chǎn)生，所有我又加了“使用特定數(shù)據(jù)庫的特性”這個(gè)作業(yè)，要求去思考一下相反的場景。

作業(yè)：

1. 補(bǔ)做之前的所有作業(yè)

宅男程序員給老婆的計(jì)算機(jī)課程之13：再談ED

【51CTO獨(dú)家特稿】ED是Enterprise Developer的縮寫，我是刻意用這個(gè)縮寫的，因?yàn)樗€可以被解釋為Ejeculation Disorder。盡管我使用的名稱不一樣，但類似的概念是一直都有的。

像Joel Spooky則是稱他們?yōu)椤癐n-house programmer”:http://www.joelonsoftware.com/items/2007/12/04.html 并極力勸說計(jì)算機(jī)系畢業(yè)生不要成為這樣的程序員。

Joel認(rèn)為“In-house programmer”是“恐怖的”，并列舉了三條理由：

1. 永遠(yuǎn)不會(huì)有機(jī)會(huì)用正確的方法做事。
2. 沒有機(jī)會(huì)做優(yōu)雅的產(chǎn)品
3. 升職空間有限

我完全同意Joel的看法，實(shí)際上，我猜想很多“ED”也非常清楚了解他們的處境，經(jīng)常可以看到一些網(wǎng)文，諸如：

程序員們 不要想一輩子靠技術(shù)混飯吃http://developer.51cto.com/art/201111/299998.htm

這位作者對(duì)ED職業(yè)發(fā)展的描述非常真實(shí)，對(duì)于那些走在ED路途上的人做出了誠摯建議：不要一輩子都做技術(shù)。

我覺得他的建議跟Joel建議畢業(yè)生不要成為"In-house programmer"的出發(fā)點(diǎn)是一致的。ED是死路一條，不同的是，Joel建議畢業(yè)生去參與那些優(yōu)秀的技術(shù)公司的研發(fā)工作，而這位作者則干脆建議ED們徹底不要做技術(shù)。

任何行業(yè)，都會(huì)有做得好，跟做得不好的人；因?yàn)樽约鹤龅貌缓?#xff0c;而否定整個(gè)行業(yè)，我覺得是挺可悲的。

即便在中國，純粹靠技術(shù)做得好，而獲得“穩(wěn)定的生活和高的薪水待遇”的程序員大有人在，當(dāng)然，做市場開發(fā)而賺得盆滿缽滿的人也有無數(shù)。

365行，行行出狀元。

在自己的行當(dāng)里面混得不好，就指著別的行當(dāng)?shù)臓钤f，看，別的行業(yè)比我們好多了～這挺沒出息的。

軟件行業(yè)有軟件行業(yè)的問題，也有它的優(yōu)越；這構(gòu)成了軟件行業(yè)的“風(fēng)格”。關(guān)鍵是，自己是否喜歡軟件行業(yè)的風(fēng)格。

若不喜歡，趁早換去別的行當(dāng)；若是喜歡，那么應(yīng)該努力的去做到最好；而不是發(fā)牢騷、抱怨這個(gè)行業(yè)中的不好。

關(guān)鍵在于自己的態(tài)度以及努力，想要有快感，首先是自己需要勃起啊！自己心態(tài)上不投入，沒有激情，ED是必然的。

作為職業(yè)發(fā)展，首先必須是自己真心喜歡、熱愛這個(gè)行業(yè)，即便沒有薪酬，沒有回報(bào)，自己也能夠在做事的過程中獲得精神上的滿足。

只有這樣才能夠在技術(shù)發(fā)展路途上精益求精，不斷進(jìn)步；是的，即便“做到技術(shù)最強(qiáng)，也不可以成為100%受尊重的人”，但這并不是不把技術(shù)做到最強(qiáng)的理由。熱愛技術(shù)，“做到技術(shù)最強(qiáng)”，本身就是一個(gè)充滿誘惑的目標(biāo)。

把技術(shù)視為敲門磚，自己本身就不尊重技術(shù)，那必然是沒有辦法成為別人尊重技術(shù)人。

無論外人怎么看，技術(shù)人都應(yīng)當(dāng)尊重自己。

豬頭時(shí)常跟我辯解即便是在銀行內(nèi)部做IT也有升職空間，并且自己也不斷的在銀行內(nèi)不斷提升、轉(zhuǎn)向更高的技術(shù)職位，其實(shí)是很厲害的。

Premier ne puis, second ne daigne, Mouton suis.

作業(yè)：
1. 這篇課程最后的法文的下句是什么？

2. Almaviva是什么？

3. 猜我為什么出上面兩道無厘頭的作業(yè)？

轉(zhuǎn)載于:https://blog.51cto.com/sleepgod/1352039

總結(jié)

以上是生活随笔為你收集整理的宅男程序员给老婆的计算机课程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。