作为一名IT工程师，特别是偏向服务型的稳定产品，其实更多的工作是> 解决问题和熟悉业务的过程，那么日常工作中，你是偏向于解决问题，> 还是偏向熟悉代码，次而解决问题？
实际的工作场景
服务型的稳定产品，例如医疗系统：服务医院，方便患者就医，提高医院工作效率，就是一个服务型系统。当你作为一个小白入职公司时，如果想短时间掌握产品的业务代码框架（从业务的分类去看产品框架代码），是有点时间的距离。但是在实际的工作中，我们已经快速投入实际工作中，我们已经开始去解决问题，技术支持，现场实施。一般3个月我已经对于工作得心应手，我们会慢慢忽略业务代码结构，因为的工作经验可以让我们快速找到问题节点，从而破解问题。特别很多问题是因为配置或者设置问题造成。故而代码结构问题我们会忽略。
工作中常见问题
- 1年后，如果让你写一套你们系统的简洁版。你会发现无从下手，碰到棘手的问题，也许要重头看业务代码，从而解决问题。
- 缺少全揽的认知，自己在工作领域没有一个高度的认知，工作趋于重复化，自身价值在贬值
- 公司来新人后，新人来问你涉及业务的问题，你有时会不知怎么回答。因为他问的不是如何解决问题，因为新人对业务不熟悉，他们往往问的是代码结构的问题。
- 当需要你在现场部署系统时，你会遇到各种问题。（例如医院自助机），因为你没有对系统代码结构没有全揽的认识，所有缺少技术支撑。
- 日常开发中，缺失代码高质量开发
- 系统的团队往往是一个人独自撑起，而其他人无法独当一面
偏向代码对公司内部团队建设的利
- 每个人对系统都有高度的共同认知
- 每个人都可以独挡一面，显示实施都是一把好手
- 解决问题更加快速
- 无论人员的流失，都不会造成团队的高质量结合。
- 每个成员在工作中都能找到自己的定位，而非只是简单的工作，只是去解决问题。
- 每个人员都敢于提出问题，解决问题。
这是我对于一个系统团队建设的认知。
