新公司入职马上就有两周了，这个新公司是一个快速成长的大平台，业务在迅猛地发展，员工人数已经突破上万人，目前技术也在快速升级中。曾经我了解过阿里的技术迭代升级之路，其实我现在所在的公司在业务快速发展的同时，也在走着阿里曾经的技术迭代升级之路。
通过这两周的梳理和梳理，我是觉得对我而言，如果仅仅是从应付工作的角度出发，那，基本可以肯定，难度并不大。既然如此，我就想着要在做完工作的同时，把工作做好做细做精。也就是说，要把小任务做成大内容。也是基于这个初步的想法，我打算在下面四个方面持续进行学习。
1 编码规范
我现在是一个开发人员，基本可以肯定未来两年之内，还是以实际的开发工作为主，所以在基础的编码技能上，还是需要进行持续地优化学习。
不能仅仅停留在CRUD方面的维度和视角，而要有更多的更高维度的模式抽象和平台化思维。毕竟现在我从事开发的都更多是一些公共平台，不是单纯的业务系统，所以不是简单为了实现业务逻辑，而更要考虑兼容变化和后续发展。
也就是我需要更进一步加强对于设计模式的学习理解和运用，以及技术开发细节上精益求精，比如代码优化重构心法的理解和应用，还有一些数据结构算法的思考和应用。
2 沟通协调
我当前所在的团队是一个围绕新项目新成立的团队，组员基本都是清一色的小年轻。在其中我可以算是一个老大哥了。另外，我们的组成并不是集中一地办公，而是分布在不同地域，办公性质属于异地联合办公，所以很多沟通都会有线上部分。
作为团队的老大哥，我是觉得自己也有这个义务主动去参与一些沟通和协调工作。另外，从利于长远职业规划发展的角度来说，主动沟通协助负责人做好组员内部的沟通与协调，也是锻炼提升我沟通协调组织能力的机会，所以不管别人如何，我自觉是有这个成长需求和自我责任驱动的。我应该这么做，我也要这么做，而且我也必须这么做。
3 架构设计
本周我了解到当前公司用的架构并不是我之前熟悉的微服务架构，而是相对更前沿一些的DDD领域模型设计架构。虽然说是有差别，但在当下的我看来其实也差不了多少。但学习最忌讳的就是差不多，既然是新接触而且不了解，更需要深入学习一下，如此才有发言权。毕竟既然这样的架构设计，肯定是有对应的思考和考量，仅因为此自己也有必要好好思考一下。为此我初步选定了三本关于DDD方面的书，要好好学习一下。
另外，我虽然现在即将开发的系统属于MVP版本，但其实在技术方案设计的时候，我看到考虑的架构问题还是蛮全面的，这点是在我之前的项目开发中，还是不曾有过的。所以这点也进一步提醒我，要持续学习和实践高可用稳定性系统架构的设计和应用。毕竟，这同样是我选择一个长远职业道路过程中需要的一个硬技能。
4 组件原理
入职以来的这两周，我大体把公司之前沉淀的技术文档全部都过了一遍，很多组件我之前都没有听说过，也都没有用过，虽然一些有用过类似的，但对于内部的实现原理和核心细节并不了解。
而通过前段时间的面试找工作，我也认识到对组件架构原理深入的理解，不仅是考量一个人技术实力的标志，更是代表着一个技术人员对于系统稳定掌控的一种能力。因为如果系统真出问题的话，对于组件核心有更多认识和思考的人，能够更快分析出问题所在，也能有更多深入的解决方案。
所以加入了新的平台新的公司，我也提醒自己，对于之前了解或者现在还不了解但接下来要使用的组件，不能光做到会用就行了，而是要花时间研究一下，核心实现原理、应用场景、各个同类组件的对比、核心原理的算法是如何实现的、有没有什么可以借鉴学习的地方。缕清了，把握住了，让技术为我所用，而不是我为技术所累。
早上在看书的时候，临时冒出想法，我是想在新公司从上面四个方面认真思考学习和践行。分享出来这些思考也是想给自己再提一个醒儿，我的年龄不小了，不能动不动稳定之后，就做温水青蛙了，要有危机意识。毕竟公司不是大家庭，而是一个球队，不行就得出局。居安思危，我必须主动行动，如此才能为自己的长远发展贡献一份坚实的力量。
