1. 程式人生 > >程式設計師修煉之道(通俗版)——第七章

程式設計師修煉之道(通俗版)——第七章

《程式設計師修煉之道》這本書中的內容挺不錯,裡面包含了很多精華,但一些句子很拗口,所以我就根據國人的閱讀習慣,在不改變原意的情況下對詞句稍加修改,標題中的“通俗版”就是這麼來的。

1、在討論使用者介面時,需求、政策和實現之間的區別會變得非常模糊。“系統必須能讓你選擇貸款期限”是對需求的陳述。“我們需要一個列表框,以選擇貸款期限”可能是,也可能不是。如果使用者一定要有列表框,那麼它就是需求。相反,如果他是在描述選擇能力,但只是用列表框做例子,這個陳述可能不是需求。
找出使用者要做某件事情的原因,而不只是他們目前做這件事的方式,這很重要。到最後,你的開發必須解決他們的商業問題,而不只是滿足他們陳述的需求。用文件記載需求背後的原因將在每天進行決策時給你的團隊帶來無價的資訊。

2、有人會認真考慮用下圖中那些過分簡單化的木棍人來為複雜的資訊建立文件,這可能會讓我們覺得難以置信。不要做任何方法的奴隸,只要是能與聽眾交流需求的好方法,你都可以加以使用。
這裡寫圖片描述

3、製作需求文件時的一大危險是太過具體,好的需求文件會保持抽象。在涉及需求的地方,最簡單的、能夠準確地反映商業需要的陳述是最好的。這並非意味著你可以含糊不清——你必須把底層的語義不變項當作需求進行捕捉,並把具體的或當前的工作實踐當做政策記錄文件。
需求不是架構、需求不是設計,也不是使用者介面。需求就是需要。

4、管理需求增長的關鍵是向出資人指出每項新特性對專案進度的影響。當專案已經拖後了一年,各種責難開始紛飛時,能夠準確、完整地瞭解需求增長是怎樣及何時發生的,會很有幫助。
我們很容易被吸進“只是再增加一個新特性”的大漩渦,但通過追蹤需求,你可以更清楚地看到,“只是再增加一個新特性”其實已經是本月新增的第15個特性。

5、不時地,你會發現自己與一個有很多問題的新專案牽扯在一起:某項工程設計你就是找不到頭緒,或是你發現有些程式碼比你想象的要難得多。也許它看起來是不可能解決的,但它真的有看上去那麼困難嗎?
考慮現實世界的謎題——那些好像是作為聖誕禮物、或是從舊貨市場突然出現的奇形怪狀的小木塊、鍛鐵、或是塑料。你要做的就是拿掉鐵環、或是把T形塊放進盒子裡等等。
於是你拉動鐵環,或是試著把T形塊放進盒子裡,並且很快發現明顯的解決方法沒有用。你無法以常用的方式解開謎題,但即使這很明顯,人們仍然會繼續嘗試同樣的事情——一次又一次——並且認為那樣肯定能行。
解開謎題的祕訣是確定真正的(而不是想象的)約束,並且在其中找出解決方法。有些約束是絕對的;有些則是先入之見。絕對的約束必須受到尊重,不管它們看上去有多討厭或與愚蠢。另一方面,有些外表上的約束也許根本不是真正的約束。
當問題百思不得其解時,換個思路、換種角度,或從其他方面解釋下這個問題,那可能會給你帶來意想不到的驚喜。

6、有時你會發現,自己在處理的問題似乎比你以為的要難得多,感覺好像是你走錯了路——一定有比這更容易的方法!這正是你退回一步,問問自己以下問題的時候:有更容易的方法嗎?

  • 你是在設法解決真正的問題,還是被外圍的技術問題轉移了注意力?
  • 這件事情為什麼是一個問題?
  • 是什麼使它如此難以解決?
  • 它必須以這種方式完成嗎?
  • 它真的必須完成嗎?
    很多時候,當你設法回答這些問題時,你會有意外的收穫,很多時候,對需求的重新詮釋能讓整個問題全部消失——就像是戈爾迪斯結。
    當你正在處理的問題變得越來越複雜時,那多半是你的解題思路出現了偏差,不要繼續往下走了馬上停下來,看看問題出在哪裡,然後重新整理思路,你一定會找到一個更好的解決方案。

7、每個人都害怕空白的紙頁,啟動新專案(或是已有專案中的新模組)可能會是讓人身心交瘁的經驗。我們許多人更願意延緩做出最初的啟動承諾。那麼,你怎樣才能知道,你什麼時候是在拖延,而不是在負責地等待所有工作準備就緒?
在這樣的情形下,我們採用的一種行之有效的技術是開始構建原型。選擇一個你覺得會有困難的地方,開始進行某種概念校正。在典型情況下,可能會有兩種結果。一種結果是,開始後不久,你可能就覺得自己是在浪費時間。這種厭煩可能很好的證明,你最初的勉強只是希望推遲啟動。放棄原型,回到真正的開發中吧。
另一種結果是,隨著原型取得進展,你可能會在某個時刻得到啟示。突然意識到有些基本的前提錯了。不僅如此,你還將清楚地看到可以怎樣糾正錯誤,你將會愉快地放棄原型,投入正常的專案。你的直覺是對的,你為自己和團隊節省了可觀的、本來會浪費的努力。
當你做出決定,把構建原型當作調查你不適的一種方法時,一定要記住你為何這樣做。你最不想看到的事情就是,你花了幾個星期認真地進行開發,然後才想起你一開始應該先畫一個原型。
有一點冷嘲熱諷的意味:從“政治策略”的角度說,去構建原型也許比簡單的宣佈“我覺得不該啟動”,並開始玩單人紙牌遊戲更能讓人接受。

8、作為注重實效的程式設計師,你應該傾向於把需求搜尋、設計、以及實現視為交付高質量系統這一過程的不同方面。不要信任這樣的環境:搜尋需求、編寫規範、然後開始編碼,所有這些步驟都是孤立進行的。相反,要設法採用無縫的方法:規範和實現不過是同一過程——設法捕捉和編纂需求——的不同方面。每一步都應該直接流入下一步,沒有人為製造的界限。如果把來自實現與測試的意見新增到規範中,你將發現,我們的開發過程會更加健康。

9、一些開發者,在由許多已沉沒的專案組成的大海里漂流,不斷抓住最新的時尚,就像是遇到海難的人緊緊抓住漂來的木頭一樣。每當有新木頭漂過時,他們都會費力地游過去,希望這一塊會更好。但到最後,不管漂浮物有多好,這些開發者仍然漫無目的地漂流著。
新工具、新技術只是我們達到目標的手段,最好是不要為了學習而學習,不要忘記學習它們的初衷是為了解決問題。