乙個服務程式前後寫了幾年之久，幾乎是在公司的發展之初就做出來。前後根據無數的需求加以修改，其中有技術需求有產品需求。服務程式的控制命令就有上百個之多！看似很雄偉的大樓卻少有只言片語，一點文件都沒。如今乙個功能的邏輯流程有了問題需要修改，但顯然不是很嚴重的問題，只涉及到了部分**在邏輯層次上是否流暢。或者多幾個判斷多也可以解決的整個問題。而不必修改邏輯流程，這個時候想當然的是就加幾個判斷解決這個看似簡單的問題。錯！
先來看下困境，邏輯流程如果要修改就要檢測相關的需求。按照絕對沒有，沒有用處的**，反推回來，所有的**都是有作用的。但用**來分析當時的功能需求的工作龐雜而難以操作。這裡正確的思考方式是收集所有功能需求結合新**邏輯整理乙個套新的**。如果沒有相關的文件沒有人會知道這段**需求是什麼！！！這麼困難的事情就是連原始的作者也會搖頭的。任何人也都不能保證新做的**不會缺少功能，會和現在執行良好的**一樣執行良好。分析所謂利弊之後大部分人的選擇是修改加上幾個if了事。
接下來會發生更糟糕的事情，如果乙個窗戶做歪了，在把窗框弄破來合適窗戶，也許還弄了幾個洞之後，人們的心態就發生了微妙變化。
乙個窗戶破掉的車子會在幾個鐘頭之後就拆的無影無蹤的。
接下來說點技術的事情乙個函式拆分和復用。
良好的語感是所有程式語言通用的，不論是物件導向還是非物件導向。好比優質的**，邏輯不清結構混亂的敘述雖然不會讓機器混亂，卻會讓閱讀者難以接受。經過多年的沉澱所有程式語言不外乎if,while,for的邏輯結構。有些人可能2句話說清楚，有些人可能說10句。乙個函式完成多少功能也完全憑藉經驗積累。有一種理論是所有函式就只描述最簡單的功能。讓人不敢苟同。我個人就很討厭那種串在一起的函式塊。函式功能的分割最好是建立在功能的分支上或反覆迴圈執行的大段程式。但個中原則也只能靈活把握，盡量讓人能看懂你要說的話。並且自己說的話不會天馬行空，讓人看著像精神病的咿語。
LineDDA的乙個例子
unit unit1 inte ce uses windows,messages,sysutils,variants,classes,graphics,controls,forms,dialogs,extctrls,stdctrls,buttons type tfmmain class tform ...
SQL GROUP CONCAT的乙個例子
我有乙個這樣的資料庫 user info 現在有乙個需求是把這樣 9 條記錄按照 username 來 group 成3條記錄 目標 shu female 201 lee male 202 yuki female 181 如果用select from user info group by usern...
explode的乙個例子
select level as level,explode split 1,2,3 as value 可以生成結果 level value level 1 level 2 level 3 lateral view 1.lateral view 用於和udtf函式 explode,split 結合來使...