Skip to content

Latest commit

 

History

History
65 lines (34 loc) · 13.1 KB

我的2019.md

File metadata and controls

65 lines (34 loc) · 13.1 KB

我的 2019

2019 年就这么悄无声息的过去了,我并不是一个喜欢缅怀过去的人,很多人喜欢回忆过去经历的困难,但就我倒是认为如果过去的苦难不能对将来生活质量或者人生经验有帮助,那这些苦难其实相当于白挨了。

从学生时代开始,每年在年末时都会总结一下过去的一年,给自己复盘,总结一下过去一年的得失。成年人的生活没有谁是容易的,而成年人的工作和交往大多数都是逐利的,只是有些是直接的,有些是间接的。当然,这也无可厚非,大家的目的虽然功利却也高尚,都希望给自己和家人或者爱的人提供更好的生活质量。

工作

先来说说我的工作吧。我是一名地地道道的程序员。我于 2018 年 12 月底从携程旅行网离职,应朋友邀请一起合伙创业,投资人是一知名大佬,创业的项目是基于区块链的期货交易系统,项目从 2018 年年底开始启动,从零开始开发,于 2019 年 8 月份正式全球上线,8 月后开始优化和重构部分框架。

整个交易系统分为场上系统和场下系统,场上系统是交易系统的核心系统,一共有多个服务,从功能上有下单服务、清算服务、撮合服务、条件单服务、K 线服务和行情推送服务,场下系统为交易非核心系统,包括指数服务、管理系统等。使用的开发语言是 Java 和 C++,行情服务使用的是 C++,其他所有服务使用的是 Java,另外我们的客户端有 Web 端和手机端(安卓和 ios)。服务与服务之间使用 Kafka 作为消息中间件,数据存储和查询使用 mysql 和 ElasticSearch。交易核心系统开发要求比较高,无论是对性能还是代码的质量的要求比较高,交易系统非核心部分,例如管理系统,由于只是给内部运营团队使用,要求不高做的相对来说粗糙一些,其技术原理也比较简单(各种对数据库进行增删改查的 RESTFUL 接口),但由于功能比较多,工作量也比较大。除了这些技术栈外,还用到了 zookeeper、consul、Prometheus 等。

互联网时代市场动态和风口转瞬即逝,因此我们需要尽快把产品做出来。从立项之初,我们自己公司技术人员加上我一共有 3 位,另外一位是邀请我的朋友,还有一位是我从携程"忽悠”过来的一位玩的比较好的同事。为了加快开发进度,加上起初我们对部分业务不是很熟悉或者经验不足,我们花了大约四百万在上海找了一个专门做交易系统的外包团队,外包团队负责主要开发,我们负责 review 代码和把控整体开发进度。原来外包团队承诺我们的是,项目可以在五月份完成,但是由于外包团队本身的质量问题导致后来我们不得不强力干预,甚至完全自己接手。由于外包团队中开发人员的素养问题以及外包团队的 leader 的管理和待遇问题,导致我们直到五月初还看不到一个可以走通基本流程的产品。于是后来我们的策略做了调整,与外包团队所在的公司进行了沟通,吸纳了外包团队中部分还不错的开发人员,对于无法达到我们要求的开发人员停止合作,最终我接手了条件单、撮合服务、K 线服务、行情推送服务等 4 个核心服务的开发,其中行情推送服务使用的是 C++,目前的人员配置中了,只有我同时拥有 C++ 和 Java 技术栈,因此只能我来接手行情推送服务。

其实从我们与外包团队的合作的刚开始的两个月后,我们就觉得行情服务外包团队在预定的工期内无法完成,因此在那个时候我就被安排开始接手这个服务的开发,起初他们给我的一套程序是他们根据之前做过的一个股票服务的行情代码精简来的一个空架子,加上他们的代码有大量我们不需要的无用功能,加上其通信协议与我们的业务并不完全契合,在我花了一周时间熟悉后,我一边在原来的老的上面开发,另外有自己重新设计了一套,经过大家的试用后完全采用了我新的设计。由于 C++ 是我的技术专长,在行情服务基本开发完毕后,八月份上线后到目前没有出现任何问题,所以基本未做过任何的修改。这样为我腾出大量的时间去集中精力去开发和优化条件单、撮合和 K 线服务。

先来说撮合服务吧。在大多数交易系统中,撮合服务是非常核心的一轮。所谓撮合,即根据一定的交易规则(常见的规则是时间优先、价格优先),将用户的报单进行成交,产生成交等相关信息,如果不能成交,则成为市场上的挂单。最初负责这个服务的外包同事,哎,但是由于其工作态度和代码素养问题,写出来的代码真的是"惨不忍睹"。我们与外包团队约定的要求是,撮合服务必须至少达到每秒可以处理 3000 ~ 5000 笔报单的性能。但是其交付后我们测试发现,每秒三百到五百的速度都达不到。但是这个事情的结果在我们整个公司,包括 CEO 都引起来非常大的恐慌。项目上线在即,如果按这个速度,我们的系统注定是个失败的产品。于是后来,CEO 给外包团队的领导施压,强行把这么同事给"撵走"了,并由我来接手,当然压力也落在我的身上,我记得我最初接手的那几周内,CEO 每天跑我工位上来问我撮合现在最新的进展怎样,有时候一天可能会跑两次。我在阅读其撮合代码的过程中,发现这个代码的质量非常差。当然造成撮合效率如此之低有两个主要原因:一是他使用的一个链表去存储所有用户的报单,这样的话,改单或者撤单,寻找某个订单时需要遍历这个链表,当订单数量多的时候,这个过程会很慢。哎,数据结构和算法不用心学的开发人员,真是贻害无穷啊。二是他往 Kafka 中写数据时使用了 Future 接口的 get 方法,熟悉 Java 的同学可能知道,这个是需要等待的,也就是说每往 Kafka 发一次数据都要等待结果返回。这种同步的做法,让整个撮合系统对报单的吞吐量变得很低。于是,在全公司上下尤其是 CEO 的"密切"注视下,我花了大概三个月时间基本重写了撮合服务的所有业务逻辑,而这个外包同事已经做这个做了半年了。

剩下的是条件单服务,所谓条件单就是用户发起的、根据一定规则(例如某个价格指数达到一定值时)才会产生的报单。这个服务也是上文中开发撮合服务的外包同事做的,条件单和撮合服务存在同样的问题,我也重写了全部的业务逻辑,但是由于时间来不及,18 年 8 月份我们上线时由于还没重构完成,我们第一次没有上线这个功能,第一次上线后的一周后我们上线了这个功能。

剩下的就是不太重要的 K 线服务了,K 线服务本身业务并不复杂,但是数据量非常大,原来是外包团队的另外一位同事开发的。原来我们的注意力并没有在这个上面有特别多的关注,主要是其比较简单。但是某天公司的产品同事,在群里发了几张关于我们生产环境的 K 线服务的图,结果某些大周期的 K 线数据竟然和小周期的 K 线数据竟然对不上,我当时真的是无语了。于是我又被安排维护 K 线服务,K 线服务的代码质量其实还是不错的,只不过一些核心的算法竟然不对,例如计算从某天到某天之间有多少小时,这都能算错,而且如果自己稍微验证一下就很容易发现问题。

上面说的四个服务,除了行情推送服务由于早期就使用我开发的版本因此对我来说,很轻松,大家也很放心,但是撮合、条件单和 K 线这三个服务让我承受了很大的压力。我没预料到的是,一个外包团队的某些开发人员开发水平能不靠谱到如此程度,而且还是工作多年的程序员。好在一切都过来了,项目也成功上线了。后来,我们陆续招聘了前端开发人员、测试团队、补齐了自己的产品团队和运营团队,后来我们又招了客服团队。

由于项目任务比较多,我们采用的是 996 模式,但是在 2018 年上半年,我基本上在晚上 12 点之前是没回去过的。当然,我并不认为工作时间与实际的产出会成正比,在团队扩大的过程中也暴露了很多的问题,有我自己的,也有 CEO 和团队其他一些负责人的。有的时候,我其实挺想和 CEO 说让大家每周多休息一天,但是看到当前的现状,我最终还是没开口。

陶渊明说:种豆南山下,草盛豆苗稀;晨兴理荒秽,带月荷锄归;道狭草木长,夕露沾我衣;衣沾不足惜,但使愿无违。有的时候一些事情并不是我个人能力而能改变的,希望我们或者他们可以成功吧。

陈述事情如果不能进行一次总结,那其实也没有意义的。让我们来复盘一下这一段的工作经历吧。应该很多人都有一个创业的梦想,这一年多的折腾我想说的是:

  1. 创业的话一定要找靠谱的人,所有的 CEO 都会画饼,当你以为他很慎重的对待你的时候,他此时此刻和你说过的话,也许已经和其他人说过了。
  2. 创业团队的成员一定要有共同的信念和理想,如果最初的团队,大家都各自想着自己的利益,那么最终项目一定是做不好的;
  3. 创业团队的 leader 或者前辈一定要虚心接受他人意见,而不是根据自己所谓丰富的行业经验压制其他人的建议。
  4. 如果你的朋友在创业团队中没有很大的话语权,慎重接受他拉你去创业的邀请。
  5. 同样的道理,如果你的朋友在创业团队中没有很大的话语权,你如果接受和他一起创业,但是请慎重再邀请你其他的朋友或者同事去创业。

知识付费和自媒体

除了忙碌的工作以外,我在我那少的可怜的闲暇时间还维护着公众号和写了几个付费课程。

先来说公众号吧,我从 2018 年 3 月份开始做公众号,我做公众号比较佛系,很少去通过一些专门的运营手段来运营。因此做了快两年了,目前粉丝只有三万四千左右。好在写的一些原创文章由于质量比较高,加上用心维护的 QQ 群氛围比较好,平均阅读量也有 1500+ 左右。当然,相比较 2018 年,2019 年写的原创文章就比较少了,同时也接了一些广告。广告是公众号的目前的主要收入来源,只有公众号作者有收入了,才会有更多的动力去给读者写更多的优质文章,做更多的优质分享。所以希望我的读者,如果你不想看我公众号发广告,可以不看,实在不喜欢就取关,实在没必要在后台喷。2020 年争取给大家创作更多的优质技术文章。

另外,就是在 GitChat 上写作了两个付费课程,一个是关于 GDB 调试的,另外一个是关于多线程编程的。由于 GitChat 的方式,我个人觉得付出的时间成本和收入其实是不太匹配的。

另外,就是运营我的知识星球——小方说服务器开发,由于个人精力有限,为了更好的为每一位球友服务,我的星球定价偏高,325一年,这样可以过滤掉一部分叶公好龙的人;当然如果真正愿意想学东西的,这个价格并不高。

最后就是从年初到现在一直在写作一本关于高性能服务器开发方面的图书,我的写作特点是人云亦云的东西我不写,我诚惶诚恐的使用"著"一词,书的内容是我几年做 C++ 服务器方面的经验总结,当然这本书可能并不适合初级读者,可能做了几年 C++ 服务器开发后,遇到了一些问题,可能通过此书与我产生共鸣,到目前为止,我统计了一下,大概写了有 120 万字了。

生活

我上次在公司和另外一位同事说,你要兼顾生活和工作,他回敬我:现在这种工作强度,我有鸡毛的生活。我竟然无法反驳,确实,今年大半年无论是平常还是节假日都是在加班中度过了,在此感谢我的媳妇对家庭的照顾和对我的支持。如果读者朋友遇到一位愿意和你一起在大城市打拼的姑娘一定要好好珍惜。

2020 的计划

2020 年的计划之一是把书写完,出版出来。

另外,继续完善自己的技术栈。自媒体和知识付费确实给我带来了一部分收入,但是与很其他的一些技术公众号主相比,让副业的收入达到或者超过主业的收入,对我来说那基本不可能。而且我个人是一个非常喜欢编码的人,我喜欢在技术上能达到一定的造诣。所以,自媒体不会成为我的重心。所以认认真真的再研究点代码,看几本好书,做些挑战性的项目,也是我 2020 的计划。

最后,锻炼身体,当然,希望我能坚持。

新的一年,大家一起加油,张小方与你同在。

如果你想和我聊一聊,可以加我微信 easy_coder