2014年5月3日 星期六

[研討會] 集英信誠「與大師對談」技術論壇

這是一場一年一度由集英信誠舉辦的研討會,和微軟的場子有些不同的是,我們在這邊的研討會內容比較多的是經驗的分享,而不只是最新技術的介紹而已。

在這場研討會中,我的講題是『軟體開發 VS 專案管理的鴻溝與橋樑』,這是我多年以來一直想談的主題,包含如何透過現在的雲端技術與相關工具,在開發人員的效率和管理工作之間取得一個平衡,如何在團隊中導入開發方法和架構設計。如何讓專案成功、讓產品獲利...

當然,這只是一個開始,1小時的時間我們能說的不多,但很開心,在現場碰到很多對這個議題有興趣的朋友留下來討論了一會,我自己也很有收穫。

如果可以,我會試著再把內容整理出來,和大家分享。


Is dead? and then?

ref : RoR之父批TDD已死,你認同嗎?

戰火很是熱鬧,我們這時候跳進來討論,其實似乎有些任性。
因為最近幾年我發現,如果當一件事情變成信仰的時候,其實就沒什麽討論的空間了,政治是、社會議題是、很不幸的,技術也是。

不過最近五年,我們持續聽到很多 XXX is dead, 例如 Silveright, Flash, ASP.NET WebForms,  MVC, 還有現在的TDD。

我並不太在乎某一種技術是否已經死亡,其實基本上 is dead 的這種標題都只是比較誇大的說法,旨在凸顯一種立場或是看法。真正 is dead 與否,是由市場決定的。不然,怎麼會出現微軟要XP死,XP死也不肯死的狀況? ref1, ref2

資本主義讓市場決定一切,所以不要說XP了,到現在我都還有朋友用 delphi 和 Foxpro寫系統,賣的還不錯咧。

所以回過頭來說這個 is dead 議題,前面說過, is dead 其實只是一種立場或看法的宣示,但為何有這種看法呢? 我不想討論細節,但我猜想台灣的技術人員一定有人這麼想:
  • David(不是我,是RoR的David Heinemeier Hansson)在講什麽? 也太沒概念了吧???
  • 什麽? TDD is dead ,我才剛準備開始unit test和導入automatic test耶...
  • 呼,好在TDD要死了,不然先寫test這種事情,誰做得出來?
  • TDD? 什麽鬼啊???
  • ....

我猜一定有各種不同的想法,而就如同我先前說的,在這個多元化、資訊爆炸的時代,不管你的想法是什麽,你一定可以在網上找到支持你論點的證據,正反兩方(喔,不,是三方或多方)都可以有一派支持者,因為這就是一個多元的時代。

但如果你看David Heinemeier Hansson的文章,你會發現他之所以反對TDD,是因為有太多人喊得太大聲了,大聲到好像不用TDD就是個罪惡,或是一種該被歧視的遜咖。他認為太多技術激進者用過於武斷與絕對的態度,以近乎沒有風度的方式來『推廣』一種技術。

但大家忘了,資訊科技出現才幾十年,軟體開發技術、軟體工程和開發流程的發展,也不過才由弱冠走向而立,在這個變動的領域裡,其實還沒有哪一件事情long live到可以被公認為真理的。

從結構化程式設計到物件導向,從CMMI、瀑布式開發到現在紅的要命的敏捷、Scrum,如果你仔細觀察,不難發現這有非常多的背景或前置因素,如今資訊透明、傳播速度快、產品生命週期短、需求與規格變動性高,所以你看敏捷和Scrum確實火的有其道理,但這並不代表,二十年前我們用的另一種開發方式就一定是錯的,也不代表,十年後大家還是會用Scrum。

所有的技術、流程、方法,都有其適用條件與背景因素,並非100%放諸四海皆準的。

我上周去廣州陪一個團隊討論專案,架構師把自己的設計攤在我眼前,逐一解釋每一個環節。講的、做的都非常好,我很疑惑為何還要給我看? 不久,我發現了,他希望我認同並支持,因為他的team member對這個架構諸多反對。大家都同意這樣做在技術上正確、技巧上高超,雖然設計上有那麼一點點過頭,但嚴格說起來又並不能說是over design,如果這是一個可以做1年,可以活5年的系統,這絕對是個很優秀的設計。但問題就在,它不是!

因為很多專案外在因素的關係,這個系統並不是這樣被定位的,開發人員對於這個架構有一定程度的抗拒,採用的新技術需要開發團隊學習(但眼前的時程和人力確實來不及),架構師很堅持,一步也不退讓,因為這是他覺得很完善的作品,但team member不接受,你可以強迫developer照做,但我想結果對專案來說,只會造成延誤而已...

這事情還在發展,或許未來我可以多聊聊結果如何? 以及我們怎麼處理。

但我想說的是,很多好的技術、設計、方法,在實現上需要人的配合,別忘了程式設計的主角是人,不只是系統、不只是規格,重點從頭到尾都是人。人是活的,你不能把人當作物品一樣管理,面對物品(專案、時程、規格),你能管理(Management),但面對人,你要帶領(Lead)。

相信我,大多數架構師最缺乏的,絕不是技術、而是溝通能力。(給架構師一句話 : why比how重要,謹記!)

回過頭來說TDD,我至今無法把TDD導入到團隊中,並非我覺得概念不對,也不是我覺得沒有用處,反過來說,這是我幾乎唯一認同的在Scrum中提升產品品質的最好方法。沒有硬推的理由很簡單,就是大家(包含我)都還沒準備好。所以,很可能根本不是TDD的錯,當然也不能說是team的錯,或許只是時候未到而已。

我面對台灣、華南、華北的developer、和我們合作的夥伴都是新加坡的PM、也接觸過新加坡 的開發人員,我只能說,一門技術和方法,到了不同的地方,就是會產生不同的影響和狀況。我們在台灣覺得理所當然的道理,只要搭一趟飛機,很多事情就變得不一定是那樣。(反過來也是)

所以,我再也不敢很大聲的說,XXX就是未來、YYY就是真理、ZZZ就是趨勢...因為我知道,只要你在這行待的夠久,隨著時間,任何技術都會過去、任何方法都會過時。往往,在一個專案中,最佳解僅僅就是『這一刻的最適當解』,換了時空、換了團隊、甚至換了地點,一切都會整個不同。

所以,別太擔心 OOO is dead ,上帝很公平,只要你活著,就會有死的一天。重點是,你每天過得如何? 活的是否開心愉快? 在工作上也是,重點不是哪種技術該被淘汰,哪種技術才是未來,真正的重點是...你的專案是否收到錢? 你的產品能不能賣? 你的team member是否愉快,你的客戶是否埋單...

Long Live Programming.