2023年年终总结 —— 致满载荣誉或满脸惆怅的你

 开篇请允许我引用歌曲《西楼儿女》的一句歌词：

陌生的朋友你请听我讲，许多年前我也曾有梦想，想过满载荣誉回到家乡，这肆意的风压弯了海棠。

         2023年即将过去，不管你这一年经历了多少，或是职场的得心应手、情场的春风得意，或是工作抑郁不得志、生活中的人间疾苦，这一切终将成为历史，成为我们人生中平凡却无可替代的2023年。

        2023年年初，公司任命我为开发部的总监，管理开发部的日常工作，并向总经理做工作汇报。2023年是忙碌的一年，几乎没有属于自己的时间，博客也停更了一年，可怜的只写了4篇学习前端的技术博客，相比前2年的博客量简直惨不忍睹。这里我介绍一下背景：

        2021年我从上家辞职，入职了现在这家公司。也就是在2021年，我发表了130多篇技术博客，记录了毕业以来所接触到的编程技术，粗略统计了一下，超过100万字。当然，也包括部分核心代码。疯狂的写原创博客并不是为了评选博客之星，也不是为了涨人气涨粉丝，也不会开通付费专栏，因为世界上最珍贵的东西往往是免费的，而是想记录自己的成长历程，分享学习的成果与大家探讨，也方便自己日后的温故而知新。

       面试这家公司的时候，和技术总监简单沟通后，技术总监觉得我个人还不错，不管是在技术研究程度还是与人相处的过程，都是他一直想找的那个人，立马答应录用了我。说起面试，我待过为数不多的公司都是很顺利的通过，换工作基本上面1~2次就可以入职了。技巧是跟面试官讨论问题的时候，能给出一些个人的解决方案，且不管对错，起码让他觉得你思考过，有主见，对问题有跟进，这一点是非常珍贵的品质的。

       2021年入职这家公司，职位是Java高级工程师，开始了“内卷”的A计划：

• 了解公司在做的业务，翻阅相关文档，熟悉业务系统，询问其他同事，自己利用业余时间（晚上、周末）阅读整套技术架构。
• 了解开发部目前存在的所有问题，包括：代码问题、数据库问题、运维问题，业务系统问题，并提出个人的解决方案。
• 编写开发部内部的技术文档，把自己了解到的业务流程、代码结构、数据库优化方案、运维操作手册等写成文档，在开发部内部讲解。

        3个月后转正，拿到了优秀员工奖。2021年的年会上，拿到了最佳新人奖。从2021年到现在的2023年，2年多的时间里，拿到过很多次奖，当然，也包括比较丰厚的奖金。以前待过的公司也拿过很多荣誉，包括在大学期间也保持着每年拿奖学金的记录，毕业设计做的是安卓点餐系统拿到了当年的优秀毕业生。虽然待过的公司都不是大公司，大学也不是985、211名校，也曾问过自己拿到这些荣誉的含金量到底多少。

当凤尾，还是鸡头？

意思是在一群厉害的人当中做一个普通人，还是在普通人群中做出类拔萃的那个

        从大学毕业进入职场以来将近8年里，我还保持着0迟到的记录。在深圳这座大城市，交通在上下班高峰期是非常拥堵的，我一般都会提前15~20分钟到公司打卡，偶尔遇到地铁故障，也能赶上打卡。有人觉得这些事情没意义，也会让自己变得很累。然而对于我来说，对自己保持高要求，保持一颗自驱心比任何外界的约束都重要，打卡只是其中的一个小事。另外我的口头禅是：有些事情早做晚做都要做的，那就早点做。

        2023年的开年，公司领导征求我的意见后，决定任命我为开发部总监，管理整个开发部。对于我来说，从一个开发者到一个管理者的角色转变，不仅仅要处理好日常的开发工作（因为后端开发并不多），还要处理和协调部门的各种事情。公司是创业型公司，开发部有20人左右，分前端组、后端组、移动端组、大屏组、运维组，同时还需要跟其他部门沟通协调。公司是做 SAAS 业务的，会有很多个项目，每个项目都有定制化需求。前所未有的挑战一下子到来，现在回头看看，并不是保持一颗赤子之心就能把事情做好。遇到的困难主要有以下几种：

1. 有一部分老员工不太服从管理，不想改变现状，不愿走出舒适区，摆烂、混日子。
2. 很多部门对开发部有意见，觉得拿高薪不干活，项目经常延期，矛头大部分指向开发部。
3. 项目进度管理混乱，包括：进度管理混乱、任务分配混乱、代码分支管理混乱、上生产环境随意经常造成生产事故、项目组内缺乏有效沟通、风险问题无人跟进。
4. 代码编写凌乱，硬编码很多，不写代码备注，不写解决思路，日志不打印或者随意打印，相同的处理逻辑出现多次，代码冗余度高、耦合度高。
5. 因为没有奖惩制度，所以每个人都可以跟领导顶嘴，不按规矩做事，边界不清楚的事情从不关心和主动处理，在整个公司内推脱责任蔚然成风。

        上任后，我在开发部开了一次会，明确每个人在公司扮演的角色和应做的事情，会上大家都客客气气的，会后还是打回原形。有人支持，也有人不以为然、无动于衷。如果采取强硬的态度要求他们在工作中执行任务，显然在短期内是不会奏效的，甚至会引起少数人的反感情绪，导致工作无法顺利安排下去。想要别人信服你，就得拿出真枪实弹的真本事。从现在回头看看，这一年的管理比以往有了很大的改善，主要做的措施如下：

1、制定项目进度管理表。把公司要做的项目列成表格，把项目要参与的所有人员都录入进去，明确每个人的工作任务，并给出工作完成的大概时间，时间的评估需要具体开发人员、开发总监、产品经理、测试人员达成一致。确定每个项目组的开发组长，由开发组长把控整个项目的进度，每周定期开项目进度会议，会议中需要提出项目存在的风险，如果在规定的时间内没能完成工作任务，需要自主无条件加班。在项目进行的过程中，很容易就知道瓶颈出现在哪个人身上，在“木桶效应”的驱动下，项目的进度得到了良好的把控。

2、建立开发部知识共享库。鼓励更多的开发人员养成写技术文档的好习惯，技术文档包括日常遇到的问题修复思路、关键业务流程解读、平时工作踩到的坑以及解决过程、学到的新技术引入到实际项目中等。我为人人，人人为我，只有每个人都乐于奉献，才会形成良好的学习环境。虽然在实施过程中，只有少数人会写技术文档，已经是良好的开端。只能说人各有志，不能要求每个人都有奉献精神，我们仍要感谢那些默默贡献自己的人。

3、规范代码编写风格。参考阿里巴巴开发手册，要求开发人员至少要做到50%，比如基本的：函数要写明白用途、关键代码必须要有注释。同时不定时抽查代码，把不按规矩做事的截图出来，加以提醒。把项目开发过程中的所有资料（包括需求文档、数据库设计文档、升级配置文档、问题汇总文档）放在项目下的代码仓库，方便大家查阅，不用到处去寻找文档。

4、规范代码分支管理。因为公司是做 SAAS 业务，会有很多项目定制化开发，今年开始做标准化产品，因此会有很多个迭代在同时进行。为了避免多个版本迭代之间不冲突，所以制定了代码分支管理。大致的思路如下：

2、流程说明2.1 开发环节1、L1 需求的后端开发负责人从【prod】切出一个分支，如：【dev-L1】分支做开发，对应图中【1、checkout】操作。2、L2 需求的后端开发负责人从【prod】切出一个分支，如：【dev-L2】分支做开发，对应图中【1#、checkout】操作。3、【dev-L1】分支和【dev-L2】分支要先合并到【dev】分支才能构建到【开发服务器】，对应图中【2、merge】和【2#、merge】操作。4、后端开发人员使用【dev】分支构建到【开发服务器】给其它端联调，对应图中【3、build】和【3#、build】操作。5、目前【dev】分支放开合并权限，由开发人员自己把控。2.2、测试环节1、如果 L1 率先完成联调要提测，需要先把【test】分支合并到 【dev-L1】分支，解决可能存在的代码冲突问题，对应图中【4、merge】操作。2、开发 L1 的后端人员使用【dev-L1】分支构建到【测试服务器】给测试团队测试，对应图中【5、build】操作。3、如果 L2 需要提测，且与 L1 的测试时间不重合，需要先把【test】分支合并到 【dev-L2】分支，解决可能存在的代码冲突问题，对应图中【4#、merge】操作。4、开发 L2 的后端人员使用【dev-L2】分支构建到【测试服务器】给测试团队测试，对应图中【5#、build】操作。重点关注：5、如果在测试 L1 过程中，L2 也进入测试环节，把 【dev-L1】和【dev-L2】2个分支合并到【dev】分支，用【dev】分支构建到【测试服务器】一起测试，对应图中【L1 & L2】操作。2.3、验收环节验收环节需要提工单，工单中把需要的每个微服务对应的哈希值、配置文件、数据库脚本等信息体现出来。1、如果 L1 率先完成测试，要给到产品部验收，需要先把【dev-L1】分支合并到 【test】分支，对应图中【6、merge】操作。2、使用【test】分支构建生成哈希值，再拿到【预发布服务器】构建给产品验收，对应图中【7、build】操作。3、在验收 L1 需求的过程中如果要修复bug，需要先把【dev-L1】分支合并到 【test】分支，使用【test】分支构建生成哈希值，再拿到【预发布服务器】构建。即重复【6、merge】和【7、build】操作。4、同样的，L2 的验收流程与 L1 的相同，即重复【6#、merge】和【7#、build】操作。重点关注：5、如果 L1 已经验收完成，但是没上线，这时候 L2 也进入验收环节，怎么办？回答：这时候就要跟产品部沟通清楚，要么先上线 L1 的需求，再验收 L2 的需求；要么等 L2 验收完成后，再一起上线 L1 和 L2 的需求。或者把 L1 在预发布的哈希值记录下来，需要上线的时候直接在生产环境构建，对应图中【8，build】操作。2.4、上线环节1、如果 L1 完成验收要上线，直接使用【预发布服务器】所对应的哈希值构建即可，确保预发布环境和生产环境代码保持一致。对应图中【8，build】和【8#，build】操作。2、上线完成，开发人员需要把【test】分支合并【prod】分支中。对应图中【9，merge】和【9#，merge】操作。2.5 生产出现日常 bug1、生产环境出现日常 bug 且不属于某次需求迭代，需要单独从【prod】分支切出一个专门修复 bug 的分支（如：bug-20231109），对应图中【1*、checkout】操作。2、修改好之后合并该分支到【prod】分支，对应图中【2*、merge】操作。然后在【预发布环境】构建测试，对应图中【3*.build】操作。3、bug 在【预发布服务器】测试通过后，要上线，直接使用【预发布服务器】对应的哈希值构建到生产环境即可，对应图中【4*、build】操作。4、上线完成后，开发人员需要把【prod】分支合并到【test】分支中，对应图中【5*、merge】操作。否则极易造成代码缺失，bug 反复出现的情况。2.6 生产出现 bug 且属于某次迭代1、某次迭代上线中发现生产出现 bug（如 L1 迭代，使用分支 dev-L1），直接使用该迭代对应的分支修复问题，合并代码到【test】分支，在【测试服务器】和【预发布服务器】构建并验证，验证通过后，直接使用对应的哈希值构建到生产环境即可。2、上线完成后，开发人员需要把【test】分支合并【prod】这 2 个分支中。对应图中【8，merge】操作。

5、搭建新的技术框架。公司以前做的项目比较小，都是单体服务，随着业务的发展，很多数据结构已经不能满足客户的需求，因此必须要进行重构。虽然开源的项目很多，比如若依框架，但是跟公司的业务不太匹配。从2022年9月份开始，我就着手搭建新架构，采用主流的SpringCloud 组件和其他优秀的、主流的开源组件，并参考优秀的开源架构设计思路，设计了一套适合公司业务发展的新架构。

6、关键业务开发人员一主一备。对员工的管理瓶颈一部分还出现在某些岗位是“独角兽”，一旦这个员工请假，开发进度就会收到影响。甚至有时候生产环境出现bug，员工不在岗，也是很难安排其他同事来处理。为了消除这个隐患，在关键业务开发上，采用了混合开发模式，也就是一主一备。比如这次迭代用户管理是张三做，下次版本迭代就安排李四做。这样张三和李四都熟悉了这个业务。也有很多人提出质疑：让某个开发一直做某一块业务不是更快、更缩短开发周期吗？我个人认为：如果一家公司某个员工无人可以替代，那么这家公司的管理就是混乱的。因为一旦这个员工请假、离职或者有事情无法顺利开展工作，公司的业务就会受到影响。这不就是微服务架构中经常提到的一主一备的思想吗？

7、招聘新人替换旧人。一个公司要有适当的人员流动，才有源源不断的活力。如果一直让不思进取的人占着一个坑，安排工作就会受阻，还有很多抱怨，那还不如招一个应届毕业生过来做一些 CRUD 的事，不仅便宜还好用，合适的人在合适的岗位。达尔文进化论告诉我们：适者生存。非洲大草原上，每天都有动物在为生存而奔跑，或是为了逃命，或是为了饱腹。在大环境不好的情况下，每家公司都在降本增效，如果一个人长期待在舒适区，没有居安思危的意识，终究会被淘汰。尤其像深圳这种大城市，只相信汗水，不相信泪水。正如足球诗人贺炜说的：“请不要相信胜利就像山坡上的蒲公英一样唾手可得，但是请相信：世上总有一些美好值得我们全力以赴，哪怕粉身碎骨！”

8、推出加班零食福利。利用月度优秀员工奖，腾出一部分资金用来购买零食，作为加班的福利。很多情况下，在深圳的科技公司下班后继续工作1个小时已是常态，让大家不再饿着肚子加班。很多时候，员工的心理需求只是一些小恩小惠，作为管理者，有理由与大家并肩作战。

         这里推荐一段个人剪辑的经典语录视频，希望在寒冷的冬天给你带来一份暖意：

        2023年是筚路蓝缕的一年，是从普通开发到管理蜕变的一年，是历练、是成长的一年。这一年的夜以继日，这一年的静夜思考，这一年的心路历程，局中人才了解。也曾彷徨，也曾迷茫，但是幸运的是都坚持了下来。

        2024年龙年即将到来，工作重心会更偏向于项目进度的管理和架构的优化，把更多开源的优秀的组件引入进来，提高架构的稳定性和实用性，把公司的业务水平往更高层次打磨，把工作中遇到的常见错误和解决思路分享出来，继往开来，走进新的人生阶段。

        从另外一个角度看，或许根本就没有管理可言，只是一个小人物在做好分内的事情罢了。正如《临江仙·滚滚长江东逝水》所言：

滚滚长江东逝水，浪花淘尽英雄，是非成败转头空。青山依旧在，几度夕阳红。
白发渔樵江渚上，惯看秋月春风，一壶浊酒喜相逢。古今多少事，都付笑谈中。