有些程式設計師可能很輕鬆()... (轉)

有些程式設計師可能很輕鬆()... (轉)[@more@]MSDN Online Voices - More or Hess：演示剖析

你們有些員可能很輕鬆：舒舒服服地坐在桌子前，按照事先精心設計的規範編寫程式碼。面前的里程碑經過精細策劃，清楚地標識著組裡所有成員為之奮鬥的功能目標。在開發週期的某些階段，你們會進入所謂“最後衝刺”的階段。計劃風險重重，當然，每個人都要工作到深夜，還要在週末加班，才能完成計劃。儘管如此，你們面前的道路往往是清晰可見的。大家很清楚自己要去哪裡，怎樣才能到達。

另一些程式設計師的境遇則完全不同。這些人設計和開發的程式碼僅僅是用作演示，或者是用來展示即將開發的解決方案的原型。不是每個公司都進行和需要這種開發的。但是毫無疑問，這種工作需要一類不同的程式設計師，同樣，這類需要一類不同的程式設計方法。

我這裡所說的演示並不只是在觀眾面前演示一個已完成（或接近完成）的應用程式的功能。我所說的是，在對於“實際”產品還根本未做多少開發的情況下，對產品演示進行的設計與開發。這種演示用來向管理人員、合作伙伴和投資者展示應用程式和技術所具備的“潛力”。

在一個基於 GUI/ 的環境中工作，在開發週期中的某些時候，一切都取決於它“看起來”像什麼。而如果演示的目的是喚起興趣和製造興奮，演示的視覺效果就往往會成為清楚闡述意圖的關鍵。

想象一下如何演示將 PC 連線至家庭自動化。你的應用程式上有個按鈕，上面寫著“關燈”。你按下按鈕，燈滅了。是啊，真沒勁。現在，想象一下這個演示是用 PocketPC 來做的。螢幕上出現的是房間佈局的俯檢視，還標出了燈的位置。演示者使用“拖放”功能從房間裡選擇了幾個燈，把它們拖到 PocketPC 螢幕的虛擬開關上。然後，演示者輕輕一按螢幕上的虛擬開關，所有選中的燈都滅了。接著，演示者將虛擬開關拖到房間裡代表開關的圖示上。他走向開關並輕輕按下開關，所有的燈又都亮了。是的，還是一個簡單的演示，不過給人的印象比第一個深刻多了。從技術角度講，這個演示實在沒什麼變化；改變的只是進行演示的方式和完成演示所使用的道具。

需要著重注意的一點是，這樣一個小小的自動化演示，並不能代表在通常情況下的使用方式。我的意思是，有多少人願意這樣來開燈和關燈呢？——不得不開啟 PocketPC，檢視房間的佈局圖，選擇燈，把它們拖到螢幕的按鈕上，然後按下按鈕。在現實生活中，這樣的工具的使用時間是很短的：第一次自動化系統時用它們來“設定”房間裡燈開關的物理位置，然後就很少使用了。但是，如果你只是走向一個實在的開關，輕輕一按，一盞燈亮了。然後告訴觀眾：“相信我，這盞燈是透過家庭自動化系統與開關連線的。”這樣的演示又怎能讓人興奮呢？

要完成這樣的原型和演示，需要一類略有不同的程式設計師和一種不同的思維方式。一切以一個演示指令碼開始，這個指令碼用來簡單地介紹你認為能夠打動人的演示是什麼樣子的。也許你需要使用像 Adobe PhotoShop 或 ® 這樣的工具來製作幾幅介面模擬圖。這樣可以推動程式，幫助組裡的其他成員從總體上把握演示需要傳達的概念。下一步，你需要編寫一些底層技術基礎結構——只要足夠讓你連線部分並令其工作即可。然後，開始建立要使用的視覺介面，要儘量讓它們引人注目。

在這一過程中，讓許多開發人員比較難以理解的一點是，他們很少根據一個定義清晰的技術規範來展開工作。他們不是在建立一個能夠完美工作多年的、穩定而結構完善的基礎結構；他們所做的是迅速將剛好夠用的真實程式碼片斷拼湊在一個新奇的介面下，從而使演示儘可能真實。

設計這種演示的時間要求往往也很殘酷。設計演示方案的時間距演示時間只有幾周的情況是很常見的。任務組迅速地分配任務，以求在最後期限內完成一切。正在這時，經理走進來向大家宣佈，公司的副總裁聽了有關演示的介紹感到非常興奮，下週就想看到演示。當天，過了一些時候，經理又回來告訴大家，公司的 CEO 將在第二天召開員工會，希望在會上看到演示，以便定位它和其他幾種正在開發的技術。這樣，曾經是兩週的期限——這已經夠短了——突然被縮減到僅僅 24 小時。生命之車駛入了快車道。

但是，對於開發人員而言，最困難的可能是臨時性的通知，整個演示可能會被更改，甚至變得面目全非。就其本質來說，這些演示需要快節奏而且富於動感。作為基礎的指令碼和方案經常在一天之內發生根本性的改變。由於開發人員被飛速塗寫的概念弄得無暇喘息，他們的工作方式經常是與其他成員進行頭腦風暴式的討論，以確定怎樣才能使演示更打動人、更好地闡明計劃開發的底層技術。

現在，想象你已越過了所有這些障礙。你和隊友們已經建立了一個令人興奮的演示方案，該方案與某些底層技術具有很好的聯絡性。在整個過程中，你把自己想象成電影“星際旅行”中的總工程師，經過與敵人的浴血奮戰奪回傳送器，重新回到了自己的時空。你控制了局勢，但只是暫時的。現在，真正的考驗到來了。公司管理層要觀看你的演示，以決定你的方案是否值得人員和資金的投入——這是賦予方案生命力的必要因素。

讓我們假設演示進行得非常完滿，不只是演示方案本身抓住了觀眾的注意力，你甚至還為一些可能被即興問到的功能做了準備。當然，如你所料地，一些問題被提到了，而演示恰好能夠說明被詢問的情況是如何處理的。這可以說是數週——有時是數月——以來長時間艱苦工作和無數次反覆設計的最完美的結局。

面對這種情況，最可能出現的問題是：這個演示“過於”完美了。它看上去工作得如此完美，將有關的技術闡述到了如此程度，讓觀眾們認為大部分工作已經完成了。他們不能理解為什麼你需要兩年的時間和四倍的人員與預算來完成這個程式：它看上去只用了三週開發時間，而且已經完成了 80% 的工作。

有時候，生活就是這樣不公平。