前一阵被邀请参与公司新任培训的师兄师姐分享环节，大体是和小组内的新入职校招同学分享工作中的积累和收获。分享内容没有要求，但是大家提的比较多的问题是入职后有没有什么成长的tips或者坑。我干脆提前做了些相关的准备，也一并在这里记录下来吧。

我回忆了下过去2年多以来，在公司遇到的之前未曾预期的种种，大致可以总结为下面两点：

先说了解业务吧。我们在日常工作中遇到的需求无非两类：业务需求和技术需求。这两类工作都要求对业务的了解。在业务需求中，首先了解业务才有可能完好地还原prd的需求，避免产生不符合预期的情况，避免被产品或QA打回。然后，我们每个人都不是需求实现的机器，了解业务能让你知道，你写的每一行代码都是有意义的，都是真真正正为人服务的，而不是机械地完成任务。同时，对业务的熟悉程度也能让你的视野上个台阶，从更高的角度考虑问题，看到更远的可能。实际上，服务端同学相对来说，由于要设计数据库表，实现底层的业务逻辑，需要对整个业务理解更深入，所以在大多数团队，leader也都是服务端同学担当。

在技术需求中，同样离不开对业务的理解。可能有些刚入职的同学不会意识到：我们其实是工程师，而不是科学家。我们需要把技术应用到实际工作中，而不是单纯地指出某个技术的可行性。失去业务土壤的技术需求是无法带来真正价值的。业务需要需要能够从业务中挖掘，并在最后真正应用到业务中产生价值。举个反例，在我刚入职时实现过一个流程图工具，想法很单纯，用技术实现工具是个很酷的事。然而没有考虑过如何应用到业务中，最后半途而废。类似地，在入职1年多的时候，和同事开发了能够托管UI稿和prd稿的平台，但是我们无视了市面上已经有太多成熟好用的产品，最终也没能推动业务使用。一个比较好的技术需求应该怎么做呢：了解业务需要、使用技术赋能，然后保证实现落地。这三步中，使用技术赋能反而是最简单的一步。理解业务需要和推动业务使用是比想象中要困难的。

第二点叫做以人为本。这也是刚加入工作时可能注意不到的一点，入职前你可能以为你每天很浪漫地和代码泡在一起，和机器打交道。真正工作一段时间后，你会发现，每天至少50%的时间是在和人打交道的。人和机器是不一样的，机器是可靠的，可预期的，可以根据在学校里学习的知识推测的；而人是不可靠的，需要技巧，需要将心比心。这种不一样的思维方式会给可能过于理性的你带来麻烦。不然你会发现每天70%~80%的烦恼都是人而非机器带来的。

说几个例子，展开聊一下。先说代码，代码是写给人看，写给人理解的，然后才是交给机器去执行。看似你是在写代码，实际上你是通过代码在和未来的你或者接手你代码的人交流思路。所以代码的风格、可读性可能比你想象中要重要。一个糟糕的代码风格、可读性会让未来的你或者其他同事想要骂人，想要通过git blame找到这一坨shi一样的代码究竟是哪一个如此没品味的人写出来的。相反，一个好的风格、可读性会让未来的你和你的同事接手代码时心情愉悦，如清风拂面。类似地，可扩展性和设计良好与否也能起到上面的效果。可扩展性强和设计良好的代码可以极高地提高修改代码的愉悦程度和生产效率。

作为前端，界面的设计也一样重要。不要只是单纯地去实现PM或者UI的设计，可以站在终端用户的角度换位思考。如果是你遇到这种交互，它是否符合你的直觉，使用起来是否够简单，是否能达到目的。遇到有疑问的地方，随时可以找PM和UI讨论。

当然，这里说以人为本也不要矫枉过正。各位在日常工作中，还是以做事为主，公司内也还是看大家工作成果如何，而不是人际关系搞的如何。这里只是提个醒，希望大家在踏实努力的同时，也不要忘记了“人”这个角色的重要性。

总结上来看，就是上面这些，没别的了。各位既然来参加今天的培训，肯定也是从学校的环境刚进入工作环境没多久。上面这段分享听完之后，如果能对有些人有启示，能让大家意识到思维方式的不同，就达到我的目的了。

谢谢！