作为技术高手，就必须有高手的自信和一往无前的气势。有了这种气势和自信，不管遇到什么难解决的问题题，都会拼尽全力的想各种办法来解决，最终克服重重难关将问题解决。

公司分配一个任务，不管之前是否接触过，是否对相关技术熟悉，只要是给我足够的时间，我都有自信能够完成任务。

软件开发领域，大多数都是使用现成的技术，如linux/windows系统的api，类库，第三方组件（无锁队列、读写锁、内存池等）

又不是造原子弹，造核潜艇等高技术含量的活，能有多难？

只要愿意花费大量时间和精力来学习和磨练，遇到问题耐心的去寻找资料解决问题。

在我眼中，没有啥大牛，技术大牛都是脚踏实地的一点点的去提高自己的技术，通过不断的解决各种疑难杂症来丰富经验，通过一行行的代码来磨练技术水平。

模板编程，模板元编程难吗？我相信我能学通

设计模式难吗？我相信我能学透

架构和设计难吗？只要坚持学，不断实践，总能够学会的。

linux汇编语言难吗？我相信我能学懂，并应用在debug调试生产环境问题上。

C++11/14/17/20的特性很多吗?一天学透一个，积少成多，自己的技术水平会越来越精进。

写个大点的编程项目，实现起来难吗？

一点点来做呗。

自己腾时间看更好的书和更好的代码，帮忙自己更好的进步。

effective C++

//公司csras组感悟//

做事真的太需要细心点了，为了确保交付质量，我们需要多次测试，

一、适应调试release版本

以前我都是喜欢调试debug版本，因为debug版本上什么信息都有。

1、寻找release对应的代码版本，并编译成对应debug版本程序，需要花费的时间有点长，想找到那个版本的代码是不容易的。

2、程序在release版本和debug版本下的行为不一致，debug版本有可能无法复现bug

3、模拟相同问题的场景浪费时间。有debug版本程序后，但复现bug需要搭建一模一样的环境，也很浪费时间

4、release版本的程序虽然被优化了，但是依旧可以想尽办法来进行调试。

5、加强反汇编能力，调试release版本程序需要对x86平台下的汇编很了解。

二、产品交付

软件不仅仅是写代码，还有各种杂七杂八的事，我们做的一切都是为了产品能够高质量的交付。

在平时的软件工程管理中，把容易出现问题的地方尽可能的先规避掉，以防积少成多，代码改来改去出现很多bug。

在公司，我们写代码写的是商业产品，要对代码怀有敬畏之心，对运行在生产环境中的代码负全责。

三、做事需细心

我这人做事的确是不太细心，提交的代码多检查几遍，多思考一下。

做一件事，就把这件事完完整整的做完做好，举个例子

做功能迭代时，开发一个需求：

从前期需求讨论及沟通，到编写设计文档，确定编程思路正确后开始编写代码，写完代码，很多人（包括我）感觉就没问题了。

其实这时候必须要进行自测，自测可以后最好再找个线上环境去测试下，这点我自己也需要改正。

编写代码不能有得过且过的心态。

换位思考下，如果我是领导，下属做的活总是出现各种杂七杂八的小问题，不让我省心，我是一定不会把重要的、核心的事情再交给他来做的。

四、主人翁精神

我觉得这点是最不好培养的，主人翁精神是啥？

是敬业精神，把公司的事当成自己的事，兢兢业业的做事情，

产品上线后有bug，我主动加班解决它，保证在线上生产环境，

我负责的项目，我就必须把它做好，这个无关技术。

五、程序员的能力模型

1、从零开始构建项目的框架设计能力

对公司业务的理解，然后抽象成各个模块，考虑模块间的关系以及通信。

包、模块、类、模块和模块之间的关系、类和类之间的关系

类图、活动图、

享受项目从0到1的过程，去锻炼自己的技术能力和编程能力。

2、解决问题的能力

产品部署到生产环境中，必然会产生各种各样稀奇古怪的问题，对于紧急和优先级高的问题，需要快速的解决，

对于不太紧急的问题，需要追踪到出问题的本质，然后从根源上解决问题，杜绝下次发生类似问题。

解决bug过程中，追踪其根源，否则治标不治本以后还会出现类似问题。

3、技术视野

学习各种新技术，对自身技术进行更新

如nginx，redis，kafka，zeromq，公司相关的开源项目学习

学一个技术，比如redis，就要从基础、使用、再到深入了解使用场景、最后到原理剖析、再深入到源代码中。

4、产品化思维

产品化思维，是一项很重要的思想，包括如何更方便的打包，安装包中资源的组织形式，如何和产品经理来进行沟通需求

如何更规范的编写代码，对于经常修改的变量或字符串（如文件路径，文件名称等），如果每个程序员都在代码中写一份，那么以后维护代码的难度将会提升，一劳永逸的解决这一问题。

在产品化的道路上，会有很多没什么技术难度，但却很重要的事情要去做。

csras组感悟

一、代码质量

1.用自动化提升工作效率

使用脚本将简单重复的工作自动化，能有效的提高工作效率，shell python 脚本的熟练使用，对工作是锦上添花

传统公司中，使用shell比较多；互联网公司变化快，使用python做测试的比较多。

2.逻辑清晰的代码，可读性和可维护性好

代码逻辑简单明了，条理越清晰，代码隐藏的bug就越少，后续维护起来成本也越小，等到需要对代码进行重构或优化时，会相对容易点。

代码逻辑混乱不清，条理越混乱，越会提高后续开发和维护中的bug缺陷的发生。

3.多阅读同事的代码

每天至少抽1个小时来code review自己的代码和同事的代码。

看看自己的代码哪里写的不好？代码写的有bug本质原因是什么？

是没有梳理清楚业务逻辑？还是技术本身掌握的不好？

哪里是可以改进的？自己看不懂或不理解的代码，多和同事交流和请教。

4.编写可测试的代码 writing Testable code（写商业代码）（重点目标）

什么样的代码是可测试的代码，

单元测试如何来编写？

如何编写有效的单元测试？

代码覆盖率

具体可看《C++程序设计和编程实践》，好好的践行其中的方法。

autotests自动化测试工具（还未尝试）

实践完成这一阶段后，找一个文档齐全的开源软件看看是它是如何做单元测试的。

5.如何输出日志

一定要控制好日志的级别，在线上机器只打印输出错误日志和必要的日志，不要打印无关的日志，原因如下：

一方面，频繁的输出日志会影响系统性能

另一方面，太多的无用日志就相当于没有日志，不利于线上环境排查问题根源

5.如何梳理项目的业务逻辑和流程

一次性看明白流程，省的每次都要看反复看相同的东西，每次只看一部分流程，然后每次还要重复的看。很浪费时间和精力。

二、学习新技术

1.培养快速学习新技术的能力（需提高）

周老师说过，高手不是懂的多，而是学的快，平时注重基础知识的积累，基础越扎实学新东西越快，举一反三的能力越强。

2.看官网文档学习新技术（需提高）

从时效性和准确性来说，成熟开源软件的官网文档doc是最好的，网上的博客文章多数都是抄来抄去，内容可能已经过时，或者翻译的并不准确，这种资料看多了也是浪费时间。

由于官网文档是英文，但真正愿意耐心看英文文档的人不多，我以前看官网文档也只是粗略的阅读，导致对新技术的原理、机制、细节掌握的并不好。

举个例子：

学习go语言的人，起码完整的看过一遍effective go文档，不过分吧？

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包。