一、代碼質量
1.用自動化提升工作效率
使用腳本將簡單重複的工作自動化，能有效的提高工作效率，shell python 腳本的熟練使用，對工作是錦上添花
傳統公司中，使用shell比較多；互聯網公司變化快，使用python做測試的比較多。
2.邏輯清晰的代碼，可讀性和可維護性好
代碼邏輯簡單明瞭，條理越清晰，代碼隱藏的bug就越少，後續維護起來成本也越小，等到需要對代碼進行重構或優化時，會相對容易點。
代碼邏輯混亂不清，條理越混亂，越會提高後續開發和維護中的bug缺陷的發生。
3.多閱讀同事的代碼
每天至少抽1個小時來code review自己的代碼和同事的代碼。
看看自己的代碼哪裏寫的不好？代碼寫的有bug本質原因是什麼？
是沒有梳理清楚業務邏輯？還是技術本身掌握的不好？
哪裏是可以改進的？自己看不懂或不理解的代碼，多和同事交流和請教。
4.編寫可測試的代碼 writing Testable code（寫商業代碼）（2020年重點目標）
什麼樣的代碼是可測試的代碼，
單元測試如何來編寫？
如何編寫有效的單元測試？
代碼覆蓋率
具體可看《C++程序設計和編程實踐》，好好的踐行其中的方法。
autotests自動化測試工具（還未嘗試）
實踐完成這一階段後，找一個文檔齊全的開源軟件看看是它是如何做單元測試的。
5.如何輸出日誌
一定要控制好日誌的級別，在線上機器只打印輸出錯誤日誌和必要的日誌，不要打印無關的日誌，原因如下：
一方面，頻繁的輸出日誌會影響系統性能
另一方面，太多的無用日誌就相當於沒有日誌，不利於線上環境排查問題根源
5.如何梳理項目的業務邏輯和流程
一次性看明白流程，省的每次都要看反覆看相同的東西，每次只看一部分流程，然後每次還要重複的看。很浪費時間和精力。
二、學習新技術
1.培養快速學習新技術的能力（需提高）
周老師說過，高手不是懂的多，而是學的快，平時注重基礎知識的積累，基礎越紮實學新東西越快，舉一反三的能力越強。
2.看官網文檔學習新技術（需提高）
從時效性和準確性來說，成熟開源軟件的官網文檔doc是最好的，網上的博客文章多數都是抄來抄去，看多了也是浪費時間。
道理簡單，但真正願意耐心看文檔的人不多，我以前看官網文檔也只是粗略的閱讀，導致對新技術的原理、機制、細節掌握的並不好
3. 自己擅長的領域，必須把技術知識搞的“門清”
和領導、同事交流技術時，分爲以下兩種場景
1）自己不熟悉的技術，耐心、細心的聽別人講；切勿誇誇其談自己的幼稚想法，降低別人對自己的印象
2）自己熟悉的技術，用通俗易懂的技術將知識點講解的明明白白，注意自己說話的語氣和語速
說的多的人往往是技術一瓶子不滿，半瓶子晃悠的人。
軟件工程師對技術掌握的“模棱兩可”是最危險的，從以下兩個角度考慮：
從領導角度考慮：領導無法放心把事情全權交給你做，因爲你的技術是半桶水水平，懂一點然而不全懂是挺尷尬的。
從其他組同事考慮：售後羣不是討論技術的羣，在客戶和運維人員的面前，給出毫無根據的猜測和結論，會降低運維人員對你的信任度，尤其是不要犯一些低級錯誤。
領導詢問一件事情時，是希望員工對這個技術的各個細節都是明確的，知道的明明白白。
不明白的地方，就老老實實的說出來，也好讓領導心裏有個底，否則領導心裏也有點懵，不知道具體情況
3）和領導探討技術問題，首先自己要經過深思熟慮，否則邏輯上都漏洞百出如何來說服領導呢？
三、做事方式
1.領導安排工作任務時，要認真仔細的聽，必要時用筆記錄下來
任務的具體內容包括哪些？（明確做什麼）
任務的優先級高不高？如果是高優先級，則考慮優先執行。
任務的時間週期是多長？3天？一週？一個月？（時間決定項目完成質量）
每個時間點對應的階段性輸出是什麼？（類似里程碑）
完成任務時的輸出是什麼？代碼？報告？文檔？
如果領導安排的任務僅僅是一個想法，那麼首先將事情拆分成一個個小任務，分批次找領導進行溝通和確認。
領導安排的工作，如果對安排的任務有不清楚的地方，及時問老員工或者領導請教，以免白白花費力氣做的事情不是領導想要的。確保心裏明白領導安排的任務是要做什麼，然後纔去動手去開展工作。
2.在工作期間遇到困難，和領導及時溝通
隨時保持和領導溝通項目進度，
當前工作進度處於什麼階段？
遇到了什麼問題？是技術問題還是非技術問題？
需要什麼幫助？
技術問題：查閱資料，共同攻克技術難關。
非技術問題：，前期低估了項目的複雜度，導致功能代碼實現和測試延後，需要調整人手和時間。
很多搞不定的問題，領導指點一下，可能很快就能找到解決問題的方法
3.做事要認真，認真，認真，提高靠譜程度
提交代碼重點前檢查以下幾點：
1. 單元測試
2.把能考慮到的應用場景都測試到位
3.集成測試，或灰度測試
4.提交的代碼要符合公司代碼規範，將調試相關的打印以及添加的日誌都刪除掉，避免污染生產環境（很重要！！！）
5.即使只改一行代碼，也要進行編譯和驗證
6.切勿在生產環境修改代碼（除線上緊急修復任務），單臺機器的批量化操作，會導致後續運維人員無法批量化升級機器。
7.代碼的覆蓋率要進行測試，提高代碼的質量
提交代碼，明明進行過單元測試，但是生產環境中又出來了低級錯誤，這點也要自己保證好
在做事時，要竭盡全力將事情做的漂亮些，做事時務必注意細節。
儘量不要犯低級錯誤，低級錯誤在領導看來就是傻逼行爲，會減低你在別人心中的印象分。
4. 做事與信任
從領導的角度考慮，分配給下屬一件任務，下屬很好的完成了任務，領導審覈通過後心裏很滿意，心裏對此員工的印象分也會有所提升，下次會分配更有挑戰性的任務給他，下屬可通過任務來不斷的磨練自己的技術。
分配給下屬一件任務，下屬頻頻遇到卡殼的問題，最後勉勉強強完成了任務或無法完成任務，領導心裏會降低對此的印象分，以後下屬只能淪爲打雜的工作。
人和人之間的信任開始都是相同的，分配的工作完成的好、質量高，對下屬的信任值會不斷的增加；
分配的工作完成的不合格、質量差，對下屬的信任值會不斷的降低；
信任的高低，決定了下次分配給你什麼樣的任務來做
把事情做好，纔是王道，時間多花一點，多測試一下，儘量確保事情做的完善。
三、溝通待加強
我以爲我知道
我以爲你知道
我以爲你知道我這樣認爲
在大型公司溝通需求時，一定要挖掘出最終的需求是什麼？
首先，明確需求有哪些內容
然後，瞭解需求背後的原因，客戶爲什麼提出這個需求
最後，將需求整理成文檔，抄送給需求相關的人員以及領導，讓客戶確認已經討論過的需求
如果和客戶談需求時只是口頭形式，那麼後面出現需求變更和成本更變等問題時，將無從查證。
在跨部門溝通時，儘量讓自己的表述能夠簡潔易懂。
在公司運維羣進行溝通時，先明確以下問題
簡單技術問題，小組內部自己解決
運維平時很忙，儘可能簡明扼要的表明自己需要什麼幫助
太傻逼的問題不要問，會降低運維對自己的印象
四、程序安裝部署以及升級
開發人員，運維人員好好合作，才能確保程序的安裝部署和升級
1.程序的依賴，是否依賴系統內核模塊？是否依賴第三方庫，redis，etcd，mongodb？是否依賴其他服務？依賴於哪些數據？
是否使用了數據庫？是否使用了定時任務contrab?這些都要在文檔中說明
2.可執行文件的路徑，需要什麼權限來運行程序？
3.程序是否需要加載配置文件？配置文件中字段的含義以及配置方法實例
4.程序是否需要寫日誌？日誌的目錄和文件是否需要創建？
5.告知運維人員程序如何啓動？以服務的方式啓動？是否需要守護進程？
6.檢查程序啓動是否成功，運行狀態是否正常
7.代碼編寫時就要把相關的錯誤情況都考慮到，並輸出對應的錯誤日誌，以便後續自己排查生產環境的問題，否則很難定位線上問題，錯誤1和錯誤2是兩種錯誤，如何在日誌中區分出這兩種錯誤？
8.程序部署或升級後，要馬上檢查程序的運行狀態，功能模塊是否符合預期，不定時的要查看下
9.在爲項目或程序編寫代碼之前，要考慮到項目或者程序是部署在什麼節點上的？才能把情況都考慮周全
普通節點
網關節點 redis的主服務器 jlb的集羣 lb rs
DNS服務器
cdn節點
五、代碼部署升級流程
提交代碼到gitlab上，提mr，review，申請發佈代碼，自己來檢查服務狀態，看syslog日誌，以及錯誤信息
某個項目的git版本，運維來編譯好release包。