找回密码
 立即注册
查看: 202|回复: 5

腾讯以及各大厂的 C++ 开发环境是什么样的?

[复制链接]
发表于 2023-3-12 16:10 | 显示全部楼层 |阅读模式
看网上各种 editor、IDE 以及各种工具的比较和撕逼,就 Linux C/C++ 开发来讲,想看看一线互联网公司更偏爱哪种?
发表于 2023-3-12 16:13 | 显示全部楼层
在腾讯待过,现在在字节做存储,放心没敬业。混得不好,就不丢人了。
字节:
标配 mbp,可选windows电脑
g++7.0 + git + cmake这是基本的,其余的随意,jetbrains的license字节买了。公司也配置开发机,和腾讯配置差不多8cpu + 16G内存 +512G 硬盘,但是开发Cpp的部门可以额外申请一台32cpu+64G内存 512G硬盘的大规格机器。对于架构部门来说没有测试环境,
选项一,线上机器(64核心+400G内存+20TB硬盘) + VIM 开发
选项二: vscode server + 开发机
选项三: vscode 本地化
选项四: clion + 开发机(设置修改自动上传)
因为组成立的时候,成员来自阿里百度,对基础代码的要求比较高,基本上都是toft+chrome+leveldb+folly库,brpc为网络库,当然toft太老的, @chen3feng 陈老师在腾讯太忙了也没时间改,我们对其进行C++11修改。
存储这边,一个脚本就可以启动单机运行环境,因此调试和测试都在单机完成。
这边代码一个cmake搞定,windows下mingw+Clion可以一键跳转,设置clion自动上传,改一点代码写一点单测,编译后运行。问题就是代码太太太太多了,好几个submodule + 很多基础库一个CMakeLists.txt包含,16G的legion i7+512GSSD还是卡。mpb一直在吃灰(当然,我是鹅厂来的习惯了clion)。
虽然人力少,但是代码流程要求很好。合入master分支需要进行以下检查:

  • cpplint,按照Google 代码规范进行,不过则失败
  • 单元测试
  • smoke测试
  • 单机测试
2-4都是在+ valgrind 环境中进行的。因此在我们组 起码 内存泄漏从来没有。
缺点:
C++在字节是小众,由于我们在架构,除了错误上报外不需要依赖任何外部模块,很多东西只能从github上自己整理,比如闭包代码用的是 @覃左言 老师写的。字节C++没有wxg的人力,肯出人维护summer框架,基本上所有的组件重写了一边 。
字节搞C++ 优点也是很明显:
不需要用公司的轮子,处理上报模块,服务发现用zk,不用consul,不需要ELK,用Ceph存储备份数据,有物理机可以使用(主要是为了避免循环依赖)
腾讯:
todo
发表于 2023-3-12 16:15 | 显示全部楼层
说下我目前的一些环境搭配吧:
代码编辑器

我用的是clion(公司买的正版)。只不过是把clion当编辑器用,不用来编译和调试。因为它的错误提示比vscode要好很多。
我一般是把公共库的头文件拉到本地,自己随便写个CMakelists.txt, 里面include下公共库路径。mac下开发相对方便些,windows下用的wsl,clion也支持的很好。
很多同事也会使用vim和vscode remote development。其实编辑器是个很次要的东西,只要把智能提示配好,用什么都无所谓,顺手就行。
(不过稍微大点的项目,对于clion默认的2G的jvm堆内存来说,就直接卡成翔。改下clion的内存大小,基本到4G就丝滑版顺畅了。)
编译

wxg的C++编译体验做的非常好,提供了云端编译。代码写完敲个命令就可以把代码的diff传到编译平台进行编译。
有两点好处:
1. 不需要自己本地有c++的编译环境
2. 云端编译采用了分布式编译,编译速度快
整套过程行云流水,还不耗本地资源
云开发机

公司给每个开发配了一台云开发机,8核16G基本够自己折腾了。用vscode remote development的同事基本可以都是把环境远程连到自己的云开发机。

总体来说,在微信写C++相比来说还是比较幸福的,公共库和研发效率都有专人负责维护和提升,自己做的事情也更聚焦了
发表于 2023-3-12 16:24 | 显示全部楼层
简单介绍下腾讯微信事业群后台开发环境。
微信事业群比较特殊,喜欢自己搞一套东西自己用,有些基础设施跟腾讯其他事业群的不太一样。
硬件:

现在通常是macbook pro + 远程Linux主机。远程主机方面当前已经舍弃了以前集体户式的开发机,每人拥有一台相对独立的云主机,我的配置是8核Xeon Gold + 16GB + 500GB,考虑到这台机绝大多数时间只是跑个编辑器,性能还是挺富余的。
软件:

代码编辑:老员工通常是vim,基本没见过emacs。新员工很多开始用vs code了。我身边绝大部分人是用vim的,大家有时会互相分享一些自己使用的插件,但是每个人的配置都大不一样。编辑器是网上程序员撕逼大战的主战场之一,但是现实中同事之间倒也没有因为编辑器争执过,大家还是很文明的,新人刚来的时候我们这些老vim用户也会安利他们学一下vim,但人家最终选择了vs code我们也没说啥不是。
版本控制:目前基本都迁移到git了,以前是用svn。vim党基本都是直接用git命令,有些vs code的用户会在mac上用图形化的前端。
编译系统:现在是基于bazel搞的一套东西,开发阶段编译代码时使用一条指令将本地代码diff发送到编译机来编译,这样可以共享很多中间文件,速度蛮快的。以前是在本地开发机编译,有些比较大的模块编一次几十分钟,而且编译吃掉太多cpu还会导致vim卡顿……
工具链:用的是GCC那一套,由于后台服务都是微服务,每个小模块都可选使用gcc4或者gcc7构建,最近我写了个小模块用了c++17,就是用gcc7编译上线的。希望哪天可以支持clang,我比较喜欢clang的编译报错信息……
微信后台开发的一天(理想情况Orz):


  • 掀开mac
  • 打开outlook把收件箱的红点全点掉
  • 切到item2,这时mosh已经自动重连到了开发机,tmux的一堆窗口已经在等着你了
  • vim...patchbuild...vim...patchbuild...git
  • 期间夹杂吃饭、午休、散步、带薪拉屎
  • mac切到chrome,打开微信变更系统,提单、编译、同步到测试机、灰度上线一气呵成
  • 盖上mac,下班回家
  • //享受夜生活
其他一些碎碎念:

微信的后台开发环境一直有很多槽点,但也一直在改进,每年都能看到一些进步。现在还没解决的比较影响开发效率的应该就是代码的语义分析工具了。目前大家写代码的环境都是没有精确的跳转和补齐能力的,考虑到大家的环境很不统一,估计也没什么动力统一去搞。由于微信的后台代码量非常非常大,如果暴力把所有代码都加到一个工程里,ycm之类的东西根本跑不动,按一下tab卡5分钟还不一定能缓过来(gdb的时候也是不怎么敢按tab的)。后台C++项目都是基于bazel的BUILD文件管理依赖,总体上来说比较粗放,基本上每个新人刚来的时候都会折腾一下这个东西,试图搞定基于BUILD的补全方案,但最后性能和准确性上很难满足日常使用的需求。目前我的解决方案是用universal-ctags定期给常用目录下的文件生成tags,写代码的时候凭经验去跳。
在微信写业务非常傻瓜化,微信的微服务框架svrkit准备了一堆配套工具来生成代码,新起一个服务就是写一个protobuf文件,里面定义好接口,然后用这个文件生成整个服务的框架代码,再把业务逻辑填进去就好了。微信的C++基础库里面大到消息队列,小到string的trim都有提供,写普通的业务代码需要什么功能基本都可以找到,完全就是堆积木,对普通的业务部门来说,面试造火箭入职拧螺丝一点都不夸张。
微信的开发最讨厌的事情有两个:一个是别人写的代码没有注释,另一个是自己写代码还要写注释。这造成了很多工具、功能、逻辑的细节都是口口相传,或者沉没在浩如烟海的km文章、邮件里。没事去看看别人的代码总会有惊喜……有时是惊吓。当然这一点最近也在慢慢改变,基础能力相关的组件开始开辟一些wiki、git issue之类的进行系统的介绍了。
发表于 2023-3-12 16:28 | 显示全部楼层
如果说腾讯的话,老项目svn,新项目很多都是git了,通讯环境的话用微信企业版比较多,而项目相关的工作内容有很多会基于网页。开发环境最需要统一的就是版本管理,其它倒是比较自由。
由于C++在腾讯最主要的用途是服务器后端,因此实际上你可以使用任意的编辑器,大厂员工很务实,是很少就这个问题撕逼的。
远古时代(大约十五年前)很多人用SourceInsight3.5,因为它有完美破解版。但是它的致命问题有两个:第一是只支持C语言,C++支持比较糟糕,第二是只支持GBK不支持UTF-8,这个问题在现在来说很致命,都2020年了你几乎不会还允许程序员用GBK写代码,虽然2005年用GBK写代码还挺常见。
SourceInsight4.0改进了这两个支持,能够有限程度支持UTF-8,并且C++支持比前作排版强了半分钱,但售价是天价(四位数以上)。鉴于大厂一般不允许本机装盗版,SI4.0的价格又几乎不可能购买,所以现实中除了可以申请购买SI4的公司,其它公司已经极少有人用它。
自己折腾党有用Vim跟Emacs的很多,当然也有直接用其它IDE的,比如VS,比如Eclipse(嗯,这货确实也可以写C++),比如JB,比如。。。各种选择都可以,服务器后端C++程序员们真的不会对IDE问题过于纠结,自己习惯用哪个就是哪个。
就现在而言,Eclipse原作者的新作品:Visual Studio Code 逐渐成为程序员新宠,它有技术跟历史的必然。虽然它目前还有不少问题,但已经越来越多的人开始使用它。
纠结IDE的项目大都缺乏自己的构建系统,而对于互联网项目来说,CI/CD 机制已经很流行,这意味着C++项目是必须自动构建的,能 CI/CD 也就意味着必须有可以被命令行批处理的构建,进而就脱离了任何指定的IDE。
--
所以你要说开发环境是什么?
那就是:统一的SCM管理,基于Web的问题跟踪及缺陷管理,客户端的项目组成员间通讯,后台服务CI/CD。——至于IDE,可以说并不是开发环境的一部分,只是程序员的个人爱好选择而已。
发表于 2023-3-12 16:38 | 显示全部楼层
先后在TB待过,都是主要做C++的开发。这里谈一下两个公司的C++开发环境。
首先声明,谈到开发环境,不仅包含IDE,还有其他很多很多的工具。
另外就是不管是哪个公司对于如何开发都没有太大限制,在保证不泄露代码的安全前提下,选择自己喜欢的开发方式就好。但是肯定每个公司的前辈程序员们还是有一定的选择偏好的,所以后来的程序员也慢慢被同化。
腾讯

由于之前很多很多年腾讯的办公电脑都是Windows(18年开始才有MacBook的选项),入职时可以申请一个台式机和笔记本。都是Windows。开发机是Linux,需要ssh登录。
IDE(开发+阅读)

所以C++的程序员长期都是在Windows下办公,腾讯使用最多的IDE就是SourceInsight。


SourceInsight开发效率其实并不高,但是作为阅读源码而言,真的是神器。甚至有老一辈的同事给SourceInsight用hook的方式做了一个牛逼的插件,支持了更多的功能,使得代码阅读的效率更上一层楼。外面也有其他人做过类似的插件,但感觉还是有一点点差距。



图片来源网络,仅作示例

同步

当时比较常见的开发方式就是在Windows上用SourceInsight进行开发。然后同步到Linux开发机上。同步方式多种多样,有用samba挂载Linux开发的目录到Window上变成虚拟目录的,我比较习惯的是WinSCP,可以实现自动同步。当时开发网的Windows电脑和Linux开发机,可以用户名密码登录,无需用token(只有生成环境的Linux登录需要token),所以可以直接让WinSCP之类的工具记住密码。
版本控制

相当长的时间,腾讯都是使用SVN做版本控制的,Windows上下载那个乌龟SVN,有图形化的方式进行各种操作。


当时公司内部也有git,但是用的不多,后来好像有在推,不知道现在情况如何。
代码的对比和合并使用BeyondCompare比较多。通常就是用BeyondCompare打开两个窗口,每个窗口打开一个版本,然后比较找出红色的文件,再逐行进行合并或修改。





图片来源网络,仅作示例

C++版本

腾讯各个BG几乎各自为战,不管是框架还是工具都没有统一标准。对于C++的版本有的部门升级到了g++编译器,支持了C++11。但也有很多部门还使用的C++98/03。美其名曰:稳定安全。
编译与包管理

编译还是手写Makefile的方式,当然有一些通用的Makefile模板,倒也不需要太花时间。对于包管理由于C++没有Maven、npm、pip那种开源方案,在腾讯内部也还是没有高级的方式,只能保证开发机上安装的公共库(自建、第三方库)和远程编译机以及生产环境上完全一致。这样Makefile写的各种连接目录才生效。不知道现在有没有好的方式了。
百度

后来来了百度,大家都是用MacBook,也就没有了SourceInsight。开发方式就是用iTerm直接SSH登录Linux开发机进行开发。并且百度技术话语权比较强,svn迁移git,C++版本升级都会从公司层面强推。
开发:vim + tmux

主流的开发方式,就是登录Linux开发机用Vim进行开发,配置一些常用的插件即可,也不用特别复杂,打造出IDE那种也没必要。因为写代码时间长了就会发现,真正写代码的时间其实并不多,主要时间是花在思考上,另外动手开始写的时候,也存在大量的拷贝粘贴,所以使用Vim写大型项目的代码,没有那么难,也不会那么不方便。感觉不方便主要是自己的心理障碍,时间长了就会发现并不是事。当然开发Java就不推荐Vim了。
除了vim之外,还有一个不得不提的神器:tmux。tmux不是写代码的工具,它主要是能做到”工作现场的保存和复原“。它可以打开多个窗口,并长期保持会话。比如我们登录开发机,会进入各个目录,一遍vim写代码,一个窗口空余处理编译,可能还需要其他窗口看下top,或者写点小脚本啥的。tmux完全就能做到这些。
说到这里你可能还没感觉,iTerm也可以打开多个tab啊。关键问题是,tmux是远程的,而且支持多个会话,每个会话中可以打开N个窗口。举个例子:我在公司上班的时候用公司的电脑,登录开发机,进入一个tmux会话进行开发。晚上下班了,我回到家,还想再写一会,用自己的电脑登录进去,可以直接打开之前的tmux会话。里面打开的vim,cd目录通通保留。所以做到了”工作现场的复原“。 第二天我来到公司,公司电脑iTerm的ssh已经退出了,重新ssh进去,继续打开tmux会话,继续昨晚的工作:Perfect!其实这个复原的不止是软件、目录、打开的文件等等,更重要的是复原了自己的思路!如果你有多个项目的话,使用多个会话,那么你每次重新进入哪个会话都能找回当时的思路!



图片来源网络,仅作示例

源码阅读

前文说了,百度主要是Mackbook,我自己笔记本也是MacBook,而源码阅读神器SourceInsight并没有Mac版本。后来我在MacBook上找过各种替代,也给VSCode配插件,但还是达不到SourceInsight的那种丝滑。给MacBook装过Windows虚拟机只为了使用这一个软件,但是卡的不行,只能作罢。后来甚至萌生再买个Windows笔记本专门用来看代码的冲动,最终因为经济原因取消原计划。
公司的老前辈们,喜欢继续用Vim来阅读各种代码,但是我实在不想再配置Vim了,感觉那样边际效益其实并不高了。最后还是采用MacBook上用VSCode阅读代码的方式。效果也还凑合。
版本控制

百度已经全部迁移到git。所以开发过程中,就是各种git命令的使用了,确实比自己玩github的时候对git的理解加深了。由于使用git也就不需要额外的代码对比和合入工具了。git pull --rebase 冲突的时候,vim进去手工解决冲突。然后git add -u,git rebase --continue。


C++版本

只要确认gcc某新版本稳定之后,经常强推到新版本。有时候也挺烦的,可能需要修改依赖库的版本,不多说了。
编译和包管理

公司内部自研了一个给C++用的包管理工具bcloud,不仅支持本地,也支持集群编译。配置方式采用python脚本,语法类似bazel或腾讯开源的blade。这个还不错。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Unity开发者联盟 ( 粤ICP备20003399号 )

GMT+8, 2024-5-6 20:15 , Processed in 0.185181 second(s), 26 queries .

Powered by Discuz! X3.5 Licensed

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表