在国内几个比较大的IT公司里面，程序员都要一定的职级，例如腾讯的T系列，应届生为T5，一般3到5年可以晋升到T9可以认为是高级工程师了。阿里也有P系列，应届生为P5，2-4年晋升到P6是高级工程师。每次晋升都需要写ppt进行述职。
经常会听到这样的吐槽，说辛辛苦苦干了几年，结果答辩的时候被评委认为是思维混乱，方案没有好好思考，没有技术深度等等等。这种情况特别常见，答辩的时候，评委最喜欢问，你为什么选择这个方案。很多同学就很郁闷，这种业务的，业内不都是这么实现的么?部门里面用的技术栈不都这些，别人也这样用，这有什么好问的。
换个角度想，评委并非十分熟悉你的业务形态，而且很难通过3-5分钟的业务介绍，就能熟悉你的业务。所以，当我们进行方案的阐述的时候，最好是能够进行方案的对比。在对比的过程中，最能直观地体现方案的好坏，业务的形态，哪种方案更贴近业务。
举个简单的例子，假如你的技术方案中需要添加一个缓存，那么，是使用本地缓存还是分布式缓存，两者的使用成本又是怎么样?如果采用分布式缓存，那么有哪些常见的分布式缓存的方案呢?当年思考到这一点的时候，你自然会从流量的情况，数据的冷热程度、冷热分布、数据大小等多个维度进行考虑。
不仅如此，需要多少的缓存空间，命中率如何，如果用最小的成本，满足业务的要求，是进一步的思考点。同时，在方案对比的过程中，你不但可以了解到业界常用的解决方案，又能够学习到各项不同的技术。
如果你只是到答辩的时候才有这样觉悟，那么，每次答辩的时候，写PPT是异常痛苦的。最好，如果把这种习惯带入我们的日常工作当中，那么你将事半功倍。很多人会觉得，平时项目排期那么紧张，怎么有可能每一个需求都下来思考呢?
不知道你有没有遇到，在项目开发到一半的时候，才发现原先的技术方案在某些环节可能存在欠缺，导致整个方案需要重新讨论，强行处理甚至推倒重做。为什么我们不在一开始设计的时候，就把整个方案考虑得更加完备呢?
最后，平时不妨多问自己：
为什么我们的系统要这么设计?
业内有什么其他常见的方案?
为什么我们不采用他们的方案?
如果你能想清楚这一点，那么，恭喜你，你已经想清楚了，评委会问你的问题。晋级自然事半功倍，技术能力也会不断提升。
