首先做下簡單描述，本人從事技術開發也就兩三年的功夫，介於經驗基礎開發過程並沒有很成熟的解決方案，公司也沒有技術大佬，公司是小型技術團隊（10人都不到），所以平時都是自己淌渾水。
上面的描述是背景，正是由於這樣的背景，纔有了我下面的親身體會。好了，開始正題。
最近公司的有個半成品的項目，所以打算在開發的過程中，進行重構一下，總體算是重新做吧，大家理解爲一個新的項目就好。
1、拿到項目的第一步當然是：規劃。
剛開始雄心壯志的苦思規劃方案。前端怎麼規劃，後臺怎麼規劃，controller怎麼放，service怎麼依賴。並且考慮了以後項目變成分佈式該怎麼搞，經過九九八十一天，終於，結構規劃好了。
2、規劃好了，當然是開發功能嘍。
每個項目成員，分配到相應的任務，開始做吧。按照規劃好的結構，把相應的東西放到相應的位置（完美）。然而鬼知道發生了什麼，項目中的代碼依舊是亂，相當亂。舉個最簡單的例子：獲取產品信息，跟我們數據庫打交道的dao層，本來一個方法就搞定了，但是我們三個項目成員竟然寫了三個類似的方法，等等類似的問題，就這樣，對於強迫症的我看的着實難受，但是沒辦法，項目得上線啊，管不了那麼多了，先做功能吧。
3、上線。
最後按照步驟2的習慣，我們的項目上線了。
出現bug了（bug很正常），開始改，同事一個核心代碼，改啊改，我的印象中大改不下5次，小改更多，最後還是總有問題。
天災來了，這個同事有事請假了，有幸（呵呵）去改別人的代碼了，我的天吶，我看到了什麼，一個整的業務邏輯看到頭皮發麻，完全沒看懂什麼意思，方法調用之前，一堆參數用的map傳遞，心裏一驚，硬着頭皮改啊改，最後還是沒有結果，跟技術負責人商量之後，決定重新寫一遍。因爲該業務比較關鍵，但是也相對比較負責，又有前一個同事的例子，所以，開始沒有急於寫代碼，畫了幾張詳細的流程圖，再次跟技術負責人確定之後，開始重寫，加上調試經過一週的時間，這個功能算是搞定了。
bug越改越少，現在基本正常穩定了。
4、優化。
針對客戶的反饋，已經我們客服人員的反饋，開始針對功能進行優化和完善。
5、擴展。
我們的業務要擴展，但是現在的項目太亂了，又跟技術負責人商量一下，確定將我們要擴展的業務重新梳理一遍，好好規劃一番，前期的經驗告訴我，這次規劃的要更細緻了，需要建幾個接口，幾個抽象類，幾個實現類，統一弄好之後，準備大幹一場了。
我們技術負責人看到我的規劃之後。跟我說，你這規劃的太細緻了，影響進度，按我們現在技術團隊，沒有提高效率反而會影響維護成本，技術這東西，不要去套那些生硬的結構，以解決問題爲基礎。我泄氣了，停止了計劃。關於這個問題，我自己思考了整整一天，覺得我的規劃確實太細了，這樣的確會影響進度，好的東西並不切合實際、不實用是沒有任何價值的。
以上就是本次項目的親身經歷和過程中的一些問題感受。那麼，我們的問題來了，項目開發之前（或者說功能開發前）要不要規劃？
首先規劃一詞是沒有標準的。規劃一輩子成爲什麼樣的人，規劃一年的關鍵目標，規劃一個月的關鍵目標，規劃一天具體的計劃。我想這些都叫規劃，但是每次規劃的內容不一樣，你實際做的內容也不一樣，負責程度更不一樣。
那麼我來說說我對項目規劃的理解。項目需不需要規劃取決於實際情況，哪些情況（簡單舉幾個例子）：
a)、BAT這樣的公司（大型技術團隊）：技術人員那麼多，如果不規劃，豈不是亂套了，並且我認爲要進行詳細的規劃。
b)、中型公司（中型技術團隊）：技術人員相對較多，也需要進行規劃，但是可以不用到那麼那麼細微，要看公司實際情況
c)、小型公司（小型技術團隊）：向我們這樣的公司，技術人員不到10人，個人認爲，規劃一下大概項目任務就可以了，所有東西，不管通過什麼方式，先做出來，如果真的有需要，後期再做（或者說等真的有這樣的需求的時候再做），完全沒有必要前期浪費大量時間規劃的太細緻
我相信有很多人都是屈居於C類型這樣的公司的，然而每天都很煩在改東西上，但是沒有辦法，還是切合現實吧。如果你的實力足夠，並且厭煩了改東西這樣的流程，請自行離職，找一個合適的公司；如果你的實力不夠，又厭煩了這種流程，那麼請你靜下心來讓自己成長，待有能力時，逃離這樣的環境。
所以加油吧，少年，努力奮鬥。過自己想過的生活，做自己想做的事。