2023年中总结，全栈工程师在深圳工作6年后的一些杂谈

今天是2023上半年的最后一天，刚好也是我在深圳一家公司的第6年，2017年6月我入职现在这家公司，到如今整好是6年。世事变迁，在这个6月回想6年前的6月，是怎样一番情愫呢。

6年前不同如今，那是一个很好找工作的年份，没有什么L型增长的经济，大环境滋润着众多中小企业如雨后春笋一般冒头，行业内大多数人都充满希望。但我在那时候找起工作来依然是十分困苦，四处奔走，因为我，遇到了各种各样的小公司。不过我发现一个特别之处，我与医疗行业十分有缘分，2016年3月就在北京朝阳三间房乡入职的一家企业也为医疗单位服务，虽然是我不大感兴趣的医疗咨询，并非医疗系统，但也引发了我对从事医疗系统服务的向往，没想到一年多之后来到深圳，真的如愿以偿了，在如今这家公司做了整整6年的HIS。

当然了即便是6年前，我也不可能根据自己的偏好去寻找工作，能找一份工作就心满意足，能找到匹配自己喜爱的业务场景，实在是一种幸运。当时我想的是，无论是什么行业只要是做erp类型的软件，都适配于我当时所掌握的一些技能。简单描述就是这类系统注重模块之间复杂的关系，并不需要担心什么高并发场景，笼统的说这也就是b2b的特性（与这些年网络上流行的技术路线b2c截然相反），我一直认为这种方式才比较锻炼复杂而抽象、又要能够连续下去的思维能力，这符合我长期对复杂系统的想象。当然了，面对这些模块比较多也比较杂乱的系统，很难快速响应其中一点，有时候定位一个问题都比较困难，这需要消耗不停的消耗耐心。即便是很有耐心的人，心力也会逐渐被消磨掉，就如同深圳的夏天，即便绿化很好，路上常常有树荫，但真要走一走，仍然是热到冒汗。

对版本控制的一些简言

6年前刚进现在的公司，最让我惊讶的是完全没有版本控制？！只通过ssh的scp文件拷贝来合并，好在我进入公司之后不久，由于开发进度的深入，就开始使用git与github private了。但通过这一短暂的时光，我深刻的体会到版本控制的重要性，表面上看，版本控制只是解决团队协作、文件合并的问题，在模块高度分离，负责明确的前期阶段，确实很难感受到版本控制的作用，只会感觉到多了一层麻烦。但他有很多的隐藏的好处，是很多人没有说明的，下面简单概括几点：

• 标记与溯源，很多时候只要通过提交信息，就能知道一块老代码的前世今生，即便信息粗糙，只要有提交的时间，就能对应上很多其他的信息，例如项目管理面板的bug列表、任务列表，亦或是聊天记录、邮件、保存的图片，通过这样的方式对应上，就能回答这样几个问题，何时新增的模块？ 新增模块的初衷可能是什么？ 修改的目的是什么？
• 上下文，一个提交除了一个代码段，还可能包括其他的文件，以及他前后的一些提交内容，这些信息是很丰富的，它们可以回答这样的问题，这段代码修改的前后都在做什么？ 这段修改是否可能是因为类似全局替换的批量处理，或是错误的格式化等意外导致的错误？
• 还原，或许你经常能听到这种抱怨，这个功能花费了好大精力快做完了，用户却要把整个功能设计推倒重来，这无疑是需要撤回一整个提交的，但你可能会想在项目的早期阶段很难发生这种事情，所以拖一段时间再加入版本控制也无所谓。但可能还有一种情况，没有外界的任何干预，一个功能卡在了最终阶段，在这个功能尚未结束的情况下，项目其他很多地方都没办法运行，此时急需进行一个阶段性的演示，这时你就不得不看看这个功能到底牵扯了哪些部分，没有版本控制的帮助，很难快速的只通过代码本身的上下文找到这些需要中止的部分。

这些虽然都是不多见的场景，但我都曾遇到过，如果没有版本控制几乎无从下手解决这些事项，版本控制是需要长期的使用才能感受到它的好处，它甚至不一定需要在有团队合作的场景下使用，即便是你一个人做的玩具项目，或是独立开发的小插件，都能避免这样的问题。但它们不是一时能体验到的，千万不要因为一些小麻烦而错过这么多解决小问题的预防性措施，用git并不一定要提交到一个centre，即便是全程都在本地使用，都能感受到许多益处，所以一个项目应该尽快从速的加入版本控制，不要等到有合并的需求才加入。

版本控制就像道路，不要觉得他只是为拼合一个集体而生，只有人多了才需要修路，其实只要是需要车辆通过，哪怕是一天只会通过一辆车，有条道路也比没有强一些。

多解决棘手问题了解一些极为罕见的意外情况

曾经看过这样的科普，硬盘会被环境噪声影响，速度会降低，寿命会减少，我想如果我遇到这样的问题一定不会想到是噪声的问题，因为环境噪声能严重到干扰硬盘设备，可能像因为吃香蕉而辐射超标一样不现实，但我却真实的遇到了一次极为罕见的意外情况：

Chrome语法检查插件Grammarly曾备受推崇，我在油管见过好多次他的广告，但我并没有尝试，没想到它却依然走入了我的视野，众所周知面对单词或语法错误的输入框，他会显示出一个类似于tooltip的悬浮块来提醒用户，但它却很神奇的影响了kendo前端框架的富文本输入框，会导致其高度发生变化，甚至遮盖下方的元素，用户完全无法正常使用，我百思不得其解，最终通过用户的截图发现这个插件，自己安装了一试，发现了问题，原来Chrome插件是真的会影响页面功能的。

遇到这样的情况当然是运气不好，但不能不有一些大胆的假象，如果完全不敢设想极端情况，只去寻找自身的常规的问题，那是很难解决问题的。

也不要害怕棘手的问题，如果能解决，自然可以向所有人分享自己的经验获得分享的快乐。就算最终解决不了，也可以成为一桩值得回味的悬案，就像一个开放式结局的小故事值得他人解读。

持续跟进社群的走向

这一点是毋容置疑的，最直接的影响就是技术路线的更新迭代，如果自己用于开发的语言、平台、框架本身已经没落，官方停止支持，那自然是要学习其他代替品的，但这个没落也分等级，像Flash、Visual Basic&VBScript、Windows Phone、.NET Framework&WinForm、Angular.js 1.x、属于已经宣告死亡的产品，是绝对要抽身的。而像PHP、CoffeeScript、Delphi、Memcached，是很多年前就被替代品取代但仍然被一些坚持的人维护着，这还是有些区别的，前者就算真的很热爱也无力挽救了，后者还可以倔强下去。但无论是哪种，都要面对下面几个问题：

• 即便是大多数人都不用了，也总会有维护性的需求在吧？
  • 并不可取，说不定某一天就要换新系统，维护性需求消失，不学点新的怎么能行呢，而且很多新技术变化并非翻天覆地，只要慢慢的接触，消除掉陌生感，就会自然的对新技术越来越感兴趣。
• 所处的公司业务体系庞大，短时间内很难更新技术，即便是要更新，到时候再学就是了。
  • 任务到面前了才开始学，时间够吗，现在很多产品开发周期越来越快，仓促之间错误一定不会少，后面还能改善这些错误呢？会不会需要很大的代价，并且引出更多的错误？技术栈一定要提前布局
• 新技术虽然用的人很多，但占用大、而且看上去只能做些简单的东西，恐怕做不了太复杂的需求，卡在替代过程中的某个位置就白费力气了。
  • 很多框架占用内存确实较大，但现在用户的设备越来越好，完全是有条件的，而且底层设计完善，占用的增加可能并非线性的，而是随着开发进度趋于平缓。如果认为做不了复杂需求，就应该看一下用例，甚至是我们所使用的工具，像掘金本身是Vue和Element-UI做的，如果你关注AI，你就会发现OpenAI官网也用了Vue，这就很给人信心。

即便许多年后也许离开了软件开发的行业，十余年后回顾这段历程，都找不到有人聊自己用过的技术，成为了一个完全的死话题，也无从向后来者介绍从前的开发经历与故事，是否会像一个孤寡老人一样无助呢，所以说为了自己的历程与故事，也要不断了解和学习新的技术，新技术的发展也并非需要天天了解，如今很多流行的技术其实也已经存在了七八年了，如果真的热爱，就值得持续的关注，并不占用多少时间，向后来者讲述技术演化的细节，每个人都会有自己独特的故事，这是其他媒体无法讲述的。

未完待续