7 年前端公开求职， 9000 字长文（web3 & remote）

前言

https://github.com/drafish

我一直认为 github 是一个程序员最好的简历。所以我把我的 github 地址放在最前面。大家只要看下我的 github 就能大致了解我的实力。不过，为了节省大家的时间，我会在下面罗列出所有我参与过的开源项目，并且按照参与程度从高到低依次做个介绍。另外还有几个我觉得比较优秀的我个人的开源项目，也会一并列出。然后我会讲下我最近的一份工作和现状，我为什么想要换工作，我希望找什么样的工作，期望薪资是多少，依据又是什么。文章最后我会给出我的联系方式。

我参与的开源项目

Remix

这是以太坊官方开源的一个用于智能合约开发的 IDE 。用 React 开发，支持浏览器环境。不过也有 Electron 版本，可以支持 Linux 、Windows 、MacOS 桌面环境。

我给这个项目开发了 1 个 feature ，修了 2 个 bug ，提了一个 issue 。

• ethereum/remix-project#2581：这个 feature 是国际化支持。早在 2020 年的时候 Remix 团队就提出这个需求。但是优先级比较低，所以一直拖着没做。我用 react-intl 实现了这个 feature ，并且将 Remix 上几个主要功能模块的文案翻译成了中文。还为这个 feature 添加了 e2e 测试代码。我提交了这个 PR 以后，Remix 团队内部展开了一次讨论。因为我的 PR 和他们正在开发中的 feature 经常会产生代码冲突，所以一直拖着没合并。不过经过漫长的等待，现在已经被合并到主分支了。我在 gitter 上跟 Remix 的 TeamLeader 私聊过，表示愿意为这个 feature 提供长期支持。在下个 PR 中，我会再翻译一些文案，并且在文档中添加一些说明，给其他语言的贡献者做个参考。
• ethereum/remix-project#2937：在 Remix 上部署合约以后会给出一个合约的可视化操作界面，用户可以通过这个界面来与合约进行交互。有用户发现了一个很奇怪的 bug 。先后部署合约 A 和 合约 B ，把 A 删了以后合约 B 的操作界面就变成了合约 A 。我当时一看就觉得应该是 react list key 使用不当。很多开发者图方便，经常会把 index 当 key 来用，有时候就会出现这种诡异的 bug 。从我看到这个 bug ，到问题定位，再到提交代码，整个过程也就几分钟。
• ethereum/remix-project#3010：因为前面那个国际化支持的 PR 之前一直没有被合并，所以我就一直要把 master 分支合并到我的 PR 。有一次合并后我发现很多 e2e 测试用例没跑过。我花了很多时间才定位到问题原因，并且提交了修复代码。但在我排查问题的过程中，意外把 CircleCI 给搞挂了，导致我代码提交后 e2e 测试不跑了。不过这个影响仅限于我的 PR ，而且我后来也找了 CircleCI 的运维工程师帮我解决了这个问题。但这期间因为没有 CircleCI 帮我验证我提交的修复代码是否有效，我就不得不在自己电脑上跑 e2e 测试。因为墙的原因，e2e 测试跑的并不顺利，但最终还是都跑过了。我也因此发现了 e2e 测试中存在的一些问题，并且提了这个 issue 来给出我的一些建议。目前 Remix 团队暂时还没有时间处理这个 issue ，但已经打了标签，应该会在下个 release 版本中有相应的处理。
• ethereum/remix-project#3026：这是 Remix 团队自己发现的一个 bug ，DGit 插件出现了两个滚动条。而且从 bug 描述来看，这已经不是第一次出现了。他们可能已经修复过一次，但显然没有彻底修复。经过我的排查，我发现不止 DGit 插件有这个问题，所有通过 iframe 来加载的外部插件都会多一个滚动条。父子元素高度完全一致，按理说不应该会出现滚动条。我工作这么多年，也是第一次碰到这么诡异的 bug 。不过经过我多方排查，最终在 stackoverflow 上找到了问题的答案，并且提交了这个 PR 。

除了贡献代码以外，我还帮忙翻译文档。虽然 Remix 的文档仓库也在 github 上面，但是 Remix 团队不直接接受文档翻译的 PR 。他们把文档上传到 crowdin 上，我在 crowdin 上把文档翻译成中文，经由 Remix 团队审核通过后，他们会自己提交一个 PR 来合并这些翻译。

大家可以点下面这个链接查看我翻译的文档。

https://crowdin.com/project/remix-translation/zh-CN

提示：crowdin 是一个支持多人协作的文档翻译平台。以太坊官网就是借助这个平台来进行翻译的。

不过在文档翻译的过程中，我发现 Remix 文档中存在一些问题，我提了 3 个 PR 来帮忙修复这些问题。

• ethereum/remix-ide#3115：文档原文中存在两处小错误，具体大家可以点链接进去看，在这里我就不赘述了。
• ethereum/remix-ide#3117：Remix 的文档是用 Markdown 写的，用 sphinx 来翻译并构建 html 文档。Remix 团队对国际化支持一直都不太重视，他们一直都没发现翻译后的文档会丢失很多样式。因为他们使用的 Markdown 解析库会自动过滤掉 Markdown 符号。我在查阅了 sphinx 官方文档后发现，sphinx 官方推荐的 Markdown 解析库是 MyST 。我测试后发现只要更换 Markdown 解析库就可以解决这个问题。另外我还发现文档仓库的 .gitignore 有问题，该忽略的没忽略，不该忽略的却忽略了。我在 PR 描述中提到了这个问题，并且给出了自己的建议。Remix 团队已经按照我给的建议提了一个 PR 来修复。大家可以点这个链接查看 ethereum/remix-ide#3118
• ethereum/remix-ide#3121：这个 PR 是我为上一个 PR 做出的弥补。我在提上一个 PR 的时候没有仔细地测试。后来我发现上一个 PR 虽然修复了 Markdown 解析的问题，但也带来了 2 个新问题。一个是图片渲染不出来，另一个是内部链接会丢失。好在我后来都自己发现并且修复了。如果让 Remix 团队来帮我擦屁股，那就糗大了。

除了以上贡献外，我还经常在 Remix 的 gitter chat 社区帮忙解答社区成员的一些疑问并且反馈一些问题。大家可以点这个链接： https://gitter.im/ethereum/remix

无需注册即可查看。往上翻下聊天记录就能找到我。我是用 github 账号登录 gitter 的，所以头像和昵称都和我的 github 一样的。

另外，还有一个事儿。Remix 团队希望我能用普通话帮他们制作几个介绍 Remix 功能点的视频，并且愿意支付我一些报酬。我在 YouTube 上看过 Remix 团队制作的英文版视频。看着挺简单的，我也就欣然答应了。目前已经做了一个视频给他们发过去了，后面如果他们更新到 YouTube 的上的话，我会把视频链接更新到这里。

ant-design-vue

前端开发领域最有名的 UI 组件库当属蚂蚁金服开源的 ant-design ，本人就是 ant-design 重度使用患者。不过这是近 3 年的事了。在这之前，我一直都是用 vue 开发的，UI 组件库用的是 element-ui 。

记得当时为了进一步提升自己的实力，我在极客时间上买了大神唐金洲的课程《 Vue 开发实战》。我惊奇地发现唐大神开源了一个 vue 版的 ant-design 。我思量许久，最终决定在新项目中尝试 ant-design-vue 。当时主要是基于两点原因。

• 第一点：ant-design-vue 长得比 element-ui 好看很多。当然这主要是蚂蚁金服 UI 设计师的功劳。唐大神只是照搬了 ant-design 的样式而已。不过我当时对 element-ui 有一点审美疲劳，可能看法也不太客观。现在再回过头去看，感觉差距也没那么大。但心里还是觉得 ant-design 要好看那么一丢丢。（饿了么同学求轻喷😂）

• 第二点：ant-design-vue 不够成熟。对，你没听错。这是个缺点，但换个角度讲，这也是个优点。像 element-ui 、ant-design 这种成熟的组件库用起来基本上不会有什么坑。就算遇到问题，网上稍微搜索一下就能找到答案。这意味着你把项目交到一个经验比较欠缺的人手上也不会出什么问题。这对项目稳定性而言是好事。但对我的技术成长就不那么好了。成熟的组件库会让你的思维始终停留在使用这个层面。而 ant-design-vue 让我有机会突破原来的思维层次进入更深的一层。

我记得那会儿 ant-design-vue 还只有几千 star ，文档也不完善，社区规模也小，很多问题都要看源码才能解决。不过也正因为如此，我的技术能力得到了很大的提升。而我也为这个组件库做了一点力所能及的贡献。

• vueComponent/ant-design-vue#931：这是我自己在使用过程中发现的一个 bug 。在 jsx 中使用 Form 组件中的 getFieldDecorator 函数就会报错。可能很多 vue 开发者，特别是初学者，都不知道，其实 vue 是可以支持 jsx 的。但因为 vue 官方推荐使用模板语法，所以大部分人都不会想到用 jsx 来开发。我也是通过唐大神的课程才知道原来在 vue 里面也可以用 jsx 。当时为了尝试更多的新鲜技术，我就在新项目中大胆的引入了 jsx ，也因此发现了这个 bug 。而且这个 bug 很容易修复。我就在 github 上提了个 issue ，顺手也提了个修复的 PR 。
• vueComponent/ant-design-vue#1250：这是一个页头组件，位于页容器顶部，起到内容概览和引导页级操作的作用。其实 ant-design-vue 就是复用了 ant-design 的所有样式和 api 设计，用 vue 重构了一遍。我在使用过程中看了很多组件的源码，并且比对了 ant-design 的源码。我感觉这事儿好像也不是很难的样子。正巧看到一个 ant-design 新出炉的组件。唐大神还没来得及把这个组件给搬过来。这不，我就逮着机会把这事儿给干了。我不光实现了这个组件，还添加了相应的单测代码和文档，还有被这个组件影响到的其他组件也一并做了修改。这是我第一次给这种级别的开源项目提 feature 级的 PR ，看到我的 PR 被 merge 还是相当激动的。

vant

这是有赞开源的基于 Vue 的移动端 UI 组件库。当时选 vant 倒是没什么技术上的追求，纯粹是冲它的 star 多。这是我的一个选择习惯。star 多意味着用户多，反馈好，坑少。其实当时我的第一选择是饿了么开源的 mint-ui 。因为我在更早的时候就用过这个组件库，而且它的 star 是最多的。但是 mint-ui 停止维护了，所以退而求其次选了 vant 。使用下来感觉 vant 还是很赞的。而且经过这两年的发展，vant 的 star 已经超过 mint-ui ，成为当之无愧的移动端第一组件库。

• youzan/vant#3804：这是我在使用 stepper 组件时遇到的一个 bug 。在 IOS 中，点 stepper 组件的输入框就会打开键盘，然后键盘会把页面往上顶，键盘收起后页面也不会回到原位。我感觉这个问题应该不光会出现在 stepper 组件上，所有带输入框的组件应该都会有这个问题。于是我就找了另一个带输入框的组件测试了一下。结果发现居然没有问题。我转念一想，估计是已经被修复了。一查源码果然如此。于是我就把那段修复代码 copy 到 stepper 组件中测试了一下，果然好用。我就这样混了一个 PR 。
• youzan/vant#3963：这是我对 ImagePreview 组件做的一点用户体验上的优化。我们那个兼职了 UX 的 UI 设计师感觉图片的切换速度太慢了，问我能不能调快一点。我听了之后感觉很容易啊，这不就一个参数能解决的问题吗。然后就在 vant 的文档里找这个参数，结果没找到。一查源码发现，原来这个组件不支持这个参数。然后我就提了个 PR 把这个参数给加上，并且解释了我为什么需要这个参数。我就这样又混了一个 PR 。

这里顺便提一嘴，有赞 @chenjiahan 大佬的 PR 处理速度是我见过最快的，当天提当天就 merge ，必须给他赞一个。

vantui

这是小电科技开源的一个 UI 组件库。细心的朋友可能已经注意到，这个组件库的名字和前面有赞的 vant 长得很像。这不是巧合。vant 是一个用于移动端网页开发的组件库。而有赞还有一个专门用于微信小程序开发的组件库叫 VantWeapp 。vantui 就是用 React 把 VantWeapp 重构了一遍，目的是为了支持 Taro 。可能有人对 Taro 不太了解，我这里做个简单的介绍。Taro 是京东开源的一个跨端跨框架的解决方案。用 Taro 开发的应用可以支持小程序、H5 、ReactNative 。

我之前没有开发过小程序和原生应用。当时是想做个技术储备，所以就研究了一下 taro 。然后选了 vantui 作为组件库，写了一个简单的小程序。这个小程序我已经开源在我的 github 上了。在后面写我自己的开源项目时会给出。

• AntmJS/vantui#177：这是 Tabbar 组件的一个小问题，算不上 bug ，因为代码是可以正常运行的。Tabbar 的 active 属性类型是 number ，而与之对应的子组件 TabbarItem 的 name 属性类型是 string | number 。如果给 TabbarItem 的 name 属性赋一个 string 值就会提示 ts 类型错误。

algo

这是极客时间专栏作者王争专门为他的课程《数据结构和算法之美》写的一个算法题库。我当时是买了王大神的课，想着恶补一下算法。然后就结结实实地体验了一把从入门到放弃。王大神的课还是很不错的，是我自己静不下心来学。后面可能会找时间把算法再捡起来，毕竟我的数学基础还是不错的。我高考数学可是满分。当然我那年卷子也相对要简单一点。

• wangzheng0822/algo#242：虽说是从入门到放弃，但我还是看出了题库里面存在的一些问题，顺利地混到了一个 PR 。具体我就不细讲了，都是些小问题。感兴趣的同学可以自己点链接进去看。

我自己的开源项目

react-native-cpp-demo

我们公司有一个用 ReactNative 开发的 app ，但是这个 app 只支持 Android ，因为 app 用到的一个签名算法是用 Java 开发的。我们后来考虑用 C++ 来重构这个签名算法，在 ReactNative 中集成 C++ ，这样就能同时支持 Android 和 IOS 。

因为 ReactNative 官方并没有给出怎么集成 C++ 的文档和 demo ，当时就由我来做这部分的技术调研。我查阅了很多资料，最终总结出三种集成 C++ 的方案。所以就写了这个 demo ，并且在 readme 文档中写明了集成 C++ 的具体方法。

discipline-clock-taro

这就是前面提到的，我为了做技术储备，用 taro + vantui 写的一个打卡小程序。点链接进去，在 readme 文档里有二维码，扫码即可体验。后端是用 nodejs 写的，readme 文档里有后端仓库地址。目前只支持小程序和 H5 ，因为 vantui 不支持 ReactNative 。将来可能会考虑把 UI 组件库换成 taro-ui ，这样就能支持原生应用了。

可能有些同学体验了这个小程序后会有点懵逼，不知道这打卡在打个什么东西。这里我稍微做点解释。纯粹是题外话。不感兴趣的可以直接跳过。

我对净土说：你先说，你把我说明白了我就信。 净土说：你都不信我，我怎么给你说明白。

闻思修和信愿行在底层思维逻辑上是很难兼容的，至少对修为尚浅的人来说是如此。当然我相信，当修行到了深处，这两者是不冲突的。只是现阶段，我觉得禅宗可能更加适合我。因为禅宗不像净土那样注重形式，只要能让你明心见性，任何方便法门都是可以借鉴的。

那次打七虽然体验不佳，但我还是借此机会认识了不少同修。有些比较精进的人每天都会做功课，然后把完成的功课量发到微信群里，互相鼓励。这就是打卡小程序的需求原型。里面的功课名称我都换成了假名，主要是怕被监管到。

小程序做出来以后只在几个微信群里面小范围传播，总共也就几十个用户。刚开始的时候坚持打卡的人还比较多，后来就慢慢减少了。我前两天还上去看了下，发现居然还有那么两三个人在坚持打卡。我也是倍感欣慰，怎么说也算是为佛门做了点贡献。

最近一份工作和现状

我目前在一家区块链公司做前端开发，同时也兼职智能合约开发。我是疫情前入职的，到现在刚好满三年。三年来一直听到很多公司裁员降薪的新闻，但我们公司没有这种情况，一直都很稳定。不过入职以后也几乎没涨过薪，这可能就是稳定的代价吧。某种程度上来说，这也是我的一种刻意追求，入职之前其实就已经想到了。

因为的我的前东家是做互联网金融的，19 年的时候暴雷了。当时打了我一个措手不及。一向不屑于考公考编的我，当时居然觉得公务员和事业编挺好的。但那个时候想考也来不及了。当时就想着尽快找个稳定的工作，钱多钱少也无所谓了。所以就找了现在这家有点类似国企的公司。工资不高，但胜在稳定清闲。

稳定前面已经说了，我再给诸位说说具体怎么个清闲法。

朝九晚六，有一个小时的弹性时间，早到可以早下班。中午有一个小时的休息时间。但实际我们都休一个半小时。因为我们一般都会提前半小时去吃午饭。早上上班先在公司楼下打个卡，吃了早饭再去公司，这样就又混了半个小时。所以其实工作时间也就 7 个小时。就这还没算摸鱼的时间。周末双休，法定节假日。碰到端午、国庆、春节这种比较大的假期，最后一天我们还会提早放假，算是公司福利。我入职三年，加班次数屈指可数。偶尔加班也可以换算成调休。

说完了工作时间，我再来说说工作强度。

像我们这种公司，求稳不求快。通常我们项目工期都是估的非常宽松的。这就给了我们很多摸鱼的时间。具体能摸多少鱼取决于你的实力。我记得我刚入职的前两年，实际花在工作上的时间也就一半。最近这一年更是连三分之一都不到了。

我举个比较夸张的例子。今年年初的时候，因为组内工作不忙，我就被借调去另一个组帮忙。当时两周的开发任务，我两天就干完了。以前像这种跨组借调的开发质量一向都是很差的，因为开发人员只是临时借调，开发完就可以拍拍屁股走人。而我的这次就是个例外。季度考核的时候，那个组的 TeamLeader 给了我很高的评价，因为我的代码质量高，bug 少，文档也完善。

平时没有开发任务的话，我会看看小说、动漫、美剧，或者打打游戏。不过这也只是偶尔，大部分时间还是用来提升自己的。我们公司一直鼓励员工在空余时间做自我提升，而且最好是能把成果回馈到公司。比如去探索一些公司可能用到的新技术，或者对某个历史悠久的项目做重构，或者组织 workshop 分享一些技术成果等等。这些事儿我都做过，不过要论收获最大的，还得是 workshop 。

我们组从去年开始就想在管理后台里面嵌入一个智能合约 IDE 。当时就由我做的技术调研。我研究了 Remix 的源码，从中抽取了几个关键组件，实现了一个简易版的合约 IDE ，可以实现合约的编辑、编译、部署、调用，而且还实现了对我们自研底链的适配。目前已经在一个外部项目中用到了这个 IDE 。四月份的时候我们组的 TeamLeader 问我有没有什么技术成果可以做个 workshop 分享。我就想到了智能合约 IDE 。于是我就以这为主题组织了一次 workshop 。

为了让我的分享内容更加丰富，我当时还调研了几个同类产品，分别是纯白矩阵、趣链、蚂蚁链的 IDE 。趣链和蚂蚁链的产品做的很烂，估计当时做出来就是为了给领导交差的，后来也没怎么维护，bug 巨多。纯白矩阵倒是踏踏实实在做产品，用户体验也不错，特别是对多链的适配算是它的一大亮点。不过我觉得纯白矩阵的技术架构对后端的依赖太重了，整个就是个中心化服务。假如后端挂了，整个服务就不可用了。为了保证服务的高可用性，纯白矩阵的运维成本和服务器成本是非常高的。相比之下，Remix 就非常的轻量。因为它其实就是个静态站，服务部署是交给第三方的。具体价格我没了解过。但是，一个静态站，你想这成本能有多高。

当时我就有一个想法，如果能基于 Remix 做二次开发，把上面的文案都翻译成中文，然后适配现在市面上主流的几个链，那这个产品完全可以碾压纯白矩阵。因为我们的成本要比纯白矩阵低很多，但是用户体验却要更好。当时我就跟领导提了这个想法，可惜并没有受到重视。但我自己还是觉得这个事儿有搞头，感兴趣的朋友可以联系我。

期望工作和薪资

首先必须是远程。这是我的核心诉求，如果不是远程，那工资再高我也不感兴趣。

其次是稳定。公司越稳定，那我越能在这家公司安心的干下去。当然，我也不是说一定不接受创业公司，但是优先级肯定会比较靠后。

工作时间 8✖️5 。考虑到境外的公司可能会有时差，所以我不一定要求像我现在的公司一样朝九晚六，可以适当往前或者往后调整一到两个小时，只要不影响我休息就行。法定节假日也不一定要按照国内的时间放假，只要时间上不来少我的假期就可以了。

我目前所在的这家公司给我开的薪资是税后一年 23W 。这个薪资对我来说算不上满意，但也算不上不满意。我的能力肯定是不止这个价的，但这份工作也确实是很清闲。好处坏处这么一对冲，我其实也没啥好抱怨的。其实总得来说在这家公司待的还算比较满意，同事之间处的挺好。如果现在这家公司能接受我远程，那我其实是很乐意继续待下去的。但这几乎是不可能的，因为公司从来没有过这种先例。

我现在的核心诉求还是远程，其次是稳定，再其次才是薪资。我可以接受平薪跳槽。甚至还可以适当降薪。因为远程工作以后，我的生活成本会降低差不多 2W 。所以我可以接受的最低薪资是税后一年 21W 。

当然，如果你只给得起这个薪资的话，那就不用指望我会投入 100%的精力了。换句话说，就算我愿意 100%投入，你也未必会有这么多活等着我干。我可以很明确的告诉你，我会有很多的摸鱼时间。你不用管我在工作时间做什么，只要知道我一定会保质保量的完成工作就行了。而且在规定的工作时间内，我一定会做到及时响应，绝对不会因为摸鱼而耽误工作。这是我作为一个程序员最基本的职业素养。在规定的工作时间之外，我不太希望受到工作的打扰。但如果事情真的很紧急，偶尔打扰我也是可以接受的。如果是我的问题，那么请随时打扰我。这是我活该，我必须为我干的活负责。当然，这种情况基本不太可能会发生。我对我的能力还是非常有信心的。

说完了下限，我再来说说上限。

我先给这个上限下个定义。上限是指，在我 100%投入 8✖️5 的工作时间的前提下，我觉得我应该能赚到的薪资。为什么说应该呢？因为我从来没赚到过这个薪资。而且要让我 100%投入，这份工作必然和我这个人是高度匹配的。这个条件其实很难达到。

我目前为止看到过跟我匹配度最高的是 Remix 团队之前开放出来的前端岗位。Remix 团队有哪些成员，各自负责做什么，开发水平怎么样，其实我心里能评估出个大概。我觉得我的技术能力应该是远超这个岗位要求的。但是这个岗位有一个要求我不太符合，就是英语口语要流利。我目前跟老外进行文字沟通已经完全没有问题了，但是口语水平还是不太行。所以当时看到这个岗位后没太敢投。我想着先混几个 PR ，做出点贡献，让他们看到我的能力后，是不是可以商量下适当降低对英语口语的要求，至少在面试的时候会顺利一点。等到我做出了一定贡献以后，我觉得我应该给 Remix 团队留下了一个不错的印象。然后我就试着问了下他们是不是还在招人，可惜那个时候他们已经不招了。不过他们跟我说后面如果再有岗位开放出来会跟我说的。

这事儿说起来我是有点小心机哈。虽然最后我也没有得逞，但我不觉得这事儿白忙活。因为给开源项目做贡献对我的提升是很大的，而且写到简历里面也很好看。而且通过这事儿我能大概推测出我的上限。

Remix 给这个前端岗位开出的年薪是 6~12W 美元。我不敢说我能达到他们的上限，但是下限肯定是绰绰有余的。鉴于我的英语口语能力比较欠缺，所以我取他们的下限作为我的上限。按照现在的汇率折算成人民币就是 42.72W 。我再给您抹个零，42W 。这就是我的上限。

我之前其实有计划通过语言交换来提升口语能力。就是找几个想学中文的老外，我教他们中文，他们教我英文。我已经下了一个叫 Tandem 的 APP ，尝试着找过几个语伴。但后来觉得短期内想把我的口语能力提升一个境界还是比较难的。所以这个计划就暂时搁置了。我想在国内试着先找找看，如果能找到满意的远程工作，那我也就没必要那么急着提升口语能力了。但如果实在找不到，那我还是得把眼光放到国外的公司上。这就意味着口语是我必须要克服的一个难关。不过这肯定是个漫长的过程。其实我的语感和发音都还是可以的，就是说的少。我得尽量找机会多说英语。语言交换就是个很不错的方式。我后面肯定会把这个事儿再捡起来的。

个人能力总结

Web 前端是我最擅长的领域。React 和 Vue 我都用过，都有很丰富的项目经验。目前我使用的技术栈是 React + TypeScript 。小程序的项目经验不多，就前面那个开源的打卡小程序，还有我们公司的周报系统。APP 这块是没有任何项目经验，但我做过技术调研，看过几个 ReactNative 项目的源码，在本地也跑过。感觉对我来说应该不是很难，当然这个前提是用 ReactNative 开发。如果是用原生语言或者 Flutter 的话，那对我还是蛮有挑战性的，而且我也不准备往那个方向发展。

后端用 Nodejs 做过几个项目，数据库用过 Mysql 、MongoDB 、Redis 。我自我感觉后端这块算不上精通，但应付日常开发是绰绰有余的。Java 这块没有很实际的项目经验，但语法我都熟，看懂项目代码是没问题的。我举个简单的例子。

我前面提到给智能合约 IDE 适配我们公司自研的底链。其中最麻烦的就是签名算法。因为我们用的是国密算法，而且算法细节上和开源的国密算法还有点不一样。这部分代码是我们底层链团队的同事用 Java 写的，我没有办法直接把 Java 代码集成到前端项目里面。算法功底强的大佬估计看下 Java 代码就能写出一个 JS 版本。但我不行。我就找了个开源的国密算法 JS 库，对着 Java 代码反复比对差别在哪里。这就需要我用 IDEA 把 Java 项目起起来，然后打断点一行一行调试。我就是靠着这个笨办法把这个签名算法给搞出来的。

经过这个事以后，我感觉如果让我开发一个 Java 项目应该不是太难的事儿。跟一般的后端同事比，我最多就是技术不熟练，开发的慢一点。但我有信心经过一两个项目，就能把这个差距弥补上来。不过我本人并没有往 Java 这方面发展的意向，最多就是把 Java 当成一个技术储备。

智能合约这块有三个项目经验，两个存证项目和一个凭证项目。其中有一个存证项目是完全由我自己独立开发的，其他两个项目是我接手维护的。这些合约和一般的公链合约相比要复杂的多。因为是基于我们自研的联盟链做的，gas 不要钱，所以我们的合约可以写的很奢侈。特别是那个凭证项目，甚至还搞出了一套合约框架，里面用了很多委托调用，可以支持业务合约和数据合约的升级。

大家看到这里应该能感觉出来，我的技术栈很杂。你要说在哪个领域我特别精通，那我谈不上。但我掌握的技术都是可以应付日常开发的。现在如果给我一个小型的区块链项目，我一个人就能搞定前端、后端、合约这三层的开发。而且 Linux 我也是一直在用的，不敢说精通，但给一个小型项目提供运维支持绝对够用了。

哪位朋友对我感兴趣的话，可以给我发邮件，简单介绍一下你们公司和你们在做的项目，并且给出你们能给到我的岗位和薪资。如果有其他想问的问题也可以在邮件里面提，我都会认真回复。

我的邮箱地址是： [email protected]