一个团队内部经常有很多针对不同场景的设计方案，同时技术系统在历史上出现的各种问题故障可能也会在事后记录下来，但是这些记录及文档通常并没有一个好的归属，随着时间的推移就淹没在邮件的海洋中。如果知识库具备，这里简单探讨一下相关作用。
团队中新人未经历过系统所有阶段，不能有历史的阅历。即使是老的员工，如果团队规模变大，或者是精力的原因，也不可兼顾到系统中所有的信息，因此设计案例及故障案例对一个团队共享经验及共同能力的提高都具有极大的帮助。
看书是一种最佳的学习方式，但是在互联网工程领域，很多经验及成果并无公开的书籍及文档描述，因此很多有志于在此领域提升的新人经常会碰到困惑，如果当前不在一个成熟的互联网公司，根本没有机会来提升自己。另外一方面，即使能进入这些环境，新人也会碰到另外一些问题，公司内的牛人忙忙碌碌，已经完成的伟大作品也很少被详细介绍，新人只能在日常零星的工作中逐渐去了解全貌，很难得到一个快速成长的机会。
这对老人也是一个启示，大家热衷于解决的新场景的问题并非最大的价值所在，新领域问题无非是根据个人经验，走了一条不那么弯的路而已。但是总结已有的典型设计加以抽象总结，形成一些系统性的设计库，或者将所有的故障及走过的弯路分门别类，形成故障库，这对于提升一个较大团队的整体能力，具有更重要的意义。
说了知识库的需求，也许有人会顾虑知识库的技术领域差异性，技术人员对专业细分领域之外的问题不感兴趣现象比较普遍。前端的对后端的案例分析不感兴趣，数据库工程师对开发领域的问题不感兴趣。因此需要案例材料尽量跳出具体的语言细节本身。但是技术人员如果能够跳出自身的认知圈子，从更宏观的视野来讨论及分析这些问题，对于综合能力的提高具有更大的帮助，这也是走向架构师方向的一个基本要求。
对于设计案例，理想的知识库需要有系统的分类，而且大部分新设计的功能都可以在其中找到一个对应的历史案例，虽然很少有两个系统完全一样，但是真正设计思想的区别并不会大。
随着案例知识库的完善，案例的讨论的深入，一个团队的技术能力得到了整体提高及升华。
新人只能在日常零星的工作中逐渐去了解全貌，这个确实，期待案例知识库的完善
案例与故障的知识库的介绍能否分享一下，这篇文章好像没显示完整。谢谢！