我的十年技术之路
我目前从事分布式服务架构的设计与开发工作，在阿里的大数据平台上进行应用程序开发。我们将整个系统拆分成许多“微服务”，服务之间通过统一的接口来调用，每个服务是通过容器技术进行隔离，此外服务可发布到统一的服务管理平台上，可通过该平台监控每个服务的运行状态与生命周期事件，并为服务调用者提供了服务发现的能力，可对服务进行平滑升级。
阿里有许多优秀的中间件与基础服务，可以快速帮助我们搭建应用系统，而且这些技术在阿里内部全是开源的，大家可以通过源码和文档学习到很多有价值的经验。阿里也提供了浓厚的技术氛围，每位同学都非常专注于自己的工作领域，大家对工作一丝不苟，相互配合，方向一致。
我是如何走上技术这条路的？
刚开始工作的时候我学习了什么是云计算？什么是 SaaS、PaaS、IaaS？我们花了三年时间开发了一款名为 ODE 的 PaaS 平台，让用户可以在该平台上量身定制自己的软件，最终为客户提供基于 SaaS 的产品。确实很骄傲，那时我们已经在做云了，只是没想到后来云会在中国得到这么好的市场，可能当时只有黄老师一个人想到了吧。
在 2008 年，我为公司拿回了“第一桶金”，这也是我从程序员转向项目经理的里程碑。当时我带领团队远赴深圳，为国信证券公司开发经纪人管理系统，这个项目对于我个人而言却是一笔至高无上的财富，我开始学习如何与人打交道，如何做需求分析，如何将需求转变为技术，如何带领团队小伙伴一起工作。学到了太多太多，但我依然选择在我工作第四个年头里离开了动量软件，我刚加入动量软件的时候，公司只有 5 个人（包括老板和前台），当我离开动量软件的时候，公司已经有 200 人左右了。感谢黄老师！我在他身上学到了很多，他的思想和态度直到今天都还在影响着我。
我在 2014 年离开了 TCL 通讯，加入了易传媒。为什么我要放弃如此舒适的工作环境，去加入一家还在不断拼搏的企业呢？其实我看到的是未来互联网的发展趋势，广告程序化交易以及广告与大数据的结合，未来最值钱的一定是数据。抱着这样的信心，我加入了易传媒，担任系统架构师职位。当时易传媒正处于技术转型的初期，需要将 .Net 全部迁移到 Java，这件事情对于我而言是非常有挑战的。我的做法是：第一步定义开发规范与流程，第二步培养核心技术人员，第三步分阶段进行改造。仅半年时间，我们所有的产品成功地迁移到了 Java 平台，结果出乎大家的想象。公司市场也非常不错，产品得到了业界的认可，订单数源源不断，大家每天都很忙碌，但却很开心。而易传媒的“易家人”企业文化，让我所感动，不管是核心技术部门还是其它支持性部门，大家就像一家人一样，你的事情就是我的事情。
直到 2015 年初，阿里巴巴与易传媒建立了合作关系，两家公司进行了深度合作，易传媒公司与阿里妈妈事业部进行了整合，新阿里妈妈从此诞生了，于是我也成为了阿里巴巴的一员，目前负责阿里妈妈大数据品牌营销产品的系统架构工作。
技术一条不归路，选择了这条路从未有过放弃的想法。
做了十年的技术，我从来都没有放弃过它，相反，我非常热爱它，因为我一直以来都很喜欢学习，希望能学到更多的东西，这样遇到了具体的技术问题，可以随时从自己积累的知识库中找到最佳的解决方案。此外，目前我在公司虽然不怎么写代码了，但我还是会利用自己工作闲暇之余写一点开源项目或者代码框架等。
工作过很多大大小小的公司，那么公司最值钱的东西是什么呢？
我认为是实实在在做事情的程序员们。
他们虽然工资不高，每天坐在位置上敲着代码，在很多人眼中被称为“屌丝”或“宅男”，但我认为恰恰就是这些人，他们才是公司最有价值的人。
- 他们有自己的理想，希望能够通过自己的努力，从中得到那一点点所谓的成就感；
- 他们需要理解产品经理真正的意图，把想法变成现实，让产品真正落地；
- 他们更容易把握细节，而这些细节往往决定着产品的命运与成败；
- 他们突如其来的跳槽，对我们的项目的交付有直接的影响；
- 他们在一起工作的气氛，能体现技术公司的文化与底蕴。
由此看来，对程序员的重视是相当有必要的，我们需要关心每一位程序员的职业发展，让他们在团队里能够充分地发挥出自己的能力。
我们也需要对他们倍加关注，挖掘出有能力、肯吃苦、敢担当的人，给他们更多的机会，让他们成为技术领袖。
互联网技术公司需要大量这样的程序员：
- 他们是一群有着技术信仰的人，他们是一群热爱编程的人，他们是一群不解决问题睡不好觉的人；
- 他们不是打杂的，不是外包，更不是工具；
- 他们不喜欢被忽悠，不喜欢被冷落，更不喜欢被驱动；
- 他们需要尊重，需要培养，更需要激情！
一个成功的项目，离不开每个人的努力，分享下我曾经的项目管理经验。
给大家提出以下 10 点建议及其目标：
- Sprint 第一天，需要将目标定义清楚，并让团队所有人都知道「确保建立一致的目标并使之明确」；
- 若出现需求变更，则优先排到下次迭代，特殊情况需特殊处理「确保本次迭代可以按时完工」；
- Scrum Master 将迭代中的需求分解为任务，每个任务只能有一个任务负责人，且不超过一个人天「确保每日任务可评估」；
- 让 Product Owner 直接与相关开发人员确定需求，Scrum Master 需一同参与「确保需求与实现不会发生偏差」；
- 每日定时站会，时长不超过 15 分钟，规模不要太大「确保任务完成情况与计划保持一致」；
- 每日进行一次代码评审，由 Scrum Master 负责，并在次日将评审结果通知给相关开发人员「确保代码质量不要下降」；
- 各个团队的 Scrum Master 保持每日沟通一次，时间不要超过 15 分钟「确保项目管理不会出现风险」；
- 每次迭代结束，让大家稍微放松一下，可提供一些团队活动，比如聚餐「确保团队能够更加凝聚」；
- Scrum Master 需要给团队一些承诺，比如项目奖金或特殊福利等「确保团队更加有激情」；
- 对于情绪异常的员工，Scrum Master 需及时与其沟通「确保不要让一个人的情绪影响整个团队」；
这基本是我这10年的开发经验以及心得的总结，希望每一个在这条路上的程序员们能够走的更稳，走的更远
对了，如果你想第一时间阅读我的文章，微信关注Java架构师联盟，更有我为你精心准备的学习资料和 高质量教学视频。
