Gitee八周年,一起创造无限可能的未来

梅川酷子 发表了文章 • 0 个评论 • 190 次浏览 • 2021-05-27 11:26 • 来自相关话题

「∞」,代表着无穷、无限、没有边界第「8」年的 Gitee 再次全新出发和Gitee最新入职的吉祥物「马建仓」一起以协作为蓝图,创造你我不设边界的未来⚠️前排提醒⚠️:文末有福利哦~来看一看学生王志、开源项目作者张硕、研发团队 Leader 李慕然和 Gite... ...查看全部

微信图片_20210527112345.png

微信图片_20210527112356.jpg

「∞」,代表着无穷、无限、没有边界

第「8」年的 Gitee 再次全新出发

和Gitee最新入职的吉祥物「马建仓」一起

以协作为蓝图,创造你我不设边界的未来

⚠️前排提醒⚠️:文末有福利哦~

微信图片_20210527112412.jpg来看一看学生王志、开源项目作者张硕、研发团队 Leader 李慕然和 Gitee 的故事吧。不论是开源作者还是研发团队,都能在 Gitee 上开创自己不设边界的未来。微信图片_20210527112428.jpg各位旅客请扶稳坐好,您的开源之旅即将发车,本次开源之旅共有三站,每到达一站Gitee都会有惊喜大礼等你赢取。微信图片_20210527112441.jpg微信图片_20210527112450.jpg

Gitee 企业版已经助力超过 18 万家企业/机构实现了协作的「新概念」:

全流程、无边界带来的极致高效。

微信图片_20210527112501.png微信图片_20210527112511.jpg在八周年活动时间内,我们为 Gitee 企业版的用户带来了超棒的优惠福利,简单粗暴,买就送哦~微信图片_20210527112522.png

感谢微信图片_20210527112544.png

推荐四款大屏可视化工具,大厂常用

苏道 发表了文章 • 0 个评论 • 247 次浏览 • 2021-05-25 15:58 • 来自相关话题

最经常的工作是将一些项目的数据从数据库导出,然后分门别类的列到excel表格中,领导看起来眼花缭乱。基基想,要是能以图表可视化展现出来,领导就可以看到项目近几个月的走势,也知道之后要怎么决策了。基基尝试了使用excel制作图表,由于操作复杂,放弃了,于是小编在... ...查看全部

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

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

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

1. 阿里云DataV

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

缺点:

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

2. 积木报表jimureport

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

缺点:

等你来发现呦!

3. 百度Sugar

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

缺点:

(1)试用期不长,试用期一过,需要花钱续费;

4. 帆软

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

缺点:

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


10大编程格言,作为程序员得你应该知道

木土走召 发表了文章 • 0 个评论 • 110 次浏览 • 2021-05-25 15:58 • 来自相关话题

每个程序员都该知道的10大编程格言(Kevin Pang):编程格言1:无风不起浪 (There is no smoke without fire)编程格言2:预防为主,治疗为辅(An ounce of prevention is worth a pound ... ...查看全部

每个程序员都该知道的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


最蛋疼的注册中心与API网关实践?看了吐血!

王叫兽 发表了文章 • 0 个评论 • 122 次浏览 • 2021-05-25 15:58 • 来自相关话题

之前在做顾问和咨询项目的时候,见到了一种非常经典的关于API网关和注册中心的错误用法。其实在我的星球里已经分享过这个案例,没想到最近又碰到了两个类似的使用姿势。。。也许这样的问题还存在不少团队的应用中,所以再拿出来分享一下,希望可以帮助读者更好的理解注册中心与... ...查看全部

之前在做顾问和咨询项目的时候,见到了一种非常经典的关于API网关和注册中心的错误用法。其实在我的星球里已经分享过这个案例,没想到最近又碰到了两个类似的使用姿势。。。也许这样的问题还存在不少团队的应用中,所以再拿出来分享一下,希望可以帮助读者更好的理解注册中心与API网关的作用,并将它们用对地方!

在微服务架构中,我们都会使用API网关来作为暴露服务的唯一出口。这样可以将与业务无关的各项控制,集中的在API网关中进行统一管理,从而使得业务服务可以更加专注于业务领域本身。

而在微服务构建的系统内部,各个服务之间的调度,我们通常采用注册中心和客户端负载均衡的方式来实现服务之间的调用。

所以,大致的结构是这样子的:

在这样的架构实践中,注册中心和API网关的功能,主要有以下两点:

  1. API网关通过注册中心发现所有后端服务,从来实现动态代理

  2. 后端服务集群间,通过注册中心互相发现对方,而实现直接调用(通常使用Ribbon、Feign这些框架)

下面就来具体说说今天的主角(错误案例),先上图:

注意图中的两个地方:

  1. 存在两套网关,一套对内访问、一套对外访问

  2. 对内访问的网关实际就是起到了一个代理作用,较之前的图对比以下,就知道,这个方案中并没有利用到服务治理机制去直接让服务A调用服务B,而是通过网关去做了一次代理。

更令人震惊的是,在我看到代码的时候,他们居然也是用feign来编写服务间调用的,但在配置请求路径的时候,是使用在内部API网关上配置的二级域名来实现(比如:http://service-name.didispace.com/api-path,这里service-name对应不同的服务名),而熟悉Spring Cloud的读者都知道,其实service-name.didispace.com这部分直接用服务名替代就可以了…是不是瞬间有种脱裤子放x的感觉?

如果这样来使用的话,其实引入注册中心的用处就很小了,实际上只有给两个网关提供了集中的后端服务发现功能。如果要实现这种功能,其实注册中心都可以不需要,每个服务都直接上报地址给网关就好了,架构会更加简单。

同时,在这样的实现方式之下,内部调用都要经过内部网关多一跳的调度过程,除了要多出内部网关的部署资源之外,每一次内部调用的时间开销实际上都大了。所以这样的用法是非常不推荐的!

对于API网关的定位,还是以作为对外出口的管理为最佳,内部的代理调用,均交给服务注册与发现机制 + 客户端负载均衡就ok了。没有必要再增加一层代理,不但增加部署成本,同时还会降低的性能。完全是赔了夫人又折兵的做法,非常不可取!

除非有一种情况,如果你的业务集群很大,对前端暴露用一套网关,同时后端服务有几千几万,由很多个不同的团队在维护,那么在团队的边界处设立内部的网关,那还是合理的。同时这种情况下,对于注册中心,按团队做隔离也是有必要的。因为这样可以分而治之,更好的做好接口的访问控制与管理。但是,如果你本身服务不多,团队也不大,那就别折腾这么复杂的架构了,越复杂稳定性就越难保障,这点一定要平衡好。


SQL优化怎么做?来这里看看!

木土走召 发表了文章 • 0 个评论 • 137 次浏览 • 2021-05-25 15:58 • 来自相关话题

前言在应用开发的早期,数据量少,开发人员开发功能时更重视功能上的实现,随着生产数据的增长,很多SQL语句开始暴露出性能问题,对生产的影响也越来越大,有时可能这些有问题的SQL就是整个系统性能的瓶颈。SQL优化一般步骤1、通过慢查日志等定位那些执行效率较低的SQ... ...查看全部

前言

在应用开发的早期,数据量少,开发人员开发功能时更重视功能上的实现,随着生产数据的增长,很多SQL语句开始暴露出性能问题,对生产的影响也越来越大,有时可能这些有问题的SQL就是整个系统性能的瓶颈。

SQL优化一般步骤

1、通过慢查日志等定位那些执行效率较低的SQL语句
2、explain 分析SQL的执行计划

需要重点关注type、rows、filtered、extra。

type由上至下,效率越来越高

  • ALL 全表扫描

  • index 索引全扫描

  • range 索引范围扫描,常用语<,<=,>=,between,in等操作

  • ref 使用非唯一索引扫描或唯一索引前缀扫描,返回单条记录,常出现在关联查询中

  • eq_ref 类似ref,区别在于使用的是唯一索引,使用主键的关联查询

  • const/system 单条记录,系统会把匹配行中的其他列作为常数处理,如主键或唯一索引查询

  • null MySQL不访问任何表或索引,直接返回结果 虽然上至下,效率越来越高,但是根据cost模型,假设有两个索引idx1(a, b, c),idx2(a, c),SQL为”select * from t where a = 1 and b in (1, 2) order by c”;如果走idx1,那么是type为range,如果走idx2,那么type是ref;当需要扫描的行数,使用idx2大约是idx1的5倍以上时,会用idx1,否则会用idx2

Extra

  • Using filesort:MySQL需要额外的一次传递,以找出如何按排序顺序检索行。通过根据联接类型浏览所有行并为所有匹配WHERE子句的行保存排序关键字和行的指针来完成排序。然后关键字被排序,并按排序顺序检索行。

  • Using temporary:使用了临时表保存中间结果,性能特别差,需要重点优化

  • Using index:表示相应的 select 操作中使用了覆盖索引(Coveing Index),避免访问了表的数据行,效率不错!如果同时出现 using where,意味着无法直接通过索引查找来查询到符合条件的数据。

  • Using index condition:MySQL5.6之后新增的ICP,using index condtion就是使用了ICP(索引下推),在存储引擎层进行数据过滤,而不是在服务层过滤,利用索引现有的数据减少回表的数据。

3、show profile 分析

了解SQL执行的线程的状态及消耗的时间。默认是关闭的,开启语句“set profiling = 1;”

SHOW PROFILES ;SHOW PROFILE FOR QUERY  #{id};
4、trace

trace分析优化器如何选择执行计划,通过trace文件能够进一步了解为什么优惠券选择A执行计划而不选择B执行计划。

set optimizer_trace="enabled=on";set optimizer_trace_max_mem_size=1000000;select * from information_schema.optimizer_trace;
5、确定问题并采用相应的措施
  • 优化索引

  • 优化SQL语句:修改SQL、IN 查询分段、时间查询分段、基于上一次数据过滤

  • 改用其他实现方式:ES、数仓等

  • 数据碎片处理

场景分析

案例1、最左匹配

索引

KEY `idx_shopid_orderno` (`shop_id`,`order_no`)

SQL语句

select * from _t where orderno=''

查询匹配从左往右匹配,要使用order_no走索引,必须查询条件携带shop_id或者索引(shop_id,order_no)调换前后顺序

案例2、隐式转换

索引

KEY `idx_mobile` (`mobile`)

SQL语句

select * from _user where mobile=12345678901

隐式转换相当于在索引上做运算,会让索引失效。mobile是字符类型,使用了数字,应该使用字符串匹配,否则MySQL会用到隐式替换,导致索引失效。

案例3、大分页

索引

KEY `idx_a_b_c` (`a`, `b`, `c`)

SQL语句

select * from _t where a = 1 and b = 2 order by c desc limit 10000, 10;

对于大分页的场景,可以优先让产品优化需求,如果没有优化的,有如下两种优化方式, 一种是把上一次的最后一条数据,也即上面的c传过来,然后做“c < xxx”处理,但是这种一般需要改接口协议,并不一定可行。另一种是采用延迟关联的方式进行处理,减少SQL回表,但是要记得索引需要完全覆盖才有效果,SQL改动如下

select t1.* from _t t1, (select id from _t where a = 1 and b = 2 order by c desc limit 10000, 10) t2 where t1.id = t2.id;
案例4、in + order by

索引

KEY `idx_shopid_status_created` (`shop_id`, `order_status`, `created_at`)

SQL语句

select * from _order where shop_id = 1 and order_status in (1, 2, 3) order by created_at desc limit 10

in查询在MySQL底层是通过 n*m 的方式去搜索,类似union,但是效率比union高。in查询在进行cost代价计算时(代价 = 元组数 * IO平均值),是通过将in包含的数值,一条条去查询获取元组数的,因此这个计算过程会比较的慢,所以MySQL设置了个临界值(eq_range_index_dive_limit),5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200,即in条件超过了200个数据,会导致in的代价计算存在问题,可能会导致Mysql选择的索引不准确。

处理方式,可以(order_statuscreated_at)互换前后顺序,并且调整SQL为延迟关联。

案例5、范围查询阻断,后续字段不能走索引

索引

KEY `idx_shopid_created_status` (`shop_id`, `created_at`, `order_status`)

SQL语句

select * from _order where shop_id = 1 and created_at > '2021-01-01 00:00:00' and order_status = 10

范围查询还有“IN、between”

案例6、不等于、不包含不能用到索引的快速搜索。(可以用到ICP)
select * from _order where shop_id=1 and order_status not in (1,2)select * from _order where shop_id=1 and order_status != 1

在索引上,避免使用NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等

案例7、优化器选择不使用索引的情况

如果要求访问的数据量很小,则优化器还是会选择辅助索引,但是当访问的数据占整个表中数据的蛮大一部分时(一般是20%左右),优化器会选择通过聚集索引来查找数据。

select * from _order where  order_status = 1

查询出所有未支付的订单,一般这种订单是很少的,即使建了索引,也没法使用索引。

案例8、复杂查询
select sum(amt) from _t where a = 1 and b in (1, 2, 3) and c > '2020-01-01';select * from _t where a = 1 and b in (1, 2, 3) and c > '2020-01-01' limit 10;

如果是统计某些数据,可能改用数仓进行解决;如果是业务上就有那么复杂的查询,可能就不建议继续走SQL了,而是采用其他的方式进行解决,比如使用ES等进行解决。

案例9、asc和desc混用
select * from _t where a=1 order by b desc, c asc

desc 和asc混用时会导致索引失效

案例10、大数据

对于推送业务的数据存储,可能数据量会很大,如果在方案的选择上,最终选择存储在MySQL上,并且做7天等有效期的保存。那么需要注意,频繁的清理数据,会照成数据碎片,需要联系DBA进行数据碎片处理。

转载于公众号“程序猿”DD


Kafka 2.8.0发布,快来看看有哪些不同!

fanta2 发表了文章 • 0 个评论 • 195 次浏览 • 2021-05-25 15:58 • 来自相关话题

平时关注 Kafka 的小伙伴要注意了,2021年4月19日,Kafka 2.8.0正式发布!这次升级包括了很多重要的改动,其中最引人瞩目的就是kafka通过自我管理的仲裁来替代ZooKeeper,通俗的说,Kafka将不再需要ZooKeeper,正式分手!其... ...查看全部

平时关注 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在关闭期间泄漏内部线程池活动

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


如何使用 Redis 实现一个轻量级的搜索引擎

fanta2 发表了文章 • 0 个评论 • 193 次浏览 • 2021-05-25 15:58 • 来自相关话题

场景大家如果是做后端开发的,想必都实现过列表查询的接口,当然有的查询条件很简单,一条 SQL 就搞定了,但有的查询条件极其复杂,再加上库表中设计的各种不合理,导致查询接口特别难写,然后加班什么的就不用说了(不知各位有没有这种感受呢~)。下面以一个例子开始,这是... ...查看全部

场景

大家如果是做后端开发的,想必都实现过列表查询的接口,当然有的查询条件很简单,一条 SQL 就搞定了,但有的查询条件极其复杂,再加上库表中设计的各种不合理,导致查询接口特别难写,然后加班什么的就不用说了(不知各位有没有这种感受呢~)。

下面以一个例子开始,这是某购物网站的搜索条件,如果让你实现这样的一个搜索接口,你会如何实现?(当然你说借助搜索引擎,像 Elasticsearch 之类的,你完全可以实现。但我这里想说的是,如果要你自己实现呢?)

从上图中可以看出,搜索总共分为6大类,每大类中又分了各个子类。这中间,各大类条件之间是取的交集,各子类中有单选、多选、以及自定义的情况,最终输出符合条件的结果集。

好了,既然需求很明确了,我们就开始来实现。

实现1

率先登场是小A同学,他是写 SQL 方面的“专家”。小A信心满满的说:“不就是一个查询接口吗?看着条件很多,但凭着我丰富的 SQL 经验,这点还是难不倒我的。”

于是乎就写出了下面这段代码(这里以 MYSQL 为例):select … from table_1left join table_2left join table_3left join (select … from table_x where …) tmp_1 …where …order by …limit m,n

代码在测试环境跑了一把,结果好像都匹配上了,于是准备上预发。这一上预发,问题就开始暴露出来。预发为了尽可能的逼真线上环境,所以数据量自然而然要比测试大的多。所以这么一个复杂的 SQL,它的执行效率可想而知。测试同学果断把小A的代码给打了回来。

实现2

总结了小A失败的教训,小B开始对SQL进行了优化,先是通过了explain关键字进行SQL性能分析,对该加索引的地方都加上了索引。同时将一条复杂SQL拆分成了多条SQL,计算结果在程序内存中进行计算。

伪代码如下:$result_1 = query(‘select … from table_1 where …’);$result_2 = query(‘select … from table_2 where …’);$result_3 = query(‘select … from table_3 where …’); …$result = array_intersect($result_1, $result_2, $result_3, …);

这种方案从性能上明显比第一种要好很多,可是在功能验收的时候,产品经理还是觉得查询速度不够快。小B自己也知道,每次查询都会向数据库查询多次,而且有些历史原因,部分条件是做不到单表查询的,所以查询等待的时间是避免不了的。

实现3

小C从上面的方案中看到了优化的空间。他发现小B在思路上是没问题的,将复杂条件拆分,计算各个子维度的结果集,最后将所有的子结果集进行一个汇总合并,得到最终想要的结果。

于是他突发奇想,能否事先将各个子维度的结果集给缓存起来,这要查询的时候直接去取想要的子集,而不用每次去查库计算。

这里小C采用 Redis 来存储缓存数据,用它的主要原因是,它提供了多种数据结构,并且在 Redis 中进行集合的交并集操作是一件很容易的事情。

具体方案,如图所示:

这里每个条件都事先将计算好的结果集ID存入对应的key中,选用的数据结构是集合(Set)。查询操作包括:

  • 子类单选:直接根据条件 key,获取对应结果集;

  • 子类多选:根据多个条件 Key,进行并集操作,获取对应结果集;

  • 最终结果:将获取的所有子类结果集进行交集操作,得到最终结果;

*这其实就是所谓的反向索引。*

这里会发现,漏了一个价格的条件。从需求中可知,价格条件是个区间,并且是无穷举的。所以上述的这种穷举条件的 Key-Value 方式是做不到的。这里我们采用 Redis 的另一种数据结构进行实现,有序集合(Sorted Set):

将所有商品加入 Key 为价格的有序集合中,值为商品ID,每个值对应的分数为商品价格的数值。这样在 Redis 的有序集合中就可以通过ZRANGEBYSCORE命令,根据分数(价格)区间,获取相应结果集。

至此,方案三的优化已全部结束,将数据的查询与计算通过缓存的手段,进行了分离。在每次查找时,只需要简单的查找 Redis 几次就能得出结果。查询速度上符合了验收的要求。

扩展

分页

这里你或许发现了一个严重的功能缺陷,列表查询怎么能没有分页。是的,我们马上来看 Redis 是如何实现分页的。

分页主要涉及排序,这里简单起见,就以创建时间为例。

如图所示:

图中蓝色部分是以创建时间为分值的商品有序集合,蓝色下方的结果集即为条件计算而得的结果,通过ZINTERSTORE命令,赋结果集权重为0,商品时间结果为1,取交集而得的结果集赋予创建时间分值的新有序集合。对新结果集的操作即能得到分页所需的各个数据:

  • 页面总数为:ZCOUNT命令

  • 当前页内容:ZRANGE命令

  • 若以倒序排列:ZREVRANGE命令

数据更新

关于索引数据更新的问题,有两种方式来进行。一种是通过商品数据的修改,来即时触发更新操作,一种是通过定时脚本来进行批量更新。这里要注意的是,关于索引内容的更新,如果暴力的删除 Key,再重新设置 Key。因为 Redis 中两个操作不会是原子性进行的,所以中间可能存在空白间隙,建议采用仅移除集合中失效元素,添加新元素的方式进行。

性能优化

Redis 是内存级操作,所以单次的查询会很快。但是如果我们的实现中会进行多次的 Redis 操作,Redis 的多次连接时间可能是不必要时间消耗。通过使用MULTI命令,开启一个事务,将 Redis 的多次操作放在一个事务中,最后通过EXEC来进行原子性执行(*注意:这里所谓的事务,只是将多个操作在一次连接中执行,如果执行过程中遇到失败,是不会回滚的 *)。

总结

这里只是一个采用 Redis 优化查询搜索的一个简单 Demo,和现有的开源搜索引擎相比,它更轻量,学习成本页相应低些。其次,它的一些思想与开源搜索引擎是类似的,如果再加上词语解析,也可以实现类似全文检索的功能。

转载于公众号“程序猿DD”

4款MySQL Binlog日志处理工具对比

苏道 发表了文章 • 0 个评论 • 214 次浏览 • 2021-05-25 15:58 • 来自相关话题

Canal定位:基于数据库增量日志解析,提供增量数据订阅&消费,目前主要支持了mysql。原理:canal模拟mysql slave的交互协议,伪装自己为mysql slave,向mysql master发送dump协议mysql master收到du... ...查看全部

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进行了针对性的性能优化。出于稳定性、性能及成本的考虑,推荐使用。


86% 的Java开发者依赖它!Spring在Java领域占有统治地位

木土走召 发表了文章 • 0 个评论 • 109 次浏览 • 2021-05-25 15:58 • 来自相关话题

每一个程序猿都有自己的开发习惯,喜欢用哪个工具喜欢用哪种框架,但不可否认的是,自从2003年被发布之后,Spring框架已经是大多数JAVA开发人员的首选!就在去年9月,VMWare发布过一个2020年Spring状态报告,其中的报告内容也恰好印证这一点。报告... ...查看全部

每一个程序猿都有自己的开发习惯,喜欢用哪个工具喜欢用哪种框架,但不可否认的是,自从2003年被发布之后,Spring框架已经是大多数JAVA开发人员的首选!

就在去年9月,VMWare发布过一个2020年Spring状态报告,其中的报告内容也恰好印证这一点。

报告中包含了各种调查,调查对象是随机抽取的全球450名程序猿,美国程序猿占比6成,剩余的是英国程序猿。而男女比例高达8:2,这里小编不尽嘀咕一句,有那么多女程序猿吗。。。

参与调查的程序猿普遍在35-44岁之间,可说都是精英程序猿。这些人都是使用Spring和其他框架的JAVA开发人员。原本计划预计大约60%来自Spring/Spring Boot,40%来自不使用Spring的人,但实际上大多数受访者都是Spring/Spring Boot的用户。450名受访者中,只有25人表示不使用Spring/Spring-Boot,另外38人不使用任何框架。 Spring比例高得惊人。

通过调查,发现Spring/Spring Boot 的开发者,往往比非 Spring 用户更重视单元测试,会比非Spring 用户多花费单元测试时间,达到25%,而非 Spring 用户这一数据只有20%。

同时Spring/Spring Boot 的开发者还倾向于拥有更高的代码质量和更可维护的代码,并在组织中拥有更好的代码覆盖率。(Spring框架的开发者有优秀代码能力的达54%,非Spring框架用户只有44%,无框架用户只有39%;单元测试覆盖率达到100%的都是Spring框架用户;同意单元测试让编写代码变得更简单的,Spring用户、其他框架用户、无框架用户分别是93%、88%、79%)

通过总结,报告对Spring/Spring Boot给出了5个特殊优点:

  • 核心技术(如Spring上下文、依赖注入等)

  • 测试支持

  • 数据存取

  • 与其他技术的集成(例如Hibernate)

  • 更容易设置web界面/API

而在这五个优点中,最受使用者青睐的是 更容易设置web界面/API(23.8%)和 测试支持(21.2%)

并且58%的Spring/Spring Boot用户说,Spring框架为开发人员节省了时间,54%的人认为他们的测试更快了,51%的人经历了更平稳的现代化。最后,49%的人说他们使用Spring/Spring Boot减少了开发者的摩擦,总之,意思就是Spring框架好处多多,谁用谁知道。

除了单元测试,在其他(非单元)测试上,花费时间的占比,Spring框架、其他框架、无框架分别是22.5%、21.8%、19.3%

和去年同期相比,使用Spring/Spring Boot的用户占比从60%提高到了86%,有显著的提升。

Spring使测试更容易的特性也使它更适合于独立开发者,这也有助于解释为什么所有被调查者所询问到Spring测试工具时,都被认为至少有点有用。例如,工具diffbluecover自动为Java代码编写单元测试。它对Spring用户尤其有效,因为Spring的标准化单元测试方式、内置模拟以及隔离被测单元和数据库依赖关系会让一切变得更加方便。

随着测试越来越被证实对开发的重要性,Spring/Spring Boot用户的增长也就只是时间的问题。


刷爆全网:一个中科大差生的8年程序员工作总结(下)

王叫兽 发表了文章 • 0 个评论 • 118 次浏览 • 2021-05-14 15:35 • 来自相关话题

2018 年前面说到,2017 年开始频繁出入医院,同时项目也越来越忙,我渐渐的开始喘不过气起来,最后医生也给了结论,需要做手术,手术有不小的失败的几率。我和妻子商量后一咬牙做吧,如果失败就走地下的路子,但是可能需要准备一笔钱(手术如果成功倒是花销不会太大),... ...查看全部
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 年的职场讲完了,不管过去如何,未来还是要继续努力,希望看到这篇文章觉得有帮助的朋友,可以帮忙点个推荐,这样可能更多的人看到,也许可以避免更多的人犯我犯的错误。

友情链接