一、代码质量
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包。