軟體工程師如同花園園丁 清理程式碼就好比拔草！

　　簡歷上寫上軟體工程師的名號或許聽起來顯得高階大氣，但倘若寫上軟體園丁則顯得經驗豐富。構建軟體專案就像是搭建園藝工程。兩者之間有許多相似之處。首先有個初步計劃，然後將種子種下，但這是個持續性的過程，因為你永遠無法保證產品的最終狀態。我們可以延伸到專案中，並引導其在給定的時間內呈現出所期望的結果，以適應現實環境。“這也是敏捷方法論的基礎。

　　原文作者 Nicholas Tuck 是敏捷開發專業人士兼軟體工程師（園丁），在他看來，軟體工程師就好比園丁，需要用心去灌溉。（以下為譯文）

　　結對園藝

　　結對園藝是一種新的特性。我們知道結對程式設計是極限程式設計技術，是指兩位開發人員在同一臺電腦上並肩作戰完成任務。

　　你會獨自一人建花園嗎？一人挖坑，一人拖著手推車。試想下，在高溫情況下，做著重複性的工作，兩個人總比一個人做得更好、更快且更加有趣。因此，園藝工程也需要結對完成。

　　測試驅動種植

　　測試驅動開發在頂級實踐專家及經驗豐富的倡導者中盛行，它也是大部分開發者採用的新技術之一。回想下你的第一個園藝專案。你去商店買一些植物，並在卡片上大致描述它的API（樣子）並將它埋在土裡。或許有些人不會選擇骯髒的泥土，而有的人則很聰明，知道這些肥沃的土壤很適合使用，巧妙的將兩者結合起來。儘管我們不知道在開始前想要什麼，但是在專案啟動前，應該弄清楚如何去做。

　　真正有經驗的園丁，應先確定計劃，定義花卉的大小以及種植的區域，並確定陽光的需求量，最後朝著這個目標來完成。

　　同樣地，有經驗的開發人員應決策如何實現客戶價值、API介面的最佳方式，首先制定測試，然後努力完成該目標。

　　這並不是說，我們需要確切知道每朵花需要多大的空間，而是確定需要多大區域以及多少陽光來滿足供需。無亂是成功或是失敗，都應有個制定的過程。

　　重構種植任務

　　重構正在改變，但不會影響程式的行為。其中包括清理程式碼，文件，將物件移至更加適宜的地方，增加測試環節等。這對於園藝來說是最簡單的比喻。

• 拔草就好比清理程式碼。
• 澆水和清掃落葉就是提高速度，這也是必做的步驟。
• 移植植物是為了改善風水，改進軟體設計。
• 與松鼠和小矮妖戰鬥，是為了清除垃圾回收，防止記憶體洩漏。
• 修剪是為了移除未使用的功能，更像是重構。

　　人月神話——需要時間

　　在人月神話中常流行有關樹的生命週期的一句話：”懷胎9月才能孕育一個baby，但你卻無法讓9個人在一個月內孕育出一個baby。”軟體亦如此，你不能讓開發者在短時間內完成一個接一個專案，這需要花費大量的時間。”

　　你知道還有什麼事情需要花費時間嗎？園藝！是的，你不可能在一個月內種植出蘋果。它需要時間、陽光，水、修剪、翻土、雨露，需要更多的空間，採摘以及生長時間。所以，你不可能在一天內完成所有這些事情。這就是生命週期。

　　當然，你可以購買具有一定規模的樹，可能它會長的很好，也可能種植一段時間後，樹就死亡了。有人會因樹死了而責怪你，就像你的老闆或者系統工程師會因為購買一個現成的解決方案而責備你沒能力使它工作。

　　有時，你無需購買解決方案，而是買了種子、鐵鍬以及土地，但你必須辛勤工作，給足它時間，才能呈現出最好的結果。

　　設計

　　在軟體專案中，設計往往並不是按照計劃進行的。這也是敏捷實踐建議緊急設計的主要原因之一。這一點同樣適用於園藝。

• 步驟 1：決定新花壇需要多少預算，迭代計劃。
• 步驟 2：準備階段。扯下所有的軟管，下載程式碼。
• 步驟 3：設想下週圍花壇的形狀，任務分解。
• 步驟 4：比預期的最終結果花費更多金錢（真的是因為植物嗎？），零迭代。
• 步驟 5：沒有按照計劃進行，但卻拿出最好的產品，團隊在規定的時間內完成專案。
• 步驟 6：盈利。

　　同行評審

　　說實話，花園不僅僅是為了我們自己，而是為了展現給大家看你是如何的優秀。這就是同行評論。

　　你可能會引起其他人的注意，他們會給你提些意見，比如種植的方式或者澆水的頻率等等，以便你做的更好。

　　持續整合

　　也許你會先將花種植在盆裡，然後再將其移植到花園裡。也許你從未想過在院子裡埋下樹的種子，你種植的，是商店裡的半成品，並儘快的將其整合在一起。

　　我認為，應將花直接種植在花壇裡而不是養在獨立的花盆中。當然這是個比喻，在軟體開發中，我們更善長在大的開發環境中努力奮鬥，相互競爭，很多專家和公司都同意這個觀點。

　　呼叫支援

　　比如，某樣東西著火了，這就需要呼叫資源。Bug就是最好的比喻。在程式碼中總有出現一些Bug，而我們的工作就是以最佳的方式清理這些Bug。但這並不意味著，當看到Bug時，要停下一切工作，而是如果這個Bug很大，你需要立即將其清理掉。

　　建議，充分信任開發者，當客戶發現Bug，協助使用者清理Bug。

　　開發程式

　　殭屍程式在軟體開發中也常見的狀態之一。

　　通常某個專案遇到這種情況，專案經理會對他/她作出一個負面評價，從而促使他/她作出更加有用的東西。在園藝中，你可以購買草坪侏儒（稻草人），幫助你協助管理園林。

　　交付功能

　　在敏捷開發中，最重要的一點就是向使用者提供可用的交付功能。在一段時間內，無論你怎麼努力，只能種植一種植物。在它們開始生長的時候你可能會發現不同的東西。而在敏捷開發中，你無需每天構建框架，很少負責一些無功能的任務。

　　需要記住的是，儘管你不會在一天內培養出一朵花，但你可以進行分批管理。就像短跑或者迭代條件。你砍掉了功能的某些特性，卻在最後的迭代環節中完成了專案。

　　花園會長雜草，你的花園永遠沒有“完工”之日。並不是因為你不再需要在花園上進行投資，你的工程就完成了。如果你不堅持除雜草，你的花園最終會被雜草淹沒，花園周邊的環境同樣也在不停的變化，一個疏於管理的花園將變得越來越難以存活。

　　寫在最後

　　在軟體工程行業中，質疑聲一直會存在，正如我將程式設計師/開發者/編碼者/軟體開發者比喻成軟體園丁。當然，任何比喻都有缺陷（也許並不恰當），但在我看來，將其比喻成園丁這個觀點不錯，因為兩者都需要我們用心去栽培，用心去灌溉。

　　你覺得呢？

　　原文出自： Thesoftwaregardener