IT初级码农的碎碎念牢骚

这是一篇一年前的牢骚文，今天才把私密改成公开，看我博客内容就知道，本人做的还是偏向于Java较多，当然其他语言有所涉及，但是熟练程度肯定不及母语。

现在的这家公司工作，业务代码都是用得node，所以我也是来到这边正式上手node写代码，之前写过一些JS，但是也是用用dom，走走ajax而已。正儿八经用起什么egg.js和nest.js，koa，express那种框架，和ES6写法。还是有很多不适应。

首先我要自我反省，我个人非常粗心大意，经常忘记一些重要地方打log，或者做判空，或者改一些URL都没会丢三落四剩下一些没改完。其二是对自己做的模块不负责任，还有蜜汁自信，做完自测只单测功能，没有全方位考虑其他的情况。

目前所在的项目线，也是公司所有项目线中算最复杂的，有时候一些业务功能会牵涉到三个后端项目，所以联调，自测，都非常有难度，整个流程跑下来很难保证不出问题，所以我也只能保证自己写的代码不错问题，整个流程跑下来有问题再排查，特别是刚进来的时候，上手难度确实较大。二是人手不足，没人带着了解业务（更别说适应了解使用技术，都是靠自己业余时间做功课去学习），基本上靠着自己找别人问，别人手头工作也忙，有时候态度冷淡也自己适应吧。。。接受别人代码就是这么枯燥且无趣，一开始不了解业务，做少了一些功能（本来就不知道要有那个功能），产品也解释不清楚，只是说了个大概跟以前一样，大姐我哪知道以前有什么功能啊，被骂得也是很委屈。

还有就是语言的不适应，有时候写着写着定义一个变量，顺手就写成了String str = “”；自己还一脸懵逼，过几秒反应过来。node里面有种写法：const a = user.name || custome.name || student.name ;意思就是判断哪个参数存在，把唯一存在的附值，不存在的false则不用管，这种写法确实非常简介，而且做一些判断兼容性非常优雅美观。但是强类型语言是真的不能这样写的（参数Boolean和String类型不兼容），我组长写习惯node，跟我说Java肯定也行，我也不好争论。

Java 中字符char就用’ '单引号，字符串才用“”双引号；所以我定义字符串会写出“XXXXX”；VScode有一个自动格式化检测工具，要安装才报警通不过编译，不安装就正常编译；我刚开始做的时候，不知道要装这个插件工具，所以一堆string类型报警。node里不管字符还是字符串，都是单引号。。。自动检测还有一个比如打log的时候，order : order；这样就会报错（不安装那个自动化格式工具就不会），因为名字重复，必须 orders : order ; 我还没见过这种报错…既然是输出的log，那么型参和日记输出的key值不对应有啥关系…可能是某种规范吧…

Java框架的引包，一般都是自动引入的，import … from XXX 那些不用自己写，但是node框架必须手动引入，手写相对路径非常不习惯，而且昨天被骂了才知道：

import * as qs from “querystring”;
和
import qs from “querystring”;

的具体区别，原来是模块导出export的时候如果没加default默认导出，就要用第一种写法，如果有，则用第二种。

JS有种写法是 ： { userId } = { userId : xxx } ; 这种说法吗？

大神们原谅我孤陋寡闻，也看书自学过js和node，但之前从未听过这种写法，传参的时候，看着service，理所当然只传一个userId,而没有写成后者形式，一直报错，都不知道原因。

Java持久层查数据库，返回值类型就已经严格限制了，查询后返回的数据也是非常简介： int a = XXXServiceDao.getNameById(id);这样写老铁没毛病，然后判空一下 a != null 就可以操作。

node的话，返回是一大串的数组 + 对象类型，假如一样的写法： const a = XXXServiceDao.getNameById(id); 必须是 a.data[0].a.name; 这样才能拿到返回值，因为它responseBody 是：

{
code: ;
msg: ;
data:[
{
a :[ name : " 小明 " ]
}
],
[
其他一些乱七八糟的东西…
]
}

小弟不才，第一次看到这么大场面吓呆了，这返回的是个啥？？做多几遍，也慢慢适应了，算了麻烦就麻烦点吧，过滤多几层，对象复杂点，就做多几层判断，慢慢习惯吧。

gitlab CI 和 jenkins CI ； 这两种自动化集成以前都没怎么接触，也算是我孤陋寡闻吧，只是听说过知道怎么用，具体详细的，用好，耐用，本人也是能力不足。配合上git分支名必须与 CI集成中正则表达式匹配，才会自动集成打包。不知道 gitlab_ci 那个配置文件的具体作用，唉…

涉及到微信公众号开发，那我之前确实没做过，关于打tag ， 模版消息，定时推送，关注/点击/扫描 事件，还有微信授权，这些东西还全部区分开发和生产环境不同的配置等等，个人总结的话，接受能力在中下等水平吧，基本需求也能做完，但是坑坑洼洼的，被骂的也不少，一些bug调了半天自己搞不懂，去问别人，被鄙视冷眼了一通后才发现是配置问题，是版本问题，是环境问题。那种憋屈。算是我自己没理解能力吧…

做报表用的pgsql，跟sql基本差不多，但是还是会有区别，一些sql能通过执行，它不行，用来做报表也是很不适应，但是还是没人教的，靠自己吧，掌控好时间。报表系统不会用，公众号管理平台，后台管理平台系统，提审系统，发布管理系统不会用…大家都很忙，自己边做边学吧，不能有一颗玻璃心，不然被冷眼几下，鄙视几下就忍受不住了。

还有一些英文缩写，也自己慢慢熟悉，别人大公司都约定书成的缩写，你不懂就显得很局外人，肯定被嫌弃。比如被骂了之后知道了 ‘提MQ’ 就是 发起 merge query ，也就是让别人对你写的代码进行review。‘过QA’就是提起测试需求，让测试同事跟进…

不要随便相信产品的话，产品想法天马行空，他们也不知道具体功能的实现，可能会叫你去做一个已经存在的功能，改一些不能轻易修改的功能，想象中非常简单，半天就能搞定，做起来才发现牵一发动全身，到时候被叼的还是自己；需求文档分分钟有改动，产品不会再通知你，你要边做开发边看文档（有的需求文档写的很抽象，有的几篇需求文档放在不同的地方），比比是改需求速度快还是做开发速度快，有几次就是做完了，才发现需求早已经改得天花乱坠了，产品才说：我已经改了呀，我已经新起一篇需求了呀，以最新的为准呀。所以，自己做好判断，没人带，靠自己。避免以后再在项目组大群被点名批评的丢脸。

还有很多不适应的坑洼，语言不同带来的失误，都要在踩坑中慢慢磨合，但是唯一肯定的是我不会停下自己学习的脚步，骂就骂吧都习惯了，委屈就自己加深印象和理解，不犯同样的错误。996不适应就自己调整，身体最重要。工作是一辈子的，学习也是一辈子的。加油。