某公司计算机算法体系架构

当前笔者主要从事的是供应链2B方向的工程职位. 简单说一下我对于当前公司的一些思考和对公司基础能力建设的一些想法.

1. 个人思考

1. 我个人认为所有的工程职位只有两种类型. 一种是为其他人员(如算法同学, 其他工程同学, 管理同学)进行能力上的支撑. 另一种是为针对业务需要对于实际的业务进行功能的开发.

   1. 对于其他同学做支撑的工作:

      对于这些同学的工作我举个简单的例子: Docker, Hive, MavenRepo, MySQL, Redis, S3, ES, Git, DepOps等工程中常见的组件或者工具的平台化. 对于一些在算法或者管理上常见的流程进行平台化: 如 对于审批流程的平台化, 对于算法迭代的平台化, 对于上线流程的平台化.

      这些同学的任务的主要目的是根据已有业务中的共性组件, 抽象出公用的平台, 简化传入传出的接口. 对于开源组件进行定制化. 加快工程开发, 算法开发, 项目管理的人效. (帮助裁员(误)hhhh)

      由于这部分工作的使用者和开发者都是工程人员, 甚至有的就在同一个项目组, 所以不太需要设立专门的需求设计岗, 而是由工程人员针对日常工作中的痛点进行项目的设计和开发. 这部分工作的压力并不算大(因为是针对现有系统的痛点, 不是从零到一的关系而是锦上添花的关系), 但是这部分工作却是一个公司在代码开发上竞争力的核心体现

   2. 对于业务需要进行功能的开发:

      这部分的工作其实不止局限于工程同学, 还有很大一部分算法同学是在进行这方面工作的开发.

      这部分的工作的实际使用人是项目组外部人员, 或者说是不会编程的人员. 这部分工作一般需要精通项目应用环境的产品设计人员对于后续项目提出自己的需求和看法, 然后由开发人员使用上一步骤同学们开发的组件进行快速的实现以及上线.

      由于这部分工作和实际因为紧密相关, 所以其工作量和压力和项目的应用场景, 生命周期阶段直接相关. 在项目处于攻城略地的拓荒场景时, 会出现大量紧急的需求开发以及加班熬夜. 当项目进入平稳期后这类型的工作量可能会相对减轻. 但是随着针对当前项目的工具平台(也就是上面那种工作内容的成果)的逐渐完善, 对于业务功能进行开发的工作也逐渐成为固定动作一般的流水线工作.

      (所以这部分开发工作在后期工作中很难有什么对自己的提升, 要么选择转换工作方向要么进行沉淀, 多读书多学习)

   3. 对于以上这两个工作方向我个人的思考

      计算机打工人的工作任务不是单一的, 随着业务的发展以及个人岗位的调用, 一个人会在不同时间进行以上两种方向的开发