转眼已半年，回头看看，总有一些成长和不足
北森，可以说是自己的选择。想想当初，为什么要换工作
第一:成长瓶颈，当初成为新进leader，却不懂得如何带领团队工作、带领团队成长。
第二:技术瓶颈，面临业务的逐步发展、时代的发展，传统软件行业遇到很多技术瓶颈，首先就是国企特有的私有化部署向云方向转变，软件供应商则面临多租户数据隔离。当初却没有看到SaaS的交付模式及企业预约的方向。
第三:平台瓶颈，随着企业个性化内容越来越多，除特有的统一功能模块以外，每面临一个客户的需求定制和细节变动，都会产生很多对代码侵入性很强的差异设计，例如多层if else等。当时没有看到PaaS的产品强大之处
第四:架构瓶颈，随着业务的发展，领域的增长越来越多，面对不通领域间的业务拆解，会划分不同的微服务，而相对应的服务的注册、服务间的发展、服务间的调用、事务一致性、数据的存储结构、高频访问的服务如何自动扩容，以及一套完整的DevOps(代码开发，代码库规范，分支使用规范，代码编译，代码部署，自动同步，及代码回滚等一套自动交付流程)、链路追踪、自动化运维等，都是当时所仅了解的皮毛，需要找一个成熟的企业来答疑这些问题。知其然不知其所以然是很可怕的。
面对这些问题，开始寻找适合自己的平台。那么同时，又面临到成都发展的自身需求，选择了完全适合自己的北森。当入职以后，更加觉得北森和自己的当下完美契合。
那接下来说说自己在北森的半年成长。
成长最快的办法是实践，思想增长最快的办法是看书，而自我内容最深刻的记忆就是文字。我自身还有一个自己的方法论，观察，观察自己的直属leader管理团队的方式，观察架构师的工作规划，能吸收一些自己目前不具备的管理能力。
半年时间，从渡江6期到渡江7期，对公司的IPD流程设计感叹伟大 (也许是目前想不出一个恰当的词)。何为IPD:
1.客户的需求为导向
2.产研体系的协同和闭环
3.合力用工，用好每一位成员
什么是客户需求为导向:面对客户提出的需求，
传统的处理逻辑是:1.销售接入客户需求，2.实施顾问考虑现有产品是否满足需求，当满足时，进行反馈。不满足时，向后导向至产研团队，产研团队讨论解决方案，当定义不能实现时，时间半个多月，回到销售反馈客户不能实现。且消耗内部大部分精力来应对这种不确定性的需求
现有方案是，增加MM，当销售接入客户需求后，MM进行需求评估和产品定义是否满足需求，不满足且能做，进入需求池或进入客开研发团队。当不满足且不能做时，反馈到客户。
接下来讲产研闭环。
产品总监对需求池中的需求进行归类细分，拉齐产品团队开始对任务进行拆解，对功能点细化，讨论设计方案等，当产品原型确定好后，设计开始出设计稿，同时前后端架构师开始针对技术方案对产品迭代做架构设计。此时产品团队同步做详细设计，和设计同步。
产品设计完成后，开始进入对应的产品详设讨论，和技术leader确定产品的所有细节，此时有对应的问答和细节讨论并解决的环节。需求完全明细完成好，开始对前后端开发、测试同学进行对应的产品设计宣讲，此时也可针对细节提问，但大部分都是答疑而不是进行讨论环节了。
当开发和测试对应需求了解完成后，开始细化和梳理产品设计的细节，准备进行需求反讲，需求反讲是产品来确认开发人员已全部明白所有的产品设计方案，包括所有的细节和产品规约。
接下来开发同学开始进入到一页纸方案设计，什么是一页纸方案设计，直白点就是伪代码，精确到每一个细节设计点，核心功能或复杂功能，需要又详细的设计思路。
(PS:此时，产品团队就可以进入下一个迭代周期的产品规划中)
可以从几个方向进行:
1.系统边界，当前自身的功能开发，涉及到哪些领悟或者代码的变更。
2.功能流程，将对应的功能点，以自身的理解来绘制一份流程图。流程图中可以标记细节的说明或规约等
3.领域关系图，此次变动，会涉及到哪些领域或者表结构的新增变更，对应的领域关系标注
4.细节设计，此次变动涉及到接口的，需要说明接口参数(含入参、出参）变动，涉及某些方法变动及上下游方法调用的，需进行详细描述。
5.MQ等中间件使用时的设计方案。
6.个人开发的估时
一页纸完成后，前后端分别又架构师和leader领导，进行一页纸设计的内容讲解和评估、讨论，有没有设计缺失的地方，对后续的产品迭代有没有形成感染，有没有对数据量和频繁请求这些方案的考虑。当这些方案讨论完后，进行问题的最终结果追踪
开发阶段，这个阶段是测试同学进行用例编写和开发同学进行编码开发的时间，此期间每天进行站立会议，用于开发过程中对产品疑问问题的团队内同步，便于测试了解到产品的变更及测试用例覆盖等。
用例评审:对测试所写的用例进行覆盖范围的确定，同时也是开发同学功能点的反省。
Demo:对开发的功能提测前的演示，要求产品主流程跑通，且细节功能无P2问题
测试:测试期间根据对应功能进行测试，开发进行bug修复，期间开发可进行自身个人提升，内部分享或技术提升
产品上线。
后续迭代继续进行需求宣讲，以此形成闭环。
对北森微服务体系的了解和梳理
北森微服务以WCF为基础，从SOA演变成微服务体系，主要有基础工具:
Beisen.Configuration(分布式配置中心)
Beisen.Log(日志，日志传输至日志收集中心，分析使用kibana)
Beisen.Log.Trace(链路上报，分析及查看使用鹰眼)
Beisen.RedisV2(redis在北森的落地)
Beisen.Amqp(rabbitmq的封装)
Beisen.Kafka(Kafka的封装)
Beisen.Data(数据库的封装)
这些工具都根据租户信息做了对应的集群划分和分库操作，天然支持拓展
Beisen.Quark是微服务调度的中心，含一个部署服务，以service形式安装在服务器，当部署应用时，通过OneOps进行服务器管理和应用管理，对应用进行部署、上下线、扩容机器等操作。同时，服务间的调用和服务注册通过consule实战，服务间调用通过nuget包引用，通过 quark调用，隐藏调用的复杂度，同时调用时，使用链路上报，将调用链上报至鹰眼
OneOps:实现应用的编译，部署，状态监控，自动上下线，灰度功能设计，服务权限管控，部署流程审批，多应用部署的部署任务构建及分期部署的过程。其中还有PaaS等元数据和功能从开发环境部署至测试，生产环境的支持(多是PaaS将部署能力以接口形制提供，OneOps调用接口来实现功能部署），且所有功能部署点都支持失败回滚，部署备份等操作
面临这些服务，及管理，衍生出数据服务组，对数据服务进行管理。
对北森PaaS的梳理
paas，天然适合企业软件服务。首先从最底层开发态进行描述，开发态为最基础的paas功能，平台算特性功能通过开发态开发，其中包含功能有，应用窗帘，对象设置，表单设计，列表呈现，搜索条件管理，按钮设计，功能权限管理，身份管理，菜单管理，对象间关系映射和相互见的元数据引用，触发器实现低代码的开发，方便代码介入业务的实现，以及操作上的协同设计，接下来还有对应的workflow协同工作流，打印模板，通知模板，消息模板，等应用构建。
2.实施态，也就是单个单位对某些功能的定制点
所有实施态的设计，都是单个租户生效。实施态可以做到和开发态相同的所有功能，而开发态又可以控制到实施态某个细节不可自定义
3.Ocean，强大的数据整合分析能力。
当面临应用数据汇总，或数据分析整理时。传统软件功能实现是一个报表做一次开发，而ocean，负责承载所有的业务数据，通过开发态定义某些应用，某些对象下的某些字段对外开放数据呈现设计。
通过对应的关系映射和视图数据呈现设计，根据拖拽的方式，以SQL生成器为引擎，动态生成SQL语句，为页面提供数据汇总和整合能力。
ocean中的业务数据是从业务中抽离，分位自动抽离和手动设计抽离方式，以引擎库的方式，供数据呈现使用，即不会因为数据分析，而影响到业务线的性能。同时满足到数据的批量汇总和分析。
迭代中的总结，通过业务迭代，渡江的研发，对招聘产品的业务有了直观了解，同时通过团队内部的分享，对几个主要产品线的功能及开发细节有了确认。
当然，成长还需要很多，自己的下一步是如何针对现有代码，在迭代功能中，对复杂代码进行分析，抽离共性点，将流水式的业务实现，通过抽象的方式，从一个功能点设计，逐步锻炼自身架构设计能力。
