下面是我總結的我們開發流程跟一般正規開發流程對比
從流程圖來看我們的開發流程跟標準的開發流程差別有點大。但是其實還是有相同點的。
一般標準流程跟我們的流程都大致可以分為三個階段：前期準備-----編碼------測試。標準流程一般是乙個階段乙個階段走，各個階段不竄差另乙個階段的事情。但是現在我們進行到的前兩個階段都沒走好。在第二階段經常需要停頓下來重新整理第一階段需要做的事情，然後再接著走。這樣多次以後就一點點影響原計畫，最後就跑偏了。
前期準備：需求沒有確定，技術可行性沒有考慮清楚；
編碼階段：由於需求沒有確定，技術可行性沒有考慮清楚，不斷變動已經寫好的**，不能按標準流程開發，也很難按原計畫開發；需求不確定，更沒有清楚的把需求分成不同的階段來開發，開發的時候很容易偏離當前的重點糾結當前不太重要的功能
如果現在返回專案一開始，我們憑藉現在的經驗，可能還是會犯同樣的錯誤。
編碼階段：如果前兩個階段都沒有問題，那編碼不會有什麼問題，而且速度會比較快。但是如果前兩個階段沒搞好，編碼就蛋疼了。
我們的初衷是按照標準流程進行開發的，但是標準流程各個階段要銜接妥當，需要每個階段精確的控制做好每一階段的任務，而且兩個階段之間需要有詳細的精確的文件。比如說，整個專案所有的功能具體實現，由於太多如果沒有詳細精確的文件，做著做著肯定會跑偏了。大家都在不斷的理解專案，沒有乙個標準慢慢地大家理解的專案就不一樣了。要形成精確的詳細的文件，又需要搞清楚需求。然而現在我們的需求看似清楚，其實還是模糊，而且經常因為各種原因變動。一邊開發，一邊改需求，此乃江湖大忌！把乙個想法用**實現的麻煩程度通常要比一般人想象中要高得多。比如乙個看似很小的改動，有時需要改動整個專案大多數的**，同時又會引起其它看似不相干的**出現新的bug，然後又是一大堆改動。由於經驗不足，我們幾乎每個階段都偏離了一般標準流程。然後就變成了現在的流程。
我感覺，一般標準流程適合有經驗的團隊，中大型專案，而且團隊對每個階段的控制力要強，每個階段做好每個階段的事情不跑偏。我們駕馭這樣的流程有難度。或許我們應該改一改方式。把專案任務進一步細分。比如這樣：
先不管其它亂七八糟的功能，只做出核心的功能中的乙個。確定司機發布路線的需求-----想想怎麼實現------寫**實現-------看看能不能跑通-------如果沒問題就搞下乙個。如果一次做的東西小到一定的程度，流程上的不規範影響就會小得多，這樣進度也好掌握。這樣還可以一邊體驗已經完成的功能作為依據設計沒有完成的功能。設計好了再來一輪流程，這樣就乙個乙個的搞定了。對整個專案有一定整體把握的情況下把整個專案拆分成可控的跟小的粒度乙個乙個完成，並在完成的過程中不斷調整。這種方式不一定靠譜，不過可以試試。
階段性總結
今天聽學長交流了一些人生的經驗，便有了一些感觸，加上對自己最近的學習狀態的總結，就寫一篇部落格給自己一點指示。最近渾渾噩噩的，有幾次考試也沒考好，考後也沒總結。晚自習本想刷一些題，複習一下，或是學習一點技術。看見其他同學在打擺，便動搖了。最後心中也只是徒留深深的罪惡感。所以我也是時候對自己的未來進行...
階段性總結
感覺上個星期還挺痛苦的，因為要練演算法，每個人都告訴我說演算法很重要很重要，但是演算法對我來說就像是一根很亂的神經，一觸就炸了，可我的驕傲還不允許我放棄。在leetcode上練習的時候是直接告訴用什麼方法，在寫藍橋杯演算法的時候就像是閱讀理解，經常讀不懂是什麼意思，要不就是理解錯誤，追根究底還是做的...
自考階段性總結
週六日這兩天的自學考試就這樣隨著落日再是告一段落，這是自己經歷的第三次自考。就著這一步走來的歷程著實令人緊張而又亢奮的，一次次的考試，乙個個課程的考試，讓我們朝著自考畢業證更進一步。總體而言，自學考試的經歷實在難稱完美。頓時轉折自己的學習需要不斷總結，需要針對這一屆的學習方法來個總結，思考這樣的學習...