停更了挺长一段时间，首先说声抱歉，去年发生了很多事情，公众号的内容一直很难做到亲力亲为，当然也有一部分是自己的原因。还在的小伙伴，非常感谢，虽然你可能只是没有取消关注的习惯。恢复更新之后，先和大家聊聊晋升的事儿，很幸运，今年首次参加答辩就通过了 6 升 7 评审，顺利晋升到 P7。说来也在阿里三年了，努力了很多年，盼望了很多年，很有必要做个总结。本文既是对过往的回顾，也是对诸多思考的整理，希望对您有帮助。
关于晋升的思考
知乎上有个见了很多次的话题，对某项技术理解很透，出了自己的技术书，能升 P7 吗？很遗憾，答案是未必。
要晋升 P7，需要有系统性能力、成为子领域的代表，需要有创新技术能够被他人复用或者有能力领导跨团队项目，需要对技术的投入产出比有明确的认知。所谓的“技术牛逼、理解深刻”，当然是优秀的 P6，甚至比6厉害，但未必是合格的 P7 ，因为两者评价标准不同。
你需要使用掌握的技术输出创新技术，用你优秀的架构能力，在特定的业务场景下解决有难度的问题，真正做出贡献才能晋升。你已经是一名非常优秀的程序员了，接下来，要把代码看成纯粹的工具，思想要转变，工作的重点是使用代码工具解决业务问题，要能做出技术创新。阿里不缺技术牛逼的人，缺的是能够用牛逼的技术解决问题的人。
关于个人成长的思考
30 岁前是提升学习能力和解决难题能力的非常非常关键的时间段，一定要把时间花在提升解决问题能力上。刚毕业的前两年，工作比较轻松，我就在这方面做得不够好。第三年，我意识到了这个问题，恰逢转行到互联网行业，一切都是新鲜的，才开始着重提升解决问题能力。每天下班后，回到家自己练习 Java、Spring 代码，自己写 IOC 框架、RMI 框架、消息队列框架、MVC 框架、ORM 框架等，通过从零开始重写开源框架，极大提升了编码能力。能力提升后，对工作中的代码做了几轮重构，逐渐成为团队中的主导者。正是这些能力提升，帮助我进入了阿里。
在阿里的这段时间，见识了超级复杂的业务系统。每每迎难而上，收获的都是能力的提升。有复杂的业务，有足够多的挑战，阿里是一个非常适合成长的公司。
关于技术创新的思考
如果你想走得远，一定要有技术创新能力。软件开发是非常困难的，而软件开发的困难其实也是软件本质的一部分。理解软件开发的本质，并采取和本质相符的实践就一定会有技术创新。认知问题是软件开发的根本问题。理解业务的本质，找到业务的痛点，解决业务开发的难点，创新并不是很难的事情。和前面说的一样，一定要明确代码只是工具，解决问题才是技术人员最大的价值。如何解决问题，是需要我们深入思考、反复思考的。解决方案有了，技术创新是水到渠成的事情。
关于架构设计的思考
之前的文章分析过，程序是什么，程序就是控制逻辑、业务逻辑、数据结构的集合。架构要解决的就是控制逻辑、数据结构的抽象沉淀，和业务逻辑的调度执行。如果没有合适的架构，代码就是负债，你越投入人力，负债越多，最后代码终将达到无法维护的状态。合适的架构，能把代码变成资产，投入人力维护代码的过程就是个滚雪球的过程，和理财一样，最终收获的是复用性好、扩展性好、稳定性好的优质资产。架构会一直演进，没有人能够在最开始的时候就设计出能够永久使用的架构，必然是随着业务发展逐渐迭代优化重构的。
不知道如何设计架构怎么办，我的建议是把提升开发效率、降低维护成本作为一个目标去思考。良好架构的本质，就是针对一个特定业务，能够提供最高的开发效率和最低的维护成本。往降本提效的方向走绝对没有错。
深度思考见本质
每年到了晋升季，关于沟通能力的讨论总是不绝于耳。一般认为沟通能力不好，本质是对业务思考不到位。答辩短短几十分钟如何向评委证明自己到了下一个层级，面对评委的提问如何才能回答好问题，每年都折磨着一波又一波的同学们。晋升不只是 PPT，还有长久沉淀下来的思考。只有思考到位了，才能脱口而出、对答如流，才能体现出良好的沟通能力，展示出到达下一层级的能力。与其费尽心思各种练习，不如平时多思考。想透了、想全了，胸中有墨水，思路自然来。
后续计划
今天最好的表现是明天最低的要求。好好学习领域驱动设计，不落下精益软件研发课程的任何一个部分。在工作中尽量实践领域驱动设计，既要提升个人水平，也要为团队做出更多贡献。为团队解决更多难题，挑战更多不可能。
如发现本站有涉嫌抄袭侵权/违法违规等内容，请联系我们举报！一经查实，本站将立刻删除。
