前言
這周完成了PPT的分享，在改了兩版之後，分享的PPT得到了大家的一致好評（說這不像是應屆生寫的PPT），哈哈。剛開始還不覺得PPT有什麼差別，不都應該是這樣麼？
直到後兩天我參加了又一個分享，通篇的協議定義和ER圖、UML活動圖，雖然看起來很專業，但是
- 沒點出爲什麼要這樣設置協議，不設置哪些字段會有什麼影響，就在那兒講哪個協議是什麼意思（倒還不如我們自己去接口文檔來得快）
- PPT上放ER圖、UML活動圖字小的根本看不清，只能聽個大概，（不如自己去看接口文檔+1）
太多的槽點，參加這樣的分享真是在浪費時間和生命，待會兒重寫下5周總結，放在反面教材裏。
需求實現準則
背景
背景一、只想不做，拖泥帶水
分享完PPT，終於可以把重心放在項目接觸瞭解上。剛開始接觸的活比較基礎，譬如寫個腳本之類的，於是老毛病又犯了（拖泥帶水），即便是幾十行的腳本，配置直接在代碼裏寫死了，導致1. 沒有一點擴展性。新的需求過來，把原來的腳本文件複製一遍，再在上面的基礎上改，導致工作量變多，要是有一萬個需求過來，我可能會改一萬個腳本進行實現。
到後來自己意識到了這個問題，開始設計一個小工具，針對同類化的需求（功能類似，但細節不同）設計接口，然後根據接口編程。這樣在新需求來的時候，擴展對應的接口即可。
但是當事情一多，可能有更高優先級的事情時，就把這事放下來，然後忘記，直到某天同類型的需求過來時，還是重複上述的情況。
背景二
做事情只做到實現功能這步，在完成相應的功能後，便把寫的腳本丟到一旁。待有同類型的需求過來（時間可能會長，一兩週後），才反應過來自己以前好像做過類似的事情，然後費勁的去找相應的文件，然後熟悉已經忘光的代碼。
針對以上兩個背景，這裏覆盤一下，接到需求時應該做的幾件事。
接到需求時應該做的
需要首先說明的是，以下並不是唯一實踐準則，可能根據項目不同需求不同，在細微的地方有所差異。
- 仔細分析需求是否合理。（從所屬項目的背景進行考慮，該需求存在在哪個位置上，原項目是否有對應的擴展接口。因爲一個項目在最開始的設計階段就應該考慮到未來需求的變化，預留相應的擴展接口，如果新需求不在預留的擴展接口裏，那麼就應該考慮這個需求是否合理，或者原來項目的設計是否合理）
- 明確需求的輸入、輸出。（需求方往往只會說他們想要什麼樣的結果。但具體結果的格式、內容，需要我們自己去進行更深一步的瞭解。切忌在不明白需求輸出的情況下，就開始動手設計實現，因爲萬一理解有出入，就是在浪費時間，浪費KPI。必要的時候，把需求寫在紙上進行確認，最後補幾個示例請需求方確認）
- 需求設計。（這步應該分析需求實現的時候，會改動系統的哪些地方，具體的工作量有多大，改動後的項目對同類的需求應有可擴展的能力。這部分需要做一個完整的設計方案，然後找到改動項目的負責人進行review確認）
- 需求實現。（一般實現用時可能只佔到整個階段的20%）
- 需求功能測試。（進行單元測試，可以將2.中的示例用作測試用例）
- 覆盤。（分析在進行需求實現的過程中，自己做了哪些重複工作，有哪些工作可以是不必要的，重複的工作是否的可以整理出一個腳本，在以後做類似的事情時，可以直接拿來用）
- 交付。（交付需求方）
做到，不求快，但求穩。忌在交付後再進行調整改動。
後記
俯臥撐的計劃如下：
4月11日:
俯臥撐，70個。 （累計1203個）
蹲起，0個。 （累計55個）
已堅持 28 天
4月12日:
俯臥撐，71個。 （累計1274個）
蹲起，0個。 （累計55個）
已堅持 29 天
4月13日:
俯臥撐，72個。 （累計1346個）
蹲起，0個。 （累計55個）
已堅持 30 天
4月14日:
俯臥撐，75個。 （累計1421個）
蹲起，0個。 （累計55個）
已堅持 31 天
4月15日:
俯臥撐，76個。 （累計1497個）
蹲起，0個。 （累計55個）
已堅持 32 天
4月16日:
俯臥撐，77個。 （累計1574個）
蹲起，0個。 （累計55個）
已堅持 33 天
4月17日:
俯臥撐，78個。 （累計1654個）
蹲起，0個。 （累計55個）
已堅持 34 天