工作雜談之說說工作中的二宗罪
先來說下近期的工作情況吧，近期一段時間在工作中不是非常如意。非常多事情沒有依照自己的規劃進行，當中最基本的表現是這段時間沒有更新文章。不管是在技術上的文章還是工作上的學習都沒有及時的去思考、反思，可能是跟自己的工作環境或者工作性質有關系吧。
一、需求變更
需求變更麻煩大。近期一段時間最不如意的事當數工作中遇到的困難。接手了上級領導所要求的新需求。也就是需求變更。
遠洋的SOA平臺總共同擁有52個服務包，我們所負責的是現場銷售的服務包，它主要是解決賣樓的問題。該服務包在四月份已經投入到生產環境。客戶如今已經在使用中。但在使用過程中提出了新的需求。而我們呢就是新需求的維護人員。對該服務包的需求做進一步的優化。這也是程序猿最頭疼的問題。開發不害怕就怕需求總做變更。需求變更是要付出代價的，當中最基本的當數浪費時間和金錢，需求變更可能會影響到整個項目的進度，當然緊接著就須要付出勞力、物力、財力，那怎樣最小化的降低需求變更帶來的損失以及怎樣應對需求變更？這是程序開發和設計人員要考慮的問題。在網上查看了一些應對需求變更的方法，最基本的是雙方面的劃分，一是在項目開發前要對需求變更最好準備，二是在開發過程中需求變更的控制。
1.1 開發前
其一：降低需求變更。
想要較好的應對需求變更。開發前的工作是相當重要的，也就是說在開發前就應該預見性的看到會有的需求變更的地方，及早的反應解決可能的變更點。這裏說的並非去規避需求的變更，事實上試圖去規避需求變更本來就是錯誤的想法，需求變更是非常正常的問題。盡管可能會對項目的開發有影響可是它是不可避免的問題，在需求變更時往往是提出新的需求，新增新的需求，這就會導致開發時間及成本的添加，所以一定要在開發前預見性的解決需求變更點。另外須要做的是在開發前要盡量的完備需求，建議開發者或者設計人員採用原型的方法啟示客戶思考功能需求，讓客戶和BA共同思考制定需求標準。
其二：規範化及合理化的設計。在開發前制定需求文檔時一定要註意需求的完備性，所以非常重要的一點是在需求制定的標準。並且在整個開發過程中需求說明書是開發者和客戶之間的重要接口，所以需求文檔的制定一定要具備完整性、一致性、基線控制、歷史記錄等特性，在制定需求文檔時一定要將文檔交付給客戶批閱，在客戶愜意的基礎上確定基線。其次是良好的結構體系，在設計軟件系統時良好的結構體系可以從非常大程度上降低需求所帶來的變更。所以在設計時一定要制定出符合情況的體系結構，在設計系統結構時首先要考慮的要數系統的靈活性、可擴展性、健壯性，這是一個良好的架構所必須的特性。想要設計出高可靠性的架構設計模式就是必需要使用的技術，一定要合理的使用設計模式，在系統的各模塊間或者模塊內部使用設計模式來控制需求變更對開發的影響。
1.2 需求變更控制
需求變更往往是不可避免的。需求變更的控制不僅能夠在開發前，還能夠在開發過程中來控制需求的變更，對需求變更的控制大致能夠分為七個步驟。
其一：變更申請。不管是做什麽事情剛開始想要做都要做申請操作。客戶首先要做變更申請，僅僅要有人提出變更。我們就須要他提出變更申請。
可是往往客戶會在電話中提出變更的要求，這時候的需求變更應該怎樣解決呢？當然不怕。客戶的變更我們能夠轉化為文字記錄吧，把變更記錄下來總能夠吧，這樣在跟客戶交流時就會有憑有據，不怕他抵賴。
其二：技術審批。審批審什麽？技術審批當然是對需求的變更是否可以在技術上實現做出評價。有時候客戶提出的需求非常難再技術上解決，這時候就要及時更客戶協商所需求有問題。當然大部分情況下技術還是可以滿足新需求的。
其三：工期評估。
新的需求的提出，會不會影響到整個項目的工期。須要將工期、成本、質量都要做一次量化，目的是強迫項目組清楚一個變更意味著什麽。這時候對整個項目作出具體的變更工期評估，變更會不會影響到整個項目工期的延誤，假設影響到了，那我麽就必須權衡利弊和客戶溝通對工期的影響，最後確定變更是否生效，假設產品處於著急上線的目的下，需求的變更最好是延遲在更改。
其四：成本預估。項目需求的變更可能會涉及到新的開發者的增加，沒人每天的話都必須支出對應的項目費用，所以必須對項目的成本做具體的預估。預估的目的是為了對需求的變更做進一步更具體的了解。
其五：分析對產品質量的影響。
需求的變更會不會對原有系統的穩定性、可靠性、安全性造成影響。另外需求的變更須要做具體的測試，是否對測試質量影響較大，會不會導致系統的其它問題。
其六：風險分析。需求的變更說大了是大事。變更意味著很多其它的功能，很多其它的功能往往意味著很多其它的工作，會面臨很多其它的變數，也就是風險會很多其它。需求的變更可能會導致項目組的士氣低下。引起人員的流失對項目組造成風險，所以要評估變更的風險。
第七：拍板，定論。
重要到了拍板的時候了，最後要有人站出來說究竟需不須要做需求的變更，假設要變更一定要客戶簽字，讓他知曉需求的變更。
二、程序編碼
開發編碼問題多。
另外非常讓人頭疼的是在開發開發過程中。開發的程序問題百出，最基本的當數程序的代碼問題，在編碼過程中編碼的效率不高，並且對代碼的優化不夠完好。
編碼最基本的考慮系統的穩定性、健壯性、可擴展性。在使用不論什麽對象時一定要記得對對象進行判空，空對象非常easy導致錯誤，另外要考慮程序的優化。盡量避免多次對數據庫的訪問。最好能一次性的查詢出全部數據。
最後在遇到新的問題時一定要理清程序開發的思路，對總體的需求有具體的把控，並對開發的思路有清楚的理解，切記不可盲目的開發。一定要理清開發的思路，涉及到相同的問題時一定要使用同一套邏輯，開發的模式也要使用相同的，不能夠千差萬別，否則會對維護造成負擔。
結語
遇到問題是好事說明自己還是非常不成熟。最基本的是需求變更和程序編碼，需求變更是一件令程序猿非常苦惱的事情，困難沒有出在開發新需求，而是重復的去改動原來的東西，可能會涉及到理解別人的思路，這就非常麻煩了。由於要跟著別人的編碼思路走，非常麻煩。另外從開始開發至今已經做過五六個項目之多了，可是對程序的編碼還有非常多地方須要精化，用最少的代碼實現最多的功能。
工作雜談之說說工作中的二宗罪