sean huang的部落格

        /// <summary>
        ///  什麼鳥?
        /// </summary>
        private string GetCode(decimal A, decimal B)
        {
            string code = "B";
            if (A > B)
            {
                code = "Y";
            }
            else if (A < B)
            {
                code = "O";
            }
            return code;
        }

        /// <summary>
        ///  直接返回鳥
        ///  兼顧可讀性和可重構性
        /// </summary>
        private string GetCode_R1(decimal A, decimal B)
        {
            if (A > B)
                return "Y";

            if (A < B)
                return "O";

            return "B";
        }

        /// <summary>
        ///  可讀性差的鳥
        ///  韌體工程師的最愛
        /// </summary>
        private string GetCode_R2(decimal A, decimal B)
        {
            return A > B ? "Y" : (A < B ? "O" : "B");
        }

使用者故事樣例要考慮以下事項

1. who:  誰? 
2. what: 做什麼?
3. why:  為何做?

第一階段:
我們透過某個方式知道了某人想做某件事
Someone want to do something.

這個人可能是客戶
客戶的利害關係人
或是公司的股東,老闆和你的上司
或某個點子和機會

第二階段:
我們要詢問為什麼?
why?

一般人會去做某件事通常是為了
1. 避免痛苦
2. 取得快樂

我們透過一些努力的成果讓客戶消除痛苦或取得快樂
客戶才有可能會掏錢

正當的手段有很多,寫軟體只是其中一個選項
有必要也可能沒必要
客戶常常只是想找人聊天
我們這時必須設法識別出來

何者是機會何者不是

第三階段:
評估市面上是否已經有解決方案?
目前客戶採用何種解決方案?

1. 無類似解決方案,very nice
2. 有類似的解決方案,但客戶不採用,why?
3. 有類似的解決方案,但客戶採用後有所不滿,why?

幾年前有一個客戶
他來找我開發一個功能
我們發覺這個功能國外大廠已經有了
而且做的相當不錯

深入一問才知道客戶已經在使用了
而且以功能面而言他們相當滿意

那為什麼還要來找我們呢?
因為功能性雖好,但價格他們覺得太貴

我們最後調查一下價格發覺其實相當合理
沒有利潤也沒必要破壞市場

浪費時間做一個沒有受眾的垃圾出來
不如去度假,不是嗎?

1.  系統僵化

若修改或新增一個功能需要同時更動許多不同模組

則此系統難以新增或變更功能,我們稱為系統僵化

現象 => 單一功能 (1 - *) 多個模組

2.  系統脆弱

若修改一個模組很容易造成其他彼此不相關的功能異常

導致系統測試成本很高,我們稱為系統脆弱

現象 => 單一模組 (1 - *) 不同功能

3. 系統黏度過高

通常解決一個問題有戰術解和戰略解

戰略解 => 對系統有長期利益的解法,通常開發時間較長,短期KPI不明顯

戰術解 => 開發時間短,但會留下技術債,長期對系統不利,短期KPI明顯

戰略解和戰術解本身沒有對錯,產品有資源和上市時間限制

所以戰略解和戰術解會一起出現在系統中

當一個系統架構讓

實行戰術解很明顯的比戰略解容易時

工程師會傾向使用戰術解增加個人KPI

而使用戰略解的工程師會被變相處罰而離開團隊

造成系統越來越傾向短期利益

此時我們稱為系統黏度過高

4. 系統複用率低

相似功能的模組多

copy and paste 現象明顯

因為每一個模組都要花成本維護

會造成維護成本明顯的大於系統所表現出來的功能

此時我們稱為系統複用率低

關於第一點和第二點解決方法就是單一責任原則,和介面分離原則

第三點不一定是問題

要看公司和產品特性

新創找投顧的和老牌公司著重地方一定不同

第四點需增強工程師們的素質和團隊合作精神

使用測試驅動開發大概有5,6年歷史了
進業界後,我寫的程式碼有BUG很少的特點
會動用到除錯器,絕大部分都在幫別人除錯

而使用測試驅動開發方法後,程式碼更近一步妖孽化
當然程式一定有bug,只是QA沒機會測出來
因為測試程式會在QA或客戶測出來之前,先自我了斷

好的~~測試驅動開發確實有用,我想

BUT.....
之前我的名聲在PM間其實並沒有太好
理由是我雖然是資深工程師,但產碼速度並沒有明顯優於資淺的
他們常常苦於面對客戶的壓力,又不敢對我大小聲

我一知道這件事立刻找他們好好吃了很多頓飯(可以申請公關費嗎)
並調整我的作法,之後我們合作愉快

我有個習慣,會把看過的舊書隔段時間再看一次
今天重溫敏捷軟體開發,原則樣式與實務
想起了這件事,所以把心得記下
到底實務面上的執行會發生什麼事呢?

台灣的軟體公司大多是接案,沒有自己的核心產品
我運氣不錯,新手前幾年是在一家做產品的公司工作
是Linux嵌入式系統,所以學了不少Linux的知識,C/C++也不錯

我第一次看見Android底層程式碼的印象是
嗯~寫得很爛 
(喂!!老兄,等你進得了google再吹牛吧)

嵌入式軟體的特點是,它一旦出貨就很難更新韌體
(你有幫你家DVD播放機更新過韌體嗎?)

所以它的軟硬體品質必須一級棒
硬體有BUG軟體必須設法克服
軟體不得有重大bug
有些必須一年365天,一天24hr無誤運作
一旦發生錯誤必須能夠自我偵測修復
因為有些系統很便宜,業務跑一次就虧本了

所以測試驅動開發是對的,我如是想

後來我來到這家做專案的公司
使用.NET MVC開發產品

C#加上VS真的是一個超棒的開發環境
它具體有多棒只有前C++/Linux工程師能感受到

我立刻發現到公司同事寫的程式問題
攏長,雜草叢生必有妖孽
我重構了100行的程式碼,發現最後只剩兩行
還順手解了幾個bug

我從一開始不解,憤怒到現在發現這是業界常態 
慢慢接受了它,並剖析它形成的原因

收回之前Android底層寫得很爛這句話,因為我們更爛
程式是寫來賺錢的,不是學究的玩具

工程師都很聰明,沒有人可以忍受雜亂無章的程式碼
但為何會寫出這樣的程式呢?

台灣的軟體專案錢很少
翻譯一下就是,客戶只出100塊但卻想要1000塊的東西
沒sense的客戶比比皆是

我認識的接案公司賺錢的沒有,倒閉一堆
還活著的都是當仲介賣人力的

以PM的角度
系統越早上線越早收錢
讓公司的現金流能夠維持穩定才是第一要務

很多PM常常兼業務和PO,我這裡談現實層面
不是人人都有機會進趨勢科技
所以台灣軟體人九成要面對這個問題
只懂軟體的人通常位置不會爬得太高

我們如何幫助他們,這是我們受雇的理由
翻譯一下就是:
系統讓客戶買單,早日收錢,薪水入賬,股東happy
然後再去做下一個系統

copy paste可以辦到的話,為何不行?
黑貓白貓可以抓老鼠的就是好貓

客戶這次找你,心理想的是系統上線後拿到原始碼
然後找更便宜的人維護( 這件事通常不會發生,理由後敘 )

所以你重構程式,程式清晰,架構好,維護輕鬆和功能新增容易
是爽到後來接手公司

做產品是你公司開門第一天到倒閉最後一天
每天都會看到它
品質差,bug多,不好客製化
會像陰魂一樣每天追著你跑

我常對小朋友說
做專案是光榮拿走,只留下恥辱
第一發有湯喝,第二發渣都沒有

所以基本上沒有人會想接手別人的爛攤子
以客戶的想法,程式都寫好了
只是寫改個小東西,收幾百塊就好了

各專案公司都清楚得很,業務能量不會投資在接舊專案
因為很難拿到合理的報酬

架構差,有時候改個小東西,運氣不好是整個模組要重寫
吃力討不好,不接,除非客戶來求

如果是第一發以拿錢為目的
那事情就單純多了

甚至有不寫一行程式就讓系統上線的方法

我後來和PM們達成共識
只有少數明顯的複雜邏輯才寫測試
做事方法改用故事流驅動

故事流的終點就是上線收錢

尋找最便宜的方案
就是我們資深工程師的責任

時間 + 人力 + 金錢
最小方程式

這裡有兩個分歧點

1. 我們要交給客戶60分的產品 (客戶所能接受的最下限,人善就被人欺,不用客氣 )
2. 發揮專業使用最節省的方案,交給客戶100分的產品

告訴你一個事實,大多數業務認為專業狗屁,你們不懂業務
所以他們心理的大多是方案1,逼不得已才是方案2
而且方案2下他們不是主角,很難有好的KPI

大多數公司業務位階比較高,這十分合理
因為賣不出去的產品,多好都沒用
我待過倒閉的公司,深知垃圾賣得出去才是硬道理
公司不賺錢是罪惡

所以我把方案一和二做了結合得出方案三

3. 發揮專業使用最節省的方案,交給客戶60分的產品

測試驅動開發雖然品質高,但它明顯比較花時間
時間金錢不是問題時無所謂
但在有限預算下,還有其他選擇
(哪個案子錢是夠的?)

有些學究派的軟體工程師可能會噴我 (比如說以前的我)
或許你運氣不錯待了一家正統的軟體公司

我只能說做人很難,沒有永遠真理
寫軟體也是

於是一個SD和PM們過著幸福快樂的日子
END?

http://avalon.signage-cloud.org (正式)

http://avalon.signage-cloud.org:9527 (測試)

因為註冊不到對岸的阿瓦隆才做了這個
喜歡玩阿瓦隆又討厭出門的朋友可以揪團來這邊打
當然有條件的話還是面對面打最好玩啾

這個伺服器有一半的目地是用來測試新技術
用來了解網路分散式應用和人工智慧
可能有時候會隨意在上面堆一些怪東西...
 

測試驅動開發是這樣一件事

繼續閱讀....