自我介绍

哈喽，大家好。首先在开篇之前我想先自己介绍一下，我叫一笑，大家也可以叫我小舒。是一名又菜又爱写代码的Java程序员。当然这个也是我目前的一个想法，可以后期也可能想着去写一下其他的语言。介绍完成之后也就是单纯的想通过这种方式来记录一下自己的开发生活。也算是给想进入这个行业或者说从事这个行业不同领域的其他小伙伴们看看我这个领域是什么样子的。

正文的开始

关于这个话题，我想到了一句话那就是人生就好比是一场电影，但是却没有彩排，每天都在现场直播。所以关于记录这种生活的方式，我想给他起一个名字那就叫《一笑的大型连续剧》以周周总结的方式呈现给大家，当然我也想记录一下自己成长的痕迹。然后本部剧的导演和演员比较单一，就是我本人舒一笑哈哈哈。

本周是完成了关于绩效面谈模块的基本开发，但是却也存在了许多问题，当然从这个当中也让我将自己学习到的知识也做出了一些实践的总结和经验想在下面分享给大家。

时间

2023年8月28-2023年9月1日

本周的工作总结

完成情况

本周算是我正式开发职业生涯中接手的第一个模块，完成对绩效面谈模块的基本流程的开发，流程的对象是绩效专责、绩效经理、绩效员工三大角色。主要完成对员工考核的流程开发。今天下班还有11个BUG，感慨一下真的是人如头像，我要加班了。

存在的问题

由于对业务中概念理解和目前管理员工模块数据库设计落地的理解不清晰，导致自己在全部启动时候使用代码去落实业务逻辑时候出现了混乱。本来写的就是根据考核关系表中的是否考核和绩效经理对应的字段去实现流程启动。但是却由于对绩效兼职理解不清晰，误认为绩效兼职就是绩效经理，部门负责人是直接上级领导。导致本来正确的逻辑是直接去考核关系表中根据当前专责登录的单位编码直接去考核关系表中查找该单位要考核的员工，然后根据要考核的员工去找到员工的绩效经理然后去生成待办信息以及他们的面谈记录。我却把正确的一版写法改写成根据当前登录专责的单位编码去查找该单位下的部门，然后根据部门的负责人，然后根据负责人编码去查找哪些人是归属于他下面要考核的。所以这边便出现了几个问题。

问题一：按照我错误的写法来说，绩效经理找到之后也启动了待办相当于我也给了面谈的数据记录，但实际上是不需要的，因为整个面谈模块的考核对象就是员工。

问题二：绩效面谈中的面谈人员是存在是否考核的业务属性的，与此同时这里也存在部门是否考核的属性。两者是两个概念，并没有直接的关联关系。简单说就是部门不考核，不意味着该部门下的员工也不考核。所以这里出现了当时和产品交涉的时候，业务概念理解出现偏差，产品说过直接取部门下的人员去考核，取到谁就是谁不用管是否考核，导致最终成品快写完的时候又说要考核员工才能启动考核。这样子口头的描述最终就说不清楚，导致出现问题。

问题三：有一点不可否认的是产品对这里负责的这个模块自身就没有清晰且深刻的业务知识的理解，导致自己在讲述相关概念的时候存在问题。然后由于自身也在不断累加对此块业务的理解，但是却并没有落实到文档。或者有时候落实到文档里面描述的也不是很清晰。比如说需要最新的周期，那么这个感性的最新到底指的是什么，存在二义性。不同人有不同的理解。还有比如说文档中有描述根据周期从上到下从近到远。那考核周期是分年、季度、月度。这个是如何体现没有详细的描述。

改进点

1. 针对上述的第一点问题，我觉得可以从以下几点入手

   第一点：首先问题肯定是从自身找原因，加强自己的语言沟通能力，为此我买了一般书《非暴力沟通》。有时候可能确实是产品设计的有问题，但是我不能直接语气直接就是否认他的设计。委婉的方式来旁敲侧击，将设计问问其他资深开发来看看这个设计是否有问题。

   第二点：下次接手新的业务模块之前，一定要产品提前给出功能设计的概要文档。不然直接给你演示原型图是什么样，没有一个初步的业务知识理解。去看他给你演示的原型图就会看不懂。话说回来原型图绘制的连贯性也不是很友好。

   第三点：关于产品文档落实不及时，我想可以通过询问的方式，当他觉得我问的烦了，自然而然就乖乖写文档了。要是他说我和你说过了你怎么还不知道，那我就说我还要写代码，还要构思技术实现。我也有很多事情要做，所以要是忘记了文档又没有说，只能来问你了。