2017.9.1 0:26 昨晚在辦公桌上碼這篇博文不到50字
2017.9.1 0:52 坐上公司樓下約得拼車
2017.9.1 2:12 到家
2017.9.1 9:52 到公司
缺點
1.使用固定值
在測試環境的DB上開發，插入一些需要的固定數據，這些數據自增長的ID與實際DB中自增長的ID不同。但在開發的後臺代碼中使用了測試環境DB中自增長的ID……
2.沒有準備腳本
新的模塊，對DB的修改，沒有準備用於生產DB的SQL腳本。幸運的是自己有記錄工作過程的習慣，快速準備好了
3.命名冗長及隨意
冗長：假設你定義變量表達【在XX活動期間註冊且首次YY金額超過ZZ的好友數量】
我的命名是：
userFriendWhoRegisteredInXXActivityAndFirstYYMoneyMoreThanZZCount
我諮詢了2個同事，都是以核心詞彙“好友數量”命名，用註釋來闡釋形容限定詞彙
隨意：上面的命名我用“Money”不是“Amount”來表達金額
4.謹慎不足-修改即提交
以爲很簡單，將int修改成string，完成新的邏輯，卻忘了還有地方用它和int類型來比較，不能用時間倉促來當藉口
5.謹慎不足-數據的唯一性
從集合中取First()這個屬性是1的數據，雖然做到了，但在真正生產環境下，是否First取到的就是這個屬性是1的數據，在First前Where明確一下是否更好，起碼更嚴謹
6.簡化前後臺接口結構
前臺開發的方式多種多樣，並不僅僅是Razor中嵌套C#，這次前臺使用VueJs打包，在View中引用，沒法集成後調試前端，過程變成了前端開發自己造簡單的假數據，集成用的後臺數據結構複雜（多級，類型多樣），導致獲取數據、想獲取數組的length都費事
如果有些狀態需要計算接口數據的個數和需要遍歷獲得，不如後端加一些冗餘屬性來記錄，前端拿來直接使用
一般兩級就好，儘可能是基元類型
7.日報堅持當晚完成進度總結
臨走前也應該打開日報，校驗一下今天的進度和是否一些備註
優點
1.深刻理解需求
不論是業務邏輯、DB、前端接口，在開動代碼前，先理解需求，先溝通相關人員，不明白的地方都搞明白，在開發的時候能夠清晰，在集成時調試能在產品上把關一下
2.積極配合前端
早晨來了索性抱着本做到前端身邊待命
3.想要做更好的技術規範（sql腳本整理）
沒有整理腳本，但整理後沒有條件判斷是否存在在CURD，找到前輩的腳本，規規範範的模仿，數據庫和字段都加了[]，校驗if not exists, sql語句換行變得好看
4.願意待在公司一起到凌晨
與上家公司朝9晚6但需要的時候晚9、10點相比，我更喜歡現在早晨9：30彈性到10點，晚上年輕人在一起有交流做事
我也明白了一件事，我的存在，即使再怎麼激情，也無法和一個老人大多數時在加班做事相比，如果真的想成爲骨幹，想學那些我不懂的，我需要加班
5.不以太晚爲理由
今早有偷懶的想法，起牀想再睡會，晚點去，但還是起了牀，不能以太晚下班爲理由，明明身體心理都都可以做得到，而且凌晨走的我們4個人才僅有一個人遲到了
見識
抓包的測試，測試在抓包
前端後臺開發，如果接口命名不好，也不能一個人去Rename, 如果模塊又趕上緊急上線，或者是開發人員焦頭爛額狀態不好也不願意去再看……