http://www.thinkingtaiwan.com/content/3426

var_dump( in_array(0, [1, 2, 3]) );

先猜一下結果才看答案哦

發現網路上已經有詳盡的說明

總之，請使用intval來測試想法是否正確

雖然是老議題，但發現BUG的時候我們常常會沒有注意到
"這麼簡單的寫法當中居然會有錯誤"

內容造假，代表我認為這內容有問題，裡面完全不可信
這狀況不應該再繼續評論任何東西，因為都是假的

內容有不當行為，代表這內容是真的，我以這個內容是事實為基底
根據各種疑點質疑這內容敘述的事情已經造成哪些問題

沒人把兩件完全矛盾的事情湊在一起瞎扯淡自以為攻擊力變兩倍好嗎?


如果你智商低於100，可能需要往下看

內容造假代表裡面不當行為可能是假的，也可能是真的
你拿這種模稜量可的東西來討論真相?是否太過膚淺?

對，或許不是全部都假的，但你如果能準確地指出哪些是造假，還能順便指出那些內容真正描述不當
那麼你自己才是造假那個人吧...

http://lapin.uhostall.com/tsl/_1404/1397389603960.htm

function 外部Class A 裡面有function FA()可以拿到對應值
function 外部Class B 裡面有function FB()可以拿到對應值

我寫的class:

class Example(){
    function getA(){
        return new A->FA();
    }
    function getB(){
        return new B->FB();
    }
    function mixData(){
        $dataA = getA();
        $dataB = getB();

        return $dataA + $dataB
    }
}

好了，假設這些ClassA ClassB是外部函數，也就是其他人開發的
那我們該怎測試才能確保自己的unit有正常運作呢?

class test_Example(){
    funciton test_mixData(){
        $mock = $this->getMock('Example');

        $mock->method('getA')->willReturn('1');
        $mock->method('getB')->willReturn('2');

        $this->assertEquals(3, $mock->mixData());
    }
}

一分鐘了，應該看懂在寫什麼了吧

看懂以後再看下面

在這樣的具體個案中，如果要確認Unit有沒有"正常運作"
最該care的是取得資料以後， "+ 有沒有執行，有沒有return"
而不該是"AB資料取得的值是否正確"

因此"對這個unit而言"，我們不應該做類似以下事情:
"FA可能沒取到值，我們應該assert確認一下"
"FA是否是字串根本不能相加，我們要確定一下是否為浮點數"

這裡要鄭重說明一下，我們的目的終究是要確認這個unit有沒有正常運作
所以，如果你做了外來資料的過度判斷，而到時候又真的出錯了自己不在現場
如果是外來資料有問題，結果unit test檢測被其他人看到，恩經判斷期望結果不符
非常有可能會以為這是你的程式出了問題，結果查好久才查到原來根本是外部程式導致
這會造成大家的麻煩，請務必別做這樣的事情

再來，為什麼這種函數都很少去用各種condition來assert結果
因為:出問題你很難判斷是外在資料錯誤，還是你計算錯(原因可以無限上綱，不要懷疑)[註1]
與其花費大量時間寫各種判斷式來嘗試抓冰山一角
更好的方式就是不要在unit test幹這種事情(不是不測，而是別在這階段做)

(假使要做這件事情，除非程式本身就帶Exception，那我們可以做另一個測試時，帶入不合法的值來確認是否真的會觸發Exception)

Mock Object的作用就是在此，我們應該準確地確認這個unit是否真的有運作
不應該被其他外在函數的特例狀況影響到
這也是單元測試好用的地方，我們即使程式還沒完成或上線前接不到資料
也可以假設某函數資料正確來直接測試，這是Unit Test Framework最強的地方

這樣也不需要在主程式改一些測試專用Code，然後可能上線前還忘記砍掉之類

老話一句，如果想用unit test，

請絕對不要迎合unit test去多做一堆沒用判斷，然後說什麼這樣可能很難測試，我要為了unit test方便而忍痛改變現有架構之類的蠢事

請去用他對你來說真正受益，可以減少程式錯誤，增進開發效率的地方，這樣才能發揮價值

註1:
因為用少數結果絕對無法檢驗程式邏輯有沒有錯
要舉一些極端例子的話，

1.如果你assert 3應該回傳5，我程式如果為了測試，最後一行真的是寫return 5，assert下去絕對有過，但這樣的結果明顯只是鬼打牆(而且這個實際真的有人發生，因為為了寫unit test最後的return還真的忘了拿掉)

2.如果你做了兩個，assert 3應該回傳5 assert 4應該回傳 6  是否裡面剛好程式搞砸了，最後變成 input+2 ，結果assert還是有過

3.然後開始上綱，你的unit判斷式寫太複雜其實有藏了幾個BUG，結果要測目標程式測不到

http://www.neo.com.tw/archives/1072

這不是引用，也不是轉貼，單純是素材...

當你看的出來哪些是消毒文的時候
恭喜你，你的判斷能力有及格

不過，有些抗性和理解真相的能力
常常是要自己被坑一次才會了解...

感覺抱怨文發有點多，發一篇來洗掉(雖然沒什麼意義)
以下請勿沒看狀況照搬，也請自己先弄懂並確認運作流程

假設有狀況需要執行A方針的流程1和流程2，但其他狀況需要執行B方針的流程1和C方針的流程2
神奇的PHP可以把他整理得很乾淨

class A{
    function magic(){
        doSomethingA;
    }
    function magic2(){
        doSomethingB;
    }
}

class B{
    function magic(){
        doSomethingC;
    }
}

class C{
    function magic2(){
        doSomethingD;
    }
}

if (condition) {
    $dynamicClass = new A();
    $dynamicClass2 = $dynamicClass;
} else {
    $dynamicClass = new B();
    $dynamicClass2 = new C();
}
$dynamicClass->magic();
$dynamicClass2->magic2();

好處的話，當流程不只兩個，而是十幾二十個的時候，差在哪顯而易見
但是這也考驗著，有沒有辦法整合自己架構，釐清整體流程

因為在這裡雖然很明確的寫出magic和magic2作為方便理解，在現實狀況卻不一定是能很輕鬆分出來的

我實在不懂為什麼有人會說
"雖然我不懂，但我還是覺得人家有這種理論，必定有一些神奇且深奧的地方"
"我覺得XX理論就是YYYYY，所以我們做這件事情，依照這理論，我們應該ZZZ"

拜託一下，用一下你的腦子好嗎?

這理論到底帶給你什麼好處，如果在寫程式，應該深有所感
TMD不要寫到綁手綁腳，寫到吐，然後回頭被問
"阿你這樣寫到底實際上拿到什麼收益，效率快在哪，維護方便在哪"

結果?拿不出來，而且還用一些自表理由
"(重複)因為這理論就是YYYYY，所以我依照這理論，我們可能要ZZZ，然後或許因為有點限制，還要ZZZZ"
"我雖然說不出來有什麼好處，但未來總有可能有幫助的"

可以停止欺騙自己了嗎?

有些人很確切的了解到自己幹這件事情雖然綁手綁腳，但逐漸為自己理想邁進，這樣的犧牲是有價值的

但是有些人不然，看到一些小地方為了展現自己知識，就硬是要大作文章，說我覺得這樣做比較好，你們遇到這件事情也都倒跟我效法

老實說，這樣算小事

但是，遇到方向性理論呢?

有些人自以為可以見葉知秋，以為我把這邊做好，考量別人可能會出狀況的BCD，恩我的系統超好超完美，你看，以後怎麼發生狀況我都不怕了啦

然後，才出一個狀況就倒了是怎樣

這絕非運氣不好，我用一個非常具體的程式例子來講

"單元測試"

為什麼單元測試不做邏輯測試，不做整合測試，甚至資料假的都可以測試
"因為他本來就不是給你測這些鬼東西的"

有些人自以為聰明，想說"測試總是要有點實際意義"，然後就寫了落落長的"可以順便驗證資料真實性，可以確定邏輯和突發狀況的"單元測試程式，雖然說測試程式比原本程式碼多有時候是正常的，但也多太多了吧?雖然問題遠比這嚴重

你的目標是"如果發生了我預想的ABCD狀況，根據我的測試，我可以準確的防禦並抓到問題"

但是，程式根本不怕預想錯誤，就TMD怕例外，所以才有Exception，才有assert
你拿這些預想內狀況來測試，是在考驗自己，測試自己的智商水平會不會哪天手殘改壞沒注意到還上線被客戶使用結果爆出來了嗎?

在某次單元測試中的對話:

"你看，為了測試我這個程式運作沒有異常，我直接抓這必要的回傳陣列第一個值判斷是否有設值，就可以完美的讓這測試有更深遠的意義"
"異議，回傳是空字串同樣算是有設值"
"那麼就在檢驗字串長度好了"
"還是有異議，回傳是錯誤資訊也還是有設值"
"那再多個判斷是否回傳的是錯誤資訊"
"一筆資料也不能確定沒有異常吧"
"那我帶十筆測試，這樣可信度更高了吧"
"資料庫被影響怎麼辦"
"哦，那我們要自己建立專門用來測試的資料庫，確保測試期間所有程式只有我的程式在運行，所有影響都可掌控，然後每次測試完畢以後都要刪光資料表，確保上一個測試沒有影響到下一個測試，接著還有還有還有還有.........."

...TMD我到底聽到什麼神奇的對話...當場傻眼
(如果讀者認為上述的很有道理，代表客官您還不是很懂單元測試在做什麼的，建議去Google或我先前的文章有非常詳細的說明)


然後?沒有然後了，因為單元測試目的在檢驗"程式跑得動"
但有人一直在檢驗"運作完全按照自己預期，資料沒有出錯"

所以才會發生死胡同
"沒有設值，恩空字串也算有設值，不對即使意外從其他資料庫拿到錯誤的資訊還是有設值，更進一步，你中途不小心手殘去設了值...這測試程式怎麼這麼難寫!"

"我預設其他人都不會傳錯資料，只會用我預期的方式發生預想中錯誤，這樣我就可以用我的理論發揚光大，展現我程式的彈性"

抱歉，這種東西，完全是妄想
程式是要預留調整的彈性，而不是自己預想將來會發生啥狀況然後擅自認定以後把這些應對寫好

一定有人會白癡問說:"阿將來發生怎麼辦，你要負責嗎?"
我可以順你的意，按你理論，我可以多寫一百多條判斷，你不准撤，因為將來只要出錯，你撤了任何一條判斷，你就要負責

為什麼這樣說
因為這只是單純的把自己的白痴思維套用到別人身上
你擅自認定了以後可能資料庫會按照自己預想的方式修改，而且哪天手殘會不小心改到程式碼的特定某個區段，此時我寫的防禦機制，將將，漂亮的防禦了一次攻擊!

....姑且不說約有99.999%是"預想外狀況"
我可以很明確的說，如果到時候發生了你所說的狀況

"百分之百是你幹的"

你正在做這件極度自婊的事情，不過你好像沒有這個自覺

為什麼這能牽扯到理論的奴隸
這非常簡單，非常直覺，因為會幹出這種事情，不外乎自己已經被一些自己擅自認定"這東西超強"的理論框架綁架，擅自認為這東西效率最高，最好，出錯一定都別人寫錯或不會用

自己捫心自問一下，真正效益在哪，犧牲在哪
不是TMD理論的白癡講解方法，而是運行呼叫次數少了多少，維護預設遍歷少了多少，記憶體少了多少

這點我一直想說，有些人被問問題，馬上很搞笑地去GOOGLE找測試數據，找別人怎支持這理論
雖然一直藏著沒講，在這邊講一下好了，反正沒幾個人看的到

"你TMD這麼有自信，不會寫測試丟自己程式身上證明一下嗎?

有些人確實這樣幹，我非常佩服，但這些人因為自己有測過，說話都會比較保守，因為如果有正確且充分的測試，都會了解到自己現在寫的都不是最好，最萬能的
為什麼?因為常常

換個環境測數據就變了
隨便換個攻擊手段你所謂的防禦機制就崩潰了
隨便換個架構修改法你預想並擅自寫好的擴充函數根本無用結果導致得全部砍掉重做

同一個演算法無法完美套用所有運算
同一架構無法完美套用於所有狀況
同一個預防機制無法因應所有意外

這是基本常識，我們因為有腦子，所以我們懂得變通
所以絕對沒有什麼"照這樣理論就對了，絕對是最有效率，最完美的"這種蠢事

但是有些人展現100%的自信，被正面婊後還死不認錯繼續轉移焦點找理由，然後再把那些已經被打臉的又重新搬回來講一次理論

沒有經過正確消化的理論，即使講第二次也沒有更大的說服力，不如說根本是反效果
因為即使這理論真的很好用，你也沒有正確使用到，才會有這樣的表現

這種，就是百分之百的，理論奴隸
常常覺得自己很忙，做苦工，結果到頭來只是屈服於好像很好用的理論之下
我真的不知道該說什麼，因為根本不知道從何吐槽起


最崇高的設計理念，架構，永遠只是夢想
因為他本來就套不進現實狀況，硬要用只會被正面婊慘後各種拘束最後在嚴重拖慢效率

夢想是目標，但從來都不是寫程式的標準
因為照著走只有死路一條，且遇到狀況就牽就所謂的夢想，只會把事情搞複雜
這叫自殘，絕非變通

沒有能力去駕馭強大理論，就放下身段，懂多少就去用多少，這才叫踏實
因為你可以明確知道自己正在幹什麼事情，犧牲多少，得到多少

"所有能用的都要全用上，讓狀況變得非常完美"
抱歉，請在夢裡面講就好，尤其奉勸某些人找到一些看起來很強大，就自以為可以完全掌握，而實際上非常生疏，是第一次接觸的技術

請三思而後行

這裡並不是說什麼，故步自封，有新技術也不學什麼的
而是指，你學了多少，掌握多少，就用這些拿來幫助自己就好
沒有必要打腫臉充胖子，以為自己沒掌握的地方也會按自己預想的狀況下進行

這非常危險，也常常讓很多人直接走進死路

但終究還是給自己一個警惕

永遠不要擅自去認定環境該怎麼改變而擅自預先做了一堆自以為是的防禦機制
因為，預想內的基本處理是"本來就該做的事情"，還去做一堆事情"預防"根本叫做"搞不清楚狀況"
要預防的是什麼?

該預防的是預想外狀況(例外)好嗎!?

http://www.ettoday.net/news/20141109/423806.htm#ixzz3IZQKV4Bk

在民主社會，人民選你，是因為你的決定會是人民心聲，因為你的決策會等於人民的決策
不能讓人民有決策權到底是啥鬼?

本篇禁止comment

有雷，點之前請先有心理準備
如作者對本BLOG轉貼有反對意見請提出，將直接移除(注意必須是作者)

http://homu.komica.org/38/src/1415525945549.jpg

http://www.stormmediagroup.com/opencms/news/detail/70d0ec64-c6bf-11e3-896c-ef2804cba5a1/?uuid=70d0ec64-c6bf-11e3-896c-ef2804cba5a1
https://tw.news.yahoo.com/%E5%8D%8A%E7%89%88%E5%BB%A3%E5%91%8A%E6%94%BB%E6%93%8A-%E4%B8%81%E5%AE%88%E4%B8%AD%E7%97%9B%E6%89%B9%E9%80%A3%E6%8A%B9%E9%BB%91-221033029.html

https://www.ptt.cc/bbs/PublicIssue/M.1413021545.A.785.html

死迴圈，一堆人有這種本末倒置的觀念
寫到最後，通常會用這種理由來解釋自己的程式比別人品質更高

"你看，我這邊判斷得多麼精準，沒用到的就是不會執行到，多麼完美"
"你看，如果你想加額外的處理項目，直接在這底下開函數就可以了"
"你看，你完全不用管我這邊怎運作的，只要使用就行了，該出的例外訊息都會丟出來"

我要反問了
"現在不是額外的處理項目了，我們資料庫要換，處理方法要換，你能馬上改出來嗎?"
"現在合作架構有點異動，很多欄位(數量)都改變了哦"

最重要的
"現在XX功能出問題了，你打算怎麼讓別人知道該怎去追這麼BUG"
"你要怎麼讓別人知道你程式運作的方式以及調整架構的方式"

然後死盲點
"你真的以為用這一大堆判斷式確認沒有額外函數執行效率會比較高嗎?"

合作開發這種事情，一個人是幹不起來的
要讀別人的程式碼是必然，因為要合作，在來有BUG，即使你說你負責處理，退個一萬步總得讓對方知道怎把這條BUG報給你吧

有些人會問我，怎麼你說你的程式是OOP的架構，GET／SET怎這麼少，函數好像也沒開很多
我倒要反問一下這些東西跟OOP到底有啥關係了

大家常常看到的 Vehicle new Car new Bike覺得很完美對不對?
可是你有沒有想過那只是大準則，你真的一new就天下太平了嗎?，別妄想了

程式，最基本最重要的東西就叫做"流程(Step)"
所有東西都依賴於他，即便你是個OOP架構，你最終還是要給我個"使用順序"來完成事情
當你確定流程以後，才有資格說我按照使用狀況去封裝必要的程式碼

為什麼?因為這樣做才能讓合作對象最容易了解你在做什麼

怎樣算是一個成功的OOP，就看需求有變動(注意不是項目，多個欄位你就顯示不出來，請不要來亂)程式能跟著變化到什麼程度

最基本的，處理流程，順序，不同資料銜接的方式，在怎麼說都是需要靈活應變的
總不能說我的資料只能完美的給A情況使用，換成B，阿不好意思我要大幅度改寫...
你再怎麼解釋你程式高效能，最終就是被貼一個標籤，應用方式太狹隘，思考太侷限


那怎樣算是一個失敗的OOP，近期看到一個例子，來分享一下
這個OOP相當省記憶體，因為只要沒有做到的他就絕對不會初始化，這點已資源考量方面是相當完善的

然而，他是怎麼運行的呢?
當我new 一個A類別，我就會執行一些B函數，但執行到一半為了處理事情我要用執行階段的部分內容呼叫C函數處理，然後執行完後我要直接拿這個結果呼叫D函數...
(後來想想，應該有人會看不懂，那白話一點，這個狀況就是:
你執行A類別，B函數以後，剩下的CDEFGHIJKL你除非去追原始CODE不然都不知道她怎幫你處理資料的)

問題來了:
這些所謂的function都是丟在該類別裡面，當有人問你
"請跟我說一下這程式處理資料的流程，我覺得好像有個地方執行怪怪的"

下場，很簡單，你要從頭到尾解釋一次程式給他聽，而且恐怕第一次解釋還聽不懂
因為function不管你怎麼整理，為了高效化就是有許多各自的細緻處理，最終的下場就是
"執行順序消失了"
這是相當嚴重的事實，我有正常跑我的類別，可是執行順序我都需要反查一下才知道跑到哪了


先不考慮過多判斷是否早已掩蓋掉原本直接執行的效率

剛才是不是有提一件事情
"現在，我的處理資料流程要變動了哦，稍微變動個執行流程，因為中間我們要加個驗證了"

然後好死不死，原作者不在現場
快，告訴我，哪個傢伙趕快神解一下這個類別到底該加在哪個位置

物件導向，是將事情正確的拆開封裝，以"方便溝通"，與"方便維護"，和"方便調整"
但這個模式同時隱含著你必須處理好運作流程，否則該封裝沒有意義

我一直不懂為什麼有些人會用效率去解釋他的OOP做得多好
你們TMD為什麼沒想過原本直接下一條指令就能搞定的東西，被你包了這麼多層
怎麼看都不可能比原本的效率還好OK? 你沒把最重要的流程，架構，溝通做好
還反過來說你看我這樣封裝，沒執行到的都被我精確排除了

抱歉，我只說一句，你正在拿最沒有效率的手段說你正在提高效率
請絕對不要做這種搞笑事情

以此觀點來說，沒錯，我也要講另一件事情
那些看起來很強的perfect coding，我就真的當它是都市傳說
因為那常常是特定狀況下才有辦法這樣幹，又或者是自身已經對資料架構摸到熟到不能再熟，且資料架構也沒啥大問題的狀況下，才有可能完美呈現的CODE

很抱歉這個需求我就是要動到5個資料表，你要我用處理單一資料表的水準把程式跑出來
這就是不可能的事情，請不要對著這支程式說
"你看人家對(單一)資料表都處理的那麼完美，怎麼你的處理方式有點雜亂"

當你正在想這件事情的時候，請自己寫一下真正會變怎樣
如果全部都能照你所想的正確呈現出來，那你真的可以去讓對方信服

反之，雖然處理漂亮了但判斷變超複雜，STEP變超複雜，你TMD還是來亂的
因為根本就不可能這樣改寫

有些理論只存在理想，如果你覺得他可以實際用出來
請拿實際能辦到且自己正在應用的事情來說服別人(不是拿其他人的程式碼哦，這有天地般的巨大差距)，而非只是宣傳一下好像很強的理論
就以為自己也辦的到，且這很完美，怎麼別人都不聽你的

理想與現實，一直都是兩回事，身為一個程式設計師，請務必先釐清這件事實