12.16：完成用户编辑接口的开发；用户编辑功能和创建功能有很多类似的地方，因此为了避免重复代码，我将参数校验抽取成了一个公共方法；且由于官网已经上过了编辑功能，基本逻辑和后台编辑用户是类似的，唯一的区别在于，web端需要回显个人信息，而后台则返回true或者false就可以。而又由于保存了用户的变更记录，因此从数据库获取的敏感信息，不能解密，需要加密保存到变更记录里面，因此web端就还需要将敏感信息单独解密，回显到个人信息；12.17：完成用户编辑接口提测，修改留资推送线索中的语言动态；原有的推送线索里包含了语言，但是是在代码中写死的常量-英语，由于现在多语言表已经创建，可以获取用户选择的语言，因此将语言通过获取当前支持的语言列表来动态获取；然后推送给ocrm12.18：专项代码review，优化已有的代码；在代码review的过程中，我的接口返回值，是基本数据类型boolean，而通用的都是返回Boolean，于是stone老师给我提了个问题，接口返回到底选择boolean还是Boolean？然后我去查资料我本以为是序列化的问题，但其实返回的时候底层已经转成了包装类Boolean，所以本质的区别其实是特殊值的问题，boolean是基本变量，只有两个值：true和false；而Boolean是包装类，有三个值：true、false和null，在某些特殊场景，用null可以进行一些特殊判断；因此接口返回布尔值最好选择包装类。12.19：修改seo设置出现的bug；在解决这个bug的时候，我发现项目中的多语言获取其实存在问题，现有的多语言配置涉及三张表，字典、模板配置表和多语言字段表，而在配置多语言时，仅仅修改了配置表，但是获取多语言字段时，只获取了字典表，因此就会出现一个问题：配置默认语言的时候，只修改了配置表，如果这个时候去获取多语言表，默认语言还是修改前的默认语言，导致了数据不一致。和孙老师讨论后，孙老师在配置默认语言时，同步修改多语言表，解决了这个问题。而seo的bug也类似，由于我是直接获取的多语言表，假如现在只有一种语言，我去新增语言，多语言字段仍然只有原先语言字段，导致回显seo时仍然只有一种语言，因此我需要去读取配置表，根据配置表的语言去获取多语言字段值。12.20：后台筛选整合优化；主要完成了字段整合的需求，例如学员邮箱分为注册邮箱和备用邮箱，现在整合到一起，并且支持多选。

12.9：完成了seo配置接口的开发和详情接口的开发；由于孙老师已经将多语言保存和获取的工具写好，所以这个任务并不难。在写完接口后，我看了多语言工具的源码，它是通过反射来赋值和获取的，这样一来，多语言获取的操作非常方便，并且可以集中维护；12.10：解决seo保存时出现的bug；在保存seo接口的时候，出现了无法清空的现象。seo的配置是可以清空的，但是保存空字符串的时候，接口返回仍然是原来的值；看代码发现，这是因为保存多语言的时候，增加了一个strutil.isBlank判断，导致空字符串无法保存到数据库，和孙老师讨论后，将判断改成了ObjectUtil.isNull，解决了这一问题。12.11：完成不登陆留资接口改造；目前已有的两种留资方式，是官网登录留资和不登陆留资，而营销落地页留资，并没有商品id；而按照原来的留资，没有商品id就无法获取项目来源，CFA或者Degree，因此需要对留资接口进行改造，而其他情况下的逻辑又不能变；所以我增加了一层判断，通过判断有无商品id，去获取商品，没有商品id的话，就去通过感兴趣项目判断是CFA或者Degree；12.12：优化已有的代码结构，设计用户编辑的command实体；在私有方法中，对于if else的使用，完全可以省略第二个esle，在满足第一个if条件后，直接return；代码看起来更美观，并且，形同的部分可以抽取成公共方法，避免出现重复代码；在设计用户编辑command对象的时候，我将所有共有的属性，抽取成了base类，然后再通过不同的场景，继承这个类然后扩展，做到了里氏原则；12.13：对用户编辑需求兼容之前的添加备注接口；由于之前考虑的不够，添加备注功能和用户编辑功能整体的逻辑是一样的，我想直接在添加备注这个接口上进行改造，而一旦改造，就意味着原来的接口不能用，将会导致自动化测试等报错，造成一定的影响，因此旧接口需要保留，重新开一个新接口，去实现功能，然后替换掉原有的接口；等配合前端改好之后，再将旧的接口下掉，做到兼容性；

12.2：梳理内容管理模块，优化了部分代码的结构，原先的异步发送邮件，已经存在了一个异步方法，就不需要自己再调用CompletableFuture去异步运行，整个项目统一代码风格。12.3：完成了不登陆留资的发布，在这次review代码后，我学到了以下要点：1、在command对象中设置默认值时，也不能使用魔法值，需要定义常量或者枚举；2、对于枚举和值的匹配，应该在枚举中提供一个根据id取值的方法；12.4：留资功能上pre后，出现了一个bug，在组装类中没有对对象进行非空判断，出现了空指针异常，导致用户数据没有推送到OCRM，我以后会注意对象的非空判断。12.5：完成了内容模板的路由设计，以及创建实体类，完成了创建页面接口。这天孙老师给我指出了一个问题，我将所有用户相关的sql都写到了一个mapper里，一开始是因为涉及其他表的sql不多，想偷点懒，但是后面用户相关的四张表都塞到了一个userMapper里，导致它非常臃肿，所以我将其他表的sql拆开，每张表对应一个mapper，这样结构就清晰明了。12.6：完成了内容模板的页面设置，将创建用户发布到pre。review创建用户这个代码的时候，我的一个查询接口没有做到通用性。在孙老师的提醒下，我学到了接口设计最好能做到以下原则：查询一般只有两个接口，一个单对象，一个列表对象，通过对象数属性去控制，否则接口越来越多，项目会很臃肿，不利于维护；

我曾经一直认为，高效率工作或者学习，是非常有必要的，这也是我喜欢写程序的原因，因为程序的效率比人类高，一个好用的程序或许能省很多时间。但是，现在，我改变了我的看法。作为一个实习生，我把分配到的活都在规定时间内干完，然后六点准时下班，然而在最近得知了自己不被领导看好的消息。我们这一共四个实习生，我总是每次准点打卡下班，而其他实习生都比我晚。或许是我分配的活比他们少，或许是其他原因，但我都保证了我的需求在规定时间内完成，甚至提前完成。我觉得至少在任务上，我是过关的。然而今天和mt聊了，他说ld不看好我，因为我每次六点准时走，从不加班（而ld也说实习生加班不做要求），然而实际情况并非如此，像mt或者其他正式员工的晋升，和工时离不开关系，在大家做的需求难度差不多的情况下，工时高就成为了晋升的标准。而我们实习生转正，工时或许成为了潜在的加分项。并且上个月，工时最高的实习生被评为了优秀实习生。我并不想说其他实习生怎么怎么样，我和他们一起吃饭，也玩的挺好。但我很痛恨这种潜在的加班内卷，毫无意义的在工位上消耗多余的时间，能让公司发展的更好吗？晋升和工时正相关，能帮公司筛选出优秀的员工吗？也许真的有人工作多需要通过加班，在规定的时间完成需求，但以现在的风气来看，这种并非多数。我曾经以为技术是晋升的标准，努力学习提升技术就能获得晋升的机会，但我现在不这么认为了。我知道公司上级只是想通过工时这种数据，让老板知道自己花的工资有价值，但这样只会让我更不热爱工作。发表一下自己的感想罢了，我不奢望能改变什么，因为我也成为了加班到八点的“优秀员工”。

建议all in春招吗？下学期不想实习，高顿这边实习一个月四千，干的正式工的活，这个工资仅仅能生存，几乎支持不了其他娱乐。转正给的还行吧，一万出头，但是没毕业应该一直都是四千。实习转正感觉能过，但是下学期要请假的话，超过三个月可能转正offer不给保留了，所以我就想干脆今年干完了明年直接all in春招了，想听听大佬们的建议。

11.25：完成不登陆留资接口开发；由于原先就存在已登录留资，和不登陆留资具体逻辑大差不差，但是考虑到可能不登陆留资后续还会添加参数等等，所以新写了个方法，将原先登录留资的部分共有的参数校验抽取成公共方法。11.26：完成创建测试环境需求，创建八个测试商品；建立测试环境主要是为了区分测试人员和正式用户的订单，因此测试商品具有正式商品一样的属性，测试人员在测试流程时就可以选择测试商品，将数据区分开。在完成这个需求的时候，我把所有学员端和后台的流程都走了一遍，也更加熟悉项目的功能结构。11.27：优化不登陆接口开发，留资推OCRM参数增加链接属性、落地页名称和链接来源；新增了推OCRM参数，要区分留资渠道是官网还是营销，如果按照之前的方法，把不登陆留资和登录留资拆开，那么两个地方都要修改，所以我梳理了一下，登录留资和不登陆留资的区别，就在于登录需要对用户进行判断，是否已经留过资，而不登陆则无需判断；除此之外，其他逻辑完全一样。思考：所以不需要写两个方法，登录和不登陆留资本质上都是留资，对于留资的处理都是一样的，只是登录需要多加一个校验，于是我将两个合并，判断如果存在uid，就进行校验，不存在就直接进行后续流程，大大简化了代码，需要增加的只有参数，以及推O那边需要做一层判断；并且我也思考了扩展性，考虑到留资只有登录和不登陆两种情况，所以目前来说我觉得这样写应该是最好的。11.28：完成后台创建用户接口，同时新增备用手机号和区号，同步到学员端和后台列表筛选；创建用户这一部分和当前学员端的注册有些区别，学员注册时只填写基础信息，后面才填写补充信息，而创建用户一次性都填写，包括非必填。因此这两部分虽然有一些共通的代码，但是目前不好抽取，后面可能需要改进。11.29：完成根据邮箱搜索学员接口和改造之前的用户变更记录保存；之前用户变更记录保存是改什么字段保存什么字段，根本不能读取什么字段发生了变更，如果每个字段都加一个属性，表结构就非常混乱。所以我统一了格式，每次保存用户变更记录时，都以user.toJson,userDetail.toJson的格式保存，读取时也可以用这种格式解析，比较前后字段就可以知道哪些字段变更，给后面的用户轨迹留一个口子。

11.18：完成学员端个人信息的对接，包括分单部分的对接。在对接分单部分的时候，由于信息沟通有误，我在订单详情页返回了订单状态，但是现在统一使用流水状态，导致学员端和后台显示不一致，因此需要修改代码；11.19：完成学员后台对接 ，在对接过程中出了点小bug，添加后台备注时如果学员已经填写了详细信息，报了个添加失败异常，原因是代码里逻辑判断有误，导致无论用户有没有填写补充信息，都走了更新，所以更新一条不存在的数据，就出现了更新失败；11.20：参加需求会，review分单相关的代码。从一开始review跟着孙老师和李老师的思路去看代码问题，到现在已经能自己看出一些问题了，并且我觉得代码review是一个很好的事，一方面可以看看别人写的规范的代码，彼此沟通；另一方面可以熟悉别人写的流程，日后也好接入11.21：梳理下个迭代的需求，拆task并估时，整理了一下缓存管理的注解，维护了一下areteup项目的缓存管理文档11.22：用户相关功能及ClassIn代码review和发布，在review代码的时候还是发现了很多问题，一些细节上的处理还是不到位，并且对于feign调用这一块的层级结构还不够清晰，经过这一次代码review，我对代码的逻辑结构以及规范上有了更深的理解。

11.11：完成学员端分单列表和详情的部分开发；思考：由于新增分单，和之前已经写好的订单逻辑有些冲突，需要重新设计，孙昕老师和李雁飞老师的设计下，将全款订单也生成一个子单信息，这样一来所有订单都可以作为子订单统一处理，而我负责的订单列表和详情也非常方便，让我感受到了技术设计的重要性，因此，在以后的开发中，我会先进行方案设计再进行开发，这样就能避免技术债务；11.12：完成学员端分单详情的开发；11.13：和前端对接分单列表和详情，新增头像审核接口，在详情页面新增了projectId，以便于前端判断项目是CFA还是大职研；思考：由于看需求不仔细，忽略了UI的重要性，导致忽略了保存头像是需要单独一个接口的，不过由于将图片审核整理到了api层，所以花费太多时间，以后会原型加上UI一起看的，以免遗漏细节；11.14：新加的订单列表展示即将逾期的订单，单独出一个接口解决：对于查找订单列表的设计，我一开始是想在代码里面做排序和筛选，但是孙老师说一条SQL就能解决，就没必要用太多代码处理，但是在后面讨论到过期时间需要加索引的时候，孙老师说当有上千万订单时，即使添加了索引也会很慢，于是还是改成了在代码里面做排序筛选。11.15：解决ClassIn出现的bug问题：ClassIn的逻辑是由吴冬辉老师之前就写好的，但是在测试的时候还是发现了bug，当用户已经在ClassIn客户端注册时，再次调用api注册，我们仍然会将他标记为首次注册；可能是我之前对接后测试的不仔细，导致出现了这个缺陷；解决：在和ClassIn售后人员沟通后，我重写了ClassIn的部分逻辑，解决了bug

11.4：完成v1.1学员端用户查询功能和部分信息变更功能的开发；出现的问题：之前已经写好了部分信息变更的逻辑，但是当时考虑欠缺，导致需要大改；解决：经过思考，理顺了逻辑，也算是把之前的代码结构优化了一下；11.5：将阿里云图像审核功能整合到代码中，完成学员端用户信息变更功能的开发；问题：官方给的sdk的demo仅仅只是一个示例，要整合到我们的代码中，还需要规范化结构化，并且需要保证client可以重复利用；解决：通过静态属性保证了client只有一个，不会重复创建链接，并且将sdk整合成了api和api实现，提供了一个通过图片url获取审核结果的接口；思考：能否用设计模式或者其他优雅的方式来编写阿里云sdk，我感觉自己写的结构并不是很好，后续通过更多的学习看能不能继续优化；11.6：完成后台给学员添加备注功能，增加补充信息，以及添加备用邮箱为后台用户列表的筛选项；问题：由于前期考虑不周，将备用邮箱放到了用户详情表，导致筛选项又需要多连一张表进行查询；解决：在孙昕老师的提醒下，我思考了用户的一些基本属性，如性别、生日，这种属性应该放到用户表中，而不是放到详情表，由于备用邮箱需要作为筛选字段，因此也放到用户表中，就可以避免多连一张表导致性能下降；11.7：完成ClassIn功能的自动化注册和发送邮件功能；问题：ClassIn需要将账号保存到第三方表，我们现在使用的账号是邮箱，而我在完成开发进行测试时发现，数据库表中存了邮箱明文，说明当时设计表时忽略了这一点；解决：增加加密字段和md5字段，新增了update接口并测试保证存到数据库的一定是密文；思考：用户相关的敏感信息（邮箱、电话）等入表一定要记得加密和md5；11.8：梳理学员端分单功能需求，梳理用户支付相关的整个流程，设计响应实体；思考：通过看李老师写的订单支付相关的代码，发现有部分共通的功能（订单完成的状态变更、通过订单编号检验流水），可以拆出来作为共有功能，方便维护和扩展，因此我以后在写代码的时候，也应该考虑，是否有部分共通的代码，可以抽取出来，或者使用设计模式让整个结构和逻辑更加清晰；

导师要求周报要写日期和思考，而不是像流水账一样寥寥几句，因此一改往常流水账风格，写成了人机周报，有些思考还挺有用的，发布到这里，后面自己还能回顾一下。后面应该每周都会更新周报了============分割线==============10.28：修改了现有代码的Assembler层的问题，同一个方法重载多次；问题：为什么不能多次重载？思考：虽然返回的是相同对象，但是功能不同，入参不同，在调用时容易混淆，因此修改方法命名，使其更加符合其功能，而不是多次重载；10.29：通过单元测试调通ClassIn自动注册接口，画了相应的时序图；问题：流程图和时序图的区别？解决：时序图主要反映时间上每个步骤的流程，结合时间更加直观，而流程图以流程为主，在较小的范围内能清晰的展示流程；思考：对于需要调用三方服务同时又有回调的功能，用时序图会更加直观；10.30：参加需求迭代会，梳理下一期迭代的需求，拆task并大致估时，同时完成前置工作，核对了业务上的一些细节；10.31：设计用户详情表等需求相关的表；问题：第三方表账号字段为什么不能以三方服务自己的名字命名？解决：如果以三方的服务命名，那么当再次接入一个服务时，又要新增字段，每一次增加服务都要新增字段，不便于维护，且数据也会不整洁，会出现某个用户这个字段有值而另一个字段没值，每个用户的数据的结构不一致；思考：第三方账号表设计应该具备通用性，对于不同的三方服务，统一用来源表示，更加容易维护和扩展；11.1：调研阿里云图像审核的前置工作，了解如何使用并且需要哪些参数，这些参数的含义，都写入了技术文档；文档比较清晰，一些疑惑的点也都问了客服，通过示例代码了解了使用方法，没有什么问题；

如何获得一个海外手机号？还有怎么在国内注册meta开发者，meta旗下的产品api基本都要开发者账号进行测试，然后开发者账号又需要海外手机号注册，现在国内手机已经收不到国外的短信了，咋整，求助！

如果你是一个苦恼于优化程序的程序员，那就来for门吧。在这里，我们解放大脑，将所有问题抛给for。如果你在算法上遇到了难题，那就用for；如果你在业务上遇到了难题，那就用for…程序中，没有for循环解决不了的问题，如果有，那就再加一层for循环。欢迎加入for门！让我们信仰for，成为for！for门！

9.14出来的bug，有没有大佬知道是咋回事

更新：9.13挂部门是网易云音乐部门，面试官一上来就跟我介绍了部门的业务。是做推荐这块的业务，就是网易云主页的推荐的音乐，他说会根据推荐算法计算出来的画像来推荐，然后部门就做一些数据的处理。说一下题外话，我发现面试我的面试官都很喜欢问我项目。题外话结束，面试官一上来和我聊了部门业务，聊完后说走一下固定流程，做自我介绍。1、你这个精研社是一个什么背景？上线了吗？用的技术栈很多啊，都有用到吗？一一介绍一下吧。（我自己简历上写的哪些技术栈记不太清了，只有一点印象，简单说了一下吧。这里还是比较煎熬的，说一下Mysql存了哪些数据，为什么要用mongoDB，redis存了什么数据等等）2、你...