码代码

三个月过去了，在六月终于进了团队。公司很土豪的花钱让我们做了三个月无产出的小蛀虫，三个月做的，不是培训，有点像入职是的设计及开发的考核，过不了的就直接拜拜，据说在日本被再见的人挺多的，而在总公司外的其他地方，像新加坡，上海这些地方，比例肯定小于5%，区别仅仅在于早点通过，和晚点通过。这三个月做的开发和实际开发中用的技术栈没半毛钱关系，除了趁这个机会好好熟悉了下 JavaScript 之外，对工作有用的点，应该就在于了解和熟悉公司的开发模式和理念侧重，说白了就是让程序员也有以用户为中心的概念，这点很重要，但用三个月的时间通过两次的开发文档来强调，投入产出比会不会太高了点？是不是应该在除了总公司外的地区适当的调整这个流程？

三个月过后，才正式进入六月的主题。“考核”过后，才是真正接触公司在用的前后端框架。前两周是在自学各种各样的框架，后两周就进具体的团队，开始干活了。短短几周，读了大量的技术文档，简谈点体会。

技术文档，条理要清晰，内容要准确。读的这些文档，有开发环境搭建说明，有分步教程，也有概念性的说明。如果跟着文档做下来，能够顺利完成想要做到的预期效果，那是大快人心。如果过程中，碰到了点什么问题，对于一个小白来说，在几番尝试后，还是解决不了，是很让人沮丧的，“我明明完完全全按照它说的做了，为什么还是不可以？”，如果是写代码上还好，有足够的耐心，基本可以自己解决，最要命的是环境搭建文档，一个小地方的疏忽，或者因为版本更新而文档没有及时更新，之前没有经验的人，可能花一整天都配置不好，找不到人帮忙的话，分分钟要骂街。文档的重要用处之一就是可以一次性把做法记录清楚，省去重复的人力。如果大部分人都需要去求助的话，那这个文档就有点鸡肋了，需要有人专门的去修改和更新，而最合适的人选，就是刚过解决问题的人，整理解决方案，过程中顺便把文档一更新，个人对解决方案加强了印象，也造福了后来人。

准确性之外，文档另外一点很重要的就是条理性，条理清晰的文档，有助于提高阅读者的阅读效率。条理不清的文档，对于读者来说，简直是折磨，估计就是一路懵逼的读完了，恍然大悟，原来是这个逻辑，你就不能好好写，写清楚吗？

本质上来说，要写好技术文档，就多想想阅读的人，这么写阅读的人能看懂吗？对方是否有足够的技术背景？他们在过程中会遇到哪些问题？是不是太高估读者了，要再多加点细节？是不是把读者当白痴了，要省去一些繁杂的东西？

简单说，就是以用户为中心。