Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 八月 2012

劣幣驅逐良幣

leave a comment »

欲速則不達,按部就班才有品質。

現代人用習慣手機拍照,久而久之用單眼費心思的照片就少去整理了。雖然手機像素逐年精進,但比起相機來,品質實在勉強的可以,正是典型的「劣幣驅逐良幣」。

衍生來看這個場景,在怎樣的環境裡,就得去適應怎樣的變化。即便你已經用慣了專業的繪圖軟體,若是把你丟進一個只能用小畫家工作的環境裡,恐怕除了回歸自然以外,也只能感慨叢生吧!
.
Open source vs.  整合式開發工具
Open source裡頭有許多的價廉物美的工具軟體,任何時刻你都可以拿來兜一兜,就成了一組堪用的開發套件,也足夠讓開發團隊拿來應用了。但比起一些需要花錢購買的整合開發工具,就顯現得陽春了許多。如果你早以經用慣了這種高檔的整合工具,例如Visual Studio及TFS這種強勢整合的工具,現在反過來要你去用open source的plugin工具,你該如何處理呢!
.

笑看劣幣驅逐良幣,除了感慨萬千,還能說什麼? ^_^

按部就班的來正確作事:

好的 coding rule: Module – object- design pattern -service.

好的品質條件: Unit test – auto testing -code coverage  … Continue integration- Continue delivery.

. . 也曾經遇過過一些程式設計師,他們從來沒作單元測試的習慣,卻是經常產出高品質的軟體,常常笑說:「一定要介紹Kent Back給你認識,因為你的程式會產生香味!」。但在近代的團隊裡,團隊常不管你是否一人獨行,也要強制規定團隊開發的原則,這種人只怕也要消失了~

廣告

Written by ruddyllee

2012 年 08 月 25 日 at 10:58:57

張貼於未分類

敏捷開發談「交接」

leave a comment »

<<同事離職,引發自己一陣聯想,就把它紀錄下來了>>

一個人若工作一輩子都待在同一家公司,這是幸還是不幸呢?

在離職轉換跑道之前勢必會面臨所謂的「交接」,到底該如何交接呢? 這是一個人生的大課題,有人草草結束,只留下Github上的一個帳號。有人大費周章的準備了許多文件,哪個對呢? 我個人覺得得依該公司、該專案以及交接人員的性質而有所區分。這一點,不想在這裡長篇闊論。但,在現實的世界裡,許多公司仍然採用傳統的Waterfall在開發專案,雖然實施敏捷開發法的公司越來越多,但是要求全公司都能理解敏捷的真諦或是擁有Scrum那種擁抱變化的精神,還真是有些難! 說起來,就好比公有雲、私有雲之爭的結論一般,混合雲才是真實世界出現最多的狀況。所謂的Scrum Under Waterfall 或 Agile Under Waterfall 或許才是真正的多數,所以只單純的憑藉任何一方的理論來談,似乎都有些遷強。而如何在其中做好該做的「交接」工作呢? 這一點書本上好像沒講,前輩們也很少談到這個,所以就來囉唆一下…。

交接重要嗎?

老實說,沒人愛搞交接,但它實在太重要了。對敏捷開發而言,交接是一種成本,這種花費,當然是越簡單越好。但對專案而言,沒了交接,如何讓客戶真正接手,如何讓軟體真正的上線呢!

對開發者而言,不論是交接給別人或是自己,在最後封存程式之前(我常常把有專案要交替時的程式備份的動作,稱之為”封存”),讓我們對自己也對未來可能看這支程式的人,說明白一切的流程,是否都如它所表現出來的一般,或是完全像,程式中的註解上所說的一樣的在運行。

在敏捷開發中,雖然每一個迭代,我們都努力的想交出一個紮實而可供執行的傢伙,但是對這些零零總總的交付,累積效應其實是一直存在的,也就是說;當功能越加越多、程式越長越大,測試的範圍及項目也會越來越多, 當完成客戶需求的具體實踐及測試案例的驗證,也就是說此時才是真正的開始。

讓程式自己描述,把程式交接給自己

對我曾經帶過的Scrum團隊而言,我們通常都會有一個共識(其實是要求),那就是要作好把程式交接給自己的工作。我常常稱它為「封存」,從一開始寫程式時就要注重命名,給變數、函式作最正確的命名。單元測試完成後的第一次重構尤其重要。此時,進行重構的第一件要事便是重新命名,讓程式依照單元測試完的結果重新再描述一便,目的是要讓程式能夠達到自我描述。讓程式碼盡量作到自我說明的動作,同時也讓撰寫程式的人在移到下一個函式撰寫前作最後一次檢查。

Unit test後依靠重構進行反思

依靠重構來完成自我反省並完成交接給自己的工作。這個重構的行為就像一輪迭代一樣,重構的過程feedback仍是重點,當你重構命名的時候,有關於這個函式的輸出入參數及功能也都會一併的擁有被重新命名的機會(這是眼前程式結構在給你feedback),這是交接中極為重要的事情,是給自己的即時交接(也就是對自己所寫出來的程式負責),此時的函式是會自己講話的。借助重構的力量來完成反思,讓函式變得更有意義。

在程式即將封存前,將測試案例(或可說是驗收報告)與測試的結果保存下來

敏捷開發的一個重要目標是要找到文件和溝通討論之間的一個合理平衡。測試計劃與可執行的測試案例以及一些記錄系列的東西,不論是內部或外部直接或間接對程式碼或文件有所影響的行為,這些都是極俱價值的東西。更足以成為程式交接時的好東西,不應該浪費的!

最後,送上Tom poppendick的箴言:

<精益軟件開發>一書的作者曾經說過:「當文件主要用於任務交接時,它們是罪惡的,而當它們是用來補抓交談記錄,使其不被忘記時,則是有價值的。」

雖然交接是一種浪費,但把它做成了有意義的記錄,卻是十分有價值的。

Written by ruddyllee

2012 年 08 月 04 日 at 14:41:43