本文總結了開發時間思考（四）.

本篇接上一篇《開發實踐思考（三）》，繼續彙總思考點，每篇10個。

1. 使用引用來捕獲異常

通過引用捕獲異常，不會有物件刪除問題，也不會發生slicing異常物件問題，異常物件只拷貝一次。

2. 資料繫結思想

將UI展示資訊和實際關聯資料繫結在一起，而不要人為拆分開。

舉個例子：

假設有一個下拉輸入框，裡面有：蘋果、香蕉、全部等三種選項。對應入參為1、2、空。那麼按照上面的思路，是將文字，例如蘋果和"1"建立關聯關係。當需要獲取對應的入參時，可以直接獲得“1”，而不是先獲取“蘋果”這種字串，再通過各種if推匯出數值"1"，後面這種硬推導的方式，筆者稱為硬編碼。

且不說硬編碼中轉換函式歸屬問題，這種實現方式在擴充套件性和使用上都不方便，很容易遺漏，不建議使用。

更進一步思考，這種資料繫結思想，可以用在多語言、多顏色、多風格等場景。將繫結關係寫在配置檔案中，使用配置中的key初始化介面資料，繫結對應的value進去。系統初始化時，根據不同環境載入不同配置檔案，得到不同的效果。

基於上可以更進一步，配置檔案增加版本資訊以及校驗資訊，啟動時由後臺推送，達到配置實時升級的效果。

3. 總結覆盤

任何工作都需要回顧總結，大到系統專案，小到具體需求，如果在完成後缺乏總結，那麼從某種程度上來說是失敗的，有以下可總結的方向：

1. 通過這個專案/需求，是否吃透了某一塊的業務，搞懂了來龍去脈？
2. 通過這個專案/需求，是否充分理解了公司某個技術框架/基礎元件的用法？
3. 整個專案的設計上，有哪些做的不好的地方？
4. 在整個專案的開發上，是否踩了坑，犯了低階的錯誤？
5. 在整個專案的進度把控、人員安排、上下游協調上，是否存在不足之處？
6. 遇到突發事件，是否快速有效的進行解決，缺乏哪些東西阻礙了問題的快速解決？

通過充分的總結，之前犯過的錯誤我們不會再犯，理清楚技術和業務的來龍去脈，對自己是一種提升，總結沉澱下來的文件，對別人也有很大幫助。

4. 理解消防

消防，消指的是消除問題，防指的是預防類似問題再次發生。在平時的處理Bug以及線上問題上，也是同樣道理，先及時解決問題，然後深挖問題根源，對問題進行復盤。

不僅僅要解決已出現的問題，更重要地是挖掘隱藏的同類問題，一起解決。

通過分析同類問題，分析出現該問題的根源，從最佳實踐、規範用法等方面向團隊成員講解，防止後續犯同樣的錯誤。

5. 海恩法則

海恩法則是航空界關於飛行安全的法則，它指出，每一起嚴重事故的背後，必然有29次輕微事故和300起未遂先兆以及1000起事故隱患。據此分析，

當發生一件重大事故後，我們在處理事故本身的同時，還要及時對同類問題的“事故徵兆”和“事故苗頭”進行排查處理，以此防止類似問題的重複出現，及時消除再次發生重大事故的隱患，把問題解決在萌芽狀態。

海恩法則強調兩點：

1. 事故的發生是量的積累結果
   2 再好的技術，再完美的規章，在實際操作層面，也無法取代人的素質和責任心

6. 釋出注意

新功能上線釋出時，要有平滑過渡機制、應急處理機制、舊方式下線方案等輔助措施。

每釋出一項新功能，都需要有後臺開關來控制，一些有可能會更改的引數，不要在前端寫死，而是通過從後臺獲取的方式來進行。這樣，當出現問題後，不至於沒有控制手段，眼睜睜的看著問題擴大。如果涉及到的業務較多，那麼開關控制粒度要細，包含功能總開關和各級子功能開關。

對於每個線上釋出版本，要進行分支封板操作，在該分支上，除非有線上緊急Bug，否則不能有任何提交，保證線上版本和原始碼版本的一致性。當該版本線上有問題時，取出該版本分支進行處理。

7. 開發目錄和釋出目錄

不要從開發目錄中直接打包程式，因為開發目錄會頻繁改動，貿然打包，可能會導致以下問題：

1. 打包時，本地還有未提交到程式碼庫中的程式碼，打包後輸出給測試，後續繼續在開發目錄中修改後再提交，這會造成測試版本和開發分支版本不一致。
2. 如果本地尚未提交的程式碼被撤銷了，而打包的是撤銷前的程式碼，也會造成測試版本和開發版本不一致。

最佳實踐：
釋出目錄需要獨立出來，在該目錄下，通過自動化構建指令碼，從程式碼庫中獲取最新程式碼，編譯成Release版本後再發布。該目錄只做編譯釋出工作，禁止任何程式碼以及配置的修改。

8. 彙報工作

撰寫工作彙報的作用：

1. 讓領導看到你，不做職場小透明。

   你寫了工作彙報，領導才知道你做了什麼，才能看到你。

   對於你來說，只需要面對一個領導，但對一個領導來說，要面對多個下屬，均攤到每個下屬的注意力實在太少。而他了解員工工作情況最方便的方法，就是看工作彙報。因此，當你敷衍工作彙報時，實際上是在敷衍自己。

2. 及時調整工作方向，避免做無用功。

3. 在工作彙報中，不僅要寫已經做過工作的結果，還要寫中間遇到的困難，目前採取了哪些方法，需要什麼樣的資源來協助推進。讓問題提前暴露，不要讓問題爛在我這裡。

   作為領導，最擔心的是下屬遇到了問題，卻不告訴他，直到該問題帶來的影響越來越大，最後兜不住了才爆發。
   領導就是你最大的資源，要好好利用。

一份優秀的工作彙報需要做到：

1. 描述工作背景: 在彙報工作前，要說清楚這件事的背景

2. 當前該項任務遇到了什麼問題，當前採取了哪些措施，取得了哪些效果
   一方面體現解決問題的能力，另一方面體現總結能力。

3. 彙報工作結果並進行小結。
   當前該項任務進行到哪一步，有沒有階段性的成果輸出，輸出數字跟過往相比，是增加還是減少了？簡要分析下原因。
   實事求是，不要擔心業績降低就不彙報，報喜不報憂在這裡是不適合的。
   只要你嘗試解決過問題，就要寫出來，讓領導看到你是在推動問題解決，而不是坐等問題在自己這裡爛掉。

4. 未來的打算和計劃
   彙報完過往之後，接下來要說未來的計劃和打算，讓領導稽核下，未來計劃的可行性，未來大方向下的繼續前行的必要性？
   無論是過去的工作遇到了問題，還是在新的計劃需要領導幫助，都要及時提出來，讓領導知道你的難處，解決你遇到的麻煩，需要什麼樣的資源來推動該問題的解決。

在撰寫工作總結時，有以下套路可參考：
* 業務功能開發（其實是做需求）
* 業務功能優化（其實是改Bug）
在寫解決Bug，不管解決過程多麼驚心動魄，解決方案多麼合情合理，這都是建立Bug的基礎上。在寫的時候，可以著重的地方。換一個視角去看待這個問題，比如，從功能優化的角度來看待，是不是覺的，之前寫的不是問題，現在做的是在改善程式效率？
* 即使是手頭上的專案沒有進展，也要提到。XX專案：跟進中。

在工作彙報中，可從這樣的時間結構上去劃分：過去、現在、未來。

• 過去可重點描述近期業務進展回顧，重點梳理不同時間點的異同之處以及推動的地方
• 現在主要包括當前工作進展
• 未來包括下一階段工作安排

9. 工作週報撰寫

工作週報主要寫上週的主要工作內容，具體細節無需寫，最後提一下結果。

本週預備完成的工作：

• 越具體越好，例如，整理優化的話，具體到後臺哪一個模組上面的整理和優化
• 本週準備解決的問題，具體到嘗試解決的功能模組，講解清楚明白。

不建議寫的太籠統， 例如解決Bug之類的，不利於讀者瞭解具體事項。

10. 接受自己的不完美

我們不應該過度著眼於我們還不夠完美這一客觀、不可改變的事實。

沒有人是十全十美的，學習、工作、生活上都不可能十全十美。

承認這一點，可以緩解一些焦慮，但也不要心裡承認了這一點，就放棄追求完美的路。

不完美的常態根本不會影響完美學習更多更深入的內容，不要固執地認為"不要完美主義"和"認真學習"是相互衝突的。

不要因為一點點沒做好，遭受到一點點挫折，就放棄後續整個計劃。

不要過度依賴學習路徑，與其把準備知識都給掌握了再去學習核心內容，不如直接上手，哪裡不會學哪裡，這樣的針對性以及學習效果會更強。

每一本教材都有適用人群，你不屬於哪個人群，就不要強求看懂。

作者：浩天之家 出處： http://www.cnblogs.com/cherishui/ 本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利. 頂 Top 收藏 關注 評論