青潤，來點評一哈我在16樓的發言可好？http://topic.csdn.net/u/20091201/18/f3d35634-a780-4b9f-9a6d-acaaa24ac0ac.html

看到後，我過去看了一下，下面是我的回覆：

西西給我發訊息，讓我過來看看。
整體上西西說的很不錯了。表揚的話不是我擅長的，我擅長批評，所以，大家多多包涵。
循序漸進，按照規律辦事，這是做任何事情的基礎，違反規律必然會受到懲罰，自己想想，我們寫程式碼的時候其實也是一樣的。
不過，關於西西提到的（4）測試驅動開發、步步為營，這裡有一個問題不好控制，比如說，寫程式碼時候的思路，不知道大家是否有過這樣的經歷，反正我有過很多 次，有些時候，我們對一個模組考慮了很久都無法下手，或者寫出來的程式碼總是磕磕絆絆的，流暢性很差，但是，在一些特殊的時候，頭腦中就很有靈感，一兩個小 時可以寫出以前幾天甚至十幾天都寫不出來的程式碼速度和程式碼質量，當遇到這個情況的時候，步步為營反而會影響思路的展開，形象一些的比喻就是：胸有成竹的那 種感覺，或者如同王羲之寫蘭亭序那樣，縱橫開闔，一瀉千里，痛快淋漓之至，這時候寫出來的程式碼質量也是非常之高。
我02年5月在上海做許可權系統開發到第三個版本，從一對n到m對n授權（每個人可以接受多個不同的許可權，每個許可權分配給多個不同的人）版本修改的時候就是如此，全部程式碼在三四個小時內一氣呵成，完成後，一次通過全部測試。
這個時候如果有人讓我步步為營，我估計非要拿刀把他劈了不可。

軟體開發是個人性化很強的過程，一切都是人為，一切都是與人相關，管理手段和措施都應該圍繞著人，如何激發人的主動性和促使人的積極性提高而活動，當然，在國內還很少有管理者能做到這個層面，包括外企業是如此。
軟體開發中的隨心隨意也應該有所控制，但是控制到底到什麼程度，就需要管理者自己的經驗和膽量來作決定了，至少目前做出這樣的量化是比較困難的，所以，也 許說水無常形，事無常規更合適，不過，這就要看管理者了，不是任何人都應該去享受這樣的管理的，畢竟人、公司、團隊千變萬化。

好了，其他的就不多作評論了。

引用 16 樓 slowgrace 的回覆:
給你另外一個視角供你參考吧。

我覺得要一開始就把程式碼的整體結構（我沒用“架構”這個詞，因為“連連看”是個不算大的應用）寫的很好、很科學是不大可能的，所以有人提出軟體開發中要“擁抱需求的變化”。

為什麼不可能呢？因為軟體的需求很難在最一開始想得非常清楚，即使是專業人員也做不到。（跑點題，其實我覺得所有事情都不可能一開始就想得很清楚，都得邊 做邊調整）。所以，可能最佳的工作方法像開車的時候把握方向，你不會一直沿一個方向不動，你會向左調一點、再向右調一點，然後持續一陣，然後路況變化，然 後你再繼續左右微調。（這個例子不是我舉的，是“極限程式設計”的作者在他的某本書的前言裡提到的，我用自己的話複述一哈:）

既然軟體在開發的過程中不可避免地要“返工”，我們不妨在開發軟體之初為未來的“返工”打好基礎。有一種打基礎的方法叫“測試驅動開發”，這個的基本思想 就是在你開發的過程中你先寫好測試，如果你要返工，沒關係，你儘管改，但是改了之後要確保之前你寫下的所有測試仍然能夠通過。

還有一種為“返工”打基礎的方法叫“重構”。別被這個詞嚇到，它無非是指，如果你遇到重複的程式碼，記得把它剝離出來成為一個單獨的單元（或函式，或類的方法），以便日後你要返工的時候只要改這一處，而不是滿世界重複地修補。

還有一種為“返工”打基礎的方法叫“路標”。這是我杜撰的詞。其實就是註釋。要知道“好記性不如爛筆頭”，甭管你多年輕、記性有多好，你也會忘記之前你的 邏輯、你的用意的。為了返工時不至於太難過，給你的每個函式每個模組加上註釋頭吧，M-ZTools可以幫你做得更容易一些。

“重構”和“路標”我做得挺多，我覺得在VB裡還是很容易做到的，只要你足夠有心。“測試驅動開發”我曾經嘗試做，但是後來因為要學習些基礎知識，暫時擱 置了。也曾經和趙老虎等童鞋探討過在VB裡這樣做的可能，也還沒有得到讓我信服的結論。但不管是否要像“測試驅動開發”倡導的那樣先把測試集寫好吧，至少 你要做到“步步為營”。所謂“步步為營”是指，每做完一小段程式碼就立刻測試，確保你的程式碼可以正常工作，切忌寫了一大堆程式碼，還沒有任何測試。

對了，還有，你得有“地圖”（這個也是我杜撰的名詞）。所謂地圖就是指對你的軟體的整體描述文件，也許只是一個簡單的框圖。這個非常重要。一開始寫程式碼的 時候，你覺不到它的重要，程式碼量增加後，你就需要它了。你需要這個地圖告訴你，你的軟體包括哪些模組，它們之間是什麼關係，你的比較大的幾個模組分別實現 什麼功能，其中包括哪些函式過程方法屬性，你要分門別類的描述它們，省得寫重複的程式碼。

對了，還有一點，保持程式碼短小，據說是比較推薦的做法。如果功能複雜，不妨把它分割成幾個sub，在主sub力分別呼叫這幾個sub。這樣你的程式碼邏輯看起來會很清晰。其實這也是一種重構

小結一下：
（1）路標
（2）地圖
（3）重構：讓程式碼簡短無重複
（4）測試驅動開發、步步為營

從軟體整體上看，國外的管理強於國內，國內的管理大部分比較鬆散或者過於苛刻，差別就在於對度的把握上。可以說過於苛刻或者過於鬆散的管理都不利於程式設計師更好的發揮自己的主觀能動性去創造更好的價值。

水無常形，地無常勢，事無常規，人無常念，並不是否定必然關係或者否定管理或者否定穩定，其實是在另一個層面對穩定，對必然對管理的肯定。

——其實仔細看看就明白，這段話說得就是辯證法的內容，是我們初高中時候學過的政治理論課上講過的東西，只是當時我們都無法理解，也不會應用，強硬的灌輸，並沒有帶來太好的效果。