質量平台的專案做前後端分離的改版，因為去年已經做的資料分析系統是從零開始的前後端分離專案，本次改造原也打算使用原有的流程和模式進行，但是將近兩個月後進展緩慢，開始反思問題。
設計階段互動和視覺的內容不足以支撐前端的設計，但時經兩個月才發現這個問題。原因主要有兩點：
因為ue的還是採用策略是乙個頁面乙個頁面的詳細設計，缺少了從全域性到區域性再細節的過程，一步跳躍到細節頁面的開發
而且沒有分階段交付，或者說階段劃分時間段太長，如果乙個頁面先出，雙方達成一致在繼續進行就不會有大量工作返工的風險
總之，快速交付快速反饋才能保證整個專案和團隊的敏捷
每個人各司其職，認真工作，但是都不關注自己上下游環節的工作，當遇到新的問題新的情況就不能及時的解決。想起一句話，1+1要想大於2，首先1+1要先等於1
第一點快速交付的地方跟這裡有類似之處，但這裡想說另乙個問題
因為是改造專案，所以犯了開發的通病，想要把之前的坑都填平，還在一行一行碼**階段的本人，就想要每個頁面都一步開發到位，每個互動細節都想糾仔細，想要ui、ue的文件詳細到每個滑鼠操作
當領導提到要先發體驗內測版才想起來做事情的層次，版本也是迭代遞進的，要先保證主流程，然後才是一步一步優化細節。一頭栽進細節就又犯了設計階段的錯誤
所以，要警鐘長鳴啊，真的時時刻刻要記住：不管什麼時候、
做什麼事都要分層次迴圈遞進
其實，在專案問題爆發前，我已經感受到不爽，上游環節交付的東西總不是自己想要的，總和自己想象的有差距。但是，自己卻沒有反思自己到底要什麼？造成這種情況的原因是什麼？也沒有想到要去解決這個問題。現在想來這才是最要命的，這也許就是很多人說的程式設計師最缺的軟技能，畢竟只有發現問題了才能思考著去解決問題。
改進的話，就一定要注意自己工作不爽的時候，一定要對自己對工作的情緒敏感，這個時候多半是遇到問題的時候。這時就要跳出手裡的具體任務，整理事情的經過，思考這件事情到底應該怎麼做？有時候這個問題想清楚真的會事半功倍
這個不應該多說，跟軟體的設計方法是乙個道理，任何環節出現問題都不應該使整個任務停滯，雖然不可避免前後銜接的工作順序，但是最大限度降低上下游不必要的耦合，一方面可以提高效率，另一方面也增強專案抗風險的能力
剛開始寫總結，這沒頭沒尾的估計除了自己也沒有人能看懂，哈哈，也來不及潤色了，暫時這樣吧
關於acm的總結和反思
看了wenwen他們的省賽總結，覺得很不是滋味。覺得自己對自己走下來的一路也需要乙個總結。所以有了如下的文章。我還記得自己第一次走進機房，敲出oj上第乙個題目的激動心情。從那天起，愛上了ac的感覺，那種快樂和滿足。班裡這群人是被班主任牽引入這個黑洞的。感謝她。真心希望每個邁入大學後的信電學生，都有那...
解決專案問題的流程反思
1.要看起來，找綜述等，首先粗略調研問題的背景及發展史，分析每一步發展各自解決了什麼問題，各自貢獻了什麼新的視角或者解決了什麼新的問題？效能？速度？2.根據以上確定當前新的效能較好的解決方案，詳讀對應文獻，最後尋找pytorch實現或其他實現。2018年12月出的pytorch1.0，0.4太老了 ...
解決專案問題的流程反思
1.要看起來，找綜述等，首先粗略調研問題的背景及發展史，分析每一步發展各自解決了什麼問題，各自貢獻了什麼新的視角或者解決了什麼新的問題？效能？速度？2.根據以上確定當前新的效能較好的解決方案，詳讀對應文獻，最後尋找pytorch實現或其他實現。2018年12月出的pytorch1.0，0.4太老了 ...