在想到這個問題的時候，很多童鞋都會篤定回答：我會先構思程序大體的框架，接着就開始寫代碼。
A：難道你就不將你的構思巨細文檔下？
B：一般的編程任務不會太難的話，我覺得YY也很可靠，可能更高效。
A：為什么這么急的寫代碼？
B：手癢~~
先小說下YY。YY即意淫，這里意即寫代碼時，不草稿不文檔，腦瓜里天馬行空，心猿意馬。
我不確定是不是大多數的Coder都這么做？！但我周遭的許多同學確實是這么說的做的。首先，很可能是程序猿對自己的YY思維太過自信，再者就是急功近利——想要一睹自己在寫完代碼后『F7』+『Ctrl+F5』（注：VS2008 C++的生成解決方案和運行的快捷鍵，筆者經常在寫完代碼后，習慣這樣快速運行）的運行結果和預期的一樣。基於這種心態，我們越想去劈劈拍拍敲代碼。
在這學期，我們課程安排里有軟件工程這一門，說的就是軟件從無到有的一個過程，其間包括提出問題，需求分析，詳細設計，軟件架構，編碼測試，接着可能就是RTM。但是，筆者似乎對軟件工程這門課程很有偏見，以為跟我的感覺，它太過教條化，與自己先前寫代碼的方式違背。先說說教材，我們學校選的是《軟件工程導論》XXX版，隨口問了身旁的一位小哥，對這本書什么評價，答曰：“不好！”問為什么還拿來當教材？答曰：“上面印着XXXX精品教材。”筆者想不明白，為什么一本在自由書市無人問津的書籍，還會出第N版（讀重音），還在各高校這么有市場。存在即合理~~呵呵。。。
在前幾天，開始看《代碼大全了》，含金量對得起它的厚度。而它的講解真教人拍手稱快。這樣的書才能被奉為“機經”，被程序猿收藏於案頭架上。當然，代碼大全並不是完整的講述軟件工程，畢竟它只在軟件架構部分“事無巨細”。而想要完整講述軟件工程這一學科，它的每一個階段都可以是一本或幾本書。
扯的有點遠了。任務越是龐雜的時候，零零碎碎的問題就越來越多，而且缺乏『高層設計』和『底層設計』的迭代設計過程，這些問題會越來越凸顯，而且一盤散沙，眼花繚亂，於是很可能前功盡棄，重頭再來一遍，又或者破罐子破摔。思維空間似一張草稿，范圍有限，不容的我們天馬行空，欲在狹小的范圍描述一個龐雜的系統，顯得有些吃力，這時候文檔就越發重要了。如果不以為然，要么恭喜你，你是天才架構師；要么XX你，項目經驗太少。當有項目經驗過后，會發現『YY』顯得蒼白無力。
童鞋們可能牢騷：這些爛大街老掉牙的東西！是啊，明白這些的人太多了，筆者是其中之一，可忍耐非常脆弱，不費吹灰便可被『噼噼啪啪敲鍵盤』的欲望擊垮。所以，如果讀者這么不幸與讀者有類似的經歷的話，當下要做的就是『禁欲』。
不是每個人天生都是天才架構師，都能鳥瞰軟件系統，一來就『噼噼啪啪』干起來。也許這一次的設計不是那么的完美，但如上所提到的，『高層設計』和『底層設計』的迭代設計的過程會讓你不斷的發現其中的瑕疵，完善整個系統。好吧，再退一步講，即便經過設計的系統還是很不合理的系統，那你也能很快體驗到設計后『奮筆疾書』敲代碼的快感，關鍵是意識到這問題的時候，學習才能提高了。
一個設計合理與否的系統很快會自己給出答案。一個顯而易見的方法是，當需要更改的時候，系統需要在多大的程度上被修改。這里提一個蹩腳的比喻：
程序猿==醫生，
客戶有問題需要解決，過來找你。你是醫生，他是患者。
你要經過望聞問切，找到患者的病因（需求分析）
針對病因，找到適合的治療方案（合適的技術）
而當醫生宣布你已經無葯可救的時候，很明顯系統有問題。
學計算機的，對IT稍有些狂熱的人，都會突發奇想做自己的應用，而且這種想法經常有，注重軟件設計的機會，將大有裨益。閱讀《代碼大全了》那會，一個很有趣的地方：說要把界面和數據邏輯分開，而『更換界面的需求（譬如將可視化變為較為容易測試的console）』能回答界面和數據邏輯分開與否。這一提示能夠讓我們日后在設計的時候時刻提高警惕——如果真的有需求要將可視化界面更換為console，數據層和業務邏輯層能否不動聲色。
最后，『真的程序員，敢於直面慘淡的重構，敢於正視淋漓的需求。』，這句話某中意義上是YY高手不思進取，對現實世界的妥協。別急着『噼噼啪啪』，設計下，文檔下，或許不至於慘淡。
筆者沒有軟件工程系統的學習經驗，上述文字自己的所感所想，歡迎斧正。
本文完 2012-11-18