工作和代码-- 你是偏向于工作,还是偏向于代码

作为一名IT工程师,特别是偏向服务型的稳定产品,其实更多的工作是> 解决问题和熟悉业务的过程,那么日常工作中,你是偏向于解决问题,> 还是偏向熟悉代码,次而解决问题?

实际的工作场景

服务型的稳定产品,例如医疗系统:服务医院,方便患者就医,提高医院工作效率,就是一个服务型系统。当你作为一个小白入职公司时,如果想短时间掌握产品的业务代码框架(从业务的分类去看产品框架代码),是有点时间的距离。但是在实际的工作中,我们已经快速投入实际工作中,我们已经开始去解决问题,技术支持,现场实施。一般3个月我已经对于工作得心应手,我们会慢慢忽略业务代码结构,因为的工作经验可以让我们快速找到问题节点,从而破解问题。特别很多问题是因为配置或者设置问题造成。故而代码结构问题我们会忽略。

工作中常见问题

  • 1年后,如果让你写一套你们系统的简洁版。你会发现无从下手,碰到棘手的问题,也许要重头看业务代码,从而解决问题。
  • 缺少全揽的认知,自己在工作领域没有一个高度的认知,工作趋于重复化,自身价值在贬值
  • 公司来新人后,新人来问你涉及业务的问题,你有时会不知怎么回答。因为他问的不是如何解决问题,因为新人对业务不熟悉,他们往往问的是代码结构的问题。
  • 当需要你在现场部署系统时,你会遇到各种问题。(例如医院自助机),因为你没有对系统代码结构没有全揽的认识,所有缺少技术支撑。
  • 日常开发中,缺失代码高质量开发
  • 系统的团队往往是一个人独自撑起,而其他人无法独当一面

偏向代码对公司内部团队建设的利

  • 每个人对系统都有高度的共同认知
  • 每个人都可以独挡一面,显示实施都是一把好手
  • 解决问题更加快速
  • 无论人员的流失,都不会造成团队的高质量结合。
  • 每个成员在工作中都能找到自己的定位,而非只是简单的工作,只是去解决问题。
  • 每个人员都敢于提出问题,解决问题。

这是我对于一个系统团队建设的认知。

你可能感兴趣的:(工作和代码-- 你是偏向于工作,还是偏向于代码)