每个程序员都该知道的10大编程格言（Kevin Pang）：

编程格言1：无风不起浪 (There is no smoke without fire）

编程格言2：预防为主，治疗为辅(An ounce of prevention is worth a pound of cure：）

编程格言3：不要把鸡蛋都放在一个篮子(Don’t put all your eggs in one basket)

编程格言4：种瓜得瓜,种豆得豆（As you sow,so shoul you reap）

编程格言5：欲速则不达（Great haste makes great waste）

编程格言6：三思而后行( Look before you leap。Think first, Program later)

编程格言7：当你仅有的一把工具是锤子，所有的东西看起来都像是钉子（When the only tool you have is a hammer, everything looks like a nail）

编程格言8：沉默就是赞同 （Silence is construed as approval）

编程格言9：双鸟在林不如一鸟在手（A bird in the hand is worth two in the bush）

编程格言10：能力越大责任越大（With great power comes great responsibility）

1.无风不起浪(There is no smoke without fire)：

设计糟糕的代码通常表现以下 的一些现象：

巨大的类或者方法

大区块注释的代码

重复的逻辑

过多 if/else 层次嵌套

Poorly designed code tends to manifest itself through some common tell-tale signs. Some examples of these are:

Giant classes and/or functions

Large blocks of commented out code

Duplicated logic

Deeply nested if/else blocks

Developers often refer to these as code smells, but personally, I think the term “code smoke” or “code fumes” is more appropriate as it implies a higher sense of urgency. If you don’t address the underlying problem it will come back to burn you later on.

2. 预防为主，治疗为辅(An ounce of prevention is worth a pound of cure）磨刀不误砍柴工

程序员经常错误地认为高效率编码就是快速编码，很多程序员不经思索和设计就直接编写代码。很不幸地是，这种 Leeroy Jenkins鲁莽做法将会编写出槽糕的代码，结果导致需要不断维护和修改代码，甚至有可能这些槽糕的代码将会被替换掉。因此，编码效率不仅以编码的时间，而且还有调试代码的时间。

捡了芝麻丢了西瓜。磨刀不误砍柴工。

原文：

Toyota’s assembly line of the 1980s was famously efficient due to its revolutionary approach towards defect prevention. Each member of the assembly line was given the ability to halt production when they noticed a problem in their sector. The idea was that it was better to halt production and fix the problem as early on as possible than to continue producing faulty units that would be tougher and more costly to fix/replace/recall later on.

Developers often make the faulty assumption that productivity = cranking out code quickly. Many programmers dive straight into coding without a second thought towards design. Unfortunately, this Leeroy Jenkins approach towards software development tends to lead to sloppy, fragile code that will need to be constantly monitored and patched — perhaps even replaced altogether down the line. Ultimately, productivity must be measured not only in how much time is spent writing it, but also by how much time is spent debugging it. A short term gain may prove to be a long term loss if one isn’t careful.

3. 不要把所有鸡蛋放在一个篮子 （Don’t put all your eggs in one basket)不要过度依赖某个人

一个软件项目开发团队的公共要素（bus factor）是指那些会影响整个项目进程的核心开发人员的总数。比如某人被车撞了或某人生孩子或某人跳槽了，项目可能就会无序，甚至会搁置。

换言之，如果团队的关键成员突然流失，项目将会怎么办？业务仍继续还是停止呢？

因此我们在项目开发中， 每位开发人员最好能最熟悉软件系统非自己所擅长的部分。

原文:

A software team’s bus factor is defined as “the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed”.

In other words, what happens if you suddenly lost a key member of your team? Would business continue as usual or would it grind to a halt?

Unfortunately, most software teams fall into the latter category. These are the teams that turn their programmers into “domain experts” who only deal with requests that fall into their area of expertise.. At first, this appears to be a fairly reasonable approach. It works for the automaking assembly lines, why not for software development teams? After all, it’s unreasonable to expect each member of the team to be intimately familiar with each and every nuance in the application, right?

The problem is that developers cannot be easily substituted and replaced. And while the pidgeon-hole approach works fairly well when everybody is available and accounted for, it quickly falls apart when “domain experts” suddenly become unavailable due to turnover, sickness, or even freak bus accidents. It is imperative that software teams have some sort of redundancy built in. Code reviews, pair programming, and communal code go a long way to foster an environment where each developer is at least superficially familiar with parts of the system outside their comfort zone.

4.种瓜得瓜，种豆得豆 （As you sow, so shall you reap)

《注重实效的程序员》一书中有这样一段话解释“破窗理论”：

不要留着“破窗户”（不良的设计、错误的决策或者糟糕的代码）不修。发现一个就修一个。

如果没有足够的时间进行适当的修复，就先把它保留起来。或许你可 以把出问题的代码放到注释中，或是显示“未实现”消息，或用虚拟数据加以替代。采取一些措施，防止进一步的恶化。这表明局势尚在掌控之中。

我们见过整洁良好的系统在出现“破窗”之后立马崩溃。虽然促使软件崩溃的原因还有其他因素（我们将在其他地方接触到），但（对“破窗”）置之不理，肯定会更快地加速系统崩溃。

简而言之，好的代码会促生好的代码，糟糕的代码也会促生糟糕的代码。别低估了习惯的力量。没人想去整理糟糕的代码，同样没人想把完美的代码弄得一团糟。写好你的代码，它才更可能经得住时间的考验。

原文：

The Pragmatic Programmer has this to say about the Broken Window theory:

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.

We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

In short, good code begets good code and bad code begets bad code. Do not underestimate the power of inertia. No one wants to be the one who has to clean up sloppy code, but neither does anyone want to be the one that makes a mess out of beautiful code. Write it right and your code will have a far better chance at standing the test of time.

5 .欲速则不达（Great haste makes great waste)

经理、客户和程序员正日益变得急躁。一切都需要做的事，都需要马上就做好。正因如此，快速修复问题变得非常急迫。

没时间对一个新功能进行适当的单元测试？好吧，你可以先完成一次测试运行，然后你就可以随时回来继续测试它。

当访问Y属性时，会不会碰到奇怪的对象引用错误？无论怎样，把代码放到try/catch语句块中。我们要钓到大鱼啦！

是不是似曾相识呢？这是因为我们在以前已经都做到了。并且在某些情况下、它是无可非议的。毕竟，我们有最后期限，还得满足客户和经理。但不要过于频繁操 作，否则你会发现你的代码不稳定，有很多热修复、逻辑重复、未测试的方案和错误处理。最后，你要么是把事情草草做完，要么是把事情好好做完。

原文：

Managers, clients, and programmers are getting more impatient by the day. Everything needs to be done and it needs to be done now. Because of this, the temptation to throw together hacks and quick-fixes becomes very tough to resist.

No time to properly unit test a new feature? Oh well, it works for the one test run you put it through. You can always come back to it later!

Mysterious object referencing error when you try to access property Y? Whatever, just throw a try/catch block around the code. We’ve got bigger fish to fry!

Sound familiar? It’s because we’ve all done it at some point in time. And in certain instances, it is justifiable. After all, we have deadlines to meet and clients/managers to satisfy. But do it too often and you’ll soon find yourself with a very unstable code base full of hotfixes, duplicated logic, untested solutions, and porous error handling. In the end, you have to strike a balance between getting things done and getting things done right.

6. 三思而后行（ Look before you leap)

“敏捷开发”这个词最近被频繁滥用，经常被程序员用来掩饰他们在软件开发过程中的糟糕规划/设计阶段。我们是设计者，看到产品朝正当方向有实质进展，我们理应高兴。但意外的是，UML图和用例分析似乎并不能满足我们的愿望。所以，在不知自己做什么的情况下或者不知自己身处何处时，我们开发人员经常就稀里糊涂地写代码了。

这就好比你要去吃饭，但你根本没有想好去哪里吃。因为你太饿了，所以你迫不及待地找个餐馆，定个桌位。然后你上车开车后沿途在想（找地方吃饭）。只是，这样会耗费更多的时间，因为你要过较多的U型弯道，还在餐馆前停车，也许最后因等待时间过长而不吃了。确切地说，你最后应该能找到地方吃饭，但你可能 吃的饭并不是你想吃的，并且这样花费的时间，可能比你直接在想去的餐馆订餐所花的时间更长。

原文：

The term “Agile Development” is used and abused frequently these days, often as a way for programmers to justify ignoring the dreaded planning/designing phase of software development. We are creators, and as such we derive pleasure from seeing actual progress made towards a finished product. Surprisingly, UML diagrams and use case analysis just don’t seem to satisfy that desire. So, we developers often start off coding without any idea of what we are doing or where we are going. It’s like heading out for dinner when you haven’t yet decided where you want to go. You’re hungry so you don’t want to waste time finding a restaurant and booking a table. Instead, you just hop in your car and figure you’ll think of something along the way. Only, it ends up taking you longer because you have to make a bunch of U-turns and stops at restaurants that end up having too long of a wait. True, you’ll probably find your way to food eventually, but you probably didn’t end up with the meal you wanted and it probably took a lot more time and hassle than it would have had you just called and booked a reservation at a restaurant you wanted to go to.

7.当你仅有的一把工具是锤子，所有的东西看起来都像是钉子（When the only tool you have is a hammer, everything looks like a nail）

看见了吧？我早就说过动态记录在这个项目中很有效

程序员有一种倾向，当一谈到他们工具时，其视野就变狭窄了。一旦某种方法在我们的一个项目上“行得通”，我们就会在接下来所有的项目上都用到它。学习新东 西仿佛是一种煎熬，有时候甚至会心神不定。从始至终都在想“如果我用之前的方法做、这个就不会这么麻烦了”。

一定要摒弃这种想法，按我们所知道的去做，即使那不是最完美的解决方法。

坚持自己所知很简单，不过从长远的角度讲，选择一个适合这项工作的工具要容易得多。否则，就会与你的职业生涯格格不入。

原文：

See? I told you Active Record would work for this project!

Programmers have a tendency to get tunnel vision when it comes to their tools. Once something “just works” for us on one project, we tend to insist on using it for every project therafter. It can be a pain to learn something new and, at times, highly unsettling. The entire time we’re thinking “it would have been easier had I just done it the old way!”. Enough of these moments and we will simply go with what we know, even if it isn’t a perfect fit for the task.

It’s easy to stick with what you know, but in the long run it’s much easier to pick the right tools for the job. Otherwise you will be fitting square pegs into round holes for the rest of your career.

8. 沉默就是赞同（Silence is construed as approval）

我什么都没看见！没看见！

“破窗理论”与”变成惯性理论”有着宏观的联系。

编程社区就好像一个现实社区。每个作品都是一个开发者的缩影。糟糕的代码发布的越多，就越容易反映现状。如果你不去努力编写优秀、整洁和稳定的代码，那你每天都将和糟糕的代码相伴了。

同样地，如果你看到别人写出了糟糕的代码，你就要跟这个人提出来。注意，这时候机智就应该用上场了。一般情况下，程序员都愿意承认他们在软件开发中还是有不懂的地方，并且会感谢你的好意。互相帮助对大家都有利，而对问题视而不见，只会使问题一直存在。

原文：

I see nothing! Nuh-thing!

This ties in with the theory on broken windows and programming inertia, only on a larger scale.

The programming community is just that, a community. Each programmer is a reflection on the craft. The more bad code that is released into the wild, the more it becomes the status quo. If you don’t make an effort to write good, clean,SOLID code, you will find yourself having to work with it on a day-to-day basis.

Likewise, if you see poorly designed code written by someone else, you should make the effort to bring it up with the creator. I should note, however, that tact ought to be employed in such a situation. In general, programmers are willing to admit that they do not know everything there is to know about software development and will appreciate the gesture. We all benefit when we help each other out. Turning a blind eye to problems only perpetuates them.

9.双鸟在林不如一鸟在手（A bird in the hand is worth two in the bush）

如果可以讨论系统架构和重构，那么就差找个时间把事情做完。为了使正常运作的东西更加简洁而做改动，权衡改动的利弊很重要。当然了，简洁是一个理想目标， 但总会有可以通过重构改进的代码。在编程世界中，为了代码不过时，会频繁简单改动代码。但有时候你又必须保证代码对客户有价值。那么，你面临一个简单窘 境：你不能一石二鸟。你在重构旧代码上所发时间越多，你编写新代码的时间就越少。在及时改进代码和维护程序之间，也需要找到平衡点。

原文：

There is a time and place to discuss system architecture and refactoring opportunities, and a time to just get things done. It is important to weigh the pros and cons of revamping something that already works just to make it cleaner. It’s an admirable goal, of course, but there will always be code that you want to restructure. The programming world simply changes too frequently for code to not get outdated. But at some point you have to provide value to your customers. The simple fact remains: you can’t do two things at once. The more time you spend refactoring old code, the less time you spend creating new code. Striking a balance is critical to enhancing as well as maintaining your application in a timely manner.

10.能力越大责任越大（With great power comes great responsibility）

毫无疑问，软件已成为我们生活中一个既基本又重要的一部分。正因如此，开发优秀软件格外重要。乒乓球游戏中的Bug是一回事，航天飞机导向系统或者航空交通管制系统中的Bug是另外一回事。Slashdot曾发表一文，讲述了单单Google News的一个小失误使一家公司股票蒸发11.4亿美元。其他例子参见《软件Bug引发的十次严重后果》。这些例子便说明了我们正行使着多大的权利。你今天写的代码，无论你是否有意，说不定有朝一日在重要的应用程序中派上用场，这想想都令人害怕。编写正确合格的代码吧！

原文：

Software has undoubtedly become an integral and vital part of our lives. Because of this, practicing good software development is more crucial than ever. It’s one thing to have a bug in a game of Pong, it’s another to have one in the guidance system of a space shuttle or air traffic control system. Slashdot recently posted an article describing how a minor glitch in Google News singlehandedly evaporated $1.14 billion in shareholder wealth. Events such as these demonstrate how much power we wield. It’s a little frightening to think that the code you write today, whether you intend it to or not, may one day be recycled and depended upon for mission-critical applications. Write accordingly.

Do you have any proverbs you feel should be added to this list? Feel free to let me know in the comments!

转载于公众号：程序猿DD

最经常的工作是将一些项目的数据从数据库导出，然后分门别类的列到excel表格中，领导看起来眼花缭乱。

基基想，要是能以图表可视化展现出来，领导就可以看到项目近几个月的走势，也知道之后要怎么决策了。

基基尝试了使用excel制作图表，由于操作复杂，放弃了，于是小编在网上找到了以下四种可视化工具，现在我们来看一下：

1. 阿里云DataV

使用手机号或邮箱注册账号，会获得7天的体验期。阿里云DataV有强大的组件库，可以制作不同的样式，还可以链接数据库或API接口，炫酷的可视化大屏可以轻松完成。

缺点：

（1）试用期比较短，试用期过了，需要几千或者几万的续期费用，对于工薪阶层来说，这是一笔不小的费用。（2）数据源的配置有点复杂，用户的学习成本有点高。

2. 积木报表jimureport

积木报表是 JeecgBoot 旗下的一款免费制作报表和大屏的软件，主打开源。跟阿里和百度一样，手机号一键注册，便可永久使用，重要的是：免费！免费！免费！积木报表采用类word风格，可以随意拖动组件，想怎么设计怎么设计，可以像百度和阿里一样，设计出炫酷的可视化大屏！

缺点：

等你来发现呦！

3. 百度Sugar

跟阿里一样，手机号一键注册，会有30天的体验期，制作效果同样炫酷。

缺点：

（1）试用期不长，试用期一过，需要花钱续费；

4. 帆软

帆软是业内做报表比较久的一家公司，使用类excel风格的界面，可添加图表和数据源，也可实现大屏效果。

缺点：

（1）只能拖动块的固定排版，对于大屏的随意排版、随意拖动很不方便；（2）需下载软件，本地制作，软件占用空间较大，打卡比较慢；（3）需要安装许多插件才可以实现一些动态效果；

平时关注 Kafka 的小伙伴要注意了，2021年4月19日，Kafka 2.8.0正式发布！

这次升级包括了很多重要的改动，其中最引人瞩目的就是kafka通过自我管理的仲裁来替代ZooKeeper，通俗的说，Kafka将不再需要ZooKeeper，正式分手！

其实早在19年，就有人在社区中提出要移除Kafka对Zookeeper依赖的想法，当时被视为几乎不可能，但随着众人齐心协力踌躇满志，竟然真的一步一步逐渐实现了。

2.8.0版本将是第一个不需要ZooKeeper就可以运行Kafka的版本，而这也被称为Kafka Raft Metadata mode（Kafka Raft 元数据模式），或许就是一个会被后人铭记的版本。

可能有一些刚接触Kafka的小伙伴还不明白这到底代表着什么。

Kafka的一大优点就是能够提供高效率和吞吐量，对先前刚接触的小伙伴来说，提交日志的底层实现往往是需要学习的第一个任务。

Kafka 的代码库中还有很大一部分是负责在多个集群中安排日志、分配领导权、处理故障等。这使的 Kafka 成为一个可靠和可信的分布式系统。而ZooKeeper就是分布式代码工作的关键。在以往的版本中，ZooKeeper 提供了权威的元数据存储，这些元数据存储了系统中最重要的东西，例如分区可以存在哪里，哪个组件是主导等等等等。

但不管怎么样，ZooKeeper 是一个基于一致日志的特殊文件系统/触发器API。而Kafka 是一个建立在一致日志之上的发布/订阅系统。

这个无法改变的现实使得实际使用中，运维人员需要跨两个日志实现、两个网络层和两个安全实现(每个实现都有不同的工具和监视钩子)对通信和性能进行调优、配置、监视、保护和评估，这就使得系统变得相当复杂！

所以和ZooKeeper的友好分手 短期可能会有阵痛，但对于Kafka的长远发展利大于弊。

除了和ZooKeeper分开，本次更新还新增了三个功能：

[KAFKA-10500]-添加API以启动和停止流线程

[KAFKA-10700]-支持使用SASL_SSL侦听器实现相互TLS身份验证

[KAFKA-10749]-通过连接速率添加IP限制

而优化及修改bug更是多达百个。

一些重要的更新例如：

[KAFKA-5488]-KStream.branch不应返回必须通过已知索引访问的流数组

[KAFKA-6687]-允许多次阅读主题

[KAFKA-6943]-如果任何线程崩溃，或者如果所有线程崩溃，可以选择干净地关闭KS

[KAFKA-9023]-生产者网络异常响应应记录更多信息

[KAFKA-12327]-删除CompressionType中的MethodHandle用法

[KAFKA-12365]-kip-500代理/控制器不支持块API（目前）

[KAFKA-12394]-考虑主题id存在和授权错误

[KAFKA-4748]-需要一种方法同时关闭Streams应用程序中的所有工作进程

[KAFKA-10722]-即使不需要，也使用时间戳存储

[KAFKA-10723]-LogManager在关闭期间泄漏内部线程池活动

如果对具体的更新内容感兴趣，可以直接登陆官网进行查看

Canal

定位：基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了mysql。

原理：

• canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议

• mysql master收到dump请求，开始推送binary log给slave(也就是canal)

• canal解析binary log对象(原始为byte流)

• 
  

整个parser过程大致可分为几步：

• Connection获取上一次解析成功的位置（如果第一次启动，则获取初始制定的位置或者是当前数据库的binlog位点）

• Connection建立连接，发生BINLOG_DUMP命令

• Mysql开始推送Binary Log

• 接收到的Binary Log通过Binlog parser进行协议解析，补充一些特定信息

• 传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功

• 存储成功后，定时记录Binary Log位置

• 数据过滤：支持通配符的过滤模式，表名，字段内容等

• 数据路由/分发：解决1:n (1个parser对应多个store的模式)

• 数据归并：解决n:1 (多个parser对应1个store)

• 数据加工：在进入store之前进行额外的处理，比如join

Maxwell

canal 由Java开发，分为服务端和客户端，拥有众多的衍生应用，性能稳定，功能强大；canal 需要自己编写客户端来消费canal解析到的数据。

maxwell相对于canal的优势是使用简单，它直接将数据变更输出为json字符串，不需要再编写客户端。

Databus

Databus是一种低延迟变化捕获系统，已成为LinkedIn数据处理管道不可或缺的一部分。Databus解决了可靠捕获，流动和处理主要数据更改的基本要求。Databus提供以下功能：

• 源与消费者之间的隔离

• 保证按顺序和至少一次交付具有高可用性

• 从更改流中的任意时间点开始消耗，包括整个数据的完全引导功能。

• 分区消费

• 源一致性保存

阿里云的数据传输服务DTS

数据传输服务（Data Transmission Service，简称DTS）是阿里云提供的一种支持 RDBMS（关系型数据库）、NoSQL、OLAP 等多种数据源之间数据交互的数据流服务。

DTS提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力，可实现不停服数据迁移、数据异地灾备、异地多活(单元化)、跨境数据同步、实时数据仓库、查询报表分流、缓存更新、异步消息通知等多种业务应用场景，助您构建高安全、可扩展、高可用的数据架构。

优势

数据传输（Data Transmission）服务 DTS 支持 RDBMS、NoSQL、OLAP 等多种数据源间的数据传输。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输方式。相对于第三方数据流工具，数据传输服务 DTS 提供更丰富多样、高性能、高安全可靠的传输链路，同时它提供了诸多便利功能，极大得方便了传输链路的创建及管理。

个人理解：就是一个消息队列，会给你推送它包装过的sql对象，可以自己做个服务去解析这些sql对象。

免去部署维护的昂贵使用成本。DTS针对阿里云RDS（在线关系型数据库）、DRDS等产品进行了适配，解决了Binlog日志回收，主备切换、VPC网络切换等场景下的订阅高可用问题。同时，针对RDS进行了针对性的性能优化。出于稳定性、性能及成本的考虑，推荐使用。

2021年5月15日，融云X-Meetup技术沙龙第三站续航上海。本场沙龙聚焦“音视频技术新方向”，由融云音视频研发高级工程师姜春雨、时光机器人创始人兼CEO徐晶、融云IM研发中心高级工程师刘佳、学而思网校架构师李亚龙，和资深音视频技术专家栗伟，五位技术大咖出任演讲嘉宾，他们以时下热门应用场景为视角，从技术实践出发，与开发者们交流分享了关于音视频技术的新观察。

iOS 上的音频开发

今年，由于Clubhouse和Tiya的示范效应，语聊房产品大火，音频的开发技术备受开发者的关注。来自融云的音视频研发高级工程师姜春雨,多年专注于移动端和音视频领域的技术研发，他分享了《iOS 音频设备开发 - Core Audio》的主题内容。

融云音视频研发高级工程师姜春雨发表演讲

姜春雨认为：移动端音频处理的难点在于声音美化、变声、实时高音质和场景玩法多样化。单从iOS设备来说，要突破这些难点，离不开iOS所提供的Audio Unit，它是一项强大灵活的音频处理技术，支持混合、均衡、格式转换和实时输入/输出，用于录制、播放、离线渲染和实时对话。

融云SDK以Audio Unit为基础，构建了长音效、短音效等多个功能模块，最终在音频设备上完成混音输出。在场景化实践中，姜春雨以音乐语聊房和百人超大会议室两个典型场景为例，分享了融云SDK的技术开发优化方案。比如，音乐语聊房注重高音质、美声变声，以舒适噪音为好，开发者要根据这些需求进行算法调优；而超大会议室的优化则要求做到服务端智能发流、多人声音同时出现可以智能选择会议发言人的声音。

姜春雨总结道：Audio Unit是一个强大的音频处理框架，音频处理要基于Audio Unit框架构建内容，并且要在音频处理内容上不断打磨优化。未来，融云音视频SDK还将不断基于不同场景需要开发新的功能，持续优化音频产品，为开发者提供更好的解决方案。

构建低延迟高可靠的信令系统

融云作为互联网通信云赛道的领先厂商，2020年在业界率先提出“IM+RTC+PUSH”的整体通信解决方案。融云RTC唤起用户的通道就是依赖于IM的SDK信令，因此，本次融云的IM研发中心高级工程师刘佳，分享了《构建低延迟高可靠信令系统的探索与实践》，帮助开发者更好地了解融云IM如何协同RTC，提供高可靠的通信能力。

 融云IM研发中心高级工程师刘佳

刘佳介绍，高可靠音视频信令系统的构建在IM信令系统设计时，首先要进行服务分层，包括接入层、内部服务和数据存储的分层。而拆分原则要根据业务差异和服务对象的不同，拆分为API和 CMP，整体做到可监控、可维护。其次，是要搭建完整的监控体系，通过可视化的图表，监看网络的性能情况，及时处理系统瓶颈。

对于低延迟信令系统的实现，刘佳分享道，融云不仅利用全球加速网络,降低网络延迟，还基于融云自有通讯协议降低数据传输量，利用缓存机制,提高了服务的业务处理速度。并且，刘佳以缓存设计为例，说明通过一致性hash提高缓存命中率、高效利用CPU的处理能力、实施异步存储等，也都是实现低延迟系统设计的要旨。

基于这些设计要点，刘佳展示了海量并发用户场景下的语聊房系统架构，为开发者提供了干货解决方案。同时，他还总结出融云现有的音视频整体服务架构的三大优势：第一，信令服务与媒体服务解藕,两个服务之间也不需要状态同步；第二，媒体服务专注通信,信令服务专注能力；第三，部署简单,方便进行全球部署媒体服务。

直播系统架构设计 满足用户对实时性的需求

本场沙龙中，音视频直播场景也是一个重点话题。深耕互联网音视频12年，在直播领域积累了丰富实战经验的拾光机器人公司创始人兼 CEO徐晶，通过他的《互联网直播快速实战》，分享了基于直播答题场景的架构设计，尤其是几个关键技术点和应对策略，以及如何保证直播中的视频和音频质量，都做出了详细的讲解。

沙龙中，专注于在线教育的学而思网校架构师李亚龙，还针对教育低延时大班的直播场景，为开发者带来了关于《在线教育直播系统架构升级》的分享。他着重从网校视频技术的发展、网校大班直播系统、网校公益直播课、低延迟直播探索这四个方面的设计要点，进行了分析讲解。对于专注在线教育的开发者而言，具有普遍的示范意义。

此外，资深音视频技术专家的栗伟，发表了《使用webrtc构建实时在线课堂》的演讲。栗伟曾任职于中科院计算所、CC视频，任职期间利用WebRTC技术开发了直播、在线课堂、视频会议等商业产品，并发用户数达到500万。他还曾主笔撰写了 《WebRTC技术详解：从0到1构建多人视频会议系统》，在该领域有多年实践经验，对WebRTC有非常深入的研究，他的实践分享也让开发者们获益匪浅。

结语

在本次沙龙中，五位讲师的分享，其共性特点在于：他们都基于当下所关注热门场景展开话题。由此可见，应用场景才是“探讨音视频技术新方向”的基础，而越热门的场景往往越是代表着这个领域的发展潜力更大，因此也就越需要通过新技术、新产品加以承载。

随着5G的进一步落地，网络带宽、网络质量的不断优化，音视频通信无论在使用量级上，还是使用场景上，都会出现更多可能。对于开发者而言，只有及早储备，尽可能多地掌握新技术，关注新方向，才能赢在当下，赢在未来。

讲师PPT下载↓↓↓

0515演讲PPT.pdf

今年终于从大菊花厂离职了，离职前收入大概 60w 不到吧！在某乎属于比较差的，今天终于有空写一下自己的职场故事，也算是给自己近 8 年的程序员工作做个总结复盘。

近 8 年有些事情做对了，也有更多事情做错了，在这里记录一下，希望能够给后人一些帮助吧，也欢迎私信交流。文笔不好，见谅，有些细节记不清了，如果有出入，就当是我编的这个故事吧。

PS：有几个问题先在这里解释一下，评论就不一一回复了

1.关于差生，我本人在科大时确实成绩偏下，差生主要讲这一点，没其他意思。

2.因为买房是我人生中的大事，我认为需要记录和总结一下，本文中会有买房，房价之类的信息出现，您如果对房价，炒房等反感的话，请您停止阅读，并且我再这里为浪费您的时间先道个歉。

2013 年

加入上海航天 x 院某卫星研究所

本人 86 年生人，13 年从中科大软件相关专业毕业，由于父母均是老师，从小接受的教育就是努力学习，找个稳定的“好工作”，报效国家。

于是乎，毕业时候头脑一热加入了上海航天 x 院某卫星研究所，没有经过自己认真思考，仅仅听从父母意见，就草率的决定了自己的第一份工作，这也为我 5 年后离职埋下了隐患。这里总结第一条经验：

如果你的亲人是普通阶层，那对于人生中一些大事来说，他们给的建议往往就是普通阶层的思维，他们的阶层就是他们一生思维决策的结果，如果你的目标是跳出本阶层，那最好只把他们的建议当成参考。

13 年 4 月份，我坐上火车来到上海，在一路换乘地铁来到了大闵行，出了地铁走路到单位，一路上建筑都比较老旧，我心里想这跟老家也没什么区别嘛，还大上海呢。

到达单位报道，负责报道的老师很亲切，填写完资料，分配了一间宿舍，还给了大概 3k 左右安家费，当时我心里那个激动啊（乡下孩子没有见过钱啊，见谅），拿了安家费，在附近小超市买好生活用品，这样我就开始了自己航天生涯。

经过 1 个月集中培训后，我分配到部门，主要负责卫星上嵌入式软件开发。不过说是高大上的卫星软件开发，其实刚开始就是打杂，给实验室、厂房推箱子搬设备，呵呵，说航天是个体力活相信很多航天人都有同感吧。不过当时年轻，心思很单纯，每天搬完设备，晚上主动加班，看文档材料，画软件流程图，编程练习，日子过得很充实。

记得第一个月到手大概 5k 左右（好少呀），当时很多一起入职的同事抱怨，我没有，我甚至不太愿意和他们比较工资，这里总结第二条经验：

不要和你的同事比工资，没有意义，比工资总会有人受伤，更多的是负面影响，并且很多时候受伤的会是你。

工作中暂露头角

工作大概一个月的时候，我遇到了一件事情，让我从新员工里面开始暂露头角。事情是这样的当时国家要对军工单位进行 GJB5000A 软件开发等级认证（搞过这个认证的同学应该都知道，过这个认证那是要多酸爽有多酸爽），但是当时一个负责配置管理的同事却提出离职，原因是他考上了公务员，当时我们用的那个软件平台后台的版本控制是 SVN 实现的，恰好我在学校写程序时用过，呵呵，话说回来现在学生自己写软件很少有人会在本地搭版本控制器吧！我记得当时还被同学嘲笑过，这让我想起了乔布斯学习美术字的故事，这里总结一下：

不要说一项技能没有用，任何你掌握的技能都有价值，但是你要学会找到发挥它的场景。如果有一天你落水了，你可能会很庆幸，自己以前学会了游泳。

工作中如果要上升，你要勇于承担麻烦的、有挑战的任务，当你推掉麻烦的时候，你也推掉了机遇。

好了，扯远了，回到前面，当时我主动跟单位认证负责人提出，我可以帮忙负责这方面的工作，我有一定经验。这里要提一下这个负责人，是位女士，她是我非常敬佩的一个前辈，认真，负责，无私，整个人为国家的航天事业奉献了几十年，其实航天领域有非常多这样的老前辈，他们默默奋斗，拿着不高的薪水，为祖国的国防建设做出了巨大的贡献。当时这位负责人，看我平时工作认真积极，思维反应也比较灵活（因为过认证需要和认证专家现场答辩的）就同意了我的请求，接受到这个任务之后，我迅速投入，学习认证流程、体系文件、迅速掌握认证工作要点，一点一点把相关的工作做好，同时周期性对业务进行复盘，总结复盘可能是我自己的一个优点：

很多人喜欢不停的做事，但不会停下来思考，缺乏总结复盘的能力，其实阶段性总结复盘，不仅能够固化前面的经验，也能梳理后面的方向；把事情做对很重要，但是更重要的是做对的事；另外不要贪快，方向正确慢就是快(后半句是我后来才想明白的，如果早想明白，就不会混成目前这样了）

1 个月后，当时有惊无险通过了当年的认证，当时负责人主动向单位申请了 2k 特别奖，当时我真的非常高兴，主要是自己的工作产生了价值，得到了认可。后来几个月的日子平淡无奇，有印象的好像只有两件事情。

一件事情是当年端午，当时我们在单位的宿舍休息，突然楼道上一阵骚动，我打开宿舍门一看，原来是书记来慰问，还给每个人送了一箱消暑饮料，这件事印象比较深刻，是我觉得国企虽然有各种各样的问题，但是论人文关怀，还是国企要好得多。

错失一次暴富的机会

另一件事是当年室友刚买房，然后天天研究生财&之道，一会劝我买房，一会劝我买比&特&币，我当时没有鸟他，为什么呢，因为当时的室友生活习惯不太好，会躺在床上抽烟，还在宿舍内做饭(我们宿舍是那种很老的单位房，通风不好），我有鼻炎，所以不是很喜欢他（嗯，这里要向室友道歉，当年真是太幼稚了）。现在 B&T&C4 万美元了，我当时要是听了室友也能小发一笔了（其实我后来 18 年买了，但是没有拿住这是后话），这里要总结一下：

不要因为某人的外在，如外貌、习惯、学历等对人贴上标签，去盲目否定别人，对于别人的建议，应该从客观出发，综合分析，从善如流是一项非常难得的品质。

人很难挣到他认知之外的财富，就算偶然拿到了，也可能很快失去。所以不要羡慕别人投机获得的财富，努力提升你的思维，财商才是正道。

航天生涯的第一个正式项目

转眼到了 9 月份（我 4 月份入职的），我迎来了我航天生涯第一个正式的型号项目（型号，是军工的术语，就相当于某个产品系列比如华为的 mate）,当时分配给我的型号正式启动，我终于可以开始写卫星上的代码了。

当时真的是心无旁骛，一心投身军工码农事业，每天实验室，测试厂房，评审会，日子虽然忙碌，但是也算充实。并且由于我的努力工作，加上还算可以的技术水平，我很快就能独立胜任一些型号基础性的工作了，并且我的努力也受到了型号（产品）线的领导的认可，他们开始计划让我担任型号主管设计师，这是一般工作 1-2 年的员工的岗位，当时还是有的激动的。

2014 年

升任主管设计师后的一次波折

转眼间到 2014 年了，大概上半年吧，我正式升任主管设计师，研发工作上也开时独挡一面了，但是没多久产品研发就给了我当头一棒。

事情是这样的，当时有一个版本软件编写完毕，加载到整星上进行测试，有一天大领导来检查，当时非常巧，领导来时测试主岗按某个岗位的人员要求，发送了一串平时整星没有使用的命令（我在实验室是验证过的），结果我的软件立刻崩溃，无法运行。由于正好领导视察，这个问题立马被上报到质量处，于是我开始了苦逼的技术归零攻关（搞航天的都懂，我就不解释了）。

期间每天都有 3 个以上领导，询问进度，当时作为新人的我压力可想而知，可是我无论如何都查不出来问题，在实验室我的软件完全正常！后来，某天中午我突然想到，整星上可能有不同的环境，具体过程就不说了。后人查出来是一个负责加载我软件的第三方软件没有受控，非法篡改了我程序的 4 个字节，而这 4 字节正好是那天发送命令才会执行的代码，结果导致我的软件崩溃。最后我花了进一个月完成了所有质量归零报告，技术分析报告，当然负责技术的领导没有责怪，相反的还更加看重我了，后来我每遇到一个质量问题，无论多忙最后定要写一份总结分析报告，这成了我一个技术习惯，也为后来我升任软件开发组长奠定了技术影响基础。

强烈建议技术团队定期开展质量回溯，需要文档化，还要当面讲解，深入的技术回溯有助于增加团队技术交流活跃度，同时提升团队技术积淀，是提升产品质量，打造优秀团队的有效方法。

个人的话建议养成写技术总结文章的习惯，这不仅能提升个人技术，同时分享也可以增加你的影响力

职场软技能的重新认识

上半年就在忙碌中度过了，到了年底，发生了一件对我们组影响很大的事情，年底单位开展优秀小组评比， 其实这个很多公司都有，那为什么说对我们组影响很大内，这里我先卖关子。这里先不得不提一个人，是个女孩子，南京大学的，比我晚来一年，她做事积极，反应灵敏，还做得一手不错的 PPT，非常优秀，就是黑了点（希望她看到了不要来找我，呵呵）。

当时单位开展优秀小组评比，我们当时是新员工，什么都很新鲜，就想参加一下，当时领导说我们每年都参加的，我们问，我们每年做不少东西，怎么没有看到过评比的奖状，领导有点不好意思，说我们没有进过决赛。我们又问，多少名可以进入决赛圈，答曰前 27 名即可（总共好像 50+个组）我们当时心里真是一万个羊驼跑过。。。。

其实当时我们组每年是做不少事情的，我们觉得我们不应该排名如此之低，于是我们几个年轻人开始策划，先是对我们的办公室彻底改造(因为要现场先打分，然后进决赛），然后好好梳理了我们当年取得的成绩，现场评比时我自告奋勇进行答辩（我沟通表达能力还不错，这也算我一个优势吧），后面在加上前文提到的女孩子做的漂亮 PPT，最后我们组拿到了铜牌班组的好成绩，我也因为这次答辩的优秀表现在领导那里又得到了认可，写了大半段了，再总结一下：

职场软技能如自我展示很重要，特别是程序员，往往在这方面是个弱项，如果可以的话，可以通过练习，培训强化一下这些软技能，对职场的中后期非常有帮助。

2015 年

时间总是过得很快，一下就到 2015 年了，这一年发生了一件对我影响很大的事情。

升任小组副组长

当时我们小组有 18 个人了，有一天部门开会，主任要求大家匿名投票选副组长（当时部门领导还是很民主的），因为日常事务逐渐增多，老组长精力有限，想把一些事物分担出来，当天选举结果就出来了，我由于前面的技术积累和沟通表达能力的展现，居然升任副组长，当时即有些意外，因为总是有传言说国企没背景一辈子就是最最底层，后来我仔细思考过，下面是我不成熟的想法：

不要总觉得国企事业单位的人都是拼背景，拼关系，我承认存在关系户，但是不要把关系户和低能力挂钩，背景只是一个放大器，当关系户做出了成绩时它会正面放大影响，当关系户做了不光彩的事情是，它也会让影响更坏。没有背景，你可以作出更大的贡献来达到自己的目标，你奋斗的过程是更大的财富。另外，我遇到的关系户能力都很强，也可能是巧合，也可能是他们的父辈给给他们在经验层次上比我们更优秀的教育。

学习团队管理技巧

升任副组长后，我的工作更加忙碌了，不仅要做自己项目的事情，还要横向管理和协调组内其他项目的事情，有人说要多体谅军工单位的基层班组长，这话真是没错啊。这个时候我开始学习一些管理技巧，如何凝聚团队，如何统一协调资源等等，这段时间我还是在不断成长。不过记得当年还是犯了一个很大的方向性错误，虽然更多的原因可能归结为体制吧，但是当时其实可以在力所能及的范围内做一些事情的。

具体是这样的，当时管理上有项目线，有行政线，就是很常见的矩阵式管理体系，不过在这个特殊的体制下面出现了一些问题。当时部门一把手被上级强制要求不得挂名某个型号，因为他要负责部门资源调配，而下面的我们每个人都归属 1-2 个型号（项目），在更高层的管理上又有横向的行政线（不归属型号），又有纵向的型号管理线。

而型号的任务往往是第一线的，因为产品还是第一位的，但是个人的绩效、升迁又归属行政线管理，这种形式在能够高效沟通的民企或者外企一般来说不是问题，但是在沟通效率缓慢，还有其他掣肘因素的国企最终导致组内每个人忙于自身的型号任务，各自单打独斗，无法聚焦，一年忙到头最终却得不到部门认可，我也因为要两面管理疲于应付，后来曾经反思过，其实可以聚焦精力打造通用平台（虽然这在我们行业很难）部分解决这个问题：

无论个人还是团队，做事情要聚焦，因为个人和团队资源永远都是有限的，如果集中一个事情都做不好，那分散就更难以成功，但是在聚焦之前要深入思考，往什么方向聚焦才是正确的，只有持续做正确的事情才是最重要的。

2016 年

这一年是我人生的关键一年，发生了很多事情。

升任小组组长

第一件事情是我正式升任组长，由于副组长的工作经验，在组长的岗位上也做得比较顺利，在保证研发工作的同时，继续带领团队连续获得铜牌以上班组奖励，另外各种认证检查都稳稳当通过，但是就在这个时候，因为年轻，我犯下了一个至今非常后悔的错误。

大概是这样的，我们部门当时有两个大组，一个是我们的软件研发组，一个是负责系统设计的系统分析组。

当时两个组的工作界面是系统组下发软件任务书给软件组，软件组依照任务书开发，当时由于历史原因，软件组有不少 10 年以上的老员工，而系统组由于新成立由很多员工工作时间不到 2 年，不知道从什么时候起，也不知道是从哪位人员开始，软件组的不少同事认为自己是给系统组打工的。并且，由于系统组同事工作年限较短，实际设计经验不足，任务书中难免出现遗漏，从而导致实际产品出错，两组同事矛盾不断加深。

最后，出现了一个爆发：当时系统组主推一项新的平台，虽然这个平台得到了行政线的支持，但是由于军工产品迭代严谨，这个新平台当时没有型号愿意使用，同时平台的部分负责人，居然没有完整的型号经验！由于这个新平台的软件需要软件组实现，但是因为已经形成的偏见，软件同事认为这项工作中自己是为利益既得者打工。

我当时也因为即负责实际软件开发，又负责部分行政事务，并且年轻思想不成熟，也持有类似的思想。过程中的摩擦、冲突就不说了，最后的结果是系统组、软件组多人辞职，系统组组长离职，部门主任离职创业（当然他们辞职不全是这个原因，包括我离职也不全是这个原因，但是我相信这件事情有一定的影响），这件事情我非常后悔，后来反思过其实当时自己应该站出来，协调两组矛盾，全力支持部门技术升级，可能最终就不会有那么多优秀的同事离开了。

公司战略的转型，技术的升级迭代，一定会伴随着阵痛，作为基层组织者，应该摒弃个人偏见，带领团队配合部门、公司主战略，主战略的成功才是团队成功的前提。

买房

16 年我第二件大事情就是买房，关注过近几年房价的人都可能还记得，16 年一线城市猛涨的情景。其实当时 15 年底，上海市中心和学区房已经开始上涨，我 15 年底听同事开始讨论上涨的房价，我心里开始有了买房的打算，大约 16 春节（2 月份吧，具体记不得了），我回老家探望父母，同时跟他们提出了买房的打算。

我的父亲是一个“央视新闻爱好者”，爱好看狼咸平，XX 刀，XX 檀的节目，大家懂了吧，父亲说上海房价太高了，都是泡沫，不要买。这个时候我已经不是菜鸟了，我想起我总结的第一条经验（见上文），我开始收集往年的房价数据，中央历年的房价政策，在复盘 15 年的经济政策时我发现，当年有 5 次降息降准，提升公积金贷款额度，放松贷款要求于是我判定房价一定会继续涨，涨到一个幅度各地才会出台各种限购政策，并且房价在城市中是按内环往外涨的于是我开始第一次在人生大事上反对父母，我坚决表态要买房。父亲还是不太同意，他说年底吧，先看看情况（实际是年底母亲的退休公积金可以拿出来大概十几万吧，另外未来丈母娘的公积金也能拿出来了大概比这多些）。我还是不同意，父亲最终拗不过我，终于松口，于是我们拿着双方家庭凑的 50w 现金开始买房，后来上海的房价大家都看到了。这件事也是我做的不多的正确的事情之一。

但是最可笑的是，我研究房价的同时居然犯下了一个匪夷所思的错误，我居然没有研究买房子最重要的因素是什么，我们当时一心想买一手房（现在想想真是脑子进水），最后买了一套松江区交通不便的房子，这第一套房子的地理位置也为我后来第二次离职埋下了隐患，这个后面会说。

一线或者准一线城市能买尽量买，不要听信房产崩溃论，如果买不起，那可以在有潜力的城市群里用父母的名义先买一套，毕竟大多数人的财富其实是涨不过通货膨胀的。另外买房最重要的三个要素是，地段，地段，地段。

买房的那天上午和女朋友领的证，话说当时居然把身份证写错了三次 。。。

这下我终于算是有个家了，交完首付那个时候身上真的是身无分文了。航天的基层员工的收入真的是不高，我记得我当时作为组长，每月到手大概也就 7k-8k 的样子，另外有少量的奖金，但是总数仍然不高，好在公积金比较多，我日常也没什么消费欲望，房贷到是压力不大。

买完房子之后，我心里想，这下真的是把双方家庭都掏空了（我们双方家庭都比较普通，我的收入也在知乎垫底，没办法）万一有个意外怎么办，我思来想去，于是在我下一个月发工资之后，做了一个我至今也不知道是对是错的举动，我利用当月的工资，给全家人家人买了保险保险，各种重疾，意外都配好了。但是为什么我至今也不知道对错呢，因为后来老丈人，我母亲都遭遇病魔，但是两次保险公司都拒赔，找出的理由我真是哑口无言，谁叫我近视呢。另外真的是要感谢国家，亲人重病之后，最终还是走了医保，赔偿了部分，不然真的是一笔不小的负担。

2017 年

对我人生重大影响的 2016 年，在历史的长河中终究连浪花都激不起来。历史长河静静流淌到了 2017 年，这一年我参加了中国深空探测项目，当然后面我没有等到天问一号发射就离开了航天，但是有时候仰望星空的时候，想想我的代码正在遥远的星空发挥作用，心里也挺感慨的，我也算是重大历史的参与者了，呵呵。好了不说工作了，平淡无奇的 2017 年，对我来说也发生了两件大事。

买了第二套房子

第一件事是我买了第二套房子，说来可笑，当年第一套房子都是掏空家里，这第二年就买了第二套房子，生活真的是难以捉摸。到 2017 年时，前文说道，我母亲和丈母娘先后退休，公积金提取出来了，然后在双方家里各自办了酒席，酒席之后，双方父母都把所有礼金给了我们，父母对自己的孩子真的是无私之至。当时我们除了月光之外，其实没有什么外债，就是生活简单点。拿到这笔钱后，我们就在想如何使用，一天我在菜市场买菜，有人给我一张 xuanchuan 页，本来对于这样的 xuanchuan 页我一般是直接扔掉的，但是当天鬼死神差我看了一眼，只见上面写着“嘉善高铁房，紧邻上海 1.5w”我当时就石化了，我记得去年我研究上海房价的时候，曾经在网站上看到过嘉善的房价，我清楚的记得是 5-6k，我突然意识到我是不是错过了什么机会，反思一下：

工作生活中尽量保持好奇心，不要对什么的持怀疑态度，很多机会就隐藏在不起眼的细节中，比如二十年前有人告诉你未来可以在网上购物，有人告诉你未来可以用手机支付，你先别把他直接归为骗子，静下来想一想，凡事要有好奇心，但是要有自己的判断。

于是我立马飞奔回家，开始分析，大城市周边的房价。我分析了昆山，燕郊，东莞，我发现燕郊极其特殊，几乎没有产业，纯粹是承接大城市人口溢出，因此房价成高度波动。而昆山和东莞，由于自身有产业支撑，又紧邻大城市，因此房价稳定上涨。我和妻子一商量，开始了外地看房之旅，后来我们去了嘉善，觉得没有产业支撑，昆山限购，我们又到嘉兴看房，我发现嘉兴房价也涨了很多，但是这里购房的大多数新房，都是上海购房者，入住率比较低，很多都是打算买给父母住的，但是实际情况是父母几乎不在里面住，我觉得这里买房不妥，存在一个变现的问题。于是我开始继续寻找，一天我看着杭州湾的地图，突然想到，杭州湾北侧不行，那南侧呢？南侧绍兴，宁波经济不是更达吗。于是我们目光投向绍兴，看了一个月后，最后在绍兴紧贴杭州的一个区，购买了一套小房子，后来 17 年房价果然如我预料的那样完成中心城市的上涨之后开始带动三四线城市上涨。后来国家出台了大湾区政策，我对我的小房子更有信心了。这里稍微总结一下我个人不成熟的看法：

在稳定通胀的时代，负债其实是一种财富。长三角城市群会未来强于珠港澳，因为香港和澳门和深圳存在竞争关系，而长三角城市间更多的是互补，未来我们看澳门可能就跟看一个中等省会城市一样了。

准备要孩子

2017 年的第二件事是，我们终于准备要孩子了，但是妻子怎么也备孕不成功，我们开始频繁的去医院，从 10 元挂号费的普通门诊，看到 200 元，300 元挂号费的专家门诊，看到 600 元的特需门诊，从综合医院看到妇幼医院，从西医看到中医，每个周末不是在医院排队，就是在去医院的路上。最后的诊疗结果是有一定的希望，但是有困难，得到消息时我真的感觉眼前一片黑暗，这种从来在新闻上才能看到了事情居然落到了我们头上，我们甚至开始接触地下 XX 市场。同时越来越高的医疗开销（专家门诊以上就不能报销了）也开始成为了我的负担，前文说了，我收入一直不高，又还贷款，又支付医疗开支渐渐的开始捉襟见肘，我甚至动了卖小房子的打算。

未完待遇~

2018 年

前面说到，2017 年开始频繁出入医院，同时项目也越来越忙，我渐渐的开始喘不过气起来，最后医生也给了结论，需要做手术，手术有不小的失败的几率。我和妻子商量后一咬牙做吧，如果失败就走地下的路子，但是可能需要准备一笔钱（手术如果成功倒是花销不会太大），哎，古人说一分钱难倒英雄汉，真是诚不欺我啊，这个时候我已经开始萌生离职的想法了。怎么办呢，生活还是要继续，我想起了经常来单位办理贷款的银行人员，贷款吧，这种事情保险公司肯定不赔的嘛，于是我办理了一笔贷款，准备应急。

项目结束，离职

时间慢慢的时间走到了 8 月份，我的项目已经告一定段落，一颗卫星圆满发射成功，深空项目也通过了初样阶段我的第一份工作也算有始有终了。我开始在网上投递简历，我技术还算可以，沟通交流也不错，面试很顺利，一个月就拿到了 6 个 offer，其中就有大菊花厂的 offer，定级 16A，25k 月薪后来政策改革加了绩效工资 6k(其实我定级和总薪水还是有些偏低了和我是国企，本来总薪水就低有很大关系，话说菊花厂级别后面真的是注水严重，博士入职轻松 17 级)菊花厂的 offer 审批流程是我见过最长，我当时的接口人天天催于流程都走了近 2 个月。

我向领导提出了离职，离职的过程很痛苦，有过经历的人估计都知道，这里就不说了。话说我为什么会选择华为呢，一是当时急需钱，二是总觉得搞嵌入式的不到华为看看真的是人生遗憾。现在想想没有认真去理解公司的企业文化就进入一家公司还是太草率了：

如果你不认同一个公司的企业文化，你大概率干不长，干不到中高层，IT 人你不及时突破到中高层很快你就会面临非常多问题；公司招人主要有两种人，一种是合格的人，一种是合适的人，合格的人是指技能合格，合适的人是指认同文化。企业招人就是先把合格的人找进来，然后通过日日宣讲，潜移默化把不合适的人淘汰掉。

入职华为

经过一阵折腾终于离职成功，开始入职华为。离职我做了一件比较疯狂的事情，当时因为手上有一笔现金了，一直在支付利息，心里就像拿它干点啥。那时由于看病，接触了地下 XX 市场，听说了 B&TC，走之前我心一横买 B&T&C，后来不断波动，最终我还是卖了，挣了一些钱，但是最终没有拿到现在，果然是考验人性啊。

2019 年

成功转正

华为的试用期真长，整整 6 个月，每个月还有流程跟踪，交流访谈，终于我转正了，转正答辩我不出意料拿到了 Excellent 评价，涨了点薪水，呵呵还不错。华为的事情我不太想说太多，总之我觉得自己没有资格评判这个公司，从公司看公司的角度华为真正是个伟大的公司，任老爷子也是一个值得敬佩的企业家。

在华为干了半年后，我发现我终究还是入职的时候太草率了，我当时没有具体的了解这个岗位，这个部门。入职之后我发现，我所在的是硬件部门，我在一个硬件部门的软件组，我真是脑子秀逗了。

在一个部门，你需要尽力进入到部门主航道里，尽力不要在边缘的航道工作，特别是那些节奏快，考核严格的部门。

更严峻的是我所在的大组，居然是一个分布在全国 4 地的组，大组长（华为叫 LM）在上海，4 地各有一个本地业务负责人。我立刻意识到，到年终考评时，所有的成果一定会是 4 地分配，并且 4 地的负责人会占去一大部分，这是组织结构形成的优势。我所在的小组到时候会难以突破，资源分配会非常激烈。

备孕成功

先不说这些，在 18 年时妻子做完了手术，手术居然很成功。休息完之后我们 19 年初开始备孕了，这次真的是上天保佑，运气不错，很快就怀上了。这段时间，我虽然每天做地铁 1.5 小时到公司上班，经受高强度的工作，我心里每天还是乐滋滋的。但是，突然有一天，PL（华为小组长）根我说，LM 需要派人去杭研所支持工作，我是最合适人选，让我有个心里准备。当时我是不想去的，这个时候妻子是最需要关怀的时候，我想 LM 表达了我的意愿，并且我也知道如果去了杭州年底绩效考评肯定不高。过程不多说了，反正结果是我去了杭州。

于是我开始了两头奔波的日子，每个月回上海一趟。这过程中还有个插曲，家里老家城中村改造，分了一点钱，父母执意卖掉了老家学校周边的房子，丈母娘也处理老家的一些房子，然后把钱都给了我们，然后我用这笔家里最后的资产，同时利用华为的现金流在绍、甬不限购地区购买一些房子，我没有炒房的想法，只是防止被通货膨胀侵蚀而已，不过后来结果证明我貌似又蒙对了啊，我自己的看法是：

杭绍甬在经济层面会连成紧密的一片，在行政区上杭州兼并绍 部分区域的概率其实不大，行政区的扩展应该是先兼并自身的下级代管城市。

宝宝出生

不说房子了，继续工作吧。10 月份干了快一年时候，我华为的师傅（华为有师徒培养体系）偷偷告诉我被定为备选 PL 了，虽然不知道真假，但是我心里还是有点小高兴。不过我心里也慢慢意识到这个公司可能不是我真正想要的公司，这么多年了，愚钝如我慢慢也开始知道自己想干什么了。因为我的宝宝出生了，看着这只四脚吞金兽，我意识到自己已经是一个父亲了。

2019 年随着美国不断升级的制裁消息，我在华为的日子也走到年底，马上将迎来神奇的 2020 年。

2020

2020 就少写一些了，有些东西真的可能忘却更好。

在家办公

年初就给大家来了一个重击，新冠疫情改变了太多的东西。这个时候真的是看出华为的执行力，居家办公也效率不减多少，并且迅速实现了复工。到了 3-4 月份，华为开始正式评议去年绩效等级，我心里开始有预感，以前的分析大概率会兑现，并且绩效和收入挂钩，华为是个风险意识极强的公司，去年的制裁会导致公司开始风险预备，虽然我日常工作还是受到多数人好评，但是我知道这其实在评议人员那里，没有任何意义。果然绩效评议结果出来了，呵呵，我很不满意。绩效沟通时 LM 破例跟我沟通了很长时间，我直接表达了我的想法。LM 承诺钱不会少，呵呵，我不评价吧。后来一天开始组织调整，成立一个新的小组，LM 给我电话让我当组长,我拒绝了，这件事情我不知道对错，我当时是这样考虑的

1. 升任新的职位，未必是好事，更高的职位意味着更高的要求，因此对备选人员要么在原岗位已经能力有余，要么时间精力有余；我认为当时我这两个都不满足，呵呵离家有点远，LM 很可以只是因为绩效事情做些补偿。

2. 华为不会垮，这点大家有信心，但未来一定会出现战略收缩，最后这艘大船上还剩下哪些人不清楚，底层士兵有可能是牺牲品。

3. 我 34 岁了

提出离职

另外我一直思考未来想做什么，已经有了一丝眉目，就这样，我拿了年终奖约 7 月就提出了离职，后来部门还让我做了最后一次贡献，把我硬留到 10 月份，这样就可以参加上半年考核了，让帮忙背了一个 C 呵呵，这是工作多年，最差绩效吧。

这里还有一个小插曲，最后这三个月我负责什么工作呢，因为 20 年 3 月开始我就接手了部分部门招聘工作（在华为干过的都知道为什么非 HR 也要帮忙招聘，呵呵大坑啊，就不多解释了），结果最后三个月我这个待离职员工居然继续负责招聘，真的是很搞笑，不过由于我在上一份工作中其实一直也有招聘的工作，所以也算做的轻车熟路，每天看 50 份左右简历（我看得都非常仔细，我害怕自己的疏忽会导致一个优秀的人才错失机会，所以比较慢）其实也蛮有收货，最后好歹对程序员如何写简历有了一些心得。

总结

好了 7 年多，近 8 年的职场讲完了，不管过去如何，未来还是要继续努力，希望看到这篇文章觉得有帮助的朋友，可以帮忙点个推荐，这样可能更多的人看到，也许可以避免更多的人犯我犯的错误。