技术人生的职场众生相 – 十多年的经验与心得 – 之一 – 协作与交流

系列目录

前言

我是个码农,在职场干了多年,在超过10个公司服务过,遇到过各种怪现状,拍案惊奇葩,不吐不快,太想写篇文章吐槽一下。

这篇文章汇集了我10多年来的工作中遇到的各种经历,总结的心得,分别讨论了团队与协作(同事/领导/客户的交流)、技术与质量(学习、技术选择、质量)、职业与事业(现实、追求、老油条、职业道德、典故、事业/经验)、找工作(猎头/中介、应聘、简历、面试别人)、辞职(原因/理由、信任)等,干货满满的,里面还夹带了我的很多秘密和典故,如果你认真看,会回来找我赞的!!!

如果你非要叫我跑龙套码农,请不要在前面加个死字,谢谢。

我在中国读的大学,工作了7年之后,移民到了澳洲,文中的经历,一部分是中国的,剩下的都是在澳洲遇到的。

下面的文章夹杂了不少英文,那是因为这些文字都是我在澳洲写的,习惯而已,不是你们想象中的所谓装逼,谢谢。

本文是我的个人经历和意见,请取滤网三钱,温水煎,和着服用,谢谢。

协作与交流

入职

不管你在以前多厉害,有多丰富的经验,去到新公司,都要重新学习,撇开业务逻辑,我们还需要学新的编码规范(不管你是否认同)、开发流程与守则、工具等等,更耗时的,是理解他们的开发框架,每个公司都有自己的一套(很多可能重复发明了了轮子)。

心态很重要,没有端正心态,很容易造成失衡。一些人一夜暴富(如中奖),然后大肆挥霍,最后比暴富前更穷困潦倒。入职新公司,可以放低身段,毕竟你掌握的技术是一回事,学习公司各种文化、流程、规范、业务逻辑等等都要花一段时间,不能一蹴而就,否则落差太大,事与愿违,如牛入泥潭,强烈的无力感。

一张厕纸,都有它的作用。每个技术公司都有过人之处,我们要关注的,不是那些不行的地方(有待后续解决),而是寻找那些有营养的干货,学习之,提高自己。20/80法则,20%的公司牛,那就算差的公司里,也有20%的人尤为突出的,要向他们学习,看他们写的高质量代码。

从一个公司角度来看,评估员工的表现,不是看他以前多厉害,经验多丰富,而是看现在为公司的贡献。所以,一些时候出现的情况是:“我自认水平很好,为什么公司给我的回报没有我想象中那么多?”

去到一个新公司,心态要摆好,低头做人,努力学习。或许,有一些同事,觉得你空降过来,不会持有热烈欢迎的态度,所以,做好本分的事情,不需要奉承别人,也更加不要得罪别人,平常心看待。

每去到一家公司,我会尝试笑着面对每个遇到的人,甚至说一声Hi,如果对方没兴趣,那没关系,我不会因此脸黑或者不爽。笑着面对各种问题,自己写的烂代码,含着泪也得把它重构好。

同事/领导/职场

林子大了,什么鸟都有,公司大了,什么人都有。有人的地方就有江湖,有利益的地方,就有冲突。

澳洲,跟美国一样,是移民国家,一般每家公司都有各色人种。文化的差异,语言的沟通,总会造成各种矛盾。

根据这些年来的观察,冲突一般有:1、邀功,当你辛苦干完活,别人把功劳拿走了;2、推卸责任,不是你造成的问题,别人强加于你身上;3、小圈子排挤外人。

说到底,工作就只是一份养家糊口的事情,其它都是不重要的,把这个想通了,一切都好办了。把心态摆正,把事情做好了,就行了,很多事情无法控制,当然,我们要懂得不要给别人留有藉口揪你小辫子。

每个公司都有各种问题,进新公司之前,大家习惯设想新公司怎么怎么好,自己的计划如何顺利开展,现实,往往不是如你所愿。所以,要做好最好的准备,最坏的打算。

办公室不是找朋友的地方,必须时刻提防各种办公室政治,披着羊皮的狼,是最危险的,越天真越容易中招,不大有人会踢一只死狗,枪打出头鸟,你越出色,越容易招惹是非,要混得开,低头做人很重要。

对美女来说,“天生丽质难自弃”,想突出自己把自己的优势最大化。职场,大部分人都想出人头地,努力往上爬,加薪升职。然而,事与愿违,总有“老子干得很不爽,去你大爷的!”的时候,如果你真有心有力,确实是可以去创业,不需要受各种非人的委屈。

一言蔽之,要干得爽,还是需要自己创业。

公司S,心累,现在公司部门和部门之间有严重的斗争,各自为政,根本就不是想干活的,恶心的事情很多,譬如部门老大不干活,让小弟干,小弟工作繁忙压力大就爆脾气,说话不像人样,然后部门老大就各种推卸责任,还美化之,去它大爷的 。

公司B,三个印度码农在印度,一个大胡子孟加拉国的,一个刚来澳洲两天的伊朗人,一个来了澳洲很多年但口音极重的越南人,一个还在马来西亚下个月才来报道的码农,加上来自黎巴嫩的上司,还有我,真的是联合国。

公司K,精神分裂的部门女同事,菲律宾大妈,在公司呆了18年,在CTO背后联合她的两个马来西亚小弟直接跟CTO的上司说CTO各种坏话,在CTO面前老装很友好地狂笑,对待客户是一样的做法。

公司T,当年很纯真,但已经目睹了各种利益纠纷。公司和别的公司协作做的GSP系统,一个医药销售系统,产品做得差不多了,各种纠纷,后来产品就烂尾了。

公司T,我离职,老板请大家吃酱板鸭,味道特别棒,至今难忘,离职后还和老板保持了多年的联系,每年春节还发祝贺短信,很精短,都是手写的。

工欲善其事,必先利其器。开发工具,是开发中重要的资源,公司不应该在这块上有任何吝啬。

公司S,我入职后发现开发部的机器,最老的7年了,新的也有3年老了,没改一行代码,重新编译,需要5分钟以上。跟我一起入职的有4个新同事,公司给我买的电脑是给其它同事买的3倍价钱,IT部经理一脸正经地跟我说:你丫的应该觉得庆幸拿到这么贵的电脑。但我一脸无奈地跟他说:“虽然你买的是我要求的ThinkPad,我我希望是t4xx,你却买了exxx,我才不想要呢!”。新来的项目经理对公司安排给他的新手提电脑很不满意,一大早打开的时候就已经用力噼噼啪啪了,还吐槽连HDMI接口都没有什么的,下班快走的时候还吐槽这i3 CPU配置都8年老的了。首先,讲道理,每次i3换代都有新版本,不能刻舟求剑,但是,省这几百块不值得。

客户

客户是不讲理的上帝。

你的代码写得那么烂,你的客户知道么?

公司S,做IT的同事告诉我几个真实的故事,忒搞笑了,其中一个是:客户说电脑不正常,同事远程协助,很客户说:“close all the windows”,然后客户说“done”,同事说我这里看见还没有关闭啊,客户坚持已经关闭。争论半天,最后发现客户关闭了的不是“窗口”,是“窗户”。

公司S,有一个潜在客户发来合同,要求我们的系统一年365日,100%在线,如果服务down了,按分钟赔钱[允悲]。

客户的需求,没有明确目标的居多,需要逐步引导,按优先度和难度分期实现,否则很容易烂尾。

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

软件的测试与发布

前言

看见有同学讨论公司产品开发过程中的单元测试、集成测试、代码审查、签入、发布等问题,我来说说我以前服务过的公司的做法。

最差的情况是,没有测试、审查,直接签入、发布,所以系统不稳定。

最好的情况,我详细说说。

编码规范

某个我服务过的公司,把代码规范做到近乎极致:严格使用FxCop:多一个空格、空行、private关键字都不允许,条件判断后一行代码必须{}等等、等等,自己实现一套更严格的代码检测:所有字符串必须支持多语言除非写例外禁止、代码全局全文拼写错误检测,等等等等。

另外,namespace必须顺序而且System必须前面,static readonly顺序不能掉转,全局变量不允许_,引用dll不允许copy local,不允许“”只能String.Empty,所有警告视为错误,必须打开overflow check,参试列表要么同一行要么全部分列。

一般新人来会被这些要求逼疯。

代码维护

该系统比较大,2200万行代码,几千个项目,所以自己搞了一套系统,整合了TFS,自动做各种shelf/取所有项目最新版本等事情,自动判断某个项目已经最近被编译,如果是就从缓存取出来无需再编译。

单元测试/整合测试 (Unit Testing/Integration Testing)

该系统有60多万个单元/整合测试,每个项目,不管什么类型的程序(Web页面/console/windows 服务/窗体界面),不过什么什么业务,都带有测试,而且这个测试还有大量的各种严格、智能的玩法,譬如实现类要测,基类都自动测;又譬如数据库相关的测试,强制打开事务/snapshot,完成测试自动回滚,然后判断是否有差异就报错。

签入(Shelf/Check-in)

这套系统禁止手工签入(check-in),这个禁止是系统根本不允许开发人员签入,任何开发人员必须通过shelf把代码提交到下面的自动化分布式编译/测试系统。这个好处是避免了任何人都可以随意把代码搞爆。

自动化分布式编译/测试(CI)

因为测试数量巨大,自己搞了一套分布式编译/测试系统。因为开发人员的机器配置相当高,譬如i9+1TB SSD,所以充分利用了几百台的开发人员机器,都给安装上了2个Hyper-V实例,在里面做CI。

大家可能没理解好,觉得市面上的Team City等都能分布式编译/测试,但是他们这种一般是一个提交只能在一个worker上编译和跑所有测试。但这套东西能把任意测试根据最优解自由组合,然后分布式到几百台*2个Hyper-V里面去做编译CI。譬如60万个测试里面,某几千个,是在机器001跑。

还有,这个测试不会盲目地跑所有60多万个测试,会自动判断代码的改变会影响到那些测试,才去跑相关的测试。

而且最关键的是,这套系统能最优解合并最近大家提交的shelf,然后再去做CI,都成功的话大家都pass,如果失败,再拆开单独跑失败的测试,这样就能节省大量时间。

代码审查(Review)和可用性测试

当上述的自动化分布式编译/测试通过之后,代码审阅者对代码分析、实际跑过之后,才标识该shelf通过,然后开发人员才能交给自动化分布式编译系统去签入代码。

 

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

批量数据导入的性能与完整性问题

刚才有网友问了一个技术问题:

我从其他接口 采集一批数据,每次上万条左右,然后存到数据库,存库前还要每条每条的判断数据库存不存在这条数据,不存在才能写库,有没有性能好的实现思路啊?

这是典型的批量数据导入的问题,一般追求是速度。

8年前来澳洲后第一份工作是一个做智能表(水电煤等)的公司,软硬件结合,软件系统采集数十万的智能表的数据,系统里一些表,单个超过30亿条记录,每天更新上千万条记录,为了这个专门实现了一个高度优化的批量导入功能。

现在拿微软SQL Server做例子,说说思路。

首先,要实现速度,会考虑批量导入(Bulk Copy),但一般来源数据格式和目标表达格式不一样(譬如字段数量、类型等),甚至需要做一些计算,甚至要从关联表取数据,所以一般先会导入到临时表,然后再插入目标表。

使用Bulk Copy有一个问题,是它不确保插入数据的顺序,所以如果你必须要求数据插入完全按照来源数据的要求,你必须确保Bulk Copy之前主键字段的值是按顺序的,因为簇集索引是物理顺序,所以会默认按这个排序。

插入目标表需要考虑2个问题:

  1. 唯一性:主键可能会重复,一般采用修改主键索引忽略重复记录,但是这个做法可能会忽略掉后面比较新的数据。
  2. 完整性:如果这个批量导入逻辑可以是多线程/多进程跑的话,那么需要额外的逻辑去处理不会重复操作。

插入数据要确保唯一性又要考虑最新数据会被导入,一般做法是判断目标表是否存在数据,如果不存在则插入,如果存在则更新,这个操作是有重复处理浪费时间,所以可以用SQL Server的MERGE语句,把插入和更新合二为一。

有朋友问:“那是否有更快的办法?”。是有的,那就是支持多线程/多进程。思路如下:

  1. 客户端调用BulkCopy,获得起始、结束Id
  2. 完成调用服务器的存储过程处理这批数据

这样做可以支持并发问题,提高性能。

如何成为爆栈成员:

  • 加我微信 unruledboy ,进入技术群

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。