人物設定：
小菜：具備基礎的計算機理論知識，剛畢業參加工作，從事Java開發，對技術很有熱情，凡事愛問個爲什麼，但是缺少項目實戰經驗，需要進一步培養。
老鳥：高級Java開發，在工作流方面有較多研究，在編程的過程中走過很多彎路，踩過很多坑之後，願意把自己的經驗、教訓分享給大家。
小菜加入公司之後，就參與一個OA系統的請假業務的開發，業務場景如下：
請假人填報請假類型、請假天數、開始時間、請假原因後，根據請假天數，小於等於2天由本部門部門經理審批，大於2天由人事部門審批，審批拒絕後退回到填報人修改，通過後請假生效，在請假到期後，請假人及時在系統中辦理銷假。
小菜拿到需求後，二話不說就開始寫代碼了，首先定義個請假實體
ID，userId(請假人），days（請假天數），startDate（開始時間），reason（請假原因），vacationType（請假類型）
然後編寫了請假申請的頁面，部門經理審批、人事部門審批，辦理銷假的頁面；一天過去了，小菜做得很有成就感，這樣明天再完善，測試一下就應該差不多了。
快到下班的時候，小菜很自信的通過svn提交了自己的代碼，看來今天不用加班了。這時老鳥從小菜身旁走過，問了下小菜今天的工作，小菜說今天做了個請假流程，定義了實體，編寫了頁面，完成基本的CURD操作，明天再努力一把，爭取做完。老鳥笑道：小夥子效率挺高的嗎，讓我看看你的代碼。小菜拿過自己電腦，熟練的打開了intellij，黑色的主題色立馬讓桌面顯得高達上。老鳥看着代碼，臉上的笑容慢慢收斂，眉頭緊鎖，程序員特有專注的表情在他臉上蔓延。旁邊的小菜也跟着認真緊張起來。
5分鐘後，老鳥轉向小菜，問道
- 請假人能隨時修改請假信息嗎？比如我請假2天，請假審批通過後，我能改成10天嗎？
- 怎麼確定是由部門經理審批、還是人事部門審批？
- 部門經理、人事部如何獲取待辦？
- 審批人拒絕後請假人怎麼修改？
一連串的問題，問的小菜有點不知所措，果然不愧是老鳥，一下子就問到問題的關鍵。小菜略微尷尬的回答：“這個問題我還沒想好，我打算明天邊做邊想，不過我……”。“你最好要改掉邊做邊想的毛病”，不等小菜說完，老鳥打斷了他，“編程需要抽象性思維、全局性思維，當你拿到一個需求或者碰到一個問題的時候，首先是要進行充分的思考，理解問題的本質，而不是倉促的動手，倉促編程的結果是設計缺少完整性和連貫性，後期會面臨大概率的返工，還有編程不是代碼越多越好，也不是越快越好，而是又快又好，編程就像寫作，不只是自己看懂，也要讓別人看懂，你的代碼還有很多可以精簡的地方”。小菜認真地聽着，很肯定地“嗯”了一聲，若有所思的點點頭，心裏想到，要是拿到需求的時候能請教下老鳥就好了。
“你剛纔說，不過什麼”，老鳥接着問道。“不過我剛想到一個解決辦法，就是在請假實體上新增一個字段state，用於標識不同流程狀態，然後根據不同的狀態，限制表單是不是可以編輯”，說完，小菜拿起筆在紙上寫了起來。
0=草稿狀態；填報人可編輯，可提交
1=審批中；部門經理審批，填報人只讀
2=審批中；人事部門審批，填報人只讀
3=審批退回；填報人可編輯，可提交
4=審批結束；填報人只讀
小菜寫完後，看了看老鳥，他的表情不像先前那麼嚴肅，彷彿示意他說下去，小菜接着說道：“在獲取待辦的時候，可以根據不同的狀態來識別是部門經理的待辦還是人事部門的待辦”，
“那填報人的銷假待辦呢，如果現在需求變了，大於2天小於10天的請假依然由人事部門審批，但是大於10天的請假人事部門審批後，還需要總經理審批，該如何處理？”老鳥問道。
小菜又陷入沉思，看着那張紙，突然靈光一閃，拿起來在原來的那張紙又畫了起來：
0=草稿狀態；填報人可編輯，可提交
10=審批中；部門經理審批，填報人只讀
20=審批中；人事部門審批，填報人只讀
30=審批中；總經理審批（大於10天），填報人只讀
40=審批退回；填報人可編輯，可提交
50=銷假；填報人銷假
60=審批結束；填報人只讀
“加大狀態碼之間的間隔，這樣隨時便於插入新的節點，可以應對流程的變化”，小菜自豪地說道。
“這確實是一種解決流程問題的思路，很多業務在相對固定的業務流程中使用狀態標識的方式來做流程，但是在一些流程頻繁變化的業務中，這樣的處理方法卻不合適，這裏面會存在一些問題，你能說說嗎？”
剛纔在紙上寫的時候，小菜已經意識到這樣做似乎有些不妥，正好藉着這個問題，他說道：“最大的問題是，業務流程變化總導致代碼的修改，還有就是，多一個節點就要多做一個界面，界面相似，卻要通過Ctrl+C,Ctrl+V來操作”。
“重要的兩點都說對了，你說的核心關鍵字是解耦和複用，如何保證流程能夠隨需應變，面對需求的變化，儘量少地去修改代碼，通過業務和流程儘可能地解耦，來達到代碼儘量地複用，這是流程需要重點考慮的問題。”老鳥果然是老鳥，侃侃而談，專業術語一個個蹦出來。
“業務表單在多個環節處理流轉，從而使得業務得到自動化處理，這就是工作流，其實類似的流程處理都可以用工作流來處理”，老鳥說道。
工作流？這個概念小菜還是第一次聽到，恨不得立馬百度一番，看看到底是個什麼東西？
“交給你一個任務，晚上查查工作流的概念，建議用工作流把重新做一遍，會比現在要好多，我以前剛做類似業務的時候，和你一樣，也是用狀態標記業務狀態，到後來狀態越來越多，程序內部變得越來越臃腫，難以維護”，老鳥說着，彷彿從小菜的身上看到了當年的影子。
“但是我今天寫了一天，重寫的話怪可惜的，能不能把這個做完，後面如果有新的類似需求再用工作流”，小菜想着今天的任務要推到重來，有些不情願地說道。
“作爲一個剛入職的員工，想盡快地做出成果，完成工作任務固然重要，但作爲一個程序員，必須要對自己要有嚴格的要求，要時刻想着有沒有更好的設計，有沒有更好的編碼實現，有沒有更好的算法提高系統性能，能不能通過自動化的工具來減少自己的重複工作，這些對程序員未來的發展很重要，所謂經驗，就是由不斷踩坑不斷填坑的過程，坑填多了，總結多了，下次碰到坑就能繞過去，經驗就漲了，如果只踩坑，不填坑，不總結就光漲工作年限，如果我現在告訴你前面有坑，你又什麼要跳進去？，我見過很多程序員，有的工作了幾年，和畢業相比沒什麼長進，有的短短一年就比有三年工作經驗的進步快，這正是對自我嚴格要求，對新技術保持足夠的熱枕，並勇於實踐。”老鳥語重心長地說道。
“好的，我晚上就看工作流”，停了老鳥一席話，小菜的戰鬥力又回來。
老鳥看看了時間，不自覺已經和小菜談了一個多小時，收拾了下，和收穫滿滿的小菜下班了。
“要是拿到需求多問一下，多研究思考下，說不定今天的工作就不用白做了” 小菜想到。
下篇文章談談如果自己實現一個工作流，應該如何設計並實現。
向《大話設計模式》致敬。歡迎訪問我的網站
JavaCode：http://code.admineap.com
AdminEAP：http://www.admineap.com