【导读】截止到目前，给甲方所做项目已接近尾声，在此写下一点个人关于技术方面的感受。若后续时间上允许或充裕的话，打算私下花一点时间分享封装可通用的组件

今年也是我首次带小伙伴，有刚毕业没什么技术经验，也有毕业不久技术很不错的小伙伴。

工作几年，感受颇多，在这个过程中，从每个人身上我都学习到了很多，这里一并写下，以下仅限于我个人看法。

???? 引导：说到带人，我想到更好的词应该是“引导”，而不是管教，管教是一种约束，反而禁锢了思维，导致小伙伴做事会束手束脚，通过引导让其发散思维。

???? 放“养”：在我所工作的公司中，不知道大家是否遇到过，无论底下小伙伴没有什么经验抑或是有经验的也好，上面的组长，有些并不太放心把这事交给底下的人去做，尤其是组长接的项目之前有相关经验，可能觉着，这事交给其他人不一定能做好，这样使得底下的小伙伴不仅很闲，关键是个人没有得到成长，同时最终将导致自己一个人加班加点很忙，而且越来越累。放心交给其他人去做，组长只需解决难点、跟进实时进度，把握交付节点就好。

???? 梳理：在理清需求，梳理业务时，有一部分人在这个过程中总会去想着我应该如何用代码去实现呢？个人认为，这是错误的想法，首先得把整个业务流程梳理清楚，然后再确认，最终只不过是用代码去落地罢了，能不能实现要么是技术经验，要么是方案选型，要么是结合现有项目情况可能无法落地需再次进行反馈等问题。技术只是实现业务的手段或工具，代码可扩展、可维护、可读性或者性能再好，但未能承载业务，毫无任何价值可言。个人以为，需求和代码占比7:3。

???? 沟通：尤其是跨部门合作，而且沟通对象在客户现场时，当和沟通对象在微信或钉钉等工具上讨论一个问题时发现并不是一两句就可以说的明白，何不通过一个电话去解决呢？减少沟通成本非常有必要，提高工作效率。

???? 冲突：当和小伙伴时发生冲突时，这里的冲突指的是对代码review上的冲突，此时一定要控制好个人情绪，别因嘴角而导致撕逼情况发生。作为技术人，摆代码，列举理由，大部分技术人都是实在人，千万注意言语和语气，看到不好或可以再改善的代码，不要动不动上来就是：这写的啥或怎么能这么写或你到底有没有理解业务或其他，完全否定他人成果也伤他人自尊，你要想到自己也不可能写出没有任何问题的代码，将心比心，何不先夸奖，然后再指出问题，这样别人从心理上也容易接受，谁不愿意听好听的话呢。

???? 专业：与甲方需要沟通的机会非常之多，尤其甲方和自己公司相关领导人都在群中时，发出的文字是否语句通顺，是否有错别字，自己通读一下，文字检查再三，要不然给甲方感觉这是马虎不专业，给自己公司相关领导人印象也不好。

???? 表达：每次通过聊天工具沟通前先想好要陈述什么问题，想想有些是否可采取列条陈列，要让对方知道你所表达的上下文，这和请求-响应机制一个道理，请求信息包罗万象，响应处理也复杂，可能结果还不是你所需要的。良好的表达是站在对方的角度去思考，要让对方能充分理解你的意思，而不是自己能看懂就足矣。

???? 危机：若有了带小伙伴的机会，需要跟进进度，解决痛点，每天也还要面对各种会议，个人敲代码时间少之又少，只能通过额外的加班来补偿，当然，这是个人本职工作，我想说的点是，个人私下学习的时间会明显减少，这个时候需要警惕，因为在技术上的成长速度将会放缓，并不利于长期发展。

而且，还有一种情况，若很多项目都由我们经手，很多同事都依赖于我们，针对这种情况，我们是否后期尝试通过文档输出，将自己从中解放出来呢？

丰子恺说过这么一句话：这不是无钱人的世界，这也不是有钱人的世界，这是有心人的世界。

善于发现、总结、反省才能走的更远，技术之路如此，人生之路亦是如此。