角色转变
自己从一线开发角色转变，这个转变没有过渡，直接怼上去的，从之前每天只撸完自己的任务代码,没有P0级 bug 就 ok。到现在，每次需求评审，需求评审,api评审,中间各种拉动会议，开发中处理跟踪问题，跟踪所有人员进度，质量把控，白盒/黑盒。再到预发布-灰度，最后保证按时上线，甚至上线后各种突发 bug,各种救火。
身份的转变，从-1到0的参与，给自己带来的压力是倍增的，毕竟你站在这个位置上，就需要有责任和担当。这段时间，真的对自己又很大提升的。
代码
之前看别人代码只有一种感觉，「丫是 sb 吗？」要么大牛写的代码我根本看不懂，要么我看懂后发现丫这么干肯定不行。哈哈。开个玩笑。小白阶段我们都是 copy 模式的，看别人代码都是拿来主义，不问东西，很多想法和细节容易被忽视，更没有把他编程自己的东西，所以现在 review 小弟的代码也好，看分包商的代码也好，开始择其善者发扬之。还好开始业务不是特被复杂，偷偷摸摸改了前人的 bug 已经不是稀罕事情了。
我觉得遇到别人的bug，不能只抱怨，而是感恩。感谢前人挖坑，锻炼了我的 trouble-shooting (填坑)能力。
人和事
之前也只会和有对接需求的同事之间聊的多点，而现在不只是开发，产品和项目的人都必须深度沟通的，首先你要从业务上和他们达成一致，还要把技术壁垒和短板跟他们阐述明白，因为所谓技术的价值在于服务好产品业务和商业模式上。 自认为和人的沟通上我是比较菜的，尤其面对业务的时候，一站嘴就暴露自己是「技术」的身份了。沟通是一门艺术，真的不只是废话。
需要吐槽一点就是，如果团队里面不是一条心，哈哈恭喜你，赶紧走人吧，如果碰上团队各种甩锅，你就遭殃了。如果没有企业文化的公司，慢慢会人心涣散。挑战和质疑每天存在，而且不晓得谁会给你穿小鞋，洗洗睡吧。
好的团队应该是，即使我挑战你，也是为了项目，为了结果好，甚至为了你好。这种态度和信念，随时欢迎大家挑战自己，敦促自己进步，何乐不为。
技术要懂业务
举个例子，12306开始各种崩溃，买不到票是为啥，其实根本不是技术架构的问题，业务的问题！搞了一次0点开始上亿人的秒杀？Are U kidding me？ 如果产品开始就知道是业务的问题，做好排队、分时段放票我就觉得这世界会更美好一些哈哈。
所以，我一再跟开发同学反复讲一件事，开发需要懂业务，不能只了解和你对接人的入参出参数，了解上下有关系还是不够的，还需要了解业务场景，考虑和你相关的 everything。
我们看解决问题能力比较强的技术不光技术比较全面，而且需求和关联逻辑都比较了解，这就是我为什么突出要懂业务，不只是需求，还有关联逻辑。
关于架构
自认为自己是二/三流的程序员，不觉得自己有架构方面的能力，但是慢慢开始学会去主动思考，这种设计会不会有坑，如何避免此类坑的出现，我觉得完全要看经验和业务认知程度，尽量考虑各种场景，才能有效避免 bug 出现，功能性需求上，有时候也要将就取舍，有些功能该砍的就砍掉，等待更新迭代。
没想过也没能力做架构师，只不过现在需要参与进去，敦促自己技术点要全面，现阶段我可能不具备架构师的能力，另外没机会接触亿量级的并发场景。但是我觉得我可以先把各点考虑进去，人后跟对应专家去沟通去了解，一起完善现在的架构体系，而不是闭门造车，或者找一本架构设计书啃完，就说自己架构经验丰富。
最后，尽管是短短的一年，对我以后的路都是宝贵经验，共勉吧!
最后的图的意思算是激励，自信一点，无所畏惧！
