最近，寫了快大半年的公司系統，終於進入了最後的階段，幾經波折，在開發過程中，也遇到了許多的難點，趁記憶猶新時紀錄下來，統合思考一下，希望下次能少走點彎路。
第一步，確認需求(功能)規模
由於這是轉換公司後的第一個多人協作的大專案，加上上頭時間給的蠻充裕，沒做太多想法，就草草的開工了，並沒有仔細的確認每個功能的關聯性，
開發到後面才發現原來有幾個功能是會互相影響的!!真的是麻煩大了，發現時也已經逼近收尾，真的是自己挖坑給自己跳…
應該在收到設計稿時，就要仔細的與設計師確認功能的規模及關連性，免得自己又要開夜車補救及重構QQ
第二步，避免重複造輪子
由於專案的頁面眾多，且為多人協作的專案，難免有些重複的邏輯功能，例如搜尋、正逆向排序等，常常A與B同事有重複的邏輯，但大家都寫了一遍，
後來經過小組會議溝通後，將邏輯抽出共用，這樣若有需要維護並修改時，才不會要維護多個重複的程式片段，省時又省力。
第三步，切頁面刻化邏輯時，多想一些邊緣案例
由於專案有一個前後版號文本比對的功能，需要由前端建構出相關聯的巢狀邏輯，比對各項欄位是否有變化，且切換文本時，更新的文本內容不能變動，換回當文本時仍需保留暫存，
屬於相當複雜的一個大功能，當初在設計架構時，並沒有構思太多異常案例(覺得使用者提出的需求，自己應該清楚如何使用)，但寫的越深入，發現有許多邏輯會互相地衝突，且有些邊緣案例真的是會出現的，使用者體驗並不好，身為一個設計者，真的無法忍受，也是不斷地重構，但若在當初，能由使用者的角度出發，而不是設計者的角度出發，是不是就可以避免一些時間的消耗呢?
經歷過這次的經驗，程式寫的快，不如構思的仔細來的好，當然沒有程式是一開始就完美的，但我們應該以更多不同的角度或是投射在不同的角色去解決及思考。
第四步，遇到卡關的地方，也許是真的需要休息一下了
在開發過程中，真的是遇到許多的關卡，很多思考上的盲點，常常苦思卻還是無法繞出迴路，同事提醒我，不用浪費時間在已經卡住的問題上，明天問題就解決了。
一開始並不是很了解這句話的意思，經歷過幾次後，發現其實不是自己不會寫，是腦袋累了跳不出那個迴圈，離開座位走個幾步，回家休息個一晚，過陣子再來看時，就發現了解決問題的方法(佛系coding也是很重要的)。硬想要寫，還是錯的那種感覺，真的是很痛苦XD，或是跟組員討論自己遇到的難點，在討論的過程中，也常常有靈光一閃的解決辦法。
第五步，溝通比甚麼都重要
有時候想說開發這個東西，應該對使用者體驗有所幫助，但提交給sa檢查時，卻被問說為什麼要多想這個東西呢?這不是與某一部分衝突了嗎?會不會反而造成困擾呢?
我才發現多做不一定是好的，應該先與設計師及架構師溝通，這究竟是不是feature，是不是在這個時間點應該實作的功能?還是可以在下一階段再開發呢?
多些溝通避免自己白做工，還沒有好果子吃QQ
第六步，不要偷懶，偷要付出的時間
在開發某部分功能時，擅自的想說這個地方可以省一點邏輯判斷的邏輯，就偷了一層的組件抽象實作，還沾沾自喜的想說，省了兩三天的開發時間，開心得很xd
但在一次的會談中，設計師改變了flow的走向，變得需要實作抽象了，真的是欲哭無淚，加上功能及接口都開好了，像是被打了一巴掌般，心裡有種熱辣辣個港覺，真的是不要偷懶，該開的就是要開XD
第七步，重新過濾每個功能及邏輯
常常隨著開發時間的進行，程式碼庫越長越大，在不經意的情況下會許會使用一些不需要的變數及函式，刪刪減減，有些東西就這樣被遺忘了，但這並不是一個好現象，
程式庫應該是要時常回顧及改寫優化的，在每一次的優化及減化下，不論是時間複雜度或是程式碼的decode時間也會有所減少，且對自己的邏輯也會更有把握，透過不斷地重複去精煉自己的思考模式~
結語
透過這次的開發，也是對程式開發有了新的認知，多思考多溝通，多方嘗試，不要先預設使用情境，畢竟程式設計師是以另一個視角去開發的，我們很難一次就勾勒出真實的使用情境!
不要害怕溝通，說不定會有意想不到的收穫~