2023日本IT派遣日记0709

【情况概要】

        工作刚满一周，记录一下在现场学到的“常识”。

---

        常识，是对于新人来说最需要获取的，在我看来常识就是经验的一部分。

        为了“不犯错”，就需要了解现场的常识。

        这周获取到的常识有：

        1. 数据库不要擅自“增删改”；

        2. 我的现场是保守工作，所以尽量不要擅自增加代码，能用现有的method解决的问题, 不要试图通过写新的代码来解决问题;

        3. 少说少做, 不给自己增加额外的工作, 不给自己惹麻烦。

---

一、数据库操作

       工作的第三天，已经配置好开发环境，熟悉了一部分代码之后，我就自顾自的想要通过写一些demo来打通逻辑。

        我复制了一份项目，这样就不会把demo代码加入到与svn直接联系的本地项目中了。我也新建了一个demo表，想第一步能够实现从数据库读数据并在页面上显示的功能，因为我想通过动手来把项目传一下。

        当前的项目使用的是jsp+struts+java8的结构，而jsp和struts我都没有接触过，自己找了一些资料学习了，但没有动手去敲代码，心里还是会不安。

        当然，我也把自己的这个思路告诉了现场的日本人leader，然后他问我什么是demo...在了解了我的这个思路之后他没有当时说什么，但第二天也可能是他终于意识到了我想做什么，就给我发了消息“むやみに更新、作成、削除しないように”。

        这个时候我才意识到，我好像做了一件没有常识的事情。表已经建了。大概过了20分钟，我和自己公司人确认了这个事情虽然没有什么大的影响，但既然对方说了，而且是在他说这个事情之前我已经做了，还是跟他提一下这个事情的好。

        所在的现场是安全方面的要求很严格的。我也意识到，他们很可能设置的有数据库的操作日志，如果被看了日志才发现我的操作，到那个时候就比较难看了。

        于是赶紧对自己的操作进行了报告，然后删了新建的表。不再想着写demo了。

        报告了之后leader并没有再说什么，而是补充了我们新建表的时候，公司的命名规则。

        总结：

        不要擅自在数据库增删改，尽量通过既有的数据去处理问题。如果需要测试一些东西，比如修改某个业务上的东西，就通过网页去操作，而不要直接操作数据库。并且在做完自己的工作之后，把数据还原，不弄脏数据库。

        新建数据库和新建表，公司都会有自己的命名规则，先了解规则。

        在自己新手保护的这个过程中，在意的事情尽量问清楚，不要害怕沟通和联系。

---

二、解决问题的思考方式

        本周的最后几天，接到一个指示是输出的csv文件中新增一条数据。

        我当时查的form表单中，就是传递数据的实体类，并没有找到新数据的属性。

        比如说传递数据的实体类是Students类, 现在有name, id 的属性, 而他让在csv中新增加的数据是phoneNumber, 我先查了students类里有没有phoneNumber,结果没找到。

        所以我觉得需要新增一条这个属性。另外是发现点开页面上的数据详情的时候，后台会进行从数据库查找的操作，所以我判断，我需要的那个phoneNumber, 在生成页面的时候并没有查出来，缓存中应该没有。

        那么，要么利用现有的查询方法，查出来这个phoneNumber，再写入csv； 要么，新写一个小方法，就专门查这个数据，这样执行的sql语句少，效率更快。我是想干脆就直接自己动手写，比较快，效果也好。

        但是打了个大脸了。

        我查form中没有这个属性的时候, 没有注意到, phoneNumber是封装在另外一个实体类的, 又裹了一层, 所以我没有查到, 而不是说form中没有这个字段. 相当于是, 我是直接在代码中搜索phoneNumber, 看有没有相关的记录, 然后没有找到. 但实际上 phoneNumber裹在StudentInfo这个类里的, 而在Students类中, StudentInfo作为一个属性, 是List studentInfo。

        我应该检查一下"搜索"按钮，来确认在生成页面的数据的时候，我需要 属性有没有被缓存。

        所以当我跟leader说估计得写个新的方法的时候他很惊讶，然后带着我找了我需要的那个属性。同时交代了我，一般还是希望你能够用现有的方法去解决问题，而不是自己去写方法。

        这个项目是个代码屎山，零几年时候的老项目了，db中连属性的备注都么有，大多数情况都得去直接看源码，然后去猜字段的含义。如果自己这么随意地去折腾这个老爷爷，说不定什么时候老爷爷就崩了，那个时候就出大事了。

        总结：

        1. 做事要更细心更小心谨慎，但同时也要提高自己的工作效率。就查个字段，查了1天最后还搞错了；

        2. 因为是保守项目，所以尽量通过现存的工具和方法来解决问题，而不能用开发的思维；

        3. 千万不要擅自做决定，尤其是涉及到新增代码的情况下，和leader沟通好自己的思路，让他来决定这个样子可以不可以。

        但是话又说回来，我是真的觉得日本人挺有耐心的，他们给我时间让我来适应和学习，我在国内基本上每份工作都是直接开干，而现在是每天leader都交给我一个老案件，或者是新案件他自己正在做的事情，他已经调查过的，让我来做着试试看，然后我们再一起对一对，我是怎么做的，他是怎么做的。

        本来前3天我是很着急的，每天晚上到家，玩儿会儿游戏之后就会找资料看，看韩顺平的视频课学习，睡觉前也在看，上班路上也会看。最后1天就换了个心态，边听歌边工作（但是现场十几个人，还真没有这样的，也没见过摸鱼的，这点我倒是挺意外的，干活的也都是中国人）。时间比较充裕，下周第一天的上午，继续把这个csv的事情处理完就行了。下午leader再交给我新的东西。

---

三、不惹麻烦

        不惹麻烦并不是从当前的经历上直接得到的经验，而是对第二件事的再思考。

        我提出来要新写个方法去解决问题，这就是在给自己找麻烦。当然，如果我要的数据没有缓存出来的话，还真的就需要写。但也不是说自己写个sql语句，封装个方法去查出来，而应该是利用现在有的方法去查。虽然那个方法我看了，有很多无用的信息也要封装进去，无用的信息也会被查出来，浪费了资源。

        但这样做是最“安全的”。比如说，我写的方法可能没有去验权，以及可能会连带出新的bug，后期还得再去解决bug的事情。

        尽量减少自己的工作，节省的精力，也可以在下班之后放在其他的方面。但这样做最重要的还是减少了犯错的风险。犯错，是要承担责任的。并不是说逃避责任，而是评估“收益”和“风险”。像我之前的做法，并没有给自己带来除了工作以外的“收益”，反而需要承担对自己新增代码负责的“风险”，这样并不划算。

        优势是一点一滴积累的，如果无法积累优势，那么就尽量避免犯错。如何避免犯错呢？源头上是少做，少说，过程上是谨小慎微。

        我不是一个头脑很灵的人，能力还配不上自己的野心，而目前来看野心也没有实现的具体途径，那么这样的情况下，还是先苟住的好，搞清楚状况，积累起经验。不折腾自己，也别折腾别人。

        如果你都看到了这里的话，不妨点个赞吧! 你的支持, 能让我坚持下去继续提供一些这样"微不足道"的经验.