公司内部技术积累的一些思考

围绕一个模块一个主题，准备材料，做一场专门的完整的培训或分享，是很有用的。其视频和文档也是重要的技术积累。此处主要想讨论的是，对日常研发过程的零碎问题和解决手段的积累，没有那么完整和重量级，但确实很难做好。

现状

问题一：很多问题没有积累。

很多小问题是大家习惯直接找到对应的负责人解决。对这个具体问题来说，当面沟通确实是最高效的，但没有形成积累，只有直接参与这个问题的人知道问题的存在和解法。一旦人员调动就没人知道了，或者时间久了连参与者自己都忘了。 当然，问题本身是否需要被记录，也是需要评判的。有些问题，确实参考意义不大。

问题二：有积累的问题过于简单

内部的研发系统上，很多问题，只有问题和简单的解决结果。对客户的系统好一点点，会有跟客户的一些交互，对客户的解释也会更加完整清晰一些，但基本也是停留在结果上。对客户是足够了，但对内部其他人员的借鉴学习，我觉得还是不够的。

问题三：不够开放

不同部门各自有积累，但未能互联互通。今年公司也在做一些这方面的工作，统一平台，加强知识库建设，希望能真正起作用。

好的例子

看到做的最好的，是以前遗留下来的一些问题解决的总结文档，会描述问题的现象，复现方式，然后进行初步分析，制定方案对可能的原因进行逐一排查，完整地写出解决的思路，用到的工具和方法。一步步逼近根本原因，最后才得出结论。看这种文档，除了学到一个知识点，更多的是学到了一些思路和方法。相当于别人手把手教你解问题，你会发现，哦，还能这么干，长见识了。下次你可能碰到的是一个完全不同的问题，但思路和方法是可以借鉴的。正所谓授人以鱼不如授人以渔，直接丢出一个问题和结果，那就只是一个知识点，读者完全不知道如何从问题自行推导出结果，但如果写出从问题到结果的过程，包括其中走的弯路，那对读者来说，就是又掌握了一种解决问题的方法。前人花十天半月解决的问题，一篇文档就掌握了重要部分，再举一反三，水平自然能迅速提高。 可惜这种文档太少了，而且写一篇也不容易，估计只有疑难杂症或重要项目才能享有如此待遇。

个人实践

知识总结放wiki

当他人问问题时，判断下是否是共性问题，是否其他人也会再问类似的问题。如果是共性的问题，且没有现成的说明文档，那么此时比起直接给对方解释清楚，更好的做法是，先在wiki上形成一个简单的说明。再将这个链接发给对方。如果对方还有不明白的，再直接沟通，沟通清楚后，再针对刚刚沟通的内容，整理整合到wiki上，如此重复，不断修改完善。等到这份文档确实够完整清晰，再有其他人需要的时候，就可以一个链接搞定，无需多费口舌，节约了大家的时间。

问题解决放论坛

搭建了一个部门内部论坛，用于记录问题和解决方式。原本的期望是，每个问题报出来就可开一帖，描述问题，不要等到问题被解决掉再总结，而是随着问题的进展，不停跟帖更新，直播解bug过程。中途其他人也可以给出意见建议。

实践效果

效果是wiki很有用，总结过的问题，有人问的话，发个链接就可以解决。论坛的话，对个人回溯问题很有用，但没有达到设想中的交互作用，仅作为另一种记录问题的方式。且个人执行程度也不高，很多问题并没有发到论坛上。

几点思考

素材收集

要形成总结，我觉得首先需要能把素材积累下来。一个问题解决完毕后，很多中间的log，测试数据，问题现象是没有保存和截图的，且关联的材料可能散布在邮件，聊天记录，口头交流等。巧妇难为无米之炊。如果要在总结文档中说清楚，那收集材料都是个问题，甚至必须重新做一遍测试。如果能让大家在解决问题的过程中，方便快捷地把所有的分析和尝试（包括无效的尝试），以及关联的材料（如问题描述，邮件往来，钉钉/微信记录）都记录下来。那起码有了一份原始记录。 一个设想是，设立一个公共邮箱，对于某个问题的邮件全部抄送该邮箱，那么，即使没有后续的进一步整理总结，其中的信息也有很大的价值。在其中搜索到关键信息，看看邮件往来，可能就能搞定一个问题，避免重复开发，重复解bug。

引入交互

最好能有交互，反馈，完善补充。有些问题和解决思路方法，你记录下来的时候，可能自己觉得讲得很明白了，但别人看到就不一定了。如果能有人在这个过程中积极参与讨论，提出疑问和建议作为反馈，那么对于这个问题的解决和后续其他人的借鉴，都会很有意义。脑补下大概类似于开源社区的邮件列表，或者技术论坛上的讨论帖，或者博客下方的一些留言探讨。

积极性

首先机制肯定是要有的，各种研发管理系统能解决部分问题，完善的流程，起码保证问题和解决方式被记录下来。但如果大家只是完成任务，那么内容肯定质量高不到哪里去，容易流于形式。如何调动大家的分享的积极性，这才是最大的问题。要打造良好的团队技术氛围，让大家都愿意分享，习惯分享和讨论。如果能引入一些激励，那就更好了。